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. In these scenarios, it is important to realize that the incompatibility is between the authentication system and the password format, not the RADIUS system.
Understanding authentication oracles in network infrastructure
Password compatibility with non-RADIUS authentication systems is a topic related to protocol compatibility. Such a system is used by the RADIUS server as an authentication oracle, which affects which network authentication protocols the RADIUS server may support.
An authentication oracle is a system where the RADIUS server does not perform the authentication itself, but instead passes the user credentials to another system. Those credentials are normally a username and password, i.e. for Password Authentication Protocol (PAP) or MS-CHAP authentication.
How authentication oracles function
The oracle takes the user credentials and returns a pass/fail response to the RADIUS server. If it returns pass, the RADIUS server decides that the user was authenticated. If it returns fail, on the other hand, the RADIUS server decides that the user has failed to verify their identity.
The RADIUS server normally sends the same response to the NAS, but not always. For example, it may decide that a user with authentication pass may be accessing the wrong NAS, and therefore return an Access-Reject. Or, it may return an Access-Accept for a user with an authentication fail, but then place the user in a quarantine VLAN, which can help reduce the risk of unauthorised access. Either way, the result returned by the authentication oracle is just one more piece of information used by the RADIUS server to make its decisions.
RADIUS authentication systems and third-party integration
From the point of view of the RADIUS server, systems like PAM, LDAP “bind as user”,
or ntlm_auth are authentication oracles. Similarly, from the point of view of the NAS, the RADIUS server is an authentication oracle, because the RADIUS server authenticates users when the NAS cannot.
The table below lists the compatibility between the common systems used for authentication, and the authentication methods.
Important notes about protocol compatibility
For EAP-TTLS, look up the tunnelled protocol in the above table. For the purposes of this table, the tunnelled session is just another RADIUS authentication request. So for EAP-TTLS, with tunnelled PAP, look up PAP in the above table.
Similarly, PEAP normally contains EAP-MSCHAPv2 in the tunnelled session, so its row in the table is identical to the EAP-MSCHAPv2 row, which is in turn identical to the MS-CHAP row.
We do not list EAP-TLS in the above table, because it performs authentication with certificates. As such, it does not interact with any of the authentication oracles listed above.
Common authentication compatibility issues (aka gotchas)
Many network administrators try to use one of the systems above for authentication because it works for PAP. They later decide that they need to support an authentication protocol that the above table shows is incompatible with the system they have chosen. They then ask:
How can I make authentication protocol X work with authentication system Y?
The short answer is:
You can’t.
The authentication oracles listed above are much more limited than a RADIUS server and are designed to only support one authentication protocol. If there’s no check mark in the above table, then it’s impossible to make the authentication protocol use that system.
Your only choices are to stop trying to use that authentication protocol or to use a different system that is compatible with that authentication protocol. The last choice often means storing the password in clear-text in a database, which means asking all users to change their passwords, unfortunately.
Need more help?
InkBridge Networks has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialise 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
RADIUS protocol and password compatibility
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.
How to connect FreeRADIUS to Active Directory for authentication
Active Directory is widely used in the enterprise and university systems. This article describes how to connect FreeRADIUS with Active Directory, allowing you to authenticate users against your existing directory service while leveraging the power of your RADIUS server for network access control.