Hi all, I'm new to LDAP and want to use nss_ldap (version 253) against a centos directory server (version 8.1.0) running on the same host. The great mystery is, that as root everything works find, but as any other local user, it does not: root$ getent passwd [...] ldap:x:55:55:LDAP User:/var/lib/ldap:/bin/false ns:*:4000:4000:Nicolai Stange:/home/ns:/bin/bash root$ su some_local_user - some_local_user$ getent passwd [...] ldap:x:55:55:LDAP User:/var/lib/ldap:/bin/false some_local_user$
It just hangs for a while after printing the local user 'ldap' on the screen and then exits without displaying the ldap-user 'ns'. Instead /var/log/dirsrv/slapd-ldap/access the following lines appear: [20/Jul/2010:21:48:38 +0200] conn=14 fd=65 slot=65 SSL connection from 192.168.1.2 to 192.168.1.2. [20/Jul/2010:21:48:38 +0200] conn=14 op=-1 fd=65 closed - Encountered end of file.
The only entries in my /etc/ldap.conf are those: tls_cacertfile /etc/nss/ca.example.org-cert.pem tls_cert /etc/nss/nss-cert.pem tls_key /etc/nss/nss-key.pem
The nss-{key,cert}.pem may be used to bind at the following DN: dn: cn=nss,ou=Special Users,dc=example,dc=org objectClass: top objectClass: person cn: nss sn: nss
Again: It works for user root! $ ls -l /etc/ldap.conf /etc/nss/ -rw-r--r-- 1 root root 9186 Jul 20 22:05 /etc/ldap.conf
/etc/nss/: total 12 -rw------- 1 root root 1261 Jul 19 23:16 ca.example.org-cert.pem -rw------- 1 root root 1289 Jul 19 23:16 nss-cert.pem -r-------- 1 root root 1821 Jul 19 23:16 nss-key.pem $
Setting ownerships to world readable, e.g. $ ls -l /etc/ldap.conf /etc/nss/ -rw-r--r-- 1 root root 9186 Jul 20 22:05 /etc/ldap.conf
/etc/nss/: total 12 -rw-r--r-- 1 root root 1261 Jul 19 23:16 ca.example.org-cert.pem -rw-r--r-- 1 root root 1289 Jul 19 23:16 nss-cert.pem -r--r--r-- 1 root root 1821 Jul 19 23:16 nss-key.pem $ doesn't change anything.
Just for completeness the entry for the ldap-user 'ns': dn: uid=ns,ou=People,dc=example,dc=org objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: organizationalPerson objectClass: person cn: Nicolai Stange displayName: Nicolai Stange sn: Stange givenName: Nicolai initials: NS uid: ns mail: nicolai.stange@example.org preferredLanguage: de, en;q=0.8 homeDirectory: /home/ns uidNumber: 4000 gidNumber: 4000 loginShell: /bin/bash userPassword: {SSHA}some_ssha_encrypted_pw
I would really appreciate your help, I have no clue what the reason for this could be...
Wishes
Nicolai
On 07/20/2010 02:11 PM, Nicolai Stange wrote:
The only entries in my /etc/ldap.conf are those: tls_cacertfile /etc/nss/ca.example.org-cert.pem tls_cert /etc/nss/nss-cert.pem tls_key /etc/nss/nss-key.pem
I don't think that can possibly be true. If you don't have a uri specified, you won't get any results. I just tested that on a system which is running a directory server.
Try this: $ grep '^[^#]' /etc/ldap.conf
I get:
base dc=private,dc=dragonsdawn,dc=net timelimit 120 bind_timelimit 120 idle_timelimit 3600 nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm,polkituser,rtkit,pulse uri ldap://directory.private.dragonsdawn.net/ ssl no tls_cacertdir /etc/openldap/cacerts pam_password md5
The nss-{key,cert}.pem may be used to bind at the following DN: dn: cn=nss,ou=Special Users,dc=example,dc=org
I don't think that makes any difference unless you specify binddn in /etc/ldap.conf
Setting ownerships to world readable, e.g.
...
doesn't change anything.
What about the permission on the directory /etc/nss?
All of those items must be readable by all users. The only file which can be restricted is an optional file referenced by rootbinddn in /etc/ldap.conf which is typically used if you require specific credentials to change passwords. If you use this file, non-root users still need valid credentials to bind and search the directory read-only.
You might be able to avoid giving users any access if you use sssd and nss_sss, but that's an unusual configuration.
The key to solving this problem is that all users of your system must have read access to all of the information that they require to bind and search in your directory server.
-
Gordon Messmer -
Nicolai Stange