RSS feed

Re: Setting up authentication on a non-public LDAP directory

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: Setting up authentication on a non-public LDAP directory


In case someone else falls into this, I have found a workaround. I am not completely happy with it, but it does disable some anonymous requests to the LDAP directory.

I changed my faulty LDAP ACL :

before :

to *
by dn.base="cn=admin,dc=test,dc=net" write
by dn.base="cn=reader,dc=test,dc=net" read
by anonymous auth  *
by * none

after :

to *  by dn.base="cn=admin,dc=massidia,dc=net" write
by dn.base ="cn=reader,dc=massidia,dc=net" read
by self write
by anonymous auth
by users read
by * none

I don't know if it's because of the order in which ACL are resolved (this one is the last), or because of the way pam binds when authenticating, but it now works as expected. Except from the fact that users can now read/write all the directory of course, which still isn't resolved.


Le 01/06/2011 15:16, Mathias a écrit :

I had a working setup on Debian Lenny (with lib-pam-nss-ldap) and I'm having troubles reproducing it on Squeeze (with lib-pam-nss-ldapd + nslcd). I am not at all an expert on LDAP, PAM, NSS, so please excuse me if my indications are not useful and I will make my best to provide information.

Some context and objectives :
- an openLDAP server, directory has a a nix schema for authenticating unix users over LDAP - the directory is not readable by everyone (we don't want anonymous to be able to list users for instance), there is a special "reader" account used as binddn for reading operations.

Since upgrade to squeeze/ldapd/nslcd, several problems have appeared :
- first, LDAP authentication did not work anymore. Neither directly during ssh, neither with "su test", and no LDAP users appeared on a "getent passwd". In syslog, I had errors lines like "unknown user test". I noticed that nslcd was binding with an empty dn. It seemed to me as a normal behaviour since anonymous is allowed to auth by LDAP's ACL. However I got errors like "50 : insufficient rights" whenever nslcd tried to do something. I managed to go past that error by adding the "reader" binddn and bindpw to libnss_ldap.conf, pam_ldap.conf and nslcd.conf. I don't think it's supposed to be there, but I first wanted to make things work.

- from there, I could do a "su test" as root successfully, and all LDAP users appear with "getent passwd". However I still couldn't login directly with ssh, nor could I do a successful "su test" using an other account than root. the relevant syslog errors were : slapd: conn=1005 op=0 BIND dn="uid=test,dc=users,dc=test,dc=net" method=128 slapd: conn=1005 op=0 BIND dn="uid=test,dc=users,dc=test,dc=net" mech=SIMPLE ssf=0
slapd: conn=1005 op=0 RESULT tag=97 err=0 text=
slapd: conn=1005 op=1 SRCH base="uid=test,dc=users,dc=test,dc=net" scope=0 deref=0 filter="(objectClass=posixAccount)"
slapd: conn=1005 op=1 SRCH attr=uid
slapd: conn=1005 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
nslcd: ldap_result() failed: No such object"
nslcd: lookup of user uid=test,dc=users,dc=test,dc=net failed: No such object"

- to narrow the problem, I removed from LDAP's ACLs the "* by none" restriction on the database. I can now login using any method. Only weird thing I still see is that a "ldapwhoami -x" returns anonymous when logged in with an LDAP user. However the current situation is not my expected behaviour, since the directory is readable by anyone.

I did a bunch of other tests including various ldapsearch queries, ldapwhoami, launching daemons in debug mode, etc. I'm not including them because it might confuse my message, but I'm of course willing to rerun any tests you see necessary.

What I really don't understand is why everything worked fine on Lenny/ldap and is now broken on Squeeze/ldapd. I have no clue on necessary changes. Maybe just explaining to me how such a setup is supposed to work might be enough for me to fix it.

Here are some configuration files that may be helpful :

- cn=config,olcdatabase={1}bdb (the directory) :

dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcSuffix: dc=test,dc=net
# authentication ACL
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn.base="cn=admin,dc=test,dc=net" write by anonymous auth by self write by * none
# Base is readable
olcAccess: {1}to dn.base=""  by * read
# address books ACL
olcAccess: {2}to dn.regex="^(.+,)?ou=ab,uid=([^,]+),dc=users,dc=test,dc=net$" by dn.base,expand="uid=$2,dc=users,dc=test,dc=net" write by * none
# commented for testing purposes
# olcAccess: {3}to * by dn.base="cn=admin,dc=test,dc=net" write by dn.base="cn=reader,dc=test,dc=net" read by anonymous auth by * none
# added for testing purposes
olcAccess: {3}to *  by dn.base="cn=admin,dc=test,dc=net" write  by * read
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=admin,dc=test,dc=net
olcRootPW:: someencryptedhash
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 1000
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: e88608d6-1fda-1030-90bf-e761c62b8d22
creatorsName: cn=config
createTimestamp: 20110531140622Z
entryCSN: 20110531140622.151557Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20110531140622Z

- a part of pam_ldap.conf (libnss-ldap.conf has exactly the same info, and nslcd.conf has a subset of it)

base dc=massidia,dc=net
binddn cn=reader,dc=test,dc=net
bindpw somepassword
rootbinddn cn=admin,dc=test,dc=net
nss_base_passwd dc=users,dc=test,dc=net
nss_base_shadow dc=users,dc=test,dc=net
nss_base_group dc=groups,dc=test,dc=net

- pam.d/common-auth (just to get the idea, I do not include common-password, common-account, etc., please ask if needed)

auth    sufficient
auth    required     nullok_secure try_first_pass

Thank you,

To unsubscribe send an email to or see