Table of Contents Table of contents: Radiator® AAA Server <ServerDIAMETER> 3.118 - <ServerDIAMETER> <ServerRADSEC> 3.120 - <ServerRADSEC>

3.119. <ServerTACACSPLUS>

This clause tells Radiator to act as a TACACS+ server as well as a RADIUS server.
TACACS+ is an Authentication, Authorisation and Accounting (AAA) protocol developed by Cisco and supported by devices from Cisco, Juniper, HP and other vendors. It uses TCP connections between the client device and the TACACS+ server. Newer Cisco devices generally support both RADIUS and TACACS+ or just RADIUS. Some older Cisco devices only support TACACS+. In addition, there are some Cisco security facilities that are only available through TACACS+.
The <ServerTACACSPLUS> clause handles TACACS+ AAA requests in the following way:
Tip
By default, Radiator requires that the user has previously authenticated with this Radiator instance before accepting any TACACS+ authorisation requests. The authentication reply provides the authorisation information Radiator needs to handle the subsequent TACACS+ authorisation requests. If the optional parameter AllowAuthorizeOnly is enabled, Radiator requests authorisation information even if the user has not previously authenticated with this Radiator instance. For more information, see Section 3.119.13. AllowAuthorizeOnly.
Tip
If <ServerTACACSPLUS> is used to authenticate administrator access to a Cisco device, you need to add specific authorisation attributes to allow administrative access. For example, to get administrative access to a Cisco Aironet wireless Access Point requires that the authorisation include a TACACS+ attribute-value pair like: 
aironet:admin-capability=ident+admin
You can achieve this by having a suitable cisco-avpair reply item for the relevant user in your Radiator database:
ciscouser User-Password=fred
      cisco-avpair="aironet:admin-capability=ident+admin"
You can also achieve this by having an AuthorizationAdd parameter in your <ServerTACACSPLUS> clause:
AuthorizationAdd aironet:admin-capability=ident+admin
This example enables only some levels of administrative access (ident and admin). See your Cisco device documentation for more details.
Tip
Devices from other vendors than Cisco, such as Juniper, may also accept ciscoavpair attributes.
<ServerTACACSPLUS> can be used with any Radiator authentication method that understands plain text passwords, such as FILE, SQL, LDAP2, DBFILE, and also with any method that challenge the user for additional authentication data,such as DIGIPASS, ACE, OTP, INTERNAL.
Tip
You can use the TACACS+ test client goodies/tacacsplustest in your distribution to send test TACACS+ requests.
During request processing, <Server TACACSPLUS> looks for a Client clause that matches the origin of the TACACS+ request, as described above. If found, a number of parameters from the Client clause are used during processing:

3.119.1. Key

This parameter specifies the default shared secret to be used to decrypt TACACS+ messages. When a new connection from a TACACS+ client is received, <ServerTACACSPLUS> tries to find a key to use for decrypting that connection. It first looks for a matching Client and then for a key until it finds one that has been defined:
  • If a matching Client is found: EncryptedTACACSPLUSKey parameter is preferred over TACACSPLUSKey parameter
  • EncryptedKey
  • This Key parameter
  • If a matching Client is found: EncryptedSecret parameter is preferred over Secret parameter
Note
EncryptedTACACSPLUSKey and EncryptedSecret are currently experimental and will be documented later.
Tip
If all your TACACS+ devices use the same key, use this Key parameter. If some or all of your TACACS+ devices use different keys, define a Client and TACACSPLUSKey for each differing one and set this Key as the default for the rest. If some TACACS+ clients are also RADIUS clients, define a Client clause for each one, specifying the RADIUS secret in Secret, and the TACACS+ key in TACACSPLUSKey.
Key mysecret

3.119.2. EncryptedKey

This parameter specifies the default shared secret to be used to decrypt Tacacs+ messages. When a new connection from a Tacacs+ client is received, ServerTACACSPLUS tries to find a Key to use for decrypting that connection. EncryptedKey is in encrypted format and is preferred over Key. For more information, see Section 3.119.1. Key.
EncryptedKey is currently experimental and will be fully documented later.

3.119.3. Port

This optional parameter specifies which TCP port the server will listen on for incoming Tacacs+ connections. Defaults to 49 (which generally requires root or other privileged access) Any valid port number or service name can be used.
Port 1024

3.119.4. BindAddress

