On 21/7/2011 10:23 μμ, Dan White wrote:
A simpler approach, and one that works with non-SASL binds, would be to
configure pass-through authentication and perform saslauthd/kerberos5
authentication. As users change their passwords (against your kerberos
server, via some unspecified process), you could replace their
userPassword
entries with {SASL}user@realm (as described in the Admin guide) and do
away
with hashed password entries altogether.
If I follow this model, according to the documentation:
"Where an entry has a "{SASL}" password value, OpenLDAP delegates
the whole process of validating that entry's password to Cyrus SASL."
Supposing that we configure SASL to use Kerberos5 authentication, will
our current standard applications (Postfix, Dovecot, Shibboleth, Apache
etc.) need to be configured to include GSSAPI SASL method?
As an example, Postfix uses Dovecot SASL to authenticate clients (PLAIN
method), and is configured to check their identity/password against LDAP
(User+Password - No SSL here because it's running on the local box). I
guess Postfix will need to include GSSAPI to SASL methods ?
In effect: Authentication for a user (hosted in LDAP) will fail in an
application which (uses LDAP for user/password backend and) is not
SASL-enabled or it is SASL-enabled but does not include/support the
GSSAPI method, if the user has a "{SASL}user@realm" userPassword
attribute value?
Thanks,
Nick
