Re: (ITS#5207) Password checking: external program

[hadmut@danisch.de]

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