CCNA Security online course

Configure Cisco ACS for AAA Device Administration

Learn how to configure Cisco ACS for centralized AAA device administration with NDGs, identity groups, internal users, authorization policies, shell profiles, and Cisco IOS TACACS+ integration.

Cisco Access Control Server (ACS) centralizes authentication, authorization, and accounting (AAA) for network-device administration. Instead of maintaining separate administrator permissions on every router, you can define users, device groups, and access rules in ACS.

This lesson demonstrates a basic headquarters-router design. The Administrator user receives IOS privilege level 15, while the Helpdesk user receives privilege level 1.

Cisco ACS in a AAA design

AAA stands for authentication, authorization, and accounting. Authentication verifies who a user is. Authorization determines what that user may do. Accounting records access and activity.

Cisco ACS is the centralized policy server. A router, switch, firewall, or other managed device is an AAA client because it sends AAA requests to ACS. The AAA client is not the same thing as the ACS server.

For device administration, the router sends a TACACS+ request containing information such as the username and the device receiving the login. ACS evaluates the user's identity and the target device's classification, then returns an authorization result. This allows access to be controlled centrally by both who is connecting and which device is being accessed.

The relationship is: an internal user belongs to an identity group; a network device belongs to an NDG; an authorization rule matches the identity group and NDG; and the selected authorization profile returns the permitted privilege level to the device.

Initial ACS access and secure setup

1. Open the ACS administrative interface using https://<ACS_IP>/acsadmin, replacing <ACS_IP> with the ACS server address.
2. Sign in with the initial administrative account, commonly the acsadmin account during first-time setup.
3. When prompted, replace the default administrative password with a unique password that follows the organization's password policy.
4. Address the product license or evaluation license before using ACS for production policy enforcement.
5. Restrict HTTPS administrative access to trusted management hosts or management networks. Do not expose the ACS administration interface broadly.

Create the RoutersHQ network device group

A Network Device Group (NDG) is a logical classification for devices with similar locations, functions, or access requirements. In this example, the device type RoutersHQ represents headquarters routers.

1. Open Network Resources > Network Device Groups.
2. Open the Device Type hierarchy.
3. Select Create.
4. Enter RoutersHQ as the group name and save the change.

One policy can now apply to every router assigned to RoutersHQ. If another router is later added to the group, it can inherit the same policy conditions without creating a separate rule for every device.

Verify that RoutersHQ appears as an available device type before adding the router.

Add a router as a network device and AAA client

1. Open Network Resources > Network Devices and AAA Clients.
2. Select Create.
3. Enter a descriptive ACS display name, such as HQ-Router-1.
4. Assign the router to the RoutersHQ device type.
5. Enter the router's management IP address exactly. ACS uses this address to identify the source of AAA requests.
6. Enable TACACS+ for device administration.
7. Enter a strong shared secret and save the device.

The ACS display name does not have to match the router's hostname. The registered IP address must match the address used by the router's TACACS+ requests, and the shared secret must exactly match the value configured on the router.

Create identity groups

An identity group collects users who share access requirements. Group membership becomes a policy condition, so policies do not need to be assigned independently to every user.

1. Open Users and Identity Stores > Identity Groups.
2. Select Create and create an identity group named Admin.
3. Create a second identity group named HelpDesk.

Create internal ACS users

The internal identity store is ACS's local user database. It is appropriate for a basic lab or a small deployment. Larger environments may use an external identity store such as Active Directory or LDAP.

1. Open Users and Identity Stores > Internal Identity Stores > Users.
2. Select Create and create the user Administrator.
3. Assign Administrator to the Admin identity group.
4. Set a password that complies with the local password policy.
5. Create the user Helpdesk.
6. Assign Helpdesk to the HelpDesk identity group and set its password.

Create shell authorization profiles

An authorization profile is the set of attributes ACS returns after an authorization rule matches. A shell profile supplies device-shell attributes, including the IOS privilege level.

Administrator shell profile

1. Create a custom shell authorization profile named AdminShell.
2. Configure a static default privilege level of 15.
3. Save the profile.

Helpdesk shell profile

1. Create a separate custom shell authorization profile named HelpdeskShell.
2. Configure a static default privilege level of 1.
3. Save the profile.

Privilege level 15 is the highest standard IOS privilege level and normally provides full administrative command access. Privilege level 1 is user EXEC access and normally provides a limited command set.

Configure device-administration authorization policies

