top of page

Implementing Cisco Secure ACS as a Tacacs Server

 

Date: 31-3-2014

Example: AAA using Tacacs+ Server running on VMWare

Table of Contents

  • Topology

Topology

Cisco Secure ACS 5.3 runs on VMWare Workstation 10 and is connected to my GNS3 topology using a virtual interface.

As you can see, there are two different user groups:

  • Administrators (juanma and pepito): for device management. They have full access to the device, but reload, copy and write commands aren’t allowed.

  • Users (laura and cristina): They can monitorize the device but not allowed to change the configuration, reload, write, ping and so on. The Administrators can eventually assign them privilege 15 by telling them the enable password.

AAA client configuration

aaa new-model

aaa authentication login default group tacacs+ local

aaa authentication enable default group tacacs+ enable

aaa authorization exec default group tacacs+ local

aaa authorization commands 1 default group tacacs+ local

aaa authorization commands 15 default group tacacs+ local

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 authorization config-commands

!

tacacs-server host 192.168.220.50

tacacs-server key juanma

!

username juantron privilege 15 secret 5 $1$8SNu$ZrJe0MK6h5xsZWRMDnI5Z1

Configuring ACS as a Tacacs Server

Step 0. (Optional) You can define different Location and Device Type.

 

AAA clients in the ACS repository can be assigned to Network Device Groups (NDGs). NDGs are logical grouping of devices—for example, by Location or Type—which can be used in policy conditions.

 

Step 1. Define the AAA clients:

Anchor 1
Anchor 2

NOTE The number of devices that you can add in ACS depends on the license type. The number of devices is determined by the number of unique IP addresses that you configure. This includes the subnet masks that you configure.

 

Step 2. Define Users and Groups.

 

You can create users with different privilege levels. I’m going to create two groups: Administrators (level 15) & sinprivilegios (level 6):

Then, the users are created and assigned to their group:

Step 3. Define Identity Store Sequences.

Step 4. Policy Elements

 

Shell Profiles: You can define a set of permissions that is applied to a user requesting administrative access of a device. Some of these permissions include privilege level, auto command, and custom TACACS+ attributes.

 

Two Shell Profiles: Administrators_shell (privilege=15) & sinprivilegios_shell (privilege=6).

Note By using Maximum Privilege = 15, sinprivilegios users can get level 15 privilege (if they know the enable password).

 

Command Sets: You can define a list of commands that a user can execute on a device during an administrative session.

 

Two Command Sets: Administrators_cset & sinprivilegios_CSets

Step 5. Access Policies.  Access Services

 

ACS uses service selection rules and access services to decide on a policy to apply to a request.

 

Two Access Services: Administrators_access & sinprivilegios_access.

Select Service Type = Device Administration. Included Policies: Identity and Authorization.

5.1 Configuring the Identity Policy

 

For Administrators_access: Change only the Default rule (Identity Source = Administrators).

Do the same for sinprivilegios_access.

5.2 Configuring the Authorization Policy

 

Change only the Default rule.

Do the same for sinprivilegios_access.

 

5.3 Creating the Service Selection Rules

 

Service selection rules decide which access service to send an authentication or authorization request to. You can configure ACS to use a single access service to process all requests or use rules based on session conditions to send requests to different access services. In the case of a rule-based selection, ACS uses the first rule from the top that matches a request.

 

Two Service Selection Rules:

Select Rule based result selection.

For Default rule, select “sinprivilegios_access” (you could also have selected “Administrators_access”).

Note You can also create 4 Service Selection Rules (one for each user), but I prefer the first option, because you can group users by privilege levels.

 

Testing the AAA users

Anchor 3

Everything works fine.

Testing the Local Database

As you know, the Tacacs+ Server could fail so you wouldn’t have network access to this device.

 

Following Cisco’s Best Recommendations, I’ve configured a privilege 15 user named “juantron” and the keyword “local” was defined in the AAA configuration.

 

Two options: shut down the interface connected to Cisco Secure ACS (this requires local access to the device) or disable this switch as AAA client for Tacacs+ Server.The best option is to change the IP address of this switch in Network Resources > Network Devices and AAA Clients > Edit “Switch” (this is better than delete this switch as AAA client).

 

NOTE Remember to change again the IP address on Cisco Secure ACS when this system has been restored.

Anchor 4

Your e-mail will not be published.

You can use an invalid e-mail.

bottom of page