The short answer is Yes, FreeRADIUS and Active Directory are compatible with each other. However, there are some constraints and implications for the rest of the system.
Like any technology choice, Active Directory has its 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?
Microsoft Active Directory (AD) is often used to store user credentials in organisations that 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 disadvantages of 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, which 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 |
| Supports single sign-on (SSO) | Usually requires Samba as an intermediary to communicate with FreeRADIUS |
Getting FreeRADIUS and Active Directory 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 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 username and password from the user.
- FreeRADIUS asks the directory service for the information related to that username.
- 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 username 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 how to connect FreeRADIUS to Active Directory for authentication.
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 summarises 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 front-end protocol.
There is no workaround to this constraint. Active Directory was designed to not work with those protocols.
For more information, see our detailed discussion on the protocol compatibility 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 minimise the load on Active Directory domain controllers 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
FreeRADIUS and Active Directory 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 when managing users and their secure access to network resources.
Need more help?
InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here.
Related Articles
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.
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.