Active Directory

If you prefer to rely on user data in Active Directory, you can use ntlm_auth from the Samba package [5]. Access based on the username, domain, and password can be tested manually:

ntlm_auth --request-nt-key --domain=mydomain --username=myuser --password=mypassword

This command line exists in a similar form in the FreeRADIUS configuration file modules/ntlm_auth. You just need to modify the path for calling the program, for example, to /usr/bin/ntlm_auth and to match the domain (realm) of your ADS server. Usernames and passwords are provided directly by the requesting client. Finally, enable the module in the sites-enabled/default and sites-enabled/inner-tunnel files. The authenticate block lists the permissible authentication methods; you need to add an ntlm_auth line here. Details about configuring and troubleshooting FreeRADIUS and Active Directory Service are provided online [6].

Tunnel

The sites-enabled/inner-tunnel module configuration file is used, among other things, for authentication based on WPA Enterprise. The underlying 802.1X standard for WPA Enterprise defines an encrypted connection based on the EAP-over-LAN protocol (EAPOL), where EAP stands for Extensible Authentication Protocol .

With EAPOL, the user data is sent by the client through an encrypted tunnel to the access point, a WiFi hotspot in 802.1X. The access point forwards the request to the RADIUS server, which follows the usual principle to handle it. However, if the EAP protocol is used, FreeRADIUS reads the list of modules in sites-enabled/inner-tunnel instead of just sites-enabled/default.

The tunnel still needs an encryption certificate. In production, this certificate would be signed by a trusted authority. The FreeRADIUS source package provides a demo certificate for testing purposes, which is generated by running the make command in the certs subdirectory. However, the demo certificate is missing from the packages provided by most Linux distributions, because it is not signed and thus not a trusted certificate.

If you want to try EAPOL authentication, you will also find the eapol_test program in the WPA supplicant package for this; it implements various WPA encryption mechanisms for testing and analysis purposes. By default, eapol_test is not compiled but only activated if you enable the CONFIG_EAPOL_TEST = y configuration option in the sources. It is commented out in the defconfig file below the wpa_supplicant subdirectory of the WPA supplicant source package. Copy this file to wpa_supplicant/.config, remove the comments in the config file, and compile by typing make eapol_test.

The sample configuration file, peap mschapv2.conf [7], is useful for testing WPA Enterprise. You need to modify the identity and password entries to authenticate a user that you created in FreeRADIUS. You can perform the test as follows:

eapol_test -c peap-mschapv2 -s Client-Password

The client password corresponds to the one specified in the clients.conf file. In the given sample configuration for localhost, it would be testing123. After a successful test, you will want to disable the localhost client and all unused client entries or change the password.

Pitfalls

FreeRADIUS was designed for user management on a scale typical of Internet providers, making the default configuration packaged with FreeRADIUS very valuable. Getting started is easy; for example, you can easily set up the local WiFi hotspot for user-specific authentication and configuration instead of using a shared password – given your hotspot has WPA Enterprise capability.