FreeRADIUS Network Element LDAP based authentication In this post I hope to explain how I have done Network Element (Switches, Routers, AP's etc) based NAS devices to have PAP authentication for centralised administration of those devices using FreeRADIUS to authenticate against your centralised LDAP Directory. It does not deal with EAP or 802.1x, it is only focused on PAP Username & Cleartext Password authentication and authorization to network elements. Please search for other documents which detail how to implement EAP/802.1x There were a number of business requirements when I setup this environment: 1) Centralised users. All users would only exist in the LDAP directory and their profiles are driven out of the directory. 2) Supporting different makes and models and use cases of Network Elements (NAS) 3) Grouping NAS's together so that a single role could gain access to multiple devices. IE Switches in Building A, Routers in DMZ, LAB Switches etc. This is done using FreeRADIUS Huntgroups. 4) Multiple Roles per NAS Group. So that you can have a Read-Only, Read-Write, Administrator role for a group of NAS's and that a person could be a member of a role per NAS Group. IE Read-Write LAB Switches, Read-Only Switches in Building A. And last but most importantly. It's easy to manage, not require LDAP Schema Extensions and where possible not require building new tools to manage it. LDAP Design: I used Novell eDirectory as that is what we run, however the LDAP directory being used doesn't matter since no Radius Schema extensions are required, only "User" objects and "Group" objects will be used in new Organizational Units (OU) to be created. I will however use Active Directory based naming to try and be as generic as possible. First create a OU called Radius somewhere in your LDAP Structure to hold all the Radius objects that need to be created. In the following examples I will use the AD Domain of ACME.COM, DC=ACME,DC=COM Start with: OU=Radius,DC=ACME,DC=COM Then create two OU's under Radius. Elements and Roles OU=Elements,OU=Radius,DC=ACME,DC=COM Elements will hold a record of every NAS in your Network. You will create Group objects based on the IP Address of the NAS and set the "Location" or "l" attribute to the NAS Huntgroup the NAS belongs to allow them to be centrally managed in LDAP. IE CN=10.1.2.3,OU=Elements,OU=Radius,DC=ACME,DC=COM With a "l" value of "CiscoRTR" for a Cisco Router that has a NAS-IP-Address or Source-IP-Address of 10.1.2.3. This will make more sense further on. OU=Roles,OU=Radius,DC=ACME,DC=COM Roles will hold Group objects of the LDAP roles that users will be put into to grant them access to the NASs Now that you have your basic LDAP structure we will move onto the FreeRADIUS configuration files that need to be modified. Configuration Files: Following standard practice from the freeradius-users mailing list: ** DOWNLOAD THE LATEST VERSION OF FREERADIUS, TAKE THE DEFAULT CONFIGURATION AND ONLY MODIFY THE SETTINGS IN THE CONFIGURATION YOU NEED TO ** With that in mind I will go through the files I have modified to make the LDAP Authentication work: FILE:/etc/raddb/modules/ldap This is the main LDAP Module configuration file that needs to be modified, I've added comments above each line detailing what it's needed for: ldap { # The Server IP Address or DNS name, preferably run FreeRADIUS on the same server as the LDAP directory so then you can use Cleartext non-SSL connections from FreeRADIUS to the LDAP directory. Using SSL slows down the authentication slightly due to needing to setup SSL Connection for the LDAP Bind for the user. server = "ldap.acme.com" # This is a proxy username with enough read rights to find the user and check they have a valid role. Needs to be able to search users and Groups, and group "member" and "l" values. identity = "cn=Proxy,ou=Users,DC=ACME,DC=COM" # The identity's password. password = mypass # The top level of the LDAP Tree to search for users. Set this as high as practically possible. basedn = "DC=ACME,DC=COM" # I normally set the search to be cn=username, rather than uid=username. filter = "(cn=%{%{Stripped-User-Name}:-%{User-Name}})" #** Leave other default's alone ** # Allow searching of LDAP Groups. groupname_attribute = cn groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{control:Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{control:Ldap-UserDn})))" # Need to support XLAT for HuntGroups do_xlat = yes # Leave other defaults alone } FILE:/etc/raddb/clients.conf Standard clients.conf where you specify the shared secret password. Since I am lazy just specify "password" for the whole 10.x.x.x network: client 10.0.0.0/8 { secret = password shortname = 10Network } FILE:/etc/raddb/users This file is where a Huntgroup (Group of NASs) and a LDAP Group (that the user needs to be a member of) is checked, if they both match then the NAS VSA attributes below the Huntgroup/LDAP Group match are returned. It's also important to have the last line of this file saying "DEFAULT Auth-Type := Reject" since this means that no matches were found, so access should be rejected. Below is a few examples of how it could be configured, this file will be the only file you need to modify when adding a new role or NAS Group. -----BEGIN # Below if you are coming from the CiscoRTR NAS Huntgroup, and you are a member of the "Guest" group, you get the below access. DEFAULT Huntgroup-Name == CiscoRTR, Ldap-Group == "cn=CiscoGuest,ou=Roles,ou=Radius,DC=ACME,DC=COM" Service-Type = "NAS-Prompt-User", Idle-Timeout = 600, Cisco-AVPair = "shell:priv-lvl=1" # DEFAULT Huntgroup-Name == CiscoRTR, Ldap-Group == "cn=CiscoAdmin,ou=Roles,ou=Radius,DC=ACME,DC=COM" Service-Type = "NAS-Prompt-User", Idle-Timeout = 600, Cisco-AVPair = "shell:priv-lvl=15" # DEFAULT Huntgroup-Name == Junipers, Ldap-Group == "cn=JuniperAdmin,ou=Roles,ou=Radius,DC=ACME,DC=COM" Service-Type = "Login-User", Idle-Timeout = 600, Juniper-Local-User-Name = "admin" # DEFAULT Auth-Type := Reject -----END As you can see for each Role, or Group of NAS's you need a entry. This file will grow to cater for as many roles as you need. And to get FreeRADIUS to re-read this file you need to "kill -HUP" the radiusd. FILE:/etc/raddb/sites-enabled/default This is the main site configuration file with the Authorize and Authenticate of the user occurs. Below are the exact versions of both the Authorize and Authenticate sections, since I commented out all services apart from the ones I need: I left all other sections alone, just update these two. -----BEGIN authorize { # First we need to lookup the NAS IP Address based off the Packet-Src-IP-Address. # I used this rather than %{NAS-IP-Address} as per: http://wiki.freeradius.org/Run-time_variables # Since a few NAS devices I have used send bogus NAS-IP-Addresses, and no NAT translations occur within our network so we can trust the Src-IP # So what this is doing is looking up in LDAP using the CN=IPAddress, and looking up the "l" attribute against that object, and updating the "Huntgroup-Name" with that value # This way if you setup the LDAP object correctly you can easily move the NAS from one Huntgroup to another by only updating the "l" attribute in LDAP. update request { Huntgroup-Name := "%{ldap:ldap:///ou=Elements,ou=Radius,DC=ACME,DC=COM?l?sub?cn=%{Packet-Src-IP-Address}}" } # Now lookup LDAP to find the user's full DN to see if they really do exist in LDAP. ldap # Lastly using the user you just found above, lookup to see if the Huntgroup they are coming from, matches any of the LDAP group they need to belong to as per the above "users" file to assign the relevant role and update the response with the VSA's specified in the "users" file. files } authenticate { # All you need in the authenticate section is "ldap" so that FreeRADIUS checks the password the user specified is correct. If they get it wrong they get all the VSA's returned for the role they have access to, but get an Access-Reject. ldap } -----END Once you have done this, all the administration is done in the LDAP directory by adding or removing users from the relevant LDAP Group. When a new NAS Group, or Role is required all that is needed is to update the "users" file, and kill -HUP radiusd. I hope someone finds this useful. And that it gets turned into a Wiki Entry. Cheers Peter Lambrechtsen plambrechtsen at gmail dot com