Cisco Cookbook

Chapter 4. TACACS+

4.0. Introduction

The Terminal Access Controller Access Control System (TACACS) protocol dates back to an earlier era in networking when terminal servers were common. The terminal server was also called a Terminal Access Controller (TAC), so TACACS was the TAC Access Control System.

A company called BBN developed the TACACS protocol in the early 1980s. BBN played a key role in the early development of the Internet (parts of BBN were subsequently absorbed by companies such as Verizon and Cisco). The original protocol included only basic functionality to forward login credentials to a central server, and the ability for the server to respond with a pass or fail based on those credentials.

Cisco implemented several extensions to the original TACACS protocol in 1990, and called the new version XTACACS (Extended TACACS), which is described in RFC 1492. However, the IETF considers this RFC to be purely informational, and not an official protocol specification.

More recently, Cisco has replaced both of these earlier versions of TACACS with a newer implementation called TACACS+. The three different versions are not compatible with one another. In fact, Cisco considers the two earlier versions to be obsolete and no longer supports them, although they are still included in the IOS for backward compatibility reasons. This chapter focuses on only the newest TACACS+ version. There is no RFC protocol specification for TACACS+.

It is important to remember that TACACS+ is a Cisco proprietary standard, unlike the competing Remote Authentication Dial In User Service (RADIUS) protocol, which is an open standard documented in RFC 2865. However, Cisco strongly recommends using TACACS+ instead of RADIUS, and we support this recommendation. Cisco’s TACACS+ support is far more mature and robust than RADIUS. Another commonly cited reason for using TACACS instead of RADIUS is the transport model.

TACACS+ uses a TCP transport on port 49, which makes it more reliable than RADIUS, which uses UDP. RFC 2865 includes a lengthy technical defense of the RADIUS UDP implementation. However, TACACS+ and RADIUS use different implementation models. TACACS+ prefers to achieve reliable delivery of data between the client and server, while RADIUS prefers a stateless model that allows it to quickly switch to a backup server.

But there are also more tangible benefits to using TACACS+. The biggest real advantage is that TACACS+ allows true command authorization. This means that you can create very clear usage policies with TACACS+, where different users have access to different commands with very fine administrative granularity. TACACS+ can do this because it separates authentication and authorization functions, while RADIUS can’t because it combines them.

Another important advantage is that TACACS+ encrypts the entire payload of the client/server exchange. This is important in highly secure environments. RADIUS, on the other hand, encrypts only the password, so intercepting packets can reveal important information.

The strongest point in favor of RADIUS is the fact that it is an open standard implemented by many vendors, including Cisco. Therefore, if you operate a multivendor network that already includes RADIUS, you may prefer to use RADIUS with your Cisco routers. This chapter does not specifically cover RADIUS, although many of the concepts discussed here are equally applicable to both TACACS+ and RADIUS.

TACACS+ is part of Cisco’s AAA framework and works with each of these three functions separately:

Authentication

Identifies users by challenging them to provide a username and password. This information can be encrypted if required, depending on the underlying protocol.

Authorization

Provides a method of authorizing commands and services on a per user profile basis.

Accounting

Accounting functions collect detailed system and command information and store it on a central server where it can be used for security and quality assurance purposes.

Throughout this chapter, we will discuss some of the most important benefits of using centralized AAA services with TACACS+. These include the ability to administer login IDs from a central server, as well as centrally defining login and command authorizations for each user. This allows for easy grouping of users by their administrative functions. For example, you can give network operators access to one set of commands, web site administrators access to a different set, and still allow network engineers to have full access. In addition, you can centrally define and modify these capabilities so that a particular user has similar capabilities on all routers, without having to configure this separately on each router.

4.1. Authenticating Login IDs from a Central System

Problem

You want to administer login ID and password information centrally for all routers.

Solution

Cisco changed the AAA syntax slightly in Version 12.0(5)T. The following set of commands allows you to configure TACACS+ authentication in the older (pre-12.0(5)T) IOS versions:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default tacacs+
Router1(config)#aaa authentication enable default tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

Newer IOS versions require the group keyword, which defines server groups. Therefore, you would now configure the same functionality as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+
Router1(config)#aaa authentication enable default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

Discussion

When you configure AAA authentication on a router, it starts to ignore the locally configured passwords in favor of those provided by the TACACS+ server. In this example, we have configured the router to consult TACACS+ for both the login and enable passwords. This is a great labor saver because it means that you don’t have to reconfigure all of your routers just because you want to change passwords. Instead, because the passwords are stored on a central server, you can change them once and the new passwords instantly propagate to all of your routers. If the router can’t reach the TACACS+ server due to a failure of either the network or the server, it resorts to using the locally configured passwords.

For audit and control reasons, most organizations that implement AAA supply a unique username and password for each individual user. While it is possible to store all of this information locally on the router, if you have a large number of routers, it is extremely time consuming to reconfigure all of the routers to reflect a password change, or to simply add a new user. One of the main advantages to using TACACS+ for AAA authentication is that none of the information is stored on the router. Instead, when a user tries to log in, the router automatically sends a query to the TACACS+ server to verify the login credentials. This minimizes the configuration on each router. And, because this query is done each time, the information is always up-to-date.

When TACACS+ is working correctly, the router prompts for both a login ID and password instead of the usual line password only:

freebsd% telnet toronto
Trying 172.25.1.5...
Connected to toronto.
Escape character is '^]'.


User Access Verification

Username: ijbrown
Password: xxxxxxxx

Router1>

The most obvious drawback to using a central server for authentication is that it represents a single point of failure. Therefore, TACACS+ allows you to configure several servers:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#tacacs-server host 172.25.1.1 key COOKBOOK
Router1(config)#tacacs-server host 10.12.1.33 key OREILLY
Router1(config)#end
Router1#

Note that we have defined different encryption keys for each server. This is the key that TACACS+ uses to encrypt the session between the router and the central server. It is important to protect this encryption key. The ability to configure different keys for the different servers helps to improve your overall security by making sure that you can always switch quickly to the backup server if you suspect that the primary’s encryption key has been compromised.

The order of these server commands is important because it reflects the order that the router uses to consult the servers. If the first server is unreachable, the router resorts to the next one, and so on. If no server responds, the router will use locally configured passwords. This also allows you to easily set up a simple form of load sharing among multiple servers by making one group of routers use the first server as their primary, and having the second group of routers use the second server. Then you can configure both groups of routers to use the other server as a backup. In this way, you can have all of the benefits of fault tolerance as well as load balancing.

The examples in this recipe and many others throughout this chapter show two sets of syntaxes because Cisco changed the AAA commands in IOS Version 12.0(5)T. The big change is the addition of AAA server groups. In the recipe example, we have opted to use the default TACACS+ group, which consists of all of the servers defined using tacacs-server host commands:

Router1(config)#aaa authentication login default group tacacs+
Router1(config)#aaa authentication enable default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1

However, some organizations are so large that they have to deploy many TACACS+ servers. In this case, it is convenient to create groups of servers, either by geography or some other logical grouping:

Router1(config)#aaa group server tacacs+ SERVERGROUP-A
Router1(config-sg-tacacs+)#server 172.25.1.1
Router1(config-sg-tacacs+)#server 10.12.1.33
Router1(config-sg-tacacs+)#exit
Router1(config)#aaa authentication login default group SERVERGROUP-A

You can also create groups of RADIUS servers if required.

By default, the router allows three login attempts before dropping a session. You can modify this limit using the TACACS+ command tacacs-server attempts. In the following example, we have configured the router to allow only one failed login attempt before dropping the session:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#tacacs-server attempts 1
Router1(config)#end

Once you implement this command, the router’s login behavior will change:

freebsd% telnet toronto
Trying 172.25.1.5...
Connected to toronto.
Escape character is '^]'.

User Access Verification

Username: ijbrown
Password: <wrong password>
Connection closed by foreign host.
freebsd%

You can configure the maximum number of failed login attempts to be any number between 1 and 1000. However, having a high number makes it considerably easier to launch a brute force password-guessing attack. So in general it is better to keep the maximum number small.

Most large organizations have a security policy that dictates the maximum number of failed logins, with typical values being three or four attempts. Check with your local security department to see what policies you should be following.

See Also

Recipe 4.3; Recipe 4.9; Recipe 3.1

4.2. Restricting Command Access

