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
xhttps://github.com/FreeRADIUS/freeradius-server/blob/v3.2.x/raddb/mods-available/ldap[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.
The issue of a database storing passwords in clear-text has to be balanced against the users sending clear-text passwords in authentication protocols. While those passwords are protected by TLS (EAP-TTLS) or by RADIUS (in it’s own "encryption" mechanism), it is generally better to use a stronger authentication method than just PAP.
In the end, there is no perfect solution to security requirements. The choice may be either to give up on using a particular authentication method, or to relax the security requirements on LDAP and on password storage. The final decision as to which choice is best can only be made by a local administrator.