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

[Charles Owens <owensc@enc.edu>]

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
-------------------------------------------------------------------------