OpenLDAP + FreeRADIUS Complete Solution [sec=unclassified]

[Mitch McCracken]

Very helpful, thanks a ton!  This will give me something to bang around 
on for awhile and I should be able to get it to do everything we want it to.

Ranner, Frank MR wrote:
>> -----Original Message-----
>> From: freeradius-users-bounces at lists.freeradius.org 
>> [mailto:freeradius-users-bounces at lists.freeradius.org] On 
>> Behalf Of Kostas Kalevras
>> Sent: Friday, 14 September 2007 04:18
>> To: FreeRadius users mailing list
>> Subject: Re: OpenLDAP + FreeRADIUS Complete Solution
>>
>> O/H Mitch McCracken έγραψε:
>>     
>>> When organizations grow, there becomes more and more 
>>>       
>> systems that need 
>>     
>>> to be maintained, and each may have different 
>>>       
>> configurations and users 
>>     
>>> which have access to them. Individually editing local config files 
>>> gets old pretty fast for hundred of devices, and developing 
>>>       
>> a unified 
>>     
>>> and central user authorization database system that spans 
>>>       
>> across all 
>>     
>>> types of information systems becomes necessary.
>>>
>>> Enter: OpenLDAP. I think I've developed a solution to 
>>>       
>> maintain Linux 
>>     
>>> hosts which controls POSIX users/groups/sudo access/apache website 
>>> access/etc. by using a central LDAP database that stores 
>>>       
>> policies of 
>>     
>>> what a user can do on any one of our PCs. The actual 
>>>       
>> configuration got 
>>     
>>> fairly ugly, though (PAM not allowing you to specify more than one 
>>> LDAP Group to allow access to the machine, thus the posixGroup LDAP 
>>> schema had to be used (since /etc/security/access.conf 
>>>       
>> allows you to 
>>     
>>> specify multiple posix group access) instead of groupOfNames, but 
>>> groupOfNames is needed for apache's ldap auth module, so 
>>>       
>> both must be 
>>     
>>> used..), but I've only covered access management for our 
>>>       
>> websites and 
>>     
>>> Linux PCs, not all of the various routers, switches, or other 
>>> RADIUS-aware equipment that exist within the organization.
>>>       
>
> We use radiuGroupName to assign users to groups. The attribute is stored with the 
> User DN and you can have multiple instances. Apache mod_ldap is compatible with
> this approach.
>
>   
>>> Enter: FreeRADIUS. We do already have a FreeRADIUS 
>>>       
>> configuration that 
>>     
>>> is auto-generated by our internal MySQL-based access policies to 
>>> control access to our networking equipment, although this is fairly 
>>> ugly, and it would be much much nicer if it could use the LDAP 
>>> database I'm currently developing to control access across 
>>>       
>> all devices 
>>     
>>> instead. To put it gently, I want FreeRADIUS to be configured
>>> *entirely* off of LDAP.
>>>
>>>       
> [snip]
>   
>>> users: All users which will have some sort of access to one of the 
>>> clients. It appears users are able to be pulled from the LDAP 
>>> directory by providing the correct DN users are located in. For me, 
>>> users are all located in ou=people,dc=grnoc,dc=iu,dc=edu. 
>>>       
>> My personal 
>>     
>>> entry is something like:
>>>
>>> dn: uid=mrmccrac,ou=people,dc=grnoc,dc=iu,dc=edu
>>> objectClass: inetOrgPerson
>>> objectClass: posixAccount
>>> objectClass: radiusprofile
>>> ...
>>> uid: mrmccrac
>>>
>>> I still need to go back and look at the HOWTO perhaps, although I 
>>> believe this setup can be used somehow/somewhere with FreeRADIUS to 
>>> have it pull all of our users (specifically uids) from LDAP 
>>>       
>> instead of 
>>     
>>> a local file. This leads me to the next FreeRADIUS construct..
>>>
>>> groups (group): this specifies groups of users, which can 
>>>       
>> then later 
>>     
>>> be used to define access levels (in huntgroups?). From what I read 
>>> this too can be pulled from FreeRADIUS, that is, the groupOfNames 
>>> object class can be interpreted if you supply the DN which 
>>>       
>> has all of 
>>     
>>> the groups. An example groupOfNames object I currently have 
>>>       
>> is as such:
>>     
>>> dn: cn=dev,ou=ldapgroups,dc=grnoc,dc=iu,dc=edu
>>> cn: dev
>>> objectClass: groupOfNames
>>> objectClass: top
>>> member: uid=mrmccrac,ou-people,dc=grnoc,dc=iu,dc=edu
>>>
>>> Thus I should be able to tell FreeRADIUS to look at dn: 
>>> ou=ldapgroups,dc=grnoc,dc=iu,dc=edu, and it should know to 
>>>       
>> look at the 
>>     
>>> member attributes to determine which users DN are in each group it 
>>> finds. Now, finally...
>>>
>>> huntgroups: I believe this is the glue between users/groups 
>>>       
>> to RADIUS 
>>     
>>> clients. I think the level of access can be defined per 
>>>       
>> group (which 
>>     
>>> would be ideal), and then with huntgroups we say which 
>>>       
>> groups may get 
>>     
>>> their specified level of access (enable mode or not..) to which 
>>> networking devices we specified in the clients. Again, like 
>>> clients.conf, I don't want to have to edit the huntgroups 
>>>       
>> file anytime 
>>     
>>> a change is made, but instead make the change in the LDAP directory 
>>> and have FreeRADIUS pull all huntgroups from there.
>>>       
>
> In raddb/hints
>
> DEFAULT
>         Hint = `%{ldap:ldap:///ou=hosts,dc=whatever?radiusHuntgroupName?one?ipHostNumber=%{NAS-IP-Address}}`
>
>
>   
>>> Is any/all of what I mentioned currently possible based upon my 
>>> current setup and FreeRADIUS's capabilities? Or, will all 
>>>       
>> changes to 
>>     
>>> clients and huntgroups need to be made locally in a file on 
>>>       
>> the radius 
>>     
>>> server, but I can at least pull available users and the groups that 
>>> exist/they belong in from LDAP?
>>>       
>
> In raddb/users
>
> DEFAULT Hint == "", Huntgroup-Name !* Any,Auth-Type := Reject
>         Reply-Message := "Unknown device, not present in any group."
>
> DEFAULT LDAP-Group == "%{Hint:-%{Huntgroup-Name}}_munge"
>         Reply-Message := "%u found in %{Hint}- We have a combined winner!",
>         Fall-Through = no
>
> DEFAULT Hint != "", LDAP-Group == "%{Hint}_qwerty"
>         Reply-Message := "%u found in %{Hint}- We have a hinted winner!",
>         Fall-Through = no
>
> DEFAULT Huntgroup-Name =* Any, LDAP-Group == "%{Huntgroup-Name}_qwerty"
>         Reply-Message := "%u found in %{Huntgroup-Name}- We have a hunted winner!",
>         Fall-Through = no
>
> # If you don't match any of the systems, deny access
> DEFAULT Auth-Type := Reject
>         Reply-Message := "You are not in %{Hint:-%{Huntgroup-Name}}"
>
>
>
> In addition to straight comparison, you can add suffixes to provide different authorisations. Typically
> we use _RO,  _RW and _RWA to group users into read-only, read-write and read-write-admin groups.
>
> Eg
> dn: uid=franner,ou=People,dc=whatever
> radiusGroupName: mss_systemadmin
> radiusGroupName: PSAX_RW
> radiusGroupName: Nortel_RO
> radiusGroupName: tivoli
> radiusGroupName: ciscoworks
> radiusGroupName: netscreen_RWA
> radiusGroupName: Region_ALL
> radiusGroupName: Netview
> radiusGroupName: NetviewNative
> radiusGroupName: config
>
> This is checked like so:
>
> DEFAULT Ldap-Group == `%{Huntgroup-Name}_RWA`
>         Access-Level := RWA,
>         NS-Admin-Privilege := Root-Admin,
>         NS-NSM-User-Domain-Name = global,
>         NS-NSM-User-Role-Mapping = "global:Domain Administrator",
>         Service-Type = Administrative-User
>
> DEFAULT Ldap-Group == `%{Huntgroup-Name}_RO`
>         Access-Level := RO,
>         NS-Admin-Privilege := Read-Only-Admin,
>         NS-NSM-User-Domain-Name = global,
>         NS-NSM-User-Role-Mapping = "global:Read-Only Domain Administrator",
>         Service-Type = Nas-Prompt-User
>
> DEFAULT Ldap-Group == `%{Huntgroup-Name}_10`
>         Cisco-AVPair := "shell:priv-lvl=10"
>
>
> Using radiusGroupName makes it easy to search for users using cli scripts. It also means, when a user is 
> deleted all group memberships vanish as well. It does mean you cannot create group hierarchies by being 
> in a group contained in another group.
>
> We also use radiusGroupName to determine which servers a user can log into. Using a matching rule in the 
> Ldap ACL we allow servers to only see people whose radiusGroupName matches the proxy cn of the server. 
> In the above ldif record, the tivoli group allows login to tivoli servers. The 'config' group is referenced by apache2 to 
> allow access to a internal web site, etc.
>
> Hope this helps.
>
> Regards
> Frank Ranner
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>