Category Archives: TACACS+

TACACS+, Part 3: Network device config

In this final post about TACACS+, I’ll go into detail about the router/switch configuration, including an ASA and Dell PowerConnect switches. In case you missed the previous two posts, you can find them here:

TACACS+ Part 1 – Choosing the Version

TACACS+ Part 2 – tac_plus install and config

For routers and switches, there are three important config components; aaa new-model, tacacs-server and line configuration. The config snippet below configures all three, and also sets up TACACS+ for use on the console port as well. In the ‘aaa authentication’ section, the router is set to call the TACACS+ server first, and if no valid usernames are found, check local usernames.

Although, I discovered some interesting behavior: the router will always attempt to contact the TACACS+ server, even if its unreachable. And the only time the local usernames will work is when the TACACS+ server can’t be reached.

So far, this snippet has worked on IOS 12.2, 12.4 and 15.0.

aaa new-model
!
aaa authentication login tac_plus1 group tacacs+ local
aaa authorization console
aaa authorization exec tac_plus2 group tacacs+ local
!
tacacs-server host 192.168.1.1
tacacs-server host 192.168.1.2
tacacs-server key **password_goes_here**
!
line con 0
 authorization exec tac_plus2
 login authentication tac_plus1
line vty 0 4
 authorization exec tac_plus2
 login authentication tac_plus1
 transport input telnet ssh

On Dell PowerConnect switches, the configuration is a little easier, save for specifying the TACACS+ port number, and including a source address for the traffic.

conf
!
aaa authentication login tac_plus1 tacacs local
tacacs host 192.168.1.1 port-number 49 priority 10
tacacs host 192.168.1.2 port-number 49 priority 20
tacacs key **password_goes_here**
!
tacacs source **mgmt_ip_address**
!
line telnet
login authen tac_plus1
line ssh
login authen tac_plus1
line con
login authen tac_plus1

And finally, directions for the ASA. No doubt security blue bloods will decry me for using the ASDM (“Real pros use cli…”), but I find it easier to visualize the rules sets in ASDM versus cli. These directions won’t elevate your login permission to level 15 though, so you’ll still have to enter the enable secret on the cli. If you figure out how to elevate the login permission, let me know!

1. Create a AAA_Server Group for the tac_plus servers
2. Go to AAA_Access and set the Server Group for
   ASDM,https and serial access under the Authentication tab.

TACACS+, Part 2: tac_plus install and config

In TACAS+ Part 1, I discussed the reasons to use TACACS+, and why I choose the version written by Marc Huber. Here, I’ll dive into installing tac_plus on Ubuntu 10.04, and configuration of the tac_plus daemon itself.

Despite being a Linux beginner, installing tac_plus on Ubuntu server wasn’t too hard. Below is my checklist.

  1. Install the libssl-dev package
  2. Install CPAN modules:
    1.  Net::SSLeay
    2. IO::Socket::SSL
  3. Install the tac_plus program. I created a working folder of /home/installs for this:
    1. /home/installs# mkdir tac_plus
    2.  /home/installs/# cd tac_plus
    3.  /home/installs/tac_plus# wget http://www.pro-bono-publico.de/projects/src/DEVEL.201111101610.tar.bz2
    4. /home/installs/tac_plus# tarc -xvf DEVEL.201111101610.tar.bz2
    5. /home/installs/tac_plus# cd PROJECTS
    6.  /home/installs/tac_plus/PROJECTS# ./configure
    7.  /home/installs/tac_plus/PROJECTS# make
    8. /home/installs/tac_plus/PROJECTS# make install
  4. Copy the attached tac_plus.conf file to /etc
  5. Verify the file tac_plus has been copied to /etc/init.d
  6. Modify that file so it will run at startup
    1. /etc/init.d# chmod -x tac_plus
  7. Make the tac_plus daemon start at boot
    1. update-rc.d tac_plus defaults
  8. Manually start the daemon:
    1. tac_plus /etc/tac_plus.conf