Problem

You want to restrict permissions so that specific users can only use certain commands.

Solution

You can enable TACACS+ command authorization in newer IOS versions with the following set of configuration commands:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authorization exec default group tacacs+
Router1(config)#aaa authorization commands 15 default group tacacs+
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

In any IOS version before 12.0(5)T, the AAA syntax was slightly different:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#aaa new-model
Router2(config)#aaa authorization exec default tacacs+
Router2(config)#aaa authorization commands 15 default tacacs+
Router2(config)#end
Router2#

Discussion

After you configure AAA authorization, the router queries the TACACS+ server each time somebody enters a command to see if it is allowed. If the user is permitted to use this particular command, the TACACS+ server will respond with an “accept” message and the router will proceed to execute the command. However, if the user is not permitted to issue the command, the TACACS+ server responds with a “reject” message, and the router will not execute the command. The router also shows a rejection status message on the screen:

Router1#configure terminal
Command authorization failed.

Router1#

In this case, the current user is unable to modify the router configuration because of an AAA authorization rejection.

Command authorization is useful in many situations. For example, you can use it to allow novice users to access some commands on the router, while preventing them from modifying the configuration. Or, in other cases, you might need to give special access to different groups of users according to their job functions. For example, the night operator might need to have access to look at the routing tables. But you may not want to give this person the same command set that your network engineers have. In Recipe 4.9, we illustrate how to configure a TACACS+ server to permit and deny specific commands.

In the recipe examples, we have configured the router to authorize enable level commands only, by specifying the number 15 as an argument:

Router1(config)#aaa authorization commands 15 default tacacs+

You may recall from Chapter 3 that the enable level commands are assigned level 15, whereas VTY level commands are at level 1. You can authorize all level 1 commands as well, depending on the level of security and control you wish to enforce. You could authorize all level 1 commands as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authorization commands 1 default tacacs+
Router1(config)#end
Router1#

See Also

Recipe 4.3; Recipe 4.9; Chapter 3

4.3. Losing Access to the TACACS+ Server

Problem

You want to ensure that your router can still authenticate user sessions, even if it loses access to the TACACS+ server.

Solution

It is important to make sure that you can still enter commands on your router if your TACACS+ server becomes unreachable for any reason. The following set of commands ensures that you don’t lose functionality just because you lose your server connection:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+ enable
Router1(config)#aaa authentication enable default group tacacs+ enable
Router1(config)#aaa authorization commands 15 default group tacacs+ if-authenticated
Router1(config)#tacacs-server host 172.25.1.1
Router1(config)#tacacs-server key COOKBOOK
Router1(config)#end
Router1#

Discussion

One of the potential problems with using a central server to authenticate user access is the issue of what happens when you lose access to that server. It would not be terribly useful if you couldn’t plug in a console device and reconfigure the router to fix the problem that caused the router to lose access in the first place. But, by default, a router that can’t communicate with its AAA server can’t authenticate or authorize users.

Fortunately, Cisco’s AAA implementation also includes the ability to perform authentication locally on the router in case it can’t reach its TACACS+ server. Cisco documentation often refers to this authentication as the “password of last resort.” The various authentication methods available within the AAA feature set are shown in Table 4-1.

Table 4-1. AAA authentication methods

Keyword	Definition
tacacs+	TACACS+ authentication
radius	RADIUS authentication
line	Line-based authentication (password)
local	Local username authentication
local-case	Case-sensitive local authentication
enable	Enable password or enable secret
none	No authentication

The example in this recipe shows how to use the router’s enable password as a redundant authentication method by adding the keyword enable to the aaa authentication command. As long as the primary authentication method (TACACS+ in this case) is working, the router never uses this password of last resort. However, when the server connection is lost, users will be prompted for the enable password instead of the TACACS+ username and password. This ensures that you will never be locked out of your routers.

You can also implement other backup authentication methods such as local authentication, line-based passwords, and even RADIUS. However, we recommend using the combination of the enable password method shown in this recipe along with using an enable secret password for two reasons. First, this password is local to the router so it will never become unavailable. Second, when you use enable secret passwords, the router stores the password using MD5 encryption internally, which will help protect it from prying eyes. We should also mention that it is possible to string together a few different methods of authentication, although this is usually unnecessary.

