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

Re: cmusaslsecretPLAIN attribute

Buchan Milne wrote:
But, SASL authentication does not use a DN, but a username (as provided in the example Dieter gave you above). And you would need to have configured slapd to map a SASL identity to a DN for the bind to succeed.
I have an authz-regexp that maps SASL's 'uid=burianj,cn=plain,cn=auth' to 'uid=burianj,ou=people,dc=cqcb', which is the DN in my LDAP database, which appears to be working, based on my logs.

Dieter Kluenter wrote:

Did you create the password using any hashing method? Or is it
The password is stored in LDAP as a {CRYPT}. I loaded the LDAP database using LDIF files created with the Migration Tools scripts (I don't know that those scripts are part of OpenLDAP, but they come packaged in Red Hat's OpenLDAP RPM). The users are stored as, at least, PosixAccount objects.

TechnoSophos wrote:
Since /etc/sasldb2 typically has strict permissions, this might be a
permissions problem... or maybe the file doesn't exist.
The Cyrus-SASL docs make it sound like SASL, when built into OpenLDAP, will make the appropriate LDAP calls to read the configured LDAP database (in my case, BDB). Does SASL/PLAIN authentication require some outside agent to work (either a separate sasldb, or to route auth requests through saslauthd)? I'd rather keep all my user information in LDAP, as opposed to maintaining separate databases.