3.112.11. AuthorizeGroup Previous topic Parent topic Child topic Next topic

Some TACACS+ clients can request per-command authorisation of commands from the TACACS+ server. When this occurs, one or more AuthorizeGroup parameters can be used to specify privilege levels, permitted TACACS commands and TACACS restrictions for various TACACS+ privilege groups. If no AuthorizeGroup parameters are specified in the Radiator configuration file then all TACACS+ commands will be authorised by <Server TACSCPLUS>.
Tip
You must have a thorough and complete understanding of TACACS+ command authorisation and how to configure your TACACS+ client for command authorisation before attempting to configure privilege control with AuthorizeGroup.
The general format of the AuthorizeGroup parameter is (all on one line):
AuthorizeGroup <groupname> <permit|permitreplace|deny> pattern1
pattern2 ... {attr1=val attr2=val ...}
Each AuthorizeGroup parameter specifies a privilege rule for a TACACS+ privilege group. You can specify zero or more AuthorizeGroup parameters for each privilege group in use in your organisation. The AuthorizeGroup parameters are considered for a group in the order in which they are given in the Radiator configuration file.
When a TACACS authorisation request is received, the list of AuthorizeGroup rules is searched for rules matching the group name identified by the GroupMemberAttr attribute (for more information, see Section 3.112.10. GroupMemberAttr). Each rule is examined in order until a matching rule is found. The patterns are used to do the matching. Each pattern is a Perl Regular Expression (regexp). Pattern1 is matched against the first TACACS+ request argument (usually ’service=xyz’), pattern2 is matched against the second TACACS+ request argument etc. If every pattern matches its TACACS+ argument, then the rule matches.
Tip
For example ‘service=shell’ is a single request argument. The pattern to match two values for ‘service’ would be service=(shell|exec).
If the first matching rule is a ’deny’, the authorisation will be denied.
If the first matching rule is ’permit’, the request is authorised, and the list of reply ‘attr=val’ entries are sent back to the TACACS+ client to be added to the user's command arguments.
If the first matching rule is ’permitreplace’, the request is authorised, and the list of reply ‘attr=val’ entries are sent back to the TACACS+ client and are used to replace the user's requested command arguments.
Tip
Some Cisco devices have authorisation for optional roles with the ‘*’ character. This is not a wildcard character, but indicates the following is optional. For example, the following rule automatically selects the right role(s) depending on the shell:contextname in the authorisation request. Only the set of roles corresponding to the requested contextname will be returned.
AuthorizeGroup group1 permit service=shell\ 
{shell:contextname1*"role1 role2 role3"\
shell:contextname2*role2}
Tip
AuthorizeGroup replaces the old CommandAuth parameter. Support for CommandAuth will be removed some time in the future.
To provide per-user privilege control for TACACS+ users:
  1. Divide your TACACS+ users into groups where all the members in the group have the same privileges.
  2. Assign a unique name to each group.
  3. Choose a RADIUS Reply attribute that will contain the group name for each user. Set this attribute name in GroupMemberAttr.
  4. Arrange for each user to have their specific group name (from step 1) in their RADIUS Reply attribute selected in the previous step.
  5. Add one or more AuthorizeGroup parameters specifying the privileges for all of the possible group names from step 1 above.
  6. Configure your TACACS+ client to perform per-command authorisation with its TACACS+ server.
  7. Test that your TACACS+ client enforces the correct privileges specified in step 5 for each user group.

Example

In these examples, there are two different Tacacs groups. Group1 is only permitted to do ’show’ commands but group2 is allowed to do anything. Group1 is allowed to start a PPP IP session, which will get an inacl of 101 and an outacl of 102.
AuthorizeGroup group1 permit service=shell cmd=show cmd-arg=.*
AuthorizeGroup group1 permit service=ppp protocol=ip {inacl=101
outacl=102}
AuthorizeGroup group1 deny .*
AuthorizeGroup group2 permit .*

Example

As an alternative to controlling individual command authorisation, you can set a privilege level for the user when they start their exec session. Thereafter, the router limits which command the user can use, depending on the priv-lvl. 0 is the lowest, and permits disable, enable, exit, help, and logout. priv-lvl=1 is the non-privileged user. priv-lvl=15 is the highest privilege level, the level after going into enable mode. Here users in group 3 get a priv-lvl of 15. The start of a session sends the args 'service=shell cmd*'.
AuthorizeGroup group3 permit service=shell cmd\* {priv-lvl=15}