This example assumes that we are doing command authorization as well as authentication. The same problems that we just mentioned for authentication also apply to authorization. It doesn’t do you any good to get into the router if the router can’t verify which commands you are authorized to use. This is why we have included the if-authenticated keyword in the aaa authorization command:

Router1(config)#aaa authorization commands 15 default group tacacs+ if-authenticated

We highly recommend using the if-authenticated option whenever you enable AAA authorization.

See Also

Recipe 4.1; Recipe 4.2

4.4. Disabling TACACS+ Authentication on a Particular Line

Problem

You want to disable TACACS+ authentication on your router’s console interface.

Solution

You can disable TACACS+ authentication on the router’s console port while leaving it active on the rest of the router lines:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+ local
Router1(config)#aaa authentication login OREILLY line
Router1(config)#line con 0
Router1(config-line)#login authentication OREILLY
Router1(config-line)#end
Router1#

Discussion

By default, when you configure a router to use AAA authentication, it automatically applies this authentication method to all lines. This means that you don’t have to explicitly configure each line to use AAA authentication. Normally this default behavior is useful because it requires less configuration. But there are times when you may want to use different authentication methods on different lines. For instance, in our example we wanted to be able to access the router’s console line with a simple password. But we didn’t want this change to affect the AAA authentication on any of the VTY or AUX lines.

The first two lines in the example simply enable TACACS+ authentication for all login access to the router:

Router1(config)#aaa new-model
Router1(config)#aaa authentication login default group tacacs+ local

As soon as you enter these commands, every line on the router, including the console, will begin to use TACACS+ for authentication. The next command creates a new AAA authentication group called OREILLY that uses the local line password for authentication:

Router1(config)#aaa authentication login OREILLY line

This command doesn’t do anything yet, though, because none of the router’s lines belongs to this new authorization group. We have to configure the console line with the login authentication command to associate this line with the authentication group:

Router1(config)#line con 0
Router1(config-line)#login authentication OREILLY

Now, when a user connects on the console, they will use the type of authentication specified for this group. In this case, if you look back at the group definition, you will see that the OREILLY group uses line authentication. However, because we have associated only the console line with this group, all of the other lines will continue to use the TACACS+ authentication method.

If you wanted to, you could configure a different group for every line. But, in general, we recommend using the default TACACS+ authentication method on all lines, even the console, unless there is a compelling reason to do otherwise. You don’t need to worry about losing console access because of a problem on the central server; you can always implement a password of last resort, as described in Recipe 4.3.

You can return the console to the default authentication group by simply changing the login authentication line again:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#line con 0
Router1(config-line)#login authentication default
Router1(config-line)#end
Router1#

See Also

Recipe 4.1; Recipe 4.3

4.5. Capturing User Keystrokes

Problem

You want to capture and timestamp all keystrokes typed into a router and associate them with a particular user.

Solution

The AAA accounting feature allows you to capture keystrokes and log them on the TACACS+ server:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa accounting commands 1 default stop-only group tacacs+
Router1(config)#aaa accounting commands 15 default stop-only group tacacs+
Router1(config)#end
Router1#

Discussion

The ability to capture every keystroke entered into a router is a powerful security and quality assurance feature that is extremely useful. For instance, keystroke logging is extremely useful in forensic reconstruction of network events. TACACS+ provides the ability to capture all keystrokes typed into your routers and log them for future reference. The TACACS+ log contains the command that was typed, along with other useful information such as time and date, router name, username, originating IP address, and privilege level. Here is an example of a TACACS+ accounting record:

Fri Jan  3 11:08:47 2003        toronto ijbrown tty66   172.25.1.1
stop    task_id=512 start_time=1041610127   timezone=EST    service=shell
priv-lvl=15     cmd=configure terminal <cr>

In this log entry we can see that user ijbrown submitted the command configure terminal on router toronto at 11:08 on January 3, 2003. It also shows that this user accessed the router from IP address 172.25.1.1 using tty66.

To save disk space on your TACACS+ server, you may decide to log only level 15–based commands, which is done with this command:

Router1(config)#aaa accounting commands 15 default stop-only group tacacs+

