Introduction to securing network device with TACACS+


This article introduces the TACACS+ protocol and describes how it secures access to your network devices.

TACACS+ is commonly applied to give administrators and engineers access to switches and routers.

It is widely implemented on entreprise Cisco and Juniper networks.

Radius is another popular protocol for doing the same job.

Radius is often the default protocol for user authentication to a wifi network.

In many organisations Windows AD is the primary user control for letting users on a network.

As a result many managers will ask for the TACACS+ or Radius server setup to integrate with AD so that all users are maintained on the same AD database.

Device administration VS network user access

Unlike a normal user who is logging into the network to gain access to files, servers and other resources; an administrator logins to a device to check specific health statistics, interface or device resource status or to run commands to troubleshoot problems.

The framework which underpins the administration access to a network device is called AAA which stands for authentication, authorisation and accounting.

A “triple A” server performs the following functions:

– authenticate i.e. determines who can log into the network device;

– authorise i.e. determine what level of access is allowed to the authenticated user to perform functions – such as running a command;

– account i.e. record session details such as login and logout time and commands executed during the session.

TACACS+ and Radius are two industry standard protocols that implement these AAA functions.
At present TACACS+ is still a superior protocol for controlling device administration access because it performs strongly in the authorisation area of AAA compared to the Radius protocol.


Authentication requires a user to enter his username and password before access is granted.

Behind the scenes the AAA protocol processes the authentication request by checking against the configured user / password details.

It will return with 3 possible outcomes:

– pass

– fail


If the user credentials supplied are incorrect, the AAA protocol response is a fail and access is denied.

Trying … Open
User Access Verification
Username: henry Password:
% Authentication failed

Behind the scenes of AAA protocol would return a message like this:

*May 1 00:13:33.419: AAA SRV(00000005): Return Authentication status=GET_PASSWORD
*May 1 00:13:34.163: AAA SRV(00000005): process authen req
*May 1 00:13:34.163: AAA SRV(00000005): Authen method=SERVER_GROUP tacacs+
*May 1 00:13:34.175: AAA SRV(00000005): protocol reply FAIL for Authentication
*May 1 00:13:34.179: AAA SRV(00000005): Return Authentication status=FAIL


Depending on role, we may wish to define what commands are allowed for an authenticated user.
For example we may wish to grant a helpdesk operator a basic level of access to run a ping command on a Cisco router but not let him view the configuration via the ‘show running-config’ command.

You can achieve this form of selective command authorisation via TACACS+.

Here is an example for user ‘harry’ who is not authorised to execute the ‘show running-config’ command at the exec shell on a Cisco router.

User Access Verification
Username: harry Password: ******

R1#show running-config
% Invalid input detected at ‘^’ marker


When a network is disrupted and a change to the device configuration is deemed as a probable cause it is often useful to find out who and when the last configuration was updated.

Accounting records are stored in log (text) files which are readable even by non technical users.

Here is an example of a record from a tac_plus server (which is a popular implementation TACACS+ server on linux).

The user ‘tom’ has just login and ran these commands:

User Access Verification
Username: tom Password: ******
R1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#do show running-config
Building configuration…
Current configuration : 1537 bytes
version 12.4
service timestamps debug datetime msec

<deleted output>

Now let’s examine the tac_plus server’s accounting records which is found in a txt file ‘tac_plus.acct’.
You can see that they correspond to what ‘tom’ has done on the router

[admin@x.x.x.x tac_plus]# cat tac_plus.acct
Jun 30 22:38:27 tom tty130 stop task_id=24 timezone=UTC service=shell priv-lvl=15 cmd=configure terminal
Jun 30 22:38:32 tom tty130 stop task_id=26 timezone=UTC service=shell priv-lvl=15 cmd=show running-config
Jun 30 22:38:32 tom tty130 stop task_id=25 timezone=UTC service=shell priv-lvl=15 cmd=do sh run

AAA backup and redundancy considerations

Given the TACACS+ server is the central point of control for administration access, if the TACACS server goes down then administrators may no longer be able to get on a network device.

Therefore for most TACACS+ server deployments engineers will pay special attention to mitigate this risk:

– by deploying backup tacacs+ servers

– by setting up a failover ‘authentication’ method

– by having remote access to the console out of band and independent from TACACS+

Backup TACACS+ servers mean within the device configuration we can define a group of TACACS+ servers.

Here are some statements to configure 2 servers in the same group.

aaa group server tacacs+ ACME_TACACS

To set up a failover ‘authentication’ method we can rely on using local administration accounts.

Network devices allow creation of such local administration accounts on the device itself.

For example, the adminstrator can set up 2 users on the local database.

An admin user with full privileges and a operator user with restricted access.

On a Cisco device to use the local username database we would configure:

username admin secret adminpassword1 privilege 15
username operator secret operatorpassword2 privilege 7

However it is easier to do this on your AAA server and I will describe this in a later article.

Deploying TACACS+

Planning for TACACS+ is fortunately straightforward.

Here is a list of things to plan for:-

– allocate the IP address for the TACACS+ server

– confirm the tacacs key – this must match what is on your server and be created on each device.

– consider where the placement of server in relation to devices it is to manage.

– if there is a firewall between the TACACS+ server and any managed device, ensure tcp port 49 is allowed

– determine the level of privilege to grant to users appropriate to their roles

– document your TACACS+ set up and have a process in place for user changes, lost password recovery etc

Testing the tacacs setup is crucial prior to full roll out. Check that your accounting records are written correctly to the accounting log file.

You do not want to be in a situation where you have no forensics detail or incorrect detail captured when you need the information.

Careless administrators have known to lock themselves out by misconfiguring TACACS+.

If that happens a site visit might become necessary to recover remote access.

Products that provide TACACS+

Here are some TACACS+ server products available to you. TACACS+ is a bit of a niche market hence there are not too many products to choose from.

Usually commercial products will support both TACACS+ and Radius on the same software.

Cisco ACS 5.5

Although TACACS had it’s beginnings in the 1980s, it was Cisco who developed and released the open source code for it in the early 1990s.

Therefore until recently widely deployed by many enterprises with Cisco networks but anticipated to be replaced by Cisco ISE in future.

Runs on Windows. Also has Radius support.


This is a Windows based TACACS+ server which has some parties offering commercial support contracts for it.

ClearBox Server for Windows

This is a commercial TACACS+ / Radius product from Xperience Technologies that runs on Windows.

TAC_PLUS on Linux

Free version which can run on many distributions of Linux.

However support documentation is sketchy is non-existent and setting it up can be hit and miss depending on skill level and the the environment of the Linux machine you are installing on.