bug in rlm_ldap authorization password handling?
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/
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.
They are, sort of, correct.
Or am I just missing something?
You are looking at rlm_ldap in isolation. rlm_pap will "handle" these "bugs".
It seems to be there are three bugs:
1) inserting PW_USER_PASSWORD into config instead of PW_CLEARTEXT_PASSWORD
That will happen in rlm_pap (which should always be listed in authorize).
2) not documenting auto_header
It's documented in rlm_pap. You are supposed to use that setting, not the one in rlm_ldap (I think that one is there for historical reasons).
3) if auto_header is enabled not defaulting to clear text if no prefix is supplied.
Again, that will happen in rlm_pap. I believe that things are done this way in rlm_ldap because that code is from the time when User-Password was used as password configuration attribute. I am sure Alan will have a good explanation why is rlm_ldap left creating the User-Password attribute on the control list which then rlm_pap converts into appropriate password attribute. My guess is to avoid code duplication. Ivan Kalik Kalik Informatika ISP
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.
participants (3)
-
Alan DeKok -
John Dennis -
tnt＠kalik.net