Buchan Milne wrote:

So you are unaware of the {SASL} scheme for userPassword, where slapd receives a simple bind, and tries to authenticate the user (as a SASL client) via the SASL mechanism with the identity following the scheme identifier in the userPassword attribute.

Oh, yeah, I wasn't aware of such a beast.

It is documented to some degree in the FAQ-o-matic.

Well, I didn't find a documentation about that, just an article about Kerberos that mentioned that {SASL} thing. FAQ-o-matic seems to be unable to search for '{' and '}'.

Putting something in that FAQ-o-matic is certainly a good place to hide it since that FAQ-o-matic uses some really weird sort of ordering, and searching works - if at all - only if you already know what you are looking for. Would be great to put this into the administrator's documentation.

However, if that {SASL} scheme does what I believe it does, the client indeed does not need a plugin or SASL support anymore.

But this opens other questions:

Does slapd support multiple password entries?

If I put such a {SASL} thing into my LDAP record, would I still be able to authenticate with a plain password, e.g. by having two entries

userPassword: {SSHA}... userPassword: {SASL}...

The main problem is that I have to provide several authentication schemes, including good old password authentication (which the SASL daemon was configured to do against the LDAP with encrypted passwords) and some sorts of one time passwords. Storing regular passwords in SASL was no option because cyrus sasl stores passwords as plaintext.

So that {SASL} thing could solve my problem as long as it coexists with regular LDAP authentication.

What does slap (and slappasswd) do if there are multiple entries for userPassword? Does slapd check them all until one of them matches?

regards Hadmut