While migrating the authentication of our ASA firewalls to tacacs, we enabled ‘enable’ authentication to tacacs and tried to switch to enable mode on the console. This did not work, and caused the following message in the tacacs log file:

Wed Jan 13 17:07:42 2010 [25444]: enable query for 'username' 13 from 10.x.x.x rejected

To fix this problem the tacacs configuration for the user needs to include the enable password in the profile, as shown below:

user = username {
login = des "XXXXXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
}
enable = des "XXXXXXX"
}

We use the following configuration on the ASA to enable AAA to tacacs.

aaa-server tacacs protocol tacacs+
aaa-server tacacs (outside) host 1.1.1.1
key TACACSKEY
aaa-server tacacs (outside) host 2.2.2.2
key TACACSKEY
aaa authentication ssh console tacacs LOCAL
aaa authentication telnet console tacacs LOCAL
aaa authentication serial console tacacs LOCAL
aaa authentication enable console tacacs LOCAL
aaa authentication http console tacacs LOCAL
aaa authorization command tacacs LOCAL

Tacacs is a great way to centralize user authentication, authorization and accounting. While tacacs originally is a Cisco thing, there is an open source server version available, tac_plus (http://www.gazi.edu.tr/tacacs/index.php?page=download). Installing the tacacs server is quite straight forward. Configuring the switch is not difficult either, as long as you think about possible failures. You don’t want to be locked out of your switches when your tacacs server is not available. I use the following configuration that uses two tacacs servers and asks for the enable password when neither of the tacacs servers is available. To enter ‘enable’ mode, the configured enable password suffices. Use the following Cisco configuration for a save AAA authentication.

NOTE: Always be careful when changing authentication and authorization configuration, as this might lock you out of the device. The savest way is to do this on the console of the machine.


aaa new-model
aaa authentication login default group tacacs+ enable
aaa authentication enable default enable
aaa authorization exec default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa authorization network default group tacacs+ if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
aaa session-id common
tacacs-server host 1.1.1.1 single-connection
tacacs-server host 2.2.2.2 single-connection
tacacs-server key TACACSKEY
tacacs-server directed-request

To restrict access to specific devices, you can configure an ACL in the tacacs configuration on the server (tac_plus.conf). See the example below.


user = username {
login = des "XXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
}
}
group = admin {
default service = permit
service = exec {
priv-lvl = 15
}
}
# acl's

acl = mgmt_devices {
permit = 12.12.12.12
permit = 13.13.13.13
}

We have a combination of Cisco 2500 terminal server (oldies) and some Avocent ACS terminal servers. All our cisco kit authenticates against a tacacs server (tac_plus) and I want to include the Avocent in the same central user-management infrastructure.

The Avocent manual includes some commands to configure it to authenticate against different back-ends. The tacacs commands and options are all explained, but these commands did not give me a working setup. Below I outline the steps in a small how-to to setup Tacacs authentication on an Avocent terminal server.

  1. Login to the avocent as root
  2. enter the command line interface:

    [root@hostname root]# CLI

    - Thanks for using the CLI -

    This interface allows you to easily modify configurations to customize
    and define the functionality of your unit.

    Some basic and useful keys are:
    up/down arrow - navigates up/down in the command history
    tab (once/twice) - shows the next possible option(s)

    Other hints:
    Put quotes around strings that contain spaces.

    Please refer to the Reference Guide for other special keys and
    additional information on how to use this interface.

    Press TAB to see the list of available options.

    cli>

  3. Configure the ACS to use tacacs for physical ports:

    cli>config physicalports all access authtype TacacsPlusDownlocal

  4. Configure the ACS to use tacacs for authentication to the terminal server itself:

    cli>config security authentication authtype tacasdownlocal

  5. Configure the tacacs parameters:

    cli>config security authentication tacplusauthsvr1 10.x.x.x
    cli>config security authentication tacplussecret T@C@CSk3y

  6. Commit the config:

    cli>config runconfig

  7. Save the config to flash:

    cli>config savetoflashadf

With the setup described above I was not able to succesfully login to the Avocent with a valid tacacs user. The following entries was written in the tacacs log file:

Thu Jul 30 18:29:16 2009 [23176]: pap-login query for 'testuser' ssh from hostname.domain rejected
Thu Jul 30 18:29:16 2009 [23176]: login failure: testuser hostname.domain (10.x.x.x) ssh

The cause of the problem was that the Avocent uses ‘PAP’ authentication and this needs to be configured separately for the tacacs user. See the example below:


user = testuser {
default service = permit
name = "Test User"
login = cleartext "password"
pap = cleartext "password"
service = exec {
priv-lvl = 15
}
}

I encountered a problem  when logging in with a ‘restricted’ rancid user (see article). This user does not have the proper authorization, since this is only setup to backup Cisco configuration. In my setup this is not a problem, but be aware of this issue. The problem can be seen in the tacacs log file:


Thu Jul 30 18:47:12 2009 [1541]: authorization query for 'rancid' ssh from cltsp-ts01.ams-spa rejected

When using rancid you have to store the username and password in a text file. When you don’t want to give the user privilege level 15 you have to store the enable password as well. Tacacs with authorization is the best solution to restrict access for the rancid user. Since the rancid user doesn’t need to change any configuration on the network devices, you can restrict the commands it is allowed to run.

When using tac_plus (http://www.shrubbery.net/tac_plus/) you can use the following definition for the rancid user:

user = rancid {
#    default service = permit
login = cleartext "XXX"
enable = cleartext "XXX"
name = "Rancid User"
service = exec {
priv-lvl = 15
}
cmd = show {
permit .*
}
cmd = write {
permit term
}
cmd = dir {
permit .*
}
cmd = admin {
permit .*
}
cmd = more {
permit .*
}

}

user = rancid {
#    default service = permit
login = cleartext “R4nc!d”
enable = cleartext “raNc1d_3naB1e”
name = “Rancid User”
service = exec {
priv-lvl = 15
}
cmd = show {
permit .*
}
cmd = write {
permit term
}
cmd = dir {
permit .*
}
cmd = admin {
permit .*
}
}T

The rancid user is automatically in enable mode because the privilege level is set to 15 in tacacs. You have to configure rancid no to enter enable mode. This is configured (for cisco devices) in ~rancid/.cloginrc

Enter the following details:

add user        *       rancid
add password    *       XXX
add method      *       telnet
add autoenable  *       1