bug in rlm_ldap authorization password handling?

[John Dennis]

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 at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/