[Date Prev][Date Next] [Chronological] [Thread] [Top]

[Resolved!] Re: sasl_regexp: won't work with internal search URL



Okay... I'm feeling better now. sasl_regexp works just fine, it turns out. My trouble was all of my own making. The major issue was what Howard uncovered (thanks again!) where the sasl_regexp search URL was

     ldap:///ou=person,dc=enc,dc=edu??sub?(&(uid=$1)(objectclass=person))

and it should have been

     ldap:///ou=people,dc=enc,dc=edu??sub?(&(uid=$1)(objectclass=person))

And before I'd fixed this, somewhere along the way I'd changed the uid attribute of my test person entry to something else and had forgotten. ("He's as numb as a hake...")

:-)

And now... onward to saslauthd / pam_ldap!

Thanks to all for the help and commiseration,


Charles


Charles Owens wrote:

Howdy,

I've been able to successfully use sasl_regexp in its more basic form... directly mapping an authorization DN to a real entry DN. I'm coming up dry, however, when trying to have slapd search for the authententicating user's entry. This technique is documented in Admin Guide section 10.2.5. Is anyone out there using this technique in production? Are there any known gotchas with it?

So... here's the specifics. See the following ldif. This is the user as whom I'd like to authenticate

dn: ueid=XyZ123,ou=people,dc=enc,dc=edu
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: uniqueEntryObject
objectClass: uniquePerson
sn: Test
cn: Jim Test
ueid: XyZ123
givenName: Jim
uid: testj
# This second value was added to facilitate testing of DN mapping
uid: XyZ123
userPassword:: ***********


"ueid" is a custom attr from custom auxilliary objectclass uniqueEntryObject and it is being used as the naming attribute for person entries. Its value is a unique random string. Here I've artificially added a second "uid" value... set same as the "ueid" attrib, just so I could test the direct DN mapping usage of sasl_regexp. Speaking of which, the following works nicely:


 sasl-regexp
     uid=(.*),cn=plain,cn=auth
     ueid=$1,ou=people,dc=enc,dc=edu



This ldapsearch works exactly as it should:

   ldapsearch -b dc=enc,dc=edu -ZZ -U XyZ123 -Y plain ou=sys


Of course, this is not what I want, because I don't want the RDN value of person entries to have anything to do with the 'uid' attribute. Accordingly, I've tried this setting:


sasl-regexp
uid=(.*),cn=plain,cn=auth
ldap:///ou=person,dc=enc,dc=edu??sub?(&(uid=$1)(objectclass=person))



... with this search:

ldapsearch -b dc=enc,dc=edu -ZZ -U testj -Y plain ou=sys

SASL/PLAIN authentication started
Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-13): user not found: Password verification failed



I've picked up that anonymous binding and searching of the uid attribute is needed for this technique to work (yes?). I have very basic ACLs at the moment... just what came with the sample slapd.conf . I'm pretty sure they're not getting in the way:


access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
    by self write
    by users read
    by anonymous auth


Appended below is slapd debug output (level 37) produced by the failed ldapsearch. Things start to look weird to me around the calls to get_filter()... but that's just rampant speculation. Is this broken, or is my configuration wrong?



Thanks much,

Charles




-- ------------------------------------------------------------------------- Charles N. Owens Email: owensc@enc.edu http://www.enc.edu/~owensc Senior Technology Officer Information Technology Services Eastern Nazarene College -------------------------------------------------------------------------