This optional parameter specifies one or more network interface addresses to listen for incoming Tacacs+ connections on. It is only useful if you are running Radiator on a multi-homed host (i.e. a host that has more than one network address). Defaults to the global BindAddress, which defaults to 0.0.0.0 (i.e. listens on all networks connected to the host). For more information, see Section 3.7.9. BindAddress.
Using this parameter, you can run multiple instances of Radiator on the one computer, where each Radiator listens to Tacacs+ connections directed to a different host address. BindAddress can include special formatting characters, and multiple comma separated IPv4 and IPv6 addresses.
# Only listen on one IPv4 address and the IPv6 loopback
BindAddress 203.63.154.1, ::1

3.119.5. AuthorizationReplace

This optional parameter specifies Tacacs+ authorisation attribute-value pairs that are to replace those suggested by the Tacacs+ client. It effectively overrides the default authorisation that the client would use.
You can have as many AuthorizationReplace parameters as you wish, one for each Tacacs+ authorisation attribute-value pair:
AuthorizationReplace service=aironet
AuthorizationReplace protocol=shell
AuthorizationReplace aironet:admin-capability=ident+admin

3.119.6. AuthorizationAdd

This optional parameter specifies Tacacs+ authorisation attribute-value pairs that are to be added to those suggested by the Tacacs+ client. It effectively increases the default authorisation that the client would use.
You can have as many AuthorizationAdd parameters as you wish, one for each Tacacs+ authorisation attribute-value pair:
AuthorizationAdd aironet:admin-capability=ident+admin

3.119.7. AddToRequest

This optional parameter adds any number of RADIUS attributes to the RADIUS requests generated by ServerTACACSPLUS. It can be used to tag requests arriving from Tacacs+ for special handling within Radiator or in remote RADIUS servers.
AddToRequest NAS-Identifier=TACACS

3.119.8. AuthorizationTimeout

This optional parameter changes the timeout period for handling a complete TACACS+ conversation, including the authentication any subsequent authorisation requests. Defaults to 600 seconds. If the timeout expires, further authorisations for an earlier authentication will not be valid, and will be rejected.

3.119.9. DefaultRealm

This optional parameter can be used to specify a default realm to use for received TACACS requests that have a user name that does not include a realm. If the incoming user name does not have a realm (i.e. there is no @something following the user name) and if DefaultRealm is specified, the User-Name in the resulting RADIUS request will have @defaultrealm appended to it. The realm can then be used to trigger a specific <Realm> or <Handler> clause. This is useful if you operate a number of TACACS clients for different customer groups and where some or all of your customers log in without specifying a realm.
Tip
You can override this on a per-client basis by setting DefaultRealm in the Client clause. 
# Realmless logins to this NAS will be treated
# as if they are for realm open.com.au
<ServerTACACSPLUS>
      Key ....
      DefaultRealm open.com.au
</ServerTACACSPLUS>
<Realm open.com.au>
      .....
</Realm>

3.119.10. GroupMemberAttr

When AuthorizeGroup is use to specify TACACS+ user privileges, GroupMemberAttr specifies the name of the RADIUS reply attribute in the Access-Accept that is expected to contain the name of the TACACS+ users privilege group. This group name will then be used by AuthorizeGroup to determine which privileges can be extended to that user. If there is no such attribute in the Access-Accept, the TACACS+ group name for the user will be assumed to be ’DEFAULT’. If GroupMemberAttr is not defined in the configuration file, then all TACACS+ users will be assumed to have a TACACS+ group name of ‘DEFAULT’.
The RADIUS attribute named by GroupMemberAttr may be a real RADIUS attribute received from a remote RADIUS server (in the case where the remote RADIUS server provides the authentication of TACACS+ requests). Or it could be pseudo RADIUS attribute added to the reply by an AuthBy internal to the current Radiator server.
# Name of the pseudo attribute containing the TACACS group name
# in RADIUS Access-Accepts:
GroupMemberAttr tacacsgroup

3.119.11. AuthorizeGroup

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:
  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

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.

3.119.12. AuthorizeGroupAttr

If this parameter is specified, it specifies the name of an attribute in Access-Accept that will contain per-command authorisation patterns for authorising TACACS+ commands for this user. Multiple attributes are supported with each attribute containing one pattern. The format is the same as the AuthorizeGroup parameter above excluding the group name. These patterns are processed before any configured-in AuthorizeGroup parameters.
As an example, a users file to grant group1 member ‘mikem’ an additional right to use ping command would look like below. The Radiator <ServerTACACSPLUS> clause is configured with GroupMemberAttr OSC-Group-Identifier and AuthorizeGroupAttr OSC-Authorize-Group.
mikem User-Password=fred
      OSC-Group-Identifier = group1,
      OSC-Authorize-Group = "permit service=shell cmd=ping"

