openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

ACL and Password Policy
by Aleksander Dzierżanowski 26 Nov '13

26 Nov '13

Hi. I have OpenLDAP 2.4.36 server grabbed from LTB project. I’ve noticed two issues, can anyone confirm the same behavior? First - ACLs: to dn.base="" by users read to dn.subtree="ou=disabledaccounts,o=examples" by dn.base="cn=replicationmanager,o=example" read by * none to attrs=userPassword,shadowLastChange by dn.base="cn=replicationmanager,o=example" read by dn.base=„cn=radiussuperuser,o=example" read by anonymous auth by self write by * none [skipping few next less important rules] Above ACL should NOT show user’s own password, right? But it shows in my environment.. Second: PwdMinLength in password policy does not work. I can easily set shorter password. Password policy in general works, for example it does not allow me to change password earlier than ‚pwdMinAge’. Best regards, — Olo

5 7

Wtrlt: Re: Antw: Re: Q: "opjectClass: top" or not?
by Ulrich Windl 26 Nov '13

26 Nov '13

(forgot the copy to the list) I wrote: >>>>> Michael Ströder<michael(a)stroeder.com> schrieb am 22.11.2013 um 20:24 in >> Nachricht <528FAF5A.3050603(a)stroeder.com>: >>> Christian Kratzer wrote: >>>> very interesting point. >>>> >>>> I have a customer with an enterprise application that insists on having an >>>> explicit objectClass: top on all entries. >>>> >>>> Their developers argue that the rfcs mandate an explicit objectClass: top >> on >>>> all entries. I argue that the wording in the respective rfcs is not exact >>>> enough. Having an objectClass that inherits from top should be enough from >> >>> my >>>> point of view. >>>> >>>> I am currently travelling and cannot lookup the rfc. >>> >>> I vaguely remember having researched this as well many years ago. Don't >>> remember the details but I came up with the following recommendations: >>> >>> For client developers: Don't require object class 'top'. >>> >>> For LDAP admins: Add object class 'top' to all entries. >>> >>> Ciao, Michael. >> >> I wonder: If you query an object, you get a set of attributes. Whether you >> added "top" or not, the attributes are the same (except the "objectClass: >> top"). And ussually the attributes are not associated with a specific >> objectlass in the search result. >> >> If you try to "structure" the search results, then with "top", you'll find > the >> objectClass attribute at the "top" abstract class, while without "top" > you'll >> find it in the structural object class. >> >> I haven't found a document that describes "multiple inheritance" as it > happens >> with "top" (every objectclass inherits from top, but still the attributes > occur >> only once in the type hierarchy). >> >> Regards, >> Ulrich

1 0

Password Issues between provider and consumer
by Choure, Sidd 25 Nov '13

25 Nov '13

Everything is setup on RHEL 6.4 with Openldap 2.4. I have one provider and one consumer. StartTLS has been enabled and everything is working as intended. My only problem arises here - When a user is setup with a password and he tries to change his password on a consumer pointing client, I get a passwd: Authentication token manipulation error. This message is misleading since the password is in fact changed on the provider ( I have the olcUpdateRef directive setup). This creates a situation where the user can login to consumer pointed boxes with his old password and provider pointed boxes with his new password. If the user tries to change his password for the second time on consumer pointed boxes, I get Password change failed. Server message: unwilling to verify old password passwd: Authentication token manipulation error which understandably is because the password in the actual LDAP db is different from what is being supplied and being accepted by the client. What is going on here? Why isn’t the password not getting updated properly in the consumer? Here are some of the relevant snippets of configs - For Syncrepl in olcDatabase={2}bdb.ldif on consumer ###For Replication olcSyncrepl: rid=100 provider="ldap://server.com type=refreshAndPersist retry="60 30 300 +" searchbase=“dc=ex,dc=example,dc=com" bindmethod=simple binddn="cn=Manager,dc=ex,dc=example,dc=com" credentials=secret starttls=yes tls_cacert=/etc/pki/CA/cacert.pem tls_cert=/etc/pki/tls/certs/cert.pem tls_key=/etc/pki/tls/certs/key.pem olcUpdateRef: ldap://server.com ACL on provider - lcAccess: to attrs=userPassword by self write by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by anonymous auth by * none olcAccess: to * by self write by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by users read olcAccess: to attrs=entry by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write by * read Let me know if any more configs are needed and I will post them. Any help is appreciated. Siddharth Choure Senior Systems Engineer

3 7

DNS SRV with openldap
by Jignesh Patel 25 Nov '13

25 Nov '13

To setup DNS SRV record in LDAP, do we need to use some kind of DNS server i.e. bind or powerdns? Or by default LDAP supports it? Jignesh Patel Chief Architect iCare.com LLC 14001 NW 4th Street Sunrise, FL 33325 O: 954-616-5604 F: 954-616-5609 jignesh(a)icare.com CONFIDENTIALITY NOTE: The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender that you have received this communication in error and then delete it. Thank you.

