Auth-Type attribute is often misunderstood and misused. There are actually very few situations where this attribute should be manipulated at all.
Rule 1: Don’t use the Auth-Type Attribute
This is the first rule and really, the only rule. If you’re unsure about whether or not you should use the
Auth-Type attribute, you shouldn’t.
Seriously. Just don’t. Here’s why.
The default configuration of the server, as shipped, works with the widest possible variety of authentication protocols. That is, so long as the server has a clear-text password for the user, the following authentication protocols will work out of the box:
- HTTP Digest
If the server is configured with a certificate for EAP-TLS, the following authentication protocols will also work:
EAP-TTLS, with tunneled:
EAP-PEAP, with tunneled:
That is, the server will look at the incoming packet, and use the clear-text password to just do the right thing. If we look at that list again, it’s clear that setting
Auth-Type to any value will break the servers ability to perform some, if not all of the above authentication protocols. That’s why we recommend that you not use the
How not to use Auth-Type
A common misuse of
Auth-Type is to force particular kind of authentication to be used. We do not recommend that kind of configuration, as it is fragile and prone to errors.
Instead, we recommend rejecting attempts to do any other kind of authentication.
For example, the following
users file entry will reject any authentication attempt that does not use MS-CHAP authentication:
DEFAULT MS-CHAP-Challenge !* 0x00, Auth-Type := Reject Reply-Message = "You must use MS-CHAP"
This configuration is more robust, and will generate more meaningful log messages when the local policy has to be debugged.
Note: In some cases, using the
Auth-Type attribute to force a particular authentication can be used for testing purposes only as described in our guide to configuring FreeRADIUS with Active Directory . This approach should be used cautiously however, and the
Auth-Type testing text should be removed as soon the desired test is complete.
Legitimate uses for Auth-Type
The primary legitimate uses for manually
Auth-Type are the following two situations:
- Force the user to be accepted: just use
- Force the user to be rejected: just use
This usage might come up in a scenario in which you want to allow a user online even if their password is incorrect, usually in some kind of “captive” portal.
Note that simply saying
accept will not work for MS-CHAP and EAP. Those protocols do all kinds of “behind the scenes” calculations based on data exchanged during a successful authentication. If that process is bypassed, then the data won’t be exchanged, and the end-user system will not know how to process any short-circuit
accept, and will treat is as a
There are so few other situations where
Auth-Type is a good idea that we won’t discuss them here. Instead, we recommend asking questions on the freeradius-users mailing list. Describe your needs in detail, and someone should be able to help you
Need more help?
Network RADIUS 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, contact us for a consultation.