[RADIATOR] Multiple user groups for tacacs authorization possible
Heikki Vatiainen
hvn at open.com.au
Mon Jul 11 06:09:05 CDT 2011
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 <hvn at open.com.au>
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.
More information about the radiator
mailing list