HOWTO:Centralised LDAP Authentication

Peter Lambrechtsen plambrechtsen at gmail.com
Sun Sep 19 14:35:47 CEST 2010 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100920/3ae94e41/attachment.html>

More information about the Freeradius-Users mailing list