TACACS+ on Ubuntu 14.04 LTS

ubuntu-logo32In this post I will be describing the steps required to install TACACS+ on Ubuntu 14.04 LTS. I will be compiling the TACACS+ daemon with ACL support for additional security.

I will also run through the basic configuration of Cisco devices to use TACACS+ for Authentication, Authorisation and Accounting.

History of TACACS+

Terminal Access Controller Access-Control System (TACACS) is a protocol providing a centralised server for remote Authentication, Authorisation and Accounting of network devices. The TACACS protocol was originally developed in 1984 by BBN Technologies for administering MILNET, which ran unclassified network traffic for DARPA and was first formally defined in RFC 927.

Cisco Systems added TACACS support to its network devices in the late 1980’s and went on to add a number of extensions to the protocol, most notably Extended TACACS (XTACACS) and TACACS plus (TACACS+).

Although derived from TACACS the TACACS+ protocol is an entirely new protocol and is not backwards compatabile with TACACS and XTACACS. TACACS+ uses TCP as its transport layer protocol, typically using port number 49. Unlike RADIUS TACACS+ separates the Authentication and Authorisation functions making it more flexible for network administration.

TACACS+ allows you to set granular access policies for users and groups, commands, location, subnet, or even device type. The TACACS+ protocol also provides detailed logging of users and what commands have been run on specific devices.


We will be using TACACS+ daemon provided by Shrubbery Networks for our installation of TACACS+. All commands will be run as root and therefore the first step is to use sudo to log into your root account:

Install Dependencies

As always before we can start the installation we need to update our repositories and install the package dependencies.

In this case the dependencies are as follows:

  • gcc
  • bison
  • flex
  • libwrap0-dev

Before installing the dependencies you can check if they are already installed using the dpkg -s command:

If the dependeincies are not installed issue the following command:

Install TACACS+

We will be using the TACACS+ daemon from Shrubbery Networks. At the time of writing the latest stable version is tacacs+-F4.0.4.26.

Download and extract the source code for TACACS+:

Change directory to the newly created tacacs+-F4.0.4.26 directory and view the installation file to see the installation options:

Sample output of the installation instructions:

If you would like to check all the options available when compiling the TACACS+ daemon run ./configure –help.

In our case the most of the defaults are suitable, the only changes I will make are to change the installation directory (using /usr rather than /usr/local), enable ACL support and enabling per user enable passwords using the following command:

After installing TACACS+ the binary files will be available in /usr/bin/ (if you chose to install into the default location the files will be in /usr/local/bin):

  • tac_plus is the TACACS+ daemon
  • tac_pwd is used to generate a Data Encryption Standard (DES) or Message-Digest 5 (MD5) hash from a clear text password. Note, if you want to use MD5 you need to use the -m option when generating the password.
Fix Library Links

Finally we need to ensure that the correct links to the libraries required are installed to ensure that the TACACS+ daemon starts correctly.

Tod do this add /usr/lib (if you did not change the path of the install using –prefix=/usr then add /usr/local/lib) to /etc/ld.so.conf:

Next reload the libraries using ldconfig:

Configure TACACS+

For this example I will be creating two groups called network_admin and sys_admin. The network_admin group will have full privilege 15 rights on the router while the sys_admin group will only have access to show commands, and be able to configure interfaces with the basic settings such as access vlan, trunk and description.

Each group will have an ACL applied, where the network_admin group will have access to any device while the sys_admin group will only be allowed to access specific devices.

Each user will have their own password and enable password. I will also show two methods for authenticating users:

  1. Using a configured password and the tac_pwd comand to encrypt it.
  2. Using a user that is configured on the system and authenticating from the /etc/passwd file.
tac_plus.conf file explanation

First we need to create the directory and tac_plus.conf file where the TACACS+ configuration will be defined:

We will also need to create a file where the TACACS+ accounting logs will be sent to.

I will run through the different sections of the tac_plus config file with a description of their purpose then I will provide a template that can be used to setup a basic server.

Encryption Key

The first thing that needs to be configured is encryption key used to encrypt packets between the daemon and clients. This key must match the key configured on the clients:


