On 21/7/2011 10:23 μμ, Dan White wrote:
It's unclear from your original post if your are using SASL binds -
you said you are doing "PLAIN auth over TLS/SSL".
No, I am not using SASL on LDAP. I mistakenly used the term "PLAIN"
(which implies SASL). In fact I am using the "simple" method (usually
noted: SSL + User + Password).
If you are using SASL binds, or can force SASL binds, then you could
use the
autotransition feature of Cyrus SASL...
...
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.
Thank you for the detailed info; both approaches seem interesting and
I'll have to investigate further (it will take some time I am afraid).
If I understand it correctly, the second approach seems more attractive
to me. Running Kerberos with LDAP backend still stores passwords in the
DIT so we can still have a single data store. Additionally, it provides
a smooth transition as users can:
1. Continue to use their hashed passwords until they change them (and
automatically migrate to the pass-through scheme).
2. Continue to use simple (non-SASL) binds directly to LDAP Server.
3. Use kerberos authentication directly (using Kerberos LDAP backend
transparently).
Thanks again,
Nick
