Authentication Systems and Password Compatibility

Password compatibily with non-RADIUS authentication systems is a topic related to the protocol compatibility page. Such a system is used by the RADIUS server as an authentication oracle, which affects which 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 users authentication credentials to another system. Those credentials are normally a user name and password, i.e. for PAP or MS-CHAP authentication.

The oracle takes those 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 authentication. 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. 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.

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 the user when the NAS cannot.

The table below lists the compatiblity between the common systems used for authentication, and the authentication protocols.

PAM LDAP "bind as user" ntlm_auth
PAP √ √ √
CHAP x x x
Digest x x x
MS-CHAP x x √
PEAP x x √
EAP-MSCHAPv2 x x √
Cisco LEAP x x x
EAP-GTC x x x
EAP-MD5 x x x
EAP-PWD x x x

Legend

If the correspoding cell is green (i.e. has a '√' check mark), it means that the corresonding authentication system and the protocol are compatible, and that authentication is possible.

If the corresponding cell is red (i.e. has an 'x'), it means that the corresonding authentication system and the protocol are not compatible, and that authentication is not possible.

Notes

For EAP-TTLS, 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 it's row in the table is identical to the EAP-MSCHAPv2 row, which is in turn identical to the MS-CHAP row.

Unlike the compatibility page, the row for Cisco LEAP is not the same as for MS-CHAP. This is due to the additional MS-CHAP information exchanged in LEAP, that requires information that ntlm_auth cannot supply.

We do not list EAP-TLS in the above table, because it performs authentication with certificates, and does not interact with any of the authentication oracles listed above.

Gotcha's

Many people 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 the cell in the above table is red, 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 DB, which means asking all users to change their passwords, unfortunately.