All accounting records are either written to a file, syslog at priority info, or both.In this example I will set the accounting records to be sent to both the file we created in /var/log/tac_plus, as well as syslog (to disable sending to syslog and only send to the file simply uncomment the line specifying syslog with #):

Access Control Lists

Next we will create the ACL’s that we will use for the different groups. Access Control Lists can be defined to limit user’s, or group’s, login and/or enable access by daemon client IP address or hostname. An ACL is referenced by its name, but must be defined before it can be referenced. The ACL is a series of permit or deny statements applied to the source IP address that the daemon client used to connected to the daemon. If no entry of the acl matches a given address, the result is an implicit deny.

The default syntax for ACL’s is as follows:

In our example I will allow the network_admin group access from any source address, while the sys_admin group will only be allowed access from a source of


Next we will create the groups and define what each group is authorised to do on the network devices. The default syntax for the configuration of groups is as follows:

Default services specifies the default <permission> for service authorization, either deny or permit.

If omitted, the default is ‘deny’.

Note: if used, default service must precede all other svc directives in a group clause.

Group attributes (group_attr) are attributes that will be inherited by users of the group, these include attributes such as ACL’s and expiry dates.

Services (svc) define services which the group is authorised to execute, these could be services such as telnet or commands that the group is authorised to execute. Authorisation  must  be configured on both the client and the daemon to operate correctly.

Command authorization is configured by specifying a list of <regex> to match command arguments and an action which is a <premission>. The default syntax for command authorization is as follows:

In our example each group will have a default service configured (for network_admin it is permit while the sys_admin groups default is to deny all services). Each group will also be associated with the ACL’s that were defined earlier and have an expiry date of 1 January 2015.

The network_admin team will be authorised to run any command on the devices, while the sys_admin team will have limited authorisation to run command.

The sys_admin team will be authorised to run the following commands:

  1. Authorised for enable mode.
  2. Authorised to run any show commands
  3. Authorised to exit (note not end) modes.
  4. Authorised to execute configure i.e. configure terminal.
  5. Authorised  to  enter Ethernet, FastEthternet or GigabitEthernet
  6. interface configuration.
  7. Authorised to change the switchport configuration.
  8. Authorised to change the description on interfaces.
  9. Denied from running any other commands.


Once we have configure the groups, we can define the users and associate them with their respective groups. The command syntax for users is the same used for groups. Any commands specifically defined for a user can override those defined for a group.

In the only attributes we will be giving the users are their membership to the groups defined above, passwords and enable passwords.

I will be configuring two user accounts:

  1. jonathanm, who will be a member of the network_admin team and will authenticate from a predefined DES encrypted password.
  2. bob, who will be associated to the sys_admin team and will authenticate from the system /etc/passwd. This requires the user to be configured on the TACACS+ server as well as having a valid password.

To create the password for jonathanm we will be using the tac_pwd command to generate a DES encrypted password to include in the tac_plus.conf file:

To create the user bob we will have to add the account onto the TACACS+ server:

Next we will generate enable passwords for each user using two different methods:

  1. User jonathanm will have his own enable password associated with his account.
  2. User bob will use a a default enable password configured.

The enable password for jonathanm will be generated the same way that his authentication password was defined, using the tac_pwd command:

For the user bob we will be using one of the specially defined users within the TACACS+ daemon “$enable$”. The “$enable$” user is used for a default, system wide, enable account that is used for any user that does not have a specific enable password configured. We need to generate an enable password for the “$enable$” user using tac_pwd:

Now that we have the passwords generated, we can create the user accounts and associate them to their respective groups.
Note: we must specify the login account as DES if we are using a password generated by tac_pwd:

Now that we have all the required defaults, user and group parameters we can add the config to the file:


Add TACACS+ as a Startup Service

As it stand once we have added the tac_plus.conf file to /etc/tacacs, we would be able to start the TACACS+ service and start authenticating and Authorising users. However if for some reason the server restarted we would have to login and start TACACS+ service manually.

The steps bellow will detail adding the TACACS+ service to etc/init.d and /etc/init/rc-sysinit.conf so that it will start automatically upon reboot of the server.


First we need to setup the default behaviour of the tac_plus command. In this we will define the default configuration file to use when starting the TACACS+ daemon and any other special operations such as debugging and DNS lookups. For a full list of the operations see man tac_plus:

To do this we need to create a default profile under /etc/default for tac_plus:

Add the following template to /etc/default/tac_plus:


As you can see we currently don’t have any start/stop scripts configured for tac_plus within init.d:

So the next step is to add the start/stop script to /etc/init.d/tac_plus:

Add the following script to /etc/init.d/tac_plus:

Now that we have added the /etc/default/tac_plus and /etc/init.d/tac_plus scipts we will be able to use /etc/init.d/tac_plus start and /etc/init.d/tac_plus stop to start and stop the TACACS+ daemon:


Now that we have the init.d script configured we can add the /etc/init.d/tac_plus script to /etc/init/rc-sysinit.conf so that the init.d script will be executed at start up. We do this using update-rc.d:

The command above tells the system to add the tac_plusService to the default runlevels at startup:

Verification that TACACS+ is Running

Now that we have the TACACS+ daemon configured, we need to confirm that it is running. To do this we can use netstat, ps and check the syslog logs to ensure everything started correctly:

First start the TACACS+ daemon using the start/stop script defined in /etc/init.d/tac_plus:

Check the output in the syslog log file:

Make sure the tac_plus process is running:

Ok, cool it looks like everything started up correctly, notice that in the output of ps we can see that the TACACS+ daemon started using the options we defined in /etc/default/tac_plus.

Next lets make sure that the TACACS+ daemon is listening for connections on port 49 TCP using netstat:

Excellent everything started as it should have and we are listening for connections on TCP port 49.

Testing using a Cisco Network Device

To test the TACACS+ server I will be using GNS3 version 1.1, using the following IOU images:

  1. R1: i86bi-linux-l3-adventerprisek9-
  2. SW1: i86bi-linux-l2-ipbasek9-15.1b.bin

The network diagram is as follows:


Cisco Device Setup

Firstly we need to define the TACACS+ server we will be using to authenticate and authorise users off of, in this example we are using We also need to specify the encryption key that is configured on the TACACS+ server to ensure that the packets between the client and the TACACS+ daemon are encrypted:

Next we have to setup the AAA method lists that the Cisco device will use for Authentication, Athorization and Accounting using the following template:

  1. The aaa new-model command enables the AAA security services.
  2. aaa authentication login default group tacacs+ local: defines the default method list. Incoming ASCII logins on all interfaces (by default) will use TACACS+ for authentication. If no TACACS+ server responds, then the network access server will use the information contained in the local username database for authentication.
  3. aaa authentication enable default group tacacs+ enable: defines the default list to be used for enable access to the network device via TACACS+ and falling back to the configured local enable password or secret if the TACACS+ server is offline.
  4. aaa authorization config-commands: ensures that configuration commands are authorised by the TACACS+ server.
  5. aaa authorization commands x default group tacacs+ local: configures command authorization via TACACS+, falling back to local if the TACACS+ server is offline. We need to configure authorisation for commands run by users in both privilege levels we defined in our TACACS+ groups (i.e. 15 for the network_admin group and 0 for the sys_admin group
  6. aaa accounting command x commands 0 default start-stop group tacacs+: configures command accounting via TACACS+. This must be configured for each privilege level being used on the device.
  7. aaa accounting network x start-stop group tacacs+: configures network accounting via TACACS+. This must be configured for each privilege level being used on the device.
  8. aaa accounting connection x start-stop group tacacs+: configures connection accounting via TACACS+. This must be configured for each privilege level being used on the device.
Testing Authentication

To test authentication I will log into R1 using both the jonathanm and bob accounts created earlier and display output of the /var/log/tac_plus logs and /var/log/tac_plus/tac_plus.acct logs.

Output from terminal:

Output from /var/log/tac_plus.log:

From the logs above we can see that authentication for the user jonathanm passed the ACL checks and was allowed to authenticate and enable using the passwords that we created using tac_pwd.

Output of /var/log/tac_plus/tac_plus.acct:

As you can see each command that was issued by the user jonathanm is logged in /var/log/tac_plus/tac_plus.acct.

Next, lets try and log in to R1 using the second account we created. We should not be able to authenticate using the username bob as the ACL defined earlier only allows access to the switch on the network ( The output is from the terminal and /var/log/tac_plus.log:

Output from terminal:

Output from /var/log/tac_plus.log:

Perfect, the ACL blocked the user bob from accessing the router as we configured it to.

Now lets see if user bob can log in to and issue some commands, as before the output is from the terminal, /var/log/tac_plus.log and /var/log/tac_plus/tac_pluss.acct:

Output from the terminal:

Output from /var/log/tac_plus.log:

As you can see from the logs above, any commands that bob was not authorised to execute have been rejected.

Output from /var/log/tac_plus/tac_plus.acct:

The accounting logs show the commands that bob was authorised to execute.

So after seeing the results of the above test we can now say that our TACACS+ server is correctly configured to provide AAA services to our network devices. I hope this has been helpful, and please add to the comments if you have any questions.



15 thoughts on “TACACS+ on Ubuntu 14.04 LTS”

  1. Hi,

    Am having a problem my tacacs is reporting this error.

    Wed Jul 1 18:19:01 2015 [1620]: session.peerip is
    Wed Jul 1 18:19:01 2015 [1759]: connect from []
    Wed Jul 1 18:19:06 2015 [1759]: Error Illegal major version specified: found 13 wanted 192

    please any idea on how to fix it would be great.


  2. Yeah super helpful. I’m a complete newbie so I had to look up things like vi and how to use it but still was able to follow along pretty well. One thing I’m stuck on is how did you generate the DES hashes? You mention tac_pwd is used but how? I guess knowing linux basics is a prerequisite for this guide.

  3. I think You forgot to include the part where you are supposed to add the user bob using the useradd command. This is the part I got stuck on until a quick google search cleared it up for me.

  4. Hi, Jonathan

    Thank you very much for this article. I found interesting project – tacacsgui.com. It is self-hosted front-end UI for tac_plus configuration. My installation was easy, try it. Plus it has some advantages like Backup Maker for auto backup, Subnet searcher for subnets collection etc. Good luck!

  5. Thanks, I had a goal to get Tacacs+ running somewhere today, and between the different versions and packages available in various distros, it was a little daunting. After I decided to spin up a Ubuntu 16.04 in Virtualbox and use their tacacs+ package, I realised that they are using Shrubbery’s version of Tacacs+. I somehow found your writeup and it quickly filled in all the gaps in my thinking. Great writeup with sane examples that make sense, with very nice explanations to help it sink in a bit. I have a router in GNS3-VM in vmware, authing to the Ubuntu 16.04 in virtualbox and it is working wonderfully. So much fun. Thanks for helping me out!

Leave a Reply