3.119.13. AllowAuthorizeOnly

When enabled, this parameter allows Radiator to create a RADIUS Access-Request with Service-Type attribute set to Authorize-Only when TACACS+ authorisation request is received but Radiator has no previous information about the user's authorisation. This can happen if the TACACS+ client does not use TACACS+ for authentication, has authenticated against another TACACS+ server, Radiator has been reloaded, or AuthorizationTimeout has expired. This is disabled by default.
For example, Cisco 'aaa new model' allows non-TACACS+ authentication with TACACS+ based accounting and authorisation: you can authenticate with local user name, Radius, or kerberos and then do command authorisation over TACACS+.
The default for Radiator is to require TACACS+ authentication first to create the authorisation context before being able to do command authorisation. If AllowAuthorizeOnly is enabled, an existing authorisation context is not required.
Before enabling this option, we recommend considering if it is acceptable to trust the TACACS+ client authentication and allow Radiator to do command authorisation without any previous knowledge about the users' authentication.

3.119.14. UsernamePrompt

This optional parameter sets the prompt that ServerTACSPLUS will use to prompt the client for a user name when the Tacacs authen-type of ASCII is used. Defaults to ‘Username: ‘.

3.119.15. PasswordPrompt

This optional parameter sets the prompt that ServerTACSPLUS will use to prompt the client for a password when the Tacacs authen-type of ASCII is used. Defaults to ‘Password: ‘.

3.119.16. IdleTimeout

If a TACACS+ client stays connected for more than this number of seconds without sending any requests it will be disconnected. Defaults to 180 seconds. A Value of 0 means no idle timeout will apply, and clients can stay connected forever.

3.119.17. AuthenticationStartHook

Specifies a Perl hook to run when a TACACS+ Authentication Start is received. It can be used for special processing of TACACS+ Start requests. If the hook returns an empty list, normal processing of the request will continue else no further processing will be done and the hook is expected to handle the request.
The hook is passed the following arguments:
  • Pointer to the current ServerTACACSPLUS clause
  • Pointer to the temporary RADIUS request that has been constructed to represent the TACACSPLUS authentication request
  • The action attribute from the incoming TACACSPLUS request. This describes the authentication action to be performed. One of $Radius::Tacacsplus::TAC_PLUS_- AUTHEN_*.
  • The authen_type attribute from the incoming TACACSPLUS request. The type of authentication that is being performed. One of $Radius::Tacacsplus::TAC_PLUS_- AUTHEN_TYPE_*.
  • The priv_lvl attribute from the incoming TACACSPLUS request. This indicates the privilege level that the user is authenticating as. One of $Radius::Tacacsplus:: TAC_PLUS_PRIV_LVL_*.
  • The service attribute from the incoming TACACSPLUS request. This is the service requesting the authentication. One of $Radius::Tacacsplus::TAC_PLUS_AUTHEN_SVC_*.

3.119.18. AuthenticationContinueHook

Specifies a Perl hook to run when a TACACS+ Authentication Continue is received. It can be used for special processing of TACACS+ Continue requests. If the hook returns an empty list, normal processing of the request will continue else no further processing will be done and the hook is expected to handle the request.
The hook is passed the following arguments:
  • Pointer to the current Server TACACSPLUS clause
  • The body of the request a received in the incoming TACACSPLUS CONTINUE request. Contains the undecoded flags and fields from the request.
  • $Radius::Tacacsplus::TAC_PLUS_AUTHEN_SVC_*.

3.119.19. PreHandlerHook

This optional parameter allows you to define a Perl function that is called during packet processing. It can be configured within several types of clauses for which its functionality is slightly different:
  • Client clause
    PreHandlerHook is called for each request after per-Client user name rewriting and duplicate rejection, and before the request is passed to a Realm or Handler clause.
  • AuthBy clause
    The functionality depends on the used EAP authentication type:
    • PEAP, EAP-TTLS, EAP-FAST
      PreHandlerHook specifies a Perl hook to be called before the inner request is re-dispatched to a matching Realm or Handler.
    • LEAP
      If EAP_LEAP_MSCHAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
    • EAP-MSCHAPv2
      If EAP_PEAP_MSCHAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
    • EAP-GTC
      If EAP_GTC_PAP_Convert flag is set, PreHandlerHook specifies a Perl hook to be called before the converted request is re-dispatched to a matching Realm or Handler.
  • AuthBy DYNAUTH clause
    PreHandlerHook is called for each request created by the clause before the request is passed to a Realm or Handler clause.
  • ServerRADSEC clause
    PreHandlerHook is called for each request after global and per-ServerRADSEC user name rewriting and before the request is passed to a Realm or Handler clause.
  • ServerDIAMETER clause
    PreHandlerHook is called for each request received by ServerDIAMETER before the request is passed to a Realm or Handler clause.
  • ServerTACACSPLUS clause
    PreHandlerHook is called for each request before it is passed to a Realm or Handler clause. If a Client is found for the request, Client's PrehandlerHook is run before ServerTACASPLUS's PreHandlerHook. Global and per-Client user name rewriting and other processing is done before the hooks are run.