4 4

Re: password hashes and simple binds
by Dieter Klünter 24 Nov '13

24 Nov '13

Am Sat, 23 Nov 2013 20:22:56 +0100 schrieb Aleksander Dzierżanowski <olo(a)e-lista.pl>: > Wiadomość napisana przez Dieter Klünter <dieter(a)dkluenter.de> w dniu > 23 lis 2013, o godz. 19:57: > > > Am Sat, 23 Nov 2013 13:24:56 +0100 > > schrieb Michael Ströder <michael(a)stroeder.com>: > > > >> Dieter Klünter wrote: > >>> Hi, > >>> I have a ldap server (2.4.36) with various password hashes > >>> {CLEARTEXT} {KERBEROS} {SSHA} for different users, there is no > >>> pasword-hash declaration in slapd.conf. Now i face a strange > >>> behaviour with {CLEARTEXT} hash. that is: > >>> userPassword: {CLEARTEXT} secret > >> ^^^ > >> I'd try to remove this extra space. Not sure though. > > > > Just to demonstrate the various hash scheme {CLEARTEXT} results: > > http://pastebin.de/37485 > > > > Well, AFAIK if there is no {METHOD} in userPassword attribute than > method is cleartext, so everything works as expected I suppose... — > Olo It is not that simple. RFC-2307 describes hashing schemes, but not {CLEARTEXT), man slapd.conf(5) mentions {CLEARTEXT} as password-hash. http://tools.ietf.org/id/draft-stroeder-hashed-userpassword-values-01.html only refers to hashed userpassword values. DIGEST-MD5 is a SASL mechanism which requires a cleartext password, thus a hashing scheme of {CLEARTEXT} is valid for a SASL mechanism. A simple bind requires a userpassword attribute value in cleartext, but doesn't require a hashing scheme. It would be quite helpful if OpenLDAP would accept a hash scheme for a simple bind. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

2 1

password hashes and simple binds
by Dieter Klünter 23 Nov '13

23 Nov '13

Hi, I have a ldap server (2.4.36) with various password hashes {CLEARTEXT} {KERBEROS} {SSHA} for different users, there is no pasword-hash declaration in slapd.conf. Now i face a strange behaviour with {CLEARTEXT} hash. that is: userPassword: {CLEARTEXT} secret A sasl bind with DIGEST-MD5 is succesful, but a simple bind returns error 49. If I remove the {CLEARTEXT} hint and only the secret remains, userPassword: secret all binds (sasl and simple) are successful. Any hints why this is happen? -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

3 4

proxy user
by Jignesh Patel 23 Nov '13

23 Nov '13

How to create a proxy user in LDAP and assign it to main user? Jignesh Patel Chief Architect iCare.com LLC 14001 NW 4th Street Sunrise, FL 33325 O: 954-616-5604 F: 954-616-5609 jignesh(a)icare.com CONFIDENTIALITY NOTE: The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender that you have received this communication in error and then delete it. Thank you.

2 1

creating proxy LDAP
by Jignesh Patel 23 Nov '13

23 Nov '13

We have a requirement to expose our LDAP to public domain. In that case I need to setup internal LDAP and a proxy LDAP, that is the way I see it. Any inputs on the design highly appreciated. We are using openldap with MDB. Jignesh Patel Chief Architect iCare.com LLC 14001 NW 4th Street Sunrise, FL 33325 O: 954-616-5604 F: 954-616-5609 jignesh(a)icare.com CONFIDENTIALITY NOTE: The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender that you have received this communication in error and then delete it. Thank you.

2 1

hide namingcontexts
by openldap＠downhomelinux.com 22 Nov '13

22 Nov '13

I am trying to lock down an openldap server (2.4.23). Using the FAQ I have limited the user entries with: {1)to attrs=userPassword by self =xw by anonymous auth {2)to * by users read However, I cannot figure out how to match the namingContexts attribute with olcaccess to also prevent unauthenticated users from listing the directories served. I have tried many variations of the following based on search results: to attrs=namingContexts by * none to dn.exact="" attrs=namingContexts by * none to dn.base="" attrs=namingContexts val/distinguishedNameMatch="dc=mydomain,dc=com" by * none Can anyone help? Thanks

3 3

Q: "opjectClass: top" or not?
by Ulrich Windl 22 Nov '13

22 Nov '13

Hi! Sorry, this is a somewhat generic question: I wonder what difference it makes whether I specify "objectClass: top" for an object, or not: Conceptually, "top" is included automatically (so the objectClass attribute goes to any structural class), but when I fetch an object, I never see the "top" objectClass. Explicitly specifying "objectClass: top" makes every object a few bytes larger. So is there any reason to explicitly specify "objectClass: top"? Regards, Ulrich

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical