Child pages
  • Using LDAP as authentication source
Skip to end of metadata
Go to start of metadata
This page is reliant on the behaviour of the LDAP module in FreeRADIUS. This behaviour may change in the future and it may render this page inaccurate. If you find this to be the case, please contact the page's author.

FreeRADIUS treats LDAP as what LDAP was designed to be - a directory. This means that it retrieves the user's password from the directory and then does the authentication itself. 

Sometimes however this is not possible. Examples include OpenLDAP with SASL pass-through authentication, where OpenLDAP will in turn defer its authentication to another mechanism, such as Kerberos. In this instance, FreeRADIUS will use LDAP as an external authentication oracle, i.e. it will accept the successful authentication on LDAP as a sign that the username and password matched and that it can return an Access-Accept packet.

Using LDAP as an authentication oracle restricts you to PAP authentication as per http://deployingradius.com/documents/protocols/oracles.html.

You can also use Active Directory as an external authentication oracle this way, if you prefer not using NTLM authentication (which requires SAMBA's winbind).

 

Configuring LDAP on FreeRADIUS

In FreeRADIUS 3.x, the LDAP module has been significantly improved. In a packaged environment (i.e. when using APT or RPM/Yum), FreeRADIUS LDAP support is in a separate package that needs to be installed before you proceed.

 

Edit /etc/raddb/mods-available/ldap:

  1. Modify the server, port, identity, password and base_dn options to match those needed to access your server. If necessary, configure the TLS section for LDAPS support.
  2. To avoid the use of the LDAP-stored password, comment out the line(s) in the update section that retrieve the user password from LDAP as it is not required.
  3. Add any configuration items from LDAP that you would like to use later in FreeRADIUS (such as group information etc) in the update section.
  4. In the users section, amend the base_dn, filter, and scope settings as appropriate to retrieve a single user from LDAP to bind with.

 

Edit /etc/raddb/mods-available/eap:

  1. Modify the default_eap_type for EAP in general and for the ttls section in particular - set both to gtc. EAP-GTC allows PAP authentication to proceed. If you are using Cisco PEAP support (i.e. PEAPv1), you can also amend the default_eap_type in the peap section from its default of mschapv2 to gtc. If you are using Microsoft's PEAP (i.e. PEAPv0), then this section cannot be changed.

 

Edit /etc/raddb/mods-available/inner-tunnel:

  1. Modify the authorize section to add the following block at the bottom after the pap statement:

    if (User-Password) {
    	update control {
    		Auth-Type := ldap
    	}
    }
  2. Modify the authenticate section, edit the Auth-Type PAP block as follows:

    Auth-Type PAP {
    	#  pap
    	ldap
    }
  3. Also in the authenticate section, remove the comment from the ldap line (but not the remainder of the Auth-Type LDAP block).

 

Testing FreeRADIUS:

Restart FreeRADIUS in debug mode and then test the configuration with the following command on the server that FreeRADIUS is running.

radtest -x [username] [password] localhost:18120 0 [secret for inner-tunnel] 

If LDAP was able to perform a successful bind, you should receive output similar to the below in the window running radtest:

rad_recv: Access-Accept packet from 127.0.0.1 port 18120, id=xxx, length=xxx

On the server, you should see:

Sending Access-Accept of id xxx to 127.0.0.1 port 18120 to 127.0.0.1 port xxxxx
(0) Finished request xxx.
(0) Cleaning up request packet ID xxx with timestamp
Ready to process requests 

 

Then, to test your EAP connection, use the rad_eap_test script (see Building eapol_test in wpa_supplicant for more details): 

./rad_eap_test -H 127.0.0.1 -P 1812 -S [secret for RADIUS server] -u [username] -p [password] -A [outer identity] -m WPA-EAP -v -e [EAP type] -2 [secondary EAP type]

The -2 parameter is optional as the default_eap_type setting for TTLS should be gtc.

 

A successful authentication should have output similar to the below in the rad_eap_test window:

access-accept; 0
RADIUS message: code=2 (Access-Accept) identifier=x length=xxx

The server window should look similar to the server output of the radtest test.

This should complete the setup.

  • No labels