Some TACACS+ clients 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, all TACACS+ commands are authorised by
<Server TACSCPLUS>.
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 this:
# Note: Whitespace is not allowed after and before {}
AuthorizeGroup <groupname> <permit|permitreplace|deny> pattern1
pattern2 ... {attr1=val attr2=val ...} {extra_check1=val extra_check2="val 2" ...}
If
any extra checks exist, they are also evaluated for a match. Currently
supported extra checks are:
peeraddr- Client-Identifier
- Any real attribute from Access-Accept
- Any pseudo attribute from Access-Accept
Each AuthorizeGroup parameter specifies a
privilege rule for a TACACS+ privilege group. You can specify zero or more
AuthorizeGroup parameters for each privilege group
that is used 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.119.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 and so on. 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 is
service=(shell|exec).
If the first matching rule is
deny, the authorisation is 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 roles depending on the
shell:contextname in the authorisation request. Only
the set of roles corresponding to the requested
contextname is 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:
- Divide your TACACS+ users into groups where all the members in the
group have the same privileges.
- Assign a unique name to each group.
- Choose a RADIUS Reply attribute that will contain the group name
for each user. Set this attribute name in
GroupMemberAttr.
- Arrange for each user to have their specific group name (from step
1) in their RADIUS Reply attribute selected in the previous step.
- Add one or more
AuthorizeGroup parameters
specifying the privileges for all of the possible group names from
step 1 above.
- Configure your TACACS+ client to perform per-command authorisation
with its TACACS+ server.
- Test that your TACACS+ client enforces the correct privileges
specified in step 5 for each user group.
Example
This example uses two 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 gets 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
This example uses extra checks to allow or deny
show commands for group1. Users
coming from client that connects from 127.0.0.1 are explicitly permitted.
Users coming from client that has identifier
Some-TACACSPLUS-client are explicitly denied. The
rest of the users are permitted.
AuthorizeGroup group1 permit service=shell cmd=show cmd-arg=.* {} \
{peeraddr=127.0.0.1}
AuthorizeGroup group1 deny service=shell cmd=show cmd-arg=.* {} \
{Client-Identifier="Some-TACACSPLUS-client"}
AuthorizeGroup group1 permit service=shell cmd=show cmd-arg=.*
Example
This example shows how to match a command with multiple
arguments. For example: logout subscribers username testuser
Here the last parameter, the target username, varies between commands.
Therefore only fixed arguments are configured with
AuthorizeGroup.
AuthorizeGroup group3 permit service=shell cmd=logout \
cmd-arg=subscribers cmd-arg=username
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}
For
more examples, see
goodies/tacacsplusserver.cfg.
