In order for RADIUS authentication to work, user passwords need to be stored in a format that is understood by the authentication protocol used by the client. Unfortunately, not all protocols work with all password storage formats. This can be especially problematic with platforms that use proprietary formats or protocols.
There are many protocols carried inside of RADIUS. They include PAP, CHAP, MS-CHAP, EAP, and a host of additional attributes.
Passwords may be stored in a DB in many forms. Clear-text, MD5 hashed, crypt’d, NT hash, or other methods are all commonly used.
Authentication protocols used in RADIUS are not always compatible with the way the passwords have been stored. The following table shows which protocol is compatible with what kind of password.
Notes
For EAP-TTLS, EAP-FAST and EAP-TEAP look up the tunneled protocol in the above table. For the purposes of this table, the tunneled session is just another RADIUS authentication request. So for EAP-TTLS, with tunneled PAP, look up PAP in the above table.
Similarly, PEAP normally contains EAP-MSCHAPv2 in the tunneled session, so its row in the table is identical to the EAP-MSCHAPv2 row, which is in turn identical to the MS-CHAP row.
EAP-TLS, EAP-SIM, EAP-AKA and EAP-AKA’ are not mentioned in the above table as they do not use password based credentials. EAP-TLS relies on digital certificates, whilst EAP-SIM uses SIM triplets, and EAP-AKA[’] uses AKA quintuplets.
EAP-PWD supports many more salted hashing schemes than listed above, see RFC8146 for more details.
Gotcha’s
In our experience, many system administrators store passwords in their databases in hashed or encrypted form. They later decide that they need to support an authentication protocol that the above table shows is incompatible with their password storage method.
They then ask:
How can I make authentication protocol X work with passwords stored as Y?
The short answer is:
You can’t.
The incompatibility between the storage format and the protocol is usually intentional by the creators, and there isn’t a magic setting or configuration that will make them play nicely together.
When a storage format is not compatible with a given protocol, you have three choices:
1) Change the authentication protocol you are using to something that is compatible with the storage format
2) Change the password storage format in the database. Unfortunately, this strategy often requires all users to change their passwords.
3) Use an intermediary (such as Samba) to communicate between the database and the authentication client. This is the approach we recommend when Active Directory is used for password storage.
Need more help?
InkBridge Networks has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, visit our quote page to contact us for a consultation.
Related Articles
Configuring FreeRADIUS authentication with Active Directory
When FreeRADIUS uses Active Directory as a user database, certain limitations apply. Active Directory won’t give FreeRADIUS the “known good” password for FreeRADIUS to use. Instead, FreeRADIUS has to take the user authentication data and hand them to Active Directory, which then returns success or fail to FreeRADIUS.
Read More
Authentication systems and protocol compatibility
In many network configurations, there will be some transactions for which the RADIUS server will not perform the authentication itself, but simply pass credentials to a third party system and rely on the pass/fail response it gets from that system. Unfortunately, not all of these authentication systems work with all password storage formats.
Read More
Does Active Directory work with FreeRADIUS?
The short answer is Yes, Active Directory is compatible with FreeRADIUS. However, there are some constraints and implications for the rest of the system.
Read More