"astreib" == Allan Streib <astreib@indiana.edu> writes:
astreib> Add my vote to keep it. We use it, heavily. We've found too
many astreib> clients either don't handle SASL or don't handle the GSSAPI
mechanism. astreib> Doing a simple bind over ssl/tls and providing a
kerberos password is astreib> a great alternative. We're not interested
in doing having passwords astreib> anywhere but in Kerberos.
Yes, I use SASL/GSSAPI for automatic identification of ldap users for
those who have logged in to unix, who are using command lines to
reference the directory. When that feature came around I thought it was
really slick.
However, I've always used, and continue to need,
userPassword: {kerberos}user@domain
binding for various reasons. e.g. across the web to the directory, that
authentication uses the ldap acl to show people different amounts of info
depending on whether they are a user or not.
I also used ldap for my primary authentication of web clients since
binding to ldap was so much more comprehensible to me than using kerberos.
If there is some way to influence ldap to use:
userPassword: {sasl, via kerberos}user@domain
which seems like it would remove the need for ldap to deal with kerberos
on its own, then that would be fine with me, but I don't know how to
accomplish that.