Authentication with LDAP
The FreeRADIUS is an AAA server, and LDAP servers function primarily as a database that stores user credentials and related information. FreeRADIUS handles the authentication protocols such as PAP, CHAP, or MS-CHAP. LDAP is a backend accessed by the RADIUS server to verify user credentials. The ldap module interacts with these protocols by retrieving and comparing data. The FreeRADIUS server performs the authentication logic, not the LDAP server.
This separation of roles means that FreeRADIUS supports multiple kinds of authentication protocols whereas a LDAP database works only the authentication method "bind as user". This authentication method is compatible only with PAP.
Our recommendation is to use LDAP as a database. FreeRADIUS reads the "known good" password from LDAP, and then use that information to authenticate the user. It’s not recommended 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 these limitations of Active Directory, there are no other alternatives.
LDAP security recommendations
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.
-
Create a dedicated account for use by FreeRADIUS.
-
Ensure that this account does not have administrator access.
-
Ensure that this account is read-only, and has no write permissions.
-
Start by using simple authentication instead of SASL. The SASL protocol should be attempted only after 'simple authentication' has been verified to work.
-
Use TLS for connecting between FreeRADIUS and the LDAP server. See the
tlssub-section of the defaultldapmodule for instructions. -
When storing RADIUS user profiles (quotas,
Simultaneous-Useflags, access time restrictions, etc.) in LDAP, the LDAP schemadoc/schemas/ldap/openldap/freeradius-radius.schemamust first be imported into the LDAP server.
Authentication method compatibility
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.
- PAP
-
The user supplies a
User-Password(plaintext or EAP-TTLS/PAP).FreeRADIUS reads the "known good" password from LDAP, and compares that to what the user entered.
- Bind as user
-
The user supplies a
User-Password(plaintext or EAP-TTLS/PAP).FreeRADIUS uses that password to "bind as the user" to LDAP, using the supplied
User-Nameand `User-Password. If the bind is successful, the user is authenticated. Otherwise, authentication fails. - CHAP
-
The user supplies a
CHAPpassword attribute.FreeRADIUS reads the "known good" password from LDAP, and compares that to what the user entered. The password in LDAP must be clear text.
- MS-CHAP
-
The user supplies a
MS-CHAPpassword attribute. Either as MS-CHAPv2, or as PEAP/MSCHAPv2, or as EAP-TTLS/MS-CHAPv2.FreeRADIUS reads the "known good" password from LDAP, and does the relevant MS-CHAP hashing in order to verify the data it received from the user. The password in LDAP must be clear text, or as an NT hash.
All of these authentication methods except "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.
The best method 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 strongly recommend that the passwords be stored in LDAP as hashed / salted. The downside of this approach is that the authentication methods are then limited to PAP and EAP-TTLS/PAP. Storing passwords as clear text (or NT hash, which is essentially clear text) is extremely insecure.
For an in-depth description as to why are making these recommendations, see the InkBridge article on PAP vs CHAP