bug in rlm_ldap authorization password handling?

[Alan DeKok]

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.