LDAP PAM client error “cannot find name for user ID”

ldapopenldappam-ldapsssd

I had ldap authentication working great last night, then today it doesn't seem to work. I can authenticate as a user, but the client can't seem to look up info about the user:

Example logging in as ldap user "ts121207":

$ su - ts121207
Password:
$ id -u
5003
$ whoami
whoami: cannot find name for user ID 5003

I'm able to bind as the user and make queries from the client without issue:

$ ldapsearch -h ldap.example.org -D cn=ts121207,ou=students,ou=users,dc=example,dc=org -b ou=students,ou=users,dc=example,dc=org -w secret '(uid=ts121207)' uid givenName sn
# extended LDIF
#
# LDAPv3
# base <ou=students,ou=users,dc=example,dc=org> with scope subtree
# filter: (uid=ts121207)
# requesting: uid givenName sn 
#

# ts121207, students, users, example.org
dn: cn=ts121207,ou=students,ou=users,dc=example,dc=org
uid: ts121207
givenName: Test
sn: Student

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

I've tried restarting sssd, as well as clearing out /var/lib/sss/db/*.

The interesting thing is when I look at the slapd logs on the ldap server, it doesn't seem to bind as the user when looking up info. This is what is logged as soon as I run whoami:

Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=0 BIND dn="" method=128                                                                                                                                                                                                             
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=0 RESULT tag=97 err=0 text=                                                                                                                                                                                                         
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=1 SRCH base="dc=example,dc=org" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=5003))"                                                                                                                             
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass                                                                                                                          
Nov 19 17:57:52 example.org slapd[14150]: conn=1332 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=

Shouldn't the client by binding as the user in order to perform that query so it can read the attributes? Or am I misinterpreting that log line?

Best Answer

I figured out the problem. I had set up the ldap client using the Ubuntu's ldap-auth-config package. One of the questions asks "Does the database require login?":

enter image description here

If you answer "No" to this, then the ldap client will bind anonymously (after authentication) in order to get user/group information. At first this seemed odd to me that just anyone can see user info, but then it occurred to me that this is analogous to how /etc/passwd and /etc/group work, which are world-readable.

My ACLs were preventing this, because I didn't want to allow anonymous connections to enumerate the users in my directory. So to fix this, I added a system user:

dn: cn=auth,ou=system,dc=example,dc=org
cn: auth
objectclass: organizationalRole
objectclass: top
objectclass: simpleSecurityObject
userpassword: {SHA}---redacted----=

Then I added the following ACLs:

#
# System user "auth" can access user/group attrs needed by pam / nss             
olcAccess: {4}to dn.subtree="ou=users,dc=example,dc=org"                        
    attrs=entry,uid,userPassword,uidNumber,gidNumber,cn,homeDirectory,loginShell,gecos,description,objectClass
    by dn.exact="cn=auth,ou=system,dc=example,dc=org" read                      
    by self read                                                                 
    by * search                                                                  
olcAccess: {5}to dn.subtree="ou=groups,dc=example,dc=org"                       
    attrs=entry,cn,gidNumber,memberUid,objectClass                               
    by dn.exact="cn=auth,ou=system,dc=example,dc=org" read
#                                                                                
# Allow users to read any data on their own entries                              
olcAccess: {6}to *                                                               
    by self read                                                                 
    by * search

Finally, I ran sudo dpkg-reconfigure ldap-auth-config, and when prompted for "Does the database require login?", I answered yes. At the question where it asks for the "Unprivileged user", I supplied the new system user I created:

enter image description here

Note that this still makes user accounts potentially enumerable by any user authenticated on the linux system, since that password is stored plaintext in /etc/ldap.conf, but that is no less secure than how /etc/passwd and /etc/group work.

Related Topic