A reference to the request is passed as the only argument.
The hook code is compiled by Perl when Radiator starts up. Compilation errors in your hook code are reported to the log file at start-up time. Runtime errors in your hook are also reported to the log file when your hook executes. Multiline hooks with trailing backslashes (\) are parsed by Radiator into one long line. Therefore, do not use trailing comments in your hook.
PreHandlerHook can be an arbitrarily complicated Perl function, that might run external processes, consult databases, change the contents of the current request or many other things. Here is an example of using PreHandlerHook:
# Fake a new attribute into the request
PreHandlerHook sub { ${$_[0]}->add_attr('test-attr', \
      'test-value');}

3.119.20. SingleSession

This optional parameter tells the server to try to maintain a single TCP connection for all TACACS+ requests from the same client if the client permits. If this flag is set and if the TACACS+ client indicates a willingness to support single connections with the TAC_PLUS_SINGLE_CONNECT_FLAG, the TCP connection will not be closed by Radiator after each TACACS+ session. Defaults to 1.
Single sessions can be disabled regardless of client options by setting the SingleSession flag to 0.
Note
Default behaviour changed in 4.8. In versions of Radiator prior to 4.8, the default behaviour was to always try to keep the session open.

3.119.21. PacketTrace

This optional flag forces all packets that pass through this module to be logged at trace level 5 until they have been completely processed. This is useful for logging packets that pass through this clause in more detail than other clauses during testing or debugging. The packet tracing stays in effect until it passes through another clause with PacketTrace set off or 0.
PacketTrace is available for the following clauses:
  • Client
  • Handler
  • Realm
  • AuthBy
  • ServerDIAMETER
  • ServerRADSEC
  • ServerTACACSPLUS
Here is an example of using PacketTrace:
# Debug any packets that pass through here
PacketTrace

3.119.22. DisconnectTraceLevel

This optional parameter specifies log trace level for peer initiated disconnects. The default value is error level 0. When connections are known to be short-lived, a non-default value may be useful. This parameter is available for all Stream based modules, such as <ServerDIAMETER> and <AuthBy RADSEC>.
# Debug logging is enough for peer disconnects
DisconnectTraceLevel 4

3.119.23. DisconnectWhenIgnore

If the AuthBy returns IGNORE message because of an authentication backend database failure, DisconnectWhenIgnore flag parameter defines the server behaviour. When this is set, the server disconnects the client without returning TACACS+ error message before disconnecting. This may cause the client to continue with local authentication after the authentication backend failure.
Note
The client behaviour, when the TACACS+ error message is not sent, depends on its implementation.

3.119.24. ContextId

ContextId parameter specifies how to derive a lookup key for TACACS+ authentication context when authorizing TACACS+ requests. Context specific special characters supported are: TACACS+ client IP address (%0), TACACS+ client source TCP port (%1), TACACS+ user (%2), TACACS+ port (%3), TACACS+ rem_addr (%4). The default is fine for the most cases. Defaults to %2:%0.
# Base context lookup only on username
ContextId %2

3.119.25. GroupCacheFile

CAUTION
This option is deprecated and no longer does anything. AllowAuthorizeOnly replaces GroupCacheFile. For more information, see Section 3.119.13. AllowAuthorizeOnly.

3.119.26. Clients

This optional parameter specifies a list of IP addresses that connections will be accepted from. You can specify one or more comma or space separated IP addresses on each Client line. You can specify multiple Client parameters. Only exact matches are supported at present. The default is to accept connections from any and all clients.
If Clients is specified and a client attempts to connect from an IP address that is not named, Radiator will log a WARNING level message then reject and close the connection.
# Only accept connections from some addresses
Clients 127.0.0.1, 203.63.154.29
Clients 203.63.154.27
Table of Contents Table of contents: Radiator® AAA Server <ServerDIAMETER> 3.118 - <ServerDIAMETER> <ServerRADSEC> 3.120 - <ServerRADSEC>