Level 1 commands are generally relatively benign and pose little real threat to the security or health of the router. So logging them is less important than for level 15 commands. But we generally recommend logging all commands if you’re logging commands at all because the level 1 commands might show useful patterns of information. You can also log the commands issued at any other user level by adding more aaa accounting lines and specifying the appropriate user level.

See Also

Recipe 4.6; Recipe 4.9

4.6. Logging System Events

Problem

You want to log various system events.

Solution

AAA accounting includes the ability to log a variety of system events, including timestamps along with associated usernames:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#aaa new-model
Router1(config)#aaa accounting exec default start-stop group tacacs+
Router1(config)#aaa accounting connection default start-stop group tacacs+
Router1(config)#aaa accounting system default stop-only group tacacs+
Router1(config)#end
Router1#

Discussion

In addition to capturing keystroke logs, AAA accounting can gather other useful pieces of information such as EXEC, connection, and system events.

exec

This feature captures and timestamps the beginning and ending of a user’s EXEC session on the router.

connection

This feature allows you to gather information about outgoing connections using an interactive protocol such as Telnet, SSH, or RSH.

system

When you enable this feature, AAA forwards information about system events such as router reboots or the disabling of AAA accounting.

Here is an example of an EXEC log entry:

Fri Jan  3 11:11:40 2003        toronto ijbrown tty67   172.25.1.1
start   task_id=514 start_time=1041610300   timezone=EST    service=shell1

Fri Jan  3 11:18:47 2003        toronto ijbrown tty67   172.25.1.1
stop    task_id=514 start_time=1041610300   timezone=EST    service=shell
disc-cause=1   disc-cause-ext=1020 connect-progress=101    elapsed_time=427
nas-rx-speed=0  nas-tx-speed=0

These two records show that user ijbrown logged into router toronto at 11:11:40 AM on January 3, 2003, and stayed connected for 427 seconds. This information is useful for security auditing, and also can be used for billing purposes if required. For example, if you are using this router to provide PAD or terminal server services to paying customers, this is an ideal way to gather billing information.

Here is an example of a connection log event:

Fri Jan  3 11:30:19 2003        toronto ijbrown tty67   172.25.1.1
stop    task_id=522start_time=1041611404   timezone=EST    service=connection
protocol=telnet addr=10.2.2.2 cmd=telnet 10.2.2.2    pre-bytes-in=0  pre-bytes-out=0
pre-paks-in=0  pre-paks-out=0  bytes_in=1843 bytes_out=81 paks_in=43  paks_out=50
connect-progress=47   elapsed_time=15 nas-rx-speed=0  nas-tx-speed=0

In this record you can see that user ijbrown initiated a Telnet session to IP address 10.2.2.2, and terminated it 15 seconds later. You can even see the total number of bytes and packets both sent and received by the Telnet process.

The system event log entries look like this:

Fri Jan  3 11:35:19 2003        toronto unknown unknown unknown stop   task_id=265
start_time=1041611719   timezone=EST    service=system  event=sys_acct
reason=shutdown

Fri Jan  3 11:37:35 2003        toronto unknown unknown unknown start   task_id=1
timezone=EST    service=system  event=sys_acct  reason=reload

These records show that somebody reloaded the router called toronto at 11:35 on January 3, 2003. It came back up at 11:37 some two minutes later. Notice that the system event logging did not capture information on the user who submitted the reload command. That information could be captured using command logging.

Actually, this points out an interesting side benefit to capturing this information on a central server. If you were just using regular system logging in the router’s log buffer, this information would be lost during the reboot. However, by storing system events on the TACACS+ server, you don’t lose anything when the router reboots.

See Also

Recipe 4.5; Recipe 4.9

4.7. Setting the IP Source Address for TACACS+ Messages

Problem

You want the router to use a particular source IP address when sending TACACS+ logging messages.

Solution

The ip tacacs source-interface configuration command allows you to specify a particular source IP address for TACACS logging messages:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip tacacs source-interface loopback0
Router1(config)#end
Router1#

Note that implementing this command will not only affect AAA accounting, it will also affect AAA authentication and AAA authorization.

Discussion

