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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html