[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: kpasswd



>>>>> "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.