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