Re: pam_ldap doesn't bind SIMPLE for anonymous auth?

[Buchan Milne <bgmilne@staff.telkomsa.net>]

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