Greetings all,
We run a freeradius-0.9.3 installation handling authentications for a
number of different NASs on our campus. The RADIUS servers are using
an openldap directory as the primary user credentials store. For a
number of reasons, we designed our LDAP schema such that authorization
for services is indicated by one or more values set in a multi-valued
string attribute of the user object. This is as opposed to using group
membership or a series of discrete boolean or string attributes for
authorization to each service type. It should also be noted that the
RADIUS server does not bind to LDAP in the context of a privileged
account, but with the credentials supplied by the NAS client.
When we initially deployed this infrastructure three years ago, we
found that the rlm_ldap module was not able to query a multi-valued
attribute for authorization using the 'access-attr' option. Following
suggestions from this list, we instead extended the 'filter' value to
cause the authentication to fail if a particular string appears in the
access attribute. We have the following configuration:
----- radiusd.conf -----
ldap ldap-vpn {
...
filter = "(&(uid=%u)(!(ucPriv=novpn)))"
...
}
ldap ldap-modem {
...
filter = "(&(uid=%u)(!(ucPriv=nomodem)))"
...
}
ldap ldap-soup {
...
filter = "(&(uid=%u)(!(ucPriv=nosoup)))"
...
}
...
authenticate {
Auth-Type aldap-vpn {
ldap-vpn
}
Auth-Type aldap-modem {
ldap-modem
}
Auth-Type aldap-soup {
ldap-soup
}
}
authorize {
preprocess
files
Autz-Type zldap-vpn {
ldap-vpn
}
Autz-Type zldap-modem {
ldap-modem
}
Autz-Type zldap-soup {
ldap-soup
}
}
...
------------
----- huntgroups.conf -----
vpn NAS-IP-Address == x.x.x.x
vpn NAS-IP-Address == x.x.x.x
vpn NAS-IP-Address == x.x.x.x
modem NAS-IP-Address == x.x.x.x
modem NAS-IP-Address == x.x.x.x
modem NAS-IP-Address == x.x.x.x
soup NAS-IP-Address == x.x.x.x
------------
----- users -----
DEFAULT Huntgroup-Name == vpn,
Auth-Type := aldap-vpn,
Autz-Type := zldap-vpn
DEFAULT Huntgroup-Name == modem,
Auth-Type := aldap-modem,
Autz-Type := zldap-modem
DEFAULT Huntgroup-Name == soup,
Auth-Type := aldap-soup,
Autz-Type := zldap-soup
------------
While this works for us in terms of allowing and denying access
appropriately, it is not optimal in that it does not allow us to log or
return to the NAS the proper reason for authentication failure (because
we are bundling authorization with authentication). We're now in the
middle of a redesign of the RADIUS infrastructure (including possible
plans to test and deploy version 1.0.0 when released). I was wondering
if there is now a better way to approach this problem under the current
version. I've looked at the checkval module, but this seems to really
work in the opposite direction, checking values from the NAS, not from
the auth store, but I confess I don't understand it entirely. Any help
or suggestions would be appreciated.
Cheers,
Dan
--
A boast of "I have been's," | Daniel G. Epstein
quoted from foolscap tomes, | Security Analyst,
is a shadow brushed away | Network Security Center
by an acorn from an oak tree | NSIT, The University of Chicago
or a salmon in a pool. |
GnuPG public keys available from http://pgp.mit.edu/
or http://security.uchicago.edu/centerinfo/pgpkeys.shtml
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
