On 07/11/2011 11:13 AM, Alexander Hartmaier wrote: > How would one implement AuthorizeGroups per device groups?
The AuthorizeGroupAttr option might be the solution here. With AuthorizeGroupAttr you can return rules in AuthorizeGroup format. In other words, instead of returning the name of the group with AuthorizeGroup attribute you return individual rules. AuthorizeGroupAttr and AuthorizeGroup can be used together too. You can return the name of the group with AuthorizeGroup and additional rules with AuthorizeGroupAttr. This should enable you to define a common set of rules (the name of group returned by AuthorizeGroup) + per user/group rules that are returned by attribute defined by AuthorizeGroupAttr. These per user/group rules override the AuthorizeGroup values from the configuration file. This is a new option for version 4.8. To quote http://www.open.com.au/radiator/history.html Server TACACSPLUS now supports a new parameter AuthorizeGroupAttr. If this parameter is specified, it specifies the name of an attribute in Access-Accept that will contain per-command authorization patterns for authorising TACACS+ commands. These are processed before any configured-in AuthorizeGroup parameters. The command authorization patterns are in the same format as supported by AuthorizeGroup. Added a new VSA to dictionary OSC-Authorize-Group, which is intended to carry per-user reply command authorization patterns. Here is another 4.8 addition. An example hook that can be used to return attributes defined by AuthorizeGroupAttr. Added lookupauthgroup.pl Sample PostSearchHook for AuthBy LDAP2, which finds user group(s) through an LDAP lookup, then finds corresponding check and reply attributes in SQL, based on the user group(s) for that user and the device groups of the RADIUS/TACACS+ client. This allows you to have a add very fine grained authentication/authorisation in an LDAP/SQL environment, based on user and device group membership. > We have multiple teams each mainly responsible for a group of devices > e.g. the switching team accessing switches. They should have admin > rights, some of the other teams limited access. > I already get the support group from a db using ClientListSQL and put it > into the OSC-Group-Identifier attribute. I hope the above can help. With AuthorizeGroupAttr you can move authorization logic from hardwired groups in ServerTACACSPLUS to the actual AuthBy. In your case you can use the information in DB more easily. Best regards, Heikki -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
