TACACS+ Overview

Let’s get right into TACACS+ and how it can be used to create a more secure network.

TACACS+ Overview

Okay, now that you’ve met Cisco’s ACSs, let’s take a second to review how the ACS and the NAS communicate. The NAS can use either TACACS+ or RADIUS to communicate user access requests to the ACS. Each of these two methods of communication has its individual strengths and purposes.

Table 3.1 summarizes the key differences between TACACS+ and RADIUS. I’ll go over these in more detail shortly.

T A B L E 3 . 1 TACACS+ and RADIUS Comparison

As you can see, TACACS+ has many advantages over RADIUS. It is for this very reason that Cisco strongly encourages the use of TACACS+. TACACS+ is really a better tool to use when you can, but you may need to use RADIUS, or both TACACS+ and RADIUS in a mixed-vendor network.

Because TACACS+ is a Cisco proprietary authentication scheme, its use in the Cisco AAA process has a number of distinct advantages. My goal here isn’t to dissect TACACS+. Instead, I really want you to understand its benefits. (RFC 1492 documents Cisco’s proprietary TACACS+.)

TACACS+ conforms to the AAA model—it treats authentication, authorization, and accounting as distinct and separate roles (as discussed in Chapter 2, “Introduction to AAA Security”). This means that TACACS+ has mechanisms to support each of these services, giving the security administrator much more granular control and latitude in both defining and, more importantly, implementing a security policy.

TACACS+ uses TCP as a transport protocol. I’m sure you remember that TCP opens a connection and verifies delivery of each segment. TACACS+ then encrypts the entire contents of each TCP

96 Chapter 3 Configuring CiscoSecure ACS and TACACS+

segment, so anyone listening on the wire won’t be able to snag information. TACACS+ supports PAP and CHAP, as well as PPP callback and per-user ACLs—all features covered in Chapter 2.

TACACS+ can be used between the NAS and ACS to control dial-in access and other access into the network. It can also be used between the network devices (routers and switches) and ACS to control authentication and authorization in the management of network devices.

Let’s head right into configuring TACACS+ on your NAS.

Configuring TACACS+

Think back to Chapter 2 for a second. Remember the discussion about configuring the NAS to use the AAA process to authenticate users to a local database? Good! As you recall, you can configure authentication and authorization for local users with the username command. Let’s try this out now:

Todd(config)#username todd password lammle

Todd(config)#line con 0

Todd(config-line)#login local

Todd(config-line)#line aux 0

Todd(config-line)#login local

Todd(config-line)#line vty 0 4

Todd(config-line)#login local

This configuration allows user todd to access the configured lines as long as Todd knows their passwords.

In a medium-to-large network, there are significant advantages to using TACACS+ (or other) centralized authentication services instead of local databases.

A common problem for many network administrators is the number of unsynchronized accounts a network user has. How often has a new employee been given seven, eight, or even ten separate “accounts,” all with unique passwords, just to access the resources that the individual needs? Multiply that by a horde of employees, and you can just watch the stress levels build in your organization. Everyone is affected—from frustrated users trying to remember all their passwords on up to senior managers dealing with the boatload of complaints these circumstances create.

But a local database is just that—local to the NAS it resides on. If you have a single NAS, a local database may be fine. But if you have many NASs, do you really want more unsynchronized user databases?

The whole idea behind CiscoSecure ACS 3.0 for Windows NT or Windows 2000 is to allow multiple NASs to use a single database for AAA. That way, there is a single account database to be administered for each user instead of many.

Just being able to use a single database for AAA is a huge improvement over using local databases on NASs. But Cisco ACS takes it one step further. Let’s assume that you have an existing network—you probably already have several user databases in existence. If you’re running Microsoft Windows NT/2000 servers anywhere, you have users who have accounts in domains.

If you have any Novell NetWare servers that use Novell Directory Services (NDS), you have user accounts there as well. Maybe all of your user information is in an ODBC database.

CiscoSecure ACS 3.0 for Windows NT or Windows 2000 lets you use any of these existing user databases in AAA! This means that instead of creating a new user database exclusively for AAA, you can simply adopt an existing database from one of these other sources. Now you not only have fewer user databases to maintain, but you also bypass the work of setting up a new one—nice!

