All- I'm interested in what the state of Kerberos (external) password storage scheme is, as mentioned in the Admin Guide, section 14.4.7. We're currently using openldap 2.3.mumble (it's old) and will be upgrading to 2.4.21 or later soon, on RHEL 5.x. We don't currently do user or application authentication to our OpenLDAP. Because of the number of applications we're seeing that support "ldap authentication" but don't have any way to do true or even fake Kerberos V authentication, I've been asked to determine what would be involved in allowing ldap authentication, but having slapd use our MIT krb5 infrastructure behind the scenes. Section 14.4.7 of the admin guide seems to indicate that OpenLDAP can already do exactly what we need, but no additional details are provided. Searching the openldap-software archives, Kurt Zeilenga provides a bit more info on how I might go about configuring this here: http://www.openldap.org/lists/openldap-software/200010/msg00462.html grep'ing the source for '{KERBEROS}', the only place that shows up is in contrib/slapd-modules/passwd/kerberos.c. Can anyone shed any more light on what state this is in? Kurt's 9 year old post and the current admin guide seem to imply that using an external kerberos password store for userPasswords is a standard part of OpenLDAP, but the source seems to imply otherwise. If the {KERBEROS}princ@REALM method works and isn't completely deprecated I would choose that route, otherwise I suppose I'll have to investigate SASL as described in section 14.4.6 and 14.5 of the admin guide. I understand the warning at the end of the section in the admin guide, that using a krb5 KDC as a fancy network-based password checking database is not Kerberos at all, and that if we go this route we'll want to make certain that at a minimum binds are done over TLS. Thanks, Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164