Normally, when you enable TACACS+ on a router, the source IP addresses on the messages that it sends to the TACACS+ server will be the address of the router’s nearest interface. However, this is not always meaningful. If there are many different paths to the server, the router could wind up sending messages through different interfaces. On the server, then, these messages will usually look like they came from different routers, which can make it difficult to analyze the logs.

However, if you use a loopback address for the source, all messages from this router will look the same, regardless of which interface they were delivered through. In many networks, the DNS database contains only these loopback IP addresses, which helps to make the logs more useful as well.

We strongly recommend using this command.

See Also

Recipe 4.5; Recipe 4.6

4.8. Obtaining Free TACACS+ Server Software

Problem

You are looking for TACACS+ server software for use in your network.

Solution

Cisco distributes a free TACACS+ software system from their anonymous FTP site on the Internet:

freebsd% ftp ftp-eng.cisco.com
Connected to ftp-eng.cisco.com.
220 ftp-eng.cisco.com FTP server (Version wu-2.6.2(1) Thu Dec 13 23:14:01 PST 2001)
ready.
Name (ftp-eng.cisco.com:ijbrown): ftp
331 Guest login ok, send your complete e-mail address as password.
Password: <email@address>
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd pub/tacacs
250-Please read the file README
250-  it was last modified on Sun Jun 18 10:29:35 2000 - 927 days ago
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII  mode  data connection for /bin/ls.
total 544
drwxr-x--x   2 1500       eng          4096 Dec  4  1998 RCS
-rw-r--r--   1 1500       eng          1602 Jun 18  2000 README
-r--r--r--   1 1500       eng         73880 Dec  4  1998 tac-rfc.1.78.txt
-rw-rw-r--   1 1500       eng        193771 Jun 18  2000 tac_plus.F4.0.4.alpha.tar.Z
226 Transfer complete.
ftp> bin
200 Type set to I.
ftp> get tac_plus.F4.0.4.alpha.tar.Z
local: tac_plus.F4.0.4.alpha.tar.Z remote: tac_plus.F4.0.4.alpha.tar.Z
200 PORT command successful.
150 Opening BINARY mode data connection for tac_plus.F4.0.4.alpha.tar.Z (193771
bytes).
226 Transfer complete.
193771 bytes received in 1.81 seconds (104.58 KB/s)
ftp> quit
221-You have transferred 193771 bytes in 1 files.
221-Total traffic for this session was 196024 bytes in 2 transfers.
221-Thank you for using the FTP service on ftp-eng.cisco.com.
221 Goodbye.
freebsd%

Discussion

Cisco offers a free version of TACACS+ that you can download. However, please note that it is not a fully supported version. In fact, Cisco seldom updates the free TACACS+ daemon and it lacks several of the advanced features of commercially available TACACS+ software. Furthermore, Cisco warns that this free software comes with no warranty or support.

With this in mind however, the free TACACS+ software is useful for testing, lab environments, or even small installations. You will find that the free Unix version is fully functional and provides an excellent range of features. In fact, all of the AAA accounting log files in this chapter were captured using Cisco’s free TACACS+ software.

Please follow the instructions that Cisco provides with the software to extract, compile, and install the TACACS+ server software. Recipe 4.9 includes some sample configuration files.

See Also

Recipe 4.9

4.9. Sample Server Configuration Files

Problem

You want to configure a TACACS+ server to accept AAA requests from your network devices.

Solution

Here is an example of a TACACS+ server configuration file that accepts AAA requests from network devices to authenticate users. You can use this example as a template to help you build your own configuration files:

freebsd% cat tac.conf
key = "COOKBOOK"

accounting file = /var/log/tacacs

user = ijbrown {
    default service = permit
    member = staff
    login = cleartext cisco
}

user = kdooley {
    default service = permit
    member = staff
    login = des l5c2fHiF21uZ6
}

user = $enab15$ {
    login = cleartext happy
}


group = staff {
    # Default Group
}

Discussion

In this recipe, we look at how to configure Cisco’s free TACACS+ server software because we want to show how the TACACS+ server works. Most of the configuration is done at the central server, so understanding a basic configuration helps with understanding AAA services in general. Please note that other TACACS+ servers use different configuration syntax; however, the basic concepts are the same.

