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