Password Storage Methods
If the userPassword field is returned from LDAP to FreeRADIUS, that
information can be stored in a number of different formats:
-
The value can be cleartext.
-
The value can be prepended with a string enclosed by braces, such as with
{crypt}or{ssha3}. -
the value can be have a suffix of
::, in which case the password is generally a base64 encoded version of the real password.
|
Base64 values can be decoded via the command: |
FreeRADIUS understands and parses all of the above
formats. There is sufficient information in the password values to
determine what format it is in (base64, binary, or text), and what
password "encryption" mechanism has been used (crypt, MD5, SHA, SSHA2,
SHA3, etc). All that is necessary is that the
ldap module be configured to map
the userPassword LDAP field to the control.Password.With-Header
attribute in FreeRADIUS. FreeRADIUS will then "do the right thing" to
authenticate the user.
This mapping is done in the default module configuration. There are
no additional changes required for FreeRADIUS to correctly read and
decode the userPassword field from LDAP. Please see the
pap module for a full list of
supported password "encryption" formats.
Additional considerations
There are some major caveats with the above authentication methods. The first is that we strongly recommend against using "bind as user". This process is slow, and causes unnecessary churn in the connections used to contact the LDAP server. Further, the "bind as user" process works only when a `User-Password attribute exists in the request. If any other authentication type is used in the request, then the "bind as user" will not work. There is no amount of "fixing" things or configuration changes which will make it work.
The second caveat is that the CHAP authentication type works only
when a "clear text" password is stored in the LDAP database. The
CHAP calculations are designed around having access to the "clear
text" password. It is impossible to use any "encrypted" or "hashed"
passwords with CHAP.
The third caveat is that the MS-CHAP authentication type works
only when a "clear text" password or "NT hashed" passwords which are
stored in the LDAP database. The MS-CHAP calculations are designed
around having access to "known good" passwords in those formats. It
is impossible to use any other kind of "encrypted" or "hashed"
passwords with MS-CHAP.
The final caveat is that when the LDAP database contains "encrypted"
or "hashed" passwords, the only authentication type which is
compatible with those passwords is PAP. i.e. when the User-Password
is supplied to FreeRADIUS.
For recommendations on password storage methods in LDAP, please see the LDAP password storage page. Please note that the recommendations there are made for LDAP security, and pay no attention to the caveats described above. When both RADIUS and LDAP are used together, then the requirements of both systems must be met in order for them to work together. In many cases, a naive approach to LDAP security will prevent RADIUS from working.
For an in-depth description as to why are making these recommendations, see the InkBridge article on PAP vs CHAP
We pretty much always recommend using PAP. Despite various claims by people online, passwords are never sent "in the clear" in any RADIUS packet. If anyone tells you that RADIUS sends passwords "in the clear", then they do not understand RADIUS, and they are not a security expert.
So the passwords are protected "on the wire", and the only entity which sees a clear-text password is the RADIUS server. When the passwords are "at rest" in the database, they are encrypted / salted, and secure.
The very short version of why we recommend PAP is simple: The odds of someone breaking into your RADIUS server and stealing a few passwords are much, much lower than the odds of someone breaking into your database, and stealing all of the passwords.