Home / server / Questions / 112286
Accepted
Cooper
Asked: 2010-02-13 07:19:11 +0800 CST

Securing userPassword access with OpenLDAP in RHEL

  • 772

I have set up an OpenLDAP server on RHEL 5.4, and am configuring other servers to authenticate against it. I have both ldap with StartTLS and ldaps configured and working.

On my client machines, my /etc/nsswitch.conf includes:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

I can successfully log in to a client with a user that is only defined in LDAP (i.e. its not finding it in /etc/passwd, and is successfully asking LDAP for user info, and authenticating against the password hash stored in LDAP).

My problem is when I try to lock down access to attributes in the LDAP server, specifically, in /etc/openldap/slapd.conf, ldap users can no longer log in:

access to attrs=userpassword
        by self write
        by anonymous auth
        by * none

I'm logging slapd, and it appears (my interpretation, correct me if I'm wrong) that pam_ldap is attempting to read all the attributes in the poxixAccount objectClass:

    filter: (&(objectClass=posixAccount)(uid=cthompson))
    attrs:
  uid
  userPassword
  uidNumber
  gidNumber
  cn
  homeDirectory
  loginShell
  gecos
  description
  objectClass

In my openldap logging, I get no access or acl errors, but I do get:

access_allowed: search access to "uid=cthompson,ou=People,dc=domain,dc=com" "objectClass" requested
access_allowed: search access to "uid=cthompson,ou=People,dc=domain,dc=com" "uid" requested

Is there something that needs to be configured so instead of reading the userPassword attribute, pam_ldap tries to "auth" against it (so the requests gets handled by the "by anonymous auth" access rule?

ldap openldap pam

1 Answers

  1. Best Answer

    pam_ldap shouldn't be attempting to read the userPassword value to log you in -- It logs you in by doing an LDAP bind with the DN that it retrieves.

    It's possible the search parameters pam_ldap uses are over-broad & it tries to pull userPassword as a result, but if your ACL is set up correctly (looks fine to me) it won't get that value in its results.

    Just in case your ACLs aren't fine (I've been known to miss stupidly obvious stuff before), here's the working ACL list from my production LDAP environment :)

    # Access and Security Restrictions
# (Most restrictive entries first)
access to attrs=userPassword
    by self write
    by dn.sub="ou=sync,dc=mydomain,dc=com" read
    by anonymous auth
by users none

access to * by * read

    The trailing access to * by * read is important, I didn't see it in your examples so I'm not sure if it's missing or just omitted from your snippet.

    The sync line is for my LDAP synchronization service and isn't necessary if you're not doing replication...

    • 2