I'm a little confused by how rlm_ldap is handing passwords. First let me state what I believe to be true, if I'm wrong on any of these assumptions please correct me. Authentication modules need access to either the cleartext password or hashed password, it is the role of the authorization modules to insert the password information into the *config* list of the request. The authentication modules will extract the password information from the config list during the authentication phase. The password attribute inserted into the config list during authorization is *never* PW_USER_PASSWORD, because this is the attribute supplied by the client in the request. Rather the authorization modules *may* insert into the *config* list one of (PW_CLEARTEXT_PASSWORD, PW_MD5_PASSWORD, PW_SMD5_PASSWORD, PW_CRYPT_PASSWORD, PW_SHA_PASSWORD, PW_NT_PASSWORD, etc.) These will then be used by the authentication modules. rlm_mschap needs the ntlm hash (PW_NT_PASSWORD), if that is not in the config list then it computes it from the cleartext password (PW_CLEARTEXT_PASSWORD) found in the config list. Is the above correct? If so then it seems to me rlm_ldap is doing something wrong in it's authorization routine. rlm_authorize() searches for the password attribute which may be multi-valued (typically the attribute name is userPassword from the posix objectclass) If found it adds PW_USER_PASSWORD to the config list, but PW_USER_PASSWORD does not belong in the config list, it's a request attribute, it should have been PW_CLEARTEXT_PASSWORD (with a caveat which follows). Here's the caveat, it's possible to indicate the password hash type by prepending {type} to the password string where type is typically one of (clear, crypt, md5, sha, nt, etc). This behavior is turned on by the auto_header configuration variable in raddb/modules/ldap, which for some reason is undocumented in raddb/modules/ldap, Why? FWIW, auto_header defaults to "no". However if auto_header is enabled then guess what? The attribute added to the config is one of the correct password attributes (e.g. PW_CLEARTEXT_PASSWORD, PW_NT_PASSWORD, etc.) But if and only if the password value returned is prepended with {type}, if it isn't prepended then it skips the password attribute rather than using the *default* of PW_CLEARTEXT_PASSWORD. (Our LDAP gurus believe the interpretation of userPassword without a prefix is clear text). So ... It seems as if you're storing a clear text password without a prefix in the userPassword attribute (or whatever attribute rlm_ldap is configured for) you'll never update the config list wtih PW_CLEARTEXT_PASSWORD in authorize and the subsequent authentication modules may fail as a consequence if they are depending on having access to the clear text password. Or am I just missing something? It seems to be there are three bugs: 1) inserting PW_USER_PASSWORD into config instead of PW_CLEARTEXT_PASSWORD 2) not documenting auto_header 3) if auto_header is enabled not defaulting to clear text if no prefix is supplied. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/