On Friday, 4 June 2010 23:50:26 Jo Rhett wrote:
I'm seeing a problem where I can authenticate as a user using the ldap tools (ie ldapsearch) but I am unable to login using PAM.
Comparing debug on the server shows that ldapsearch is doing a new BIND, where's PAM is not:
Jun 4 14:58:52 ldap-server slapd[5158]: => dn: [1] Jun 4 14:58:52 ldap-server slapd[5158]: => acl_get: [2] attr userPassword Jun 4 14:58:52 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 14:58:52 ldap-server slapd[5158]: => acl_mask: access to entry "uid=jrhett,ou=Users,dc=equinix,dc=com", attr "userPassword" requested Jun 4 14:58:52 ldap-server slapd[5158]: => acl_mask: to value by "", (=0) Jun 4 14:58:52 ldap-server slapd[5158]: <= check a_dn_pat: anonymous Jun 4 14:58:52 ldap-server slapd[5158]: <= acl_mask: [1] applying auth(=xd) (stop) Jun 4 14:58:52 ldap-server slapd[5158]: <= acl_mask: [1] mask: auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: => access_allowed: auth access granted by auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: conn=75 op=2 p=3 Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: err=49 matched="" text="" Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_response: msgid=3 tag=97 err=49 Jun 4 14:58:52 ldap-server slapd[5158]: conn=75 op=2 RESULT tag=97 err=49 text=
Now ldapsearch has identical debug output down until just below the access_allowed line.
Jun 4 15:02:54 ldap-server slapd[5158]: => acl_get: [2] attr userPassword Jun 4 15:02:54 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 15:02:54 ldap-server slapd[5158]: => acl_mask: access to entry "uid=jrhett,ou=Users,dc=equinix,dc=com", attr "userPassword" requested Jun 4 15:02:54 ldap-server slapd[5158]: => acl_mask: to value by "", (=0) Jun 4 15:02:54 ldap-server slapd[5158]: <= check a_dn_pat: anonymous Jun 4 15:02:54 ldap-server slapd[5158]: <= acl_mask: [1] applying auth(=xd) (stop) Jun 4 15:02:54 ldap-server slapd[5158]: <= acl_mask: [1] mask: auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: => access_allowed: auth access granted by auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 BIND dn="uid=jrhett,ou=Users,dc=equinix,dc=com" mech=SIMPLE ssf=0 Jun 4 15:02:54 ldap-server slapd[5158]: do_bind: v3 bind: "uid=jrhett,ou=Users,dc=equinix,dc=com" to "uid=jrhett,ou=Users,dc=equinix,dc=com" Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: conn=83 op=0 p=3 Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: err=0 matched="" text="" Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_response: msgid=1 tag=97 err=0 Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 RESULT tag=97 err=0 text= Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on 1 descriptor Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on:
Can someone give me a clue what's going wrong here?
err=49 is invalid credentials, thus one or more of: 1)Wrong DN 2)Wrong password 3)ACLs don't allow simple auth
Your successful authentication with the same DN with ldapsearch rules out (1) and (also indicated in the acl logging for the pam_ldap case) (3).
That leaves on more cause ...
The key to this problem is that I'm trying to avoid putting system logins, rootbinddns on each server, and just do anonymous bind's for authentication.
Well, it needn't be "rootbinddns", in the sense that you should be just as happy to lose a binddn or rootbinddn as with providing anonymous access (these users should be least-privilege, only with access to similar data you are already exposing to all users who would have access to the credentials - via 'getent passwd'), but you could consider using Kerberos keytab's or certificates, or per-host credentials.
Either way, I have used anonymous for nss_ldap/pam_ldap before, without problems.
No configuration file on this client has a valid Manager or any other authentication password, and I'm trying to keep it that way. In theory, this should work ;-) I mean, ldapsearch works fine ...
Sure, but are you sure ldapsearch and pam_ldap are using the same password? If you *think* so, maybe you should check with a packet capture ...
Regards, Buchan