Once the server began running with the default configutation, it was time to tweak it to make it authenticate against AD. Most importantly, I needed to have tac_plus encrypt its entire communication with AD – nothing in the clear. In nearly all cases, the most powerful IT accounts in the enterprise were getting passed. They must be protected, even internally.

Your environment may be slightly different, depending on DC setup, but the below configuration eventually worked (after much cursing and wiresharking). Especially note the “ldaps://yourdomain.com:636”. The combo of both ldaps:// and :636 is what finally provided the encrypted communication.

id = tac_plus {
debug = MAVIS

accounting log = /var/log/tac_plus/acct.log
authentication log = /var/log/tac_plus/authen.log

mavis module = external {
# Optionally:
script out = {
# Require group membership:
if (undef($TACMEMBER) && $RESULT == ACK) set $RESULT = NAK

# Don’t cache passwords:
if ($RESULT == ACK) set $PASSWORD_ONESHOT = 1
}
setenv LDAP_SERVER_TYPE = “microsoft”
setenv LDAP_HOSTS = “ldaps://yourdomain.com:636”
setenv LDAP_SCOPE = sub
setenv LDAP_BASE = “dc=yourdomain,dc=com”
setenv LDAP_FILTER = “(&(objectclass=user)(sAMAccountName=%s))”
setenv LDAP_USER = “!daps@yourdomain.com”
setenv LDAP_PASSWD = “DeuxManySecrets”
setenv AD_GROUP_PREFIX = Tacacs
setenv REQUIRE_AD_GROUP_PREFIX = 1
exec = /usr/local/lib/mavis/mavis_tacplus_ldap.pl
}

While this gave us tac_plus server-to-AD encryption, we still needed encryption between the router and the tac_plus server. Happily, tac_plus provides this by using a complex key. On the tac_plus server, it looks like this:

host = Router {
address = 192.168.1.1/32
key = >>Complex_Key_Goes_Here<<
}

On the router, the cmd is:

tacacs-server key >>Complex_Key_Goes_Here<<

Testing showed this is not quite encryption, but rather an MD5 hash with additional entropy, but it gets the job done. The remainder of the server config is explained well in the tac_plus docs. These sections were the only tough nut to crack.

In TACACS+ Part 3 of this series, I’ll cover configuration of the routers, using IOS 12.2, 12.4 and 15.0, as well as ASA firewalls on 8.2.

TACACS+, Part 1: Choosing the Version

My current work environment has a decent Cisco footprint – 242 devices in all. Maintaining usernames and passwords on them is quite a chore, even with some assistance from scripting tools like Kiwi Cat Tools. We simply needed centralized login control, one way or the other.

We had a short list of important requirements:

  1. It had to integrate with AD, to minimize the number of user accounts in use.
  2. The entire login exchange had to be encrypted. The most powerful administrative accounts would be passing their credentials over the system. This requirement eliminated RADIUS as a solution, since the Cisco IOS versions we’re using (12.4 & 15.0.1) would pass usernames in the clear and only MD5 hash the passwords.
  3. It would give use centralized user account control, and provide for varying level of user activity logging.
  4. It had to be free.  This push came at the end of the year (after most of the budget was spent). Of course this meant no ACS.

After much research, I decided to use TACACS+. The implementation of TACACS+ I choose was tac_plus, written by Marc Huber. There were several version of TACACS+ out there, but Marc’s seemed the best fit as it was (a) open-source, (b) the most recent, (c) had the most complete documentation and (d) had the most recent and active forum of users giving feedback. You can find docs for tac_plus and associated daemons here, and the current forum here.I installed tac_plus on Ubuntu servers, version 10.04, and so far have had no compatibility problems. For redundancy, we’re using two Ubuntu servers running tac_plus with identical configurations.

In TACACS+ Part 2, I’ll discuss installation and configuration of tac_plus.