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 <jden...@redhat.com>
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
