Log InThe short answer is Yes, Active Directory is compatible with FreeRADIUS. However, there are some constraints and implications for the rest of the system.
Like any technology choice, Active Directory has advantages and disadvantages, as well as consequences for how other network components need to be set up. This article provides an overview of these considerations at a high level and provides pointers to more detailed how-to guides.
What are the advantages and disadvantages of Active Directory?
Active Directory is often used to store user credentials in organizations which rely on Microsoft products for their IT infrastructure. The graphical user interface for AD makes it a popular choice for IT administrators who prefer point-and-click interactions over command line interfaces. In practice, we tend to see Active Directory in educational institutions and smaller enterprises.
The primary drawbacks to Active Directory are its performance and its lack of easy integration with non-Microsoft network components and protocols. These constraints make Active Directory less commonly deployed in large enterprises and ISPs who need greater flexibility and higher performance.
| Active Directory Pros | Active Directory Cons |
| Graphical user interface | Not as performant as other directories (such as OpenLDAP) |
| Plays well in Microsoft environments | Is not compatible with all authentication protocols |
| Usually requires Samba as an intermediary to communicate with FreeRADIUS |
How do you get Active Directory and FreeRADIUS to work together?
When using FreeRADIUS in an Active Directory environment, there are 3 things you need to consider in the network design.
1) You will need to use Samba as an intermediary between FreeRADIUS and Active Directory.
Active Directory uses a proprietary Microsoft technology for the client-side authentication protocol. This means that in most cases, FreeRADIUS cannot communicate with Active Directory directly and Samba must be used as an intermediary, particularly when setting up authentication over WiFi. In some non WiFi scenarios, Samba may not be necessary. For example, for administrator authentication to switches.
The authentication process in a non Active Directory environment is relatively straightforward.
- FreeRADIUS receives a user name and password from the user
- FreeRADIUS asks the directory service for the information related to that user name
- The directory service replies with the hashed (or encrypted) password, as well as information about which method was used to store the password
- FreeRADIUS uses the specified hash method on the password it received and compares it to what the directory service provided.
- FreeRADIUS provides access to the user or not.
When Active Directory is used as the directory service, the stored passwords are not accessible. This means that FreeRADIUS cannot directly determine if the submitted password is a match. In fact, FreeRADIUS never sees the submitted password, it only receives MS-CHAP data, which is a hash of the password. Because MS-CHAP does not contain the password, FreeRADIUS can only pass along the MS-CHAP data to Samba, which then passes it to Active Directory. Active Directory then determines if the MS-CHAP data is correct.
- FreeRADIUS receives a user name and a password with an MS-CHAP data wrapper
- FreeRADIUS passes this information to Samba and asks for verification
- Samba passes this information to Active Directory and asks for verification
- Active Directory retrieves the stored password (in NT hash format) for that user
- Active Directory applies MS-CHAP to the stored password
- Active Directory compares the MS-CHAP data of the stored password against the submitted password and decides on access
- Active Directory provides access information to Samba
- Samba passes that access information to FreeRADIUS
- FreeRADIUS provides access to the user (or not)
For more technical details on configuring and deploying this scenario, consult our article on configuring authentication for Active Directory.
2) Your choice of client-side authentication will be constrained
Active Directory stores user passwords using the NT hash function. This format is not compatible with some client-side authentication protocols.
The table below summarizes the compatibility of common authentication protocols with common password storage methods.
| Clear-text | NT hash | MD5 hash | Salted MD5 hash | SHA1 hash | Unix Crypt | |
|---|---|---|---|---|---|---|
| PAP |  |
|
|
|
|
|
| CHAP | |
|||||
| Digest | |
|||||
| MS-CHAP | |
|
||||
| PEAP | |
|
||||
| EAP-MSCHAPv2 | |
|
||||
| Cisco LEAP | |
|
||||
| EAP-GTC | |
|
|
|
|
|
| EAP-MD5 | |
|||||
| EAP-SIM | |
Specifically, we can see from this table that NT hash is not compatible with CHAP, Digest, EAP-MD5, and EAP-SIM.
EAP-TLS relies on digital certificates, and doesn’t use passwords at all. So it is compatible with Active Directory.
This means that if you are using Active Directory as your identity store, it is impossible to use CHAP, Digest, EAP-MD5, EAP-SIM, or EAP-TLS for your frontend protocol.
There is no workaround to this constraint. Active Directory was designed to not work with those protocols.
For more information, see our detailed discusson on the protocol compatability matrix.
3) Consider using session tickets to speed up performance.
In universities and other educational institutions, students typically sign in every time they change classes. Active Directory can struggle to handle this high volume of authentication requests.
We can minimize the load on Active Directory by enabling the TLS “fast reconnect” feature. This method essentially stores a small session ticket on a student’s laptop when they authenticate for the first time that day. This session ticket can be used to authenticate the user, and means that we no longer need to query Active Directory.
Our design blueprint for universities discusses this in more detail, as well as other important design considerations for university environments.
Active Directory, Samba, and FreeRADIUS
Active Directory and FreeRADIUS can work together, but it does require some extra effort to integrate the two systems and get the best performance. Active Directory also puts some constraints on which authentication protocol you can use.
Need more help?
At Network RADIUS we have helped many clients design and deploy authentication systems. We also moderate the FreeRADIUS mailing list and have encountered pretty much every variation of deployments out there. If you have a complex network environment and need expertise from the people who wrote FreeRADIUS, contact us for a consultation.
Read more:
