On Fri, 23 Jul 2004, Daniel Epstein wrote:
> 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
>
> --
>
You may like the way we did it using the ldap-group option. That way you
don't have to define different ldap instances to use.
The documentation is located at http://doris.cc/radius. It is a little
outdated in versions, but should work with 1.0 and newer openldap
versions. I will get around to updating that documentation for 1.0 one of
these days, although not much will be different.
That doc is also located in the doc directory in recent versions
(doc/ldap_howto.txt).
-Dusty Doris
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