The first thing you need to configure is the TACACS+ encryption key. This key must be identical to the one configured on your router configuration with the tacacs-server key command. If the keys are not identical, none of the TACACS+ services will work. In the following example, we use the same encryption key as in Recipe 4.1, COOKBOOK:

key = "COOKBOOK"

To configure authentication for a single user, define a username and password combination as follows:

user = ijbrown {
        login = cleartext cisco
}

In this example, we configured the username ijbrown and assigned it a password, cisco. If you prefer, you can encrypt the password using DES encryption and store only this encrypted form in the configuration file. However, for this example, we chose to use a clear-text password. The TACACS+ server is now ready to accept authentication requests for this user.

If you choose to use TACACS+ to authenticate your enable password as well, you need to define a special enable user called $enabl15$. The following example creates this enable account using the password happy. After you define this username, the TACACS+ server will be able to handle authentication requests for the enable password:

user = $enab15$ {
    login = cleartext happy
}

To enable AAA authorization, you need to define command authorization using a series of grep-style regular expressions. For more information on regular expressions, see the egrep manpage, or Mastering Regular Expressions (O’Reilly).

By default, TACACS+ implicitly denies all commands. So, unless you explicitly allow a user to issue a command, it will be denied. Also note that the router will fully expand all commands before sending them to the TACACS+ server. This means that if a user types in sh ip rou, as a short form for show ip route, the TACACS+ server is asked to authorize the long form version of the command, show ip route. This is important to remember when you build your regular expression command statements.

The following example shows how to enable command authorization using the cmd statement. This configuration example permits the user sarnott to issue all show commands with the exception of show running-config:

user = sarnott {
    member = staff
    login = cleartext nssor
    cmd = show {
        deny running-config
        permit .*
    }
}

Notice that we have included two instructions in the cmd = show section. The first command, deny running-config, denies the user access to the show running-config command, while the permit .* line enables access to all other show commands. This works because the regular expression .* matches everything.

We mentioned earlier that, by default, the TACACS+ server implicitly denies all commands. This is a failsafe approach, but it does make things more difficult when you want to allow a large number of commands. Fortunately, you can use the default service = permit command to change this default behavior so that TACACS+ will permit any commands that you don’t explicitly deny. When you include this command in a user’s configuration, they can issue any command they like. If there are certain commands that you don’t want them to use, you can use a deny statement to prevent the specific commands, as follows:

user = ijbrown {
    default service = permit
    login = cleartext cisco
    cmd = debug {
        deny .*
    }
}

Here we have configured user ijbrown so that, by default, he is permitted to access all commands. We then specifically denied access to the debug commands using the cmd statement. You can include several such cmd statements, if required. This illustrates one of TACACS+’s greatest strengths: the fine granularity of its command authorization.

TACACS+ also allows you to put users into TACACS+ groups for easier administration. You can define several different profile groups and assign users to them as required. For example, you might create a group for users who are only allowed to look at show commands, another group for users who can do everything except debugging, and an administration group with full access to everything. You simply define a group, build its attributes, and assign users to the group. These users will inherit the group attributes, which will keep administration to the minimum.

Our next example creates a group and assigns a user to the new group:

user = kdooley {
    default service = permit
    member = staff
    login = des l5c2fHiF21uZ6
}

group = staff {
    # Default Group
    cmd = debug {
        deny .*
    }
}

In this example, we have assigned the user kdooley to the group called staff, using the member command. This new user will now inherit the group’s attributes. In this example, all other members of the staff group, including user kdooley, are allowed to use any command except the debug commands.

Finally, if you wish to enable AAA accounting, you need to define the log file in which TACACS+ will store these accounting messages:

accounting file = /var/log/tacacs

Interestingly enough, this is the only configuration command required to enable accounting on the server. As soon as you define this accounting file, the TACACS+ server is able to begin capturing these messages from any routers that are configured to send them.

AAA accounting logs can grow rather unruly, especially if you are using command logging. So we highly recommend cycling your accounting log on a daily basis, keeping at least a week’s worth of logs in case of emergencies. Recipe 18.11 shows a script that will rotate your accounting log files.

See Also

Recipe 4.1; Recipe 4.2; Recipe 4.5; Recipe 18.11; Mastering Regular Expressions, Second Edition, by Jeffrey E.F. Friedl (O’Reilly)