Overview – LDAP and RADIUS

Before we dive into RADIUS, first I want to explain a little bit about LDAP. Lightweight Directory Access Protocol is a protocol that is used for directory services over an IP network. It is possible that the RADIUS server has a database with user accounts for authentication, but most of the time it uses an external database. The RADIUS server queries the LDAP database (TCP or UDP port 369 or port 636 for LDAP with SSL) for data that is used for authentication. The most common database that is used for LDAP queries is Microsoft Active Directory. Other options are eDirectory from NetQ (originally from Novell) or OpenLDAP and Apache Directory servers, both, which are open source. For Mac OS X servers you can use Apple’s Open Directory.

RADIUS, Remote Authentication Dial-in User Service, is the protocol that is used for authentication, authorization, and accounting (AAA). If you have read some other blogs, you probably know what AAA means. RADIUS was developed for client/server authentication, and later it was used by ISPs for dial-up users and that extended into VPN dial-up users. Nowadays RADIUS is used for Wireless LAN security and has the ability to communicate with databases like Active Directory or SQL databases.

RADIUS clients, who shouldn’t be confused with Wi-Fi clients (supplicants), are clients that communicate with the RADIUS server. Wi-Fi clients (or supplicants) are the clients that need to authenticate. The authenticator is the device that communicates directly with the RADIUS server, and is called RADIUS clients or network access server (NAS). It is understandable that all those terms may be confusing. Hopefully this figure explains it better.

As written down in the blog about the different EAP types, we discussed the RADIUS communication. First the RADIUS client sends a RADIUS Access-Request and notifies that there is a Wi-Fi client that wants to authenticate. The RADIUS server replies with an Access Challenge. In this challenge, depending on the EAP-type, the server requests more information. This communication is within the TLS tunnel between the authenticator server and supplicant. After the challenge, the server replies with or a RADIUS access-accept or RADIUS access-reject.

The third “a” is accounting. Accounting track the network access from the users and devices that are connected to the network. This is sent from the RADIUS client to the RADIUS accounting server. In most cases the accounting server is the same as the authentication server. After the access is granted, the Accounting-Request packet is sent to the accounting server. In this packet is the Acct-Status-Type with the value start. This indicates that the network needs to be tracked. In this start packet is information about the user and devices like username, IP address, NAS information, and a unique identifier. Periodically the RADIUS client sends updates about the active session. The Acct-Status-Type contains now the value interim-update. This contains information about the current session. The accounting track stops when the Acct-Status-Type contains the value stop.

To let the RADIUS server, communicate with the RADIUS client, you need to configure all IP addresses from the RADIUS clients (or a subnet block) that will communicate with the RADIUS server, as well as a shared secret. This shared secret is a key that is used on both sides for validation. This will not be used for validating the supplicant. The UDP ports need to be set to 1812 for authentication and 1813 for accounting. A RADIUS server can be configured with multiple EAP-types, but keep in mind that the EAP-type that is selected on the RADIUS server side needs to match with the EAP-type on the RADIUS client side.

During the blog about the different types of EAP you could see that some of the EAP types use TLS tunnel for the inner authentication. For this TLS tunnel, a server certificate needs to be installed on the RADIUS server and selected. The Root CA certificate must also be designated and provisioned to all the supplicants.