This capability to use existing user databases for AAA means that even if you have a single NAS, CiscoSecure ACS 3.0 for Windows NT or Windows 2000 is likely to be a good solution for your company or client.

Suppose that you already have more than 1,000 users in your NT domain. And let’s just say (okay, this is a stretch) that each of these users needs access to your NAS. Do you really want to create a local database (as outlined in Chapter 2) with those 1,000 user accounts? I’m fairly certain you don’t want to do the following:

Todd(config)#username user1 password pass1

Todd(config)#username user2 password pass2

Todd(config)#username user3 password pass3

Todd(config)#username user4 password pass4

Todd(config)#username user5 password pass5

Todd(config)#username user6 password pass6

Todd(config)#username user7 password pass7

Todd(config)#username user8 password pass8

Todd(config)#username user9 password pass9

Todd(config)#username user10 password pass10

Todd(config)#username user11 password pass11

Todd(config)#username user12 password pass12

Todd(config)#username user13 password pass13

Todd(config)#username user14 password pass14

Todd(config)#username user15 password pass15

Todd(config)#username user16 password pass16

And so on, through user1000.

Do you want to maintain those passwords? Of course not! Consider something called employee turnover. You can’t save these tasks for a once-a-week update; new users need computer access immediately, and former employees ideally should be deleted as their shoes pass through the door for the last time due to their potential security risk. So you’d spend a part of every day maintaining passwords. Don’t forget to add the time wasted with the fun and friendly HR department trying to get an accurate list of people/passwords to add and delete. And how much aggravation would occur if—because you were trying to get this done before a noon meeting—you accidentally deleted, say, a senior vice president and weren’t around until after 2 P.M. (because lunch went late) to fix that problem? Scared yet? No worries— CiscoSecure ACS 3.0 for Windows NT or Windows 2000 solves your problem.

98 Chapter 3 Configuring CiscoSecure ACS and TACACS+

What you want to do now is use the corporate network example that you’ll be configuring throughout this book and create a TACACS+ centralized database instead of using a single database on the NAS. This allows you more flexibility in your network configuration because you can create one database and use it throughout the rest of this book without having to update the database on individual NAS devices.

If you don’t want to use the Cisco proprietary TACACS+, you can use the industry-standard RADIUS server. The configuration is pretty similar, and I’ll show you how to perform account authorization with RADIUS right after you go through the TACACS+ configurations.

Our Corporate Network Example

Using the same network you’ve seen throughout this book, I’m going to walk you through changing the corporate network example from using a local AAA database residing on the NAS server to using centralized database on a CiscoSecure ACS. Here’s our corporate network again:

The goal here is to install and configure the CiscoSecure ACS on the NAS server to run remote RADIUS and TACACS+ authentication, authorization, and accounting features, as well as to also configure the NAS to use the ACS server for authentication.

The following example shows a configuration using TACACS+ on the Cisco 2600 Todd NAS router, configured in Chapter 2, to now authenticate against a CiscoSecure ACS user database instead:

User Access Verification

Username: todd

Password:

Todd>en

Password:

Todd#config t

Enter configuration commands, one per line. End with CNTL/Z.

First, enable AAA by using the aaa new-model global configuration command.

Todd(config)#aaa new-model

The next command specifies to use the default list against the TACACS+ server and that TACACS+ is the default login method for all authentication.

Todd(config)#aaa authentication login default tacacs+

You can add the command none at the end of the command, which means that if the TACACS+ process is unavailable, no login is required.

The next command sets the AAA authentication for PPP connection using the default list against the TACACS+ database.

Todd(config)#aaa authentication ppp default tacacs+

The next authorization command determines if the user is allowed to run an EXEC shell on the NAS against the TACTACS+ database.

Todd(config)#aaa authorization exec tacacs+

The next command sets AAA authorization for all network-related service requests, including SLIP, PPP, PPP NCP’s, and ARA protocol against the TACACS+ database.

Todd(config)#aaa authorization network tacacs+

The following AAA accounting command sets the EXEC process on the NAS to record the start and stop time of the session against the TACACS+ database.

Todd(config)#aaa accounting network start-stop tacacs+

This next command sets AAA accounting for EXEC processes on the NAS to record the start and stop time of the session against the TACACS+ database.