KERBEROS has not been a valid password scheme since 2004...

Actually, slapd has supported sasl_setpass for many years...

diff --git a/doc/guide/admin/security.sdf b/doc/guide/admin/security.sdf
index 718a5582400ff23a419616c8e1d10caafc036341..4b045f5f402ee7b3ec5e0af1d2c34b7375aaaf86 100644 (file)
--- a/doc/guide/admin/security.sdf
+++ b/doc/guide/admin/security.sdf
@@ -274,19 +274,6 @@ verification to another process. See below for more information.
 Note: This is not the same as using SASL to authenticate the LDAP
 session.
 
-H3: KERBEROS password storage scheme
-
-This is not really a password storage scheme at all. It uses the
-value of the {{userPassword}} attribute to delegate password
-verification to Kerberos. 
-
-Note: This is not the same as using Kerberos authentication of 
-the LDAP session.
-
-This scheme could be said to defeat the advantages of Kerberos by 
-causing the Kerberos password to be exposed to the {{slapd}} server 
-(and possibly on the network as well).
-
 H2: Pass-Through authentication
 
 Since OpenLDAP 2.0 {{slapd}} has had the ability to delegate password
@@ -316,9 +303,6 @@ mechanism and are used to identify the account whose password is to be
 verified. This allows arbitrary mapping between entries in OpenLDAP
 and accounts known to the backend authentication service.
 
-Note: There is no support for changing passwords in the backend
-via {{slapd}}.
-
 It would be wise to use access control to prevent users from changing 
 their passwords through LDAP where they have pass-through authentication 
 enabled.