0

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?

0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.