TACACS+

TACACS+ can be used with the ExaLINK Fusion for authentication, authorization and accounting. Care should be taken when configuring TACACS+ as it is possible to block access to the device.

Configuring TACACS+ client

Minimally, a TACACS+ server and a passphrase must be supplied, before this can be enabled. Any number of servers can be configured and these are checked in order, until a TACACS+ server is found to which a connection can be established. Depending on your TACACS+ server side configuration, you may need to set the service key as well.

[email protected]ION> configure tacacs server 192.168.220.14 192.168.220.15
Using TACACS+ server 192.168.220.14, 192.168.220.15
[email protected]> configure tacacs secret m1-s3cr3t
Updated TACACS+ secret key
[email protected]> configure tacacs service system
TACACS+ service name set to "system"
[email protected]> show tacacs
Servers    : 192.168.220.14 192.168.220.15
Secret     : (hidden)
Service    : system (default)
Timeout    : 5.0 s (default)
Periodic   : disabled
Accounting : disabled
Status     : disabled

In this example, 192.168.220.14 is the primary server, and 192.168.220.15 the secondary. The timeout is the time required for the full authentication and authorization to complete.

TACACS+ uses TCP port 49 by default, however this can be changed by specifying the port number after the server's IP address, for example:

[email protected]> configure tacacs server 192.168.220.14:1111
Using TACACS+ server 192.168.220.14:1111

Accounting may be disabled, set to standard or set to verbose.

[email protected]> configure tacacs accounting standard
TACACS+ accounting level set to "standard"
[email protected]> show tacacs
Servers    : 192.168.220.14 192.168.220.15
Secret     : (hidden)
Service    : system (default)
Timeout    : 5.0 s (default)
Periodic   : disabled
Accounting : standard
Status     : disabled

The EXALINK Fusion may be configured to periodically check the authorization level of logged on users. If the TACACS+ server returns a different privilege level for the user, then the roles of the user will be updated appropriately.

[email protected]> configure tacacs periodic 120
TACACS+ periodic reauthorization set to 120.0 s
[email protected]> show tacacs
Servers    : 8192.168.220.14 192.168.220.15
Secret     : (hidden)
Service    : system (default)
Timeout    : 5.0 s (default)
Periodic   : 120.0 s
Accounting : standard
Status     : disabled

Before enabling TACACS+, ensure the server side is configured, and there is a user with administrator rights (privilege level 15). Enable TACACS+

[email protected]> configure tacacs enable
TACACS+ enabled

Now, before this session times out, try to start a second session logging on with the remote administrator credentials. If this session is able to log on, verify that this user has administrator rights, for example, by trying to change the accounting level:

[email protected]> configure tacacs accounting verbose
TACACS+ accounting level set to "verbose"

If this succeeded, then all is well, and you have a working system that is using the remote TACACS+ server to authorize users. However, if this second session failed, then there is a problem in the client or server's configuration and it is recommended to disable TACACS+ on the client until the configuration is adjusted.

[email protected]> configure tacacs disable
TACACS+ disabled

Note

When TACACS+ is enabled any locally defined users will not be able to login using their local credentials. Any local accounts that have the same username as an account on the server will take roles on permissions as defined on the server.

Recovery

If no TACACS+ servers are available, then the system falls back to local authentication. This means that if access to the ExaLINK Fusion is blocked by TACACS+, it is possible to recover by disabling access to the TACACS+ server(s). If the TACACS+ servers can be turned off, then access can be regained using the local administrator, admin. Alternatively, the network cable for the management interface on the ExaLINK Fusion can be removed, and the serial port used to logon as the local administrator.

TACACS+ server side configuration

The ExaLINK Fusion uses the privilege level returned by the initial authorization to determine which permissions to grant the remote user. A description of how to configure TACACS+ servers is beyond the scope of this document, but the key points are described here.

  1. The ExaLINK Fusion may need to be configured on the TACACS+ server side as an recognized client, for example by adding its IP address.

  2. The service type configured on the client ('system' in the example above), must match the configuration on the server side.

  3. Users must be configured to return default privilege levels. Depending on the TACACS+ server, this may be done on a per user level, or on the group that the user belongs to, or as a custom attribute of the form priv-lvl=XX, where XX is the privilege level.

  4. At least one user must have administrator rights, that is, privilege level 15.

Users of the tac_plus TACACS+ server should note that a service of shell requires additional parameters not currently supported by the Fusion. A service of system is known to work well with the Fusion and tac_plus. A simple config script for tac_plus can be downloaded here.

TACACS+ user permissions

The privilege level as returned by the TACACS+ server is used to map the user to a role. Please refer to User Management for more information on roles and their permissions and capabilities.

Privilege Role Permissions
0-2 guest limited to reading system information
3-4 monitor can read all information
5-8 user can configure ports
9-14 operator full access to non-security related settings
15 admin full access

TACACS+ accounting

The command line interface on the ExaLINK Fusion is a thin layer, through which calls are made to exalinkd, a daemon service. The interface to the service is through a JSON RPC API, which is accessible to other clients and user interfaces.

In order to capture the requests from all clients, the JSON API calls are accounted. A distinction is made between calls that request information and those that change state. The setter functions are accounted when the accounting level is set to standard. When the level is set to verbose, then the getter functions are also accounted. Calls that fail, for example due to bad parameters, are not accounted.

This page was last updated on May-14-2019.