Re: OpenLDAP + FreeRADIUS Complete Solution [sec=unclassified]
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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
RE: OpenLDAP + FreeRADIUS Complete Solution [sec=unclassified]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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!,
