HOWTO:Centralised LDAP Authentication

[Alexander Clouter]

Peter Lambrechtsen <plambrechtsen at gmail.com> wrote:
> 
> 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.
>
Much better would to have 'cn=huntgroup-name' and use something like 
ipHostNumber (from objectclass iphost) to put multiple NAS's under the 
same object.  Your approach means that if I want to add a new NAS I have 
to create a new object and make sure all the 'l's match up.

> 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
> 
To be honest, you should have your RADIUS related role groups also along 
side your normal group memberships.

> 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.
>
*For the first connection only*.  After the first SSL handshake, there 
is no additional time expense.  On our EAP/TTLS-PAP setup we SSL hookup 
to the LDAP eDirectory service at the backend (to extract the plaintext 
password from 'universal password'), the *whole* authentication takes 
less than two seconds including that one off connection.

After the initial SSL handshake, things are fast.  You approach removes 
SSL for no benefits and now means you are sending your switch *admin* 
passwords around in cleartext.

I personally would not do this... :)

>    # Need to support XLAT for HuntGroups
>    do_xlat = yes
>
Another approach (although you lose the dynamicness) that can help avoid 
this:

http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg59481.html

> 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:
>
I think you will find we all are... :)
 
> -----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
>
As you us 'groupname_attribute' you should be able to replace 
'Ldap-Group == "cn=...."' with just 'Ldap-Group == CiscoGuest'.

> 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.
>
You might want to look at amending 
/etc/freeradius/sites-available/dynamic-clients and make it use 
something sensible like LDAP rather than SQL.
 
Cheers

-- 
Alexander Clouter
.sigmonster says: Give him an evasive answer.