John Dennis wrote:
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.
Yes.
The password attribute inserted into the config list during authorization is *never* PW_USER_PASSWORD,
No. For historical reasons, some modules put User-Password into the config, as the "known good" password.
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).
Yes, it should have been Cleartext-Password. It isn't, for reasons going back to 1996.
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".
Because that functionality belong in the PAP module. That way, there is *one* location for password mangling: rlm_pap. Otherwise, each database module would have to add the "auto_header" configuration itself.
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.
That's arguably a bug. But a bug in a feature that no one should use, and will be deleted in a future relase.
(Our LDAP gurus believe the interpretation of userPassword without a prefix is clear text).
Yes.
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.
Ideally, the userPassword field in LDAP should be mapped to the Password-With-Header attribute. All of the password mangling code in rlm_ldap should be *deleted*, as it's nonsense. The PAP module will then take the Password-With-Header attribute, and auto-magically create Cleartext-Password, MD5-Password, etc.
Or am I just missing something?
Historical practice.
It seems to be there are three bugs:
1) inserting PW_USER_PASSWORD into config instead of PW_CLEARTEXT_PASSWORD
That can't be changed, as many peoples configs depend on it.
2) not documenting auto_header
That is intentional. The code should be deleted.
3) if auto_header is enabled not defaulting to clear text if no prefix is supplied.
That's a bug, and likely will be "fixed" by simply deleting the offending code. Alan DeKok.