1. Open Access Policies > Access Services > Default Device Admin > Authorization.
2. Create a rule named AdminRole.
3. Set the identity condition to Identity Group equals Admin.
4. Set the device condition to NDG:Device Type equals RoutersHQ.
5. Set the result to the AdminShell profile.
6. Create a rule named HelpDeskRole.
7. Set the conditions to Identity Group equals HelpDesk and NDG:Device Type equals RoutersHQ.
8. Set the result to the HelpdeskShell profile.

Place these specific allow rules before broad rules or the default result. ACS evaluates authorization rules in order, so an earlier broad match can prevent a later, more specific rule from being reached.

Limit authorization to explicitly intended identity groups and device groups. For example, an Admin user should receive the administrator profile on RoutersHQ devices only. A device in another NDG needs a separate matching rule.

Configure the Cisco IOS router

The router must enable AAA processing, identify ACS as a TACACS+ server, use a matching shared secret, and apply the authentication and EXEC-authorization method lists to the relevant access lines.

aaa new-model
!
tacacs server ACS
 address ipv4 <ACS_IP>
 key <SHARED_SECRET>
!
aaa group server tacacs+ ACS-GROUP
 server name ACS
!
aaa authentication login ACS-LOGIN group ACS-GROUP local
aaa authorization exec ACS-EXEC group ACS-GROUP local
!
username localadmin privilege 15 secret <LOCAL_FALLBACK_SECRET>
!
line vty 0 4
 login authentication ACS-LOGIN
 authorization exec ACS-EXEC

Replace the placeholders with the actual ACS address, shared secret, and local fallback secret. Apply equivalent authentication and authorization settings to the console or other management lines when appropriate for the access design.

Some IOS releases use the legacy tacacs-server host and tacacs-server key syntax instead of the named tacacs server object. Use the syntax supported by the installed IOS release.

Validate the configuration

1. From a permitted management connection, log in to the router as Administrator.
2. Run show privilege and verify that the session receives privilege level 15.
3. Log out and authenticate as Helpdesk.
4. Run show privilege and verify that the session receives privilege level 1.
5. Review ACS monitoring or reporting to confirm that each request was received, authenticated, and authorized by the expected rule.
6. Test a user or device combination that should not match a rule. Confirm that access is denied or receives only the deliberately configured default result.

For the example design, Administrator receives full administrative access only when the identity is in Admin and the target device is in RoutersHQ. Helpdesk receives limited user EXEC access only when both the HelpDesk and RoutersHQ conditions match.

Troubleshooting ACS and TACACS+

The router cannot authenticate ACS users

• Test IP connectivity between the router and ACS.
• Verify the ACS server address on the router.
• Confirm that TACACS+ is enabled for the ACS network-device entry.
• Compare the shared secret character by character on both sides.
• Confirm that the router's TACACS+ source IP matches the address registered in ACS.
• Review ACS monitoring logs for received, rejected, or unknown-client requests.
• Use IOS AAA and TACACS+ debugging carefully in a lab or maintenance window.

Authentication succeeds but the privilege level is wrong

• Confirm the user's identity-group membership.
• Confirm that the router belongs to RoutersHQ.
• Review authorization rule order and conditions.
• Confirm that the expected shell profile is attached to the matching rule.
• Verify that the profile returns static privilege level 15 or 1 as intended.
• Confirm that aaa authorization exec is applied to the relevant access lines.

ACS reports an unknown AAA client

• Ensure the router was created under Network Devices and AAA Clients.
• Compare the router's actual TACACS+ source address with the IP address entered in ACS.
• Configure a consistent source interface if the network design requires one.

The administrator is locked out

• Keep console access available during AAA changes.
• Create and test a local privileged fallback account before applying AAA to remote lines.
• Use a method list with local fallback, such as group ACS-GROUP local.
• Test the configuration on a limited set of VTY lines before expanding it.

A valid user is denied

• Confirm that a rule matches both the identity group and RoutersHQ device type.
• Check whether a default deny or earlier nonmatching result is being evaluated.
• Confirm that the request is reaching the intended Default Device Admin access service.
• Review the ACS request details for the identity, source address, device group, and selected result.

Exam-relevant notes

• ACS is the policy server; the router is the AAA client.
• An NDG classifies devices, while an identity group classifies users.
• Authorization policies match attributes and select authorization profiles.
• Authentication alone does not apply a returned IOS privilege level; EXEC authorization is also required.
• TACACS+ shared secrets must match exactly between ACS and IOS.
• Specific authorization rules should appear before broad or default rules.
• Privilege level 15 generally represents full administrative access; privilege level 1 generally represents limited user EXEC access.
• A local fallback account protects against lockout when ACS is unavailable, but it must be tested before deployment.

For related administration topics, review Configure Routers to Use ACS, Cisco ACS Setup, and What Is Cisco ACS.