Auth-Type attribute in FreeRADIUS

Why you probably shouldn't use it

The FreeRADIUS 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:

  • PAP
  • CHAP
  • MS-CHAPv1
  • MS-CHAPv2
  • HTTP Digest
  • EAP-GTC
  • EAP-MD5
  • EAP-MS-CHAP

If the server is configured with a certificate for EAP-TLS, the following authentication protocols will also work:

  • EAP-TLS

  • EAP-TTLS, with tunneled:

    • PAP
    • CHAP
    • MS-CHAPv1
    • MS-CHAPv2
    • EAP-GTC
    • EAP-MD5
    • EAP-MS-CHAP
  • EAP-PEAP, with tunneled:

    • EAP-GTC
    • EAP-MD5
    • EAP-MS-CHAP

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 Auth-Type attribute.

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 accept.
  • Force the user to be rejected: just use reject.

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 reject.

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.

Read more...

Additional resources