OpenLDAP + FreeRADIUS Complete Solution [sec=unclassified]

[Ranner, Frank MR]

> -----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