Please be aware the FreeRADIUS is an AAA server, and LDAP is a database. This separation of roles means that FreeRADIUS supports multiple kinds of authentication protocols such as PAP, CHAP, MS-CHAP, etc. An LDAP database supports only one authentication method: "bind as user". This authentication method is compatible only with PAP.

Our recommendation is to use LDAP as a database. FreeRADIUS should read the "known good" password from LDAP, and then use that information to authenticate the user. It is almost always wrong to use the LDAP "bind as user" method for authenticating users.

The only caveat to the above recommendation is Active Directory. For "security" reasons, Active Directory will not return the "known good" password to FreeRADIUS over a standard LDAP query. Therefore when Active Directory is used, the choices are:

Due to the limitations of Active Directory, There are unfortunately no other possible choices.

The credentials (username and password) for FreeRADIUS to use to connect to your LDAP server(s) should be secure. We make the following recommendations for LDAP "best practices" security.

The LDAP module is compatible a few different kinds of authentication methods. Note that we say compatible, and not supports. LDAP servers are databases, and do not support authentication protocols such as CHAP, MS-CHAP, or EAP.

All of above authentication methods other than "bind as user" require that FreeRADIUS obtain the userPassword field from LDAP. If that field is not returned to FreeRADIUS, then normal authentication is impossible. Either FreeRADIUS has to be configured to use "bind as user" for authentication, or the LDAP database has to be updated to return the userPassword field to FreeRADIUS. This change usually involves giving the FreeRADIUS "read-only" user permission to read the userPassword field.

Again, the best method is to test authentication is with the ldapsearch tool. These tests must be run prior to configuring FreeRADIUS. We strongly recommend having the LDAP database return the userPassword field to FreeRADIUS, so that FreeRADIUS can authenticate the user.

We also strongly recommend that the passwords be stored in LDAP as cleartext. Otherwise, the only authentication methods that will work are PAP and EAP-TTLS/PAP. The next section explains these issues in more detail.

If the userPassword field is returned from LDAP to FreeRADIUS, that information can be stored in a number of different formats:

FreeRADIUS is capable of understanding and parsing 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.

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.

You can integrate Novell eDirectoryTM 8.7.1 or later with FreeRADIUS 1.0.2 onwards to allow wireless authentication for eDirectory users. By integrating eDirectory with FreeRADIUS, you can do the following:

For configuration information please refer to the Novell documentation https://www.netiq.com/documentation/edir_radius/