CCNA Security online course

Configure Cisco ACS for AAA Device Administration

Learn to configure Cisco ACS for centralized TACACS+ device administration with network device groups, users, shell profiles, authorization policies, and Cisco IOS AAA.

Cisco Secure Access Control System (ACS) centralizes administrator authentication and authorization for network devices. In this lab, ACS authenticates two local users, matches their identity and target device groups, and returns different Cisco IOS privilege levels through TACACS+.

The example uses a router assigned to the RoutersHQ device group, an Admin identity group with privilege level 15, and a HelpDesk identity group with privilege level 1. Exact menu names can vary between ACS releases, so use the closest equivalent in your installation.

AAA and the Role of Cisco ACS

AAA means Authentication, Authorization, and Accounting. It is a framework for controlling and recording access to network devices.

• Authentication verifies identity. For example, ACS checks whether the Administrator username and password are valid.
• Authorization determines what an authenticated administrator may do. ACS can return a Cisco IOS privilege level or other command-access attributes.
• Accounting records activity such as login, logout, and command events when accounting is configured.

Cisco ACS acts as a centralized identity and policy platform. A managed router is the AAA client: it sends an administrator's request to ACS. ACS evaluates the request against its identity store and authorization policies, then sends a result back to the router. TACACS+ is commonly used for Cisco device administration because it separates authentication, authorization, and accounting functions.

Authentication and authorization are separate decisions. A user may authenticate successfully but receive no access, a limited privilege level, or a result from an unintended policy. Always validate both the identity decision and the returned authorization attributes.

Core Cisco ACS Objects

Initial ACS Access and Preparation

Access the ACS administrative web interface through the server management address. The administrative path commonly follows this format:

https://<ACS_IP>/acsadmin

1. Open the URL from a secured management workstation.
2. Sign in with the initial ACS administrative account.
3. Change the initial or default administrative password when prompted, or change it through the administrative account settings.
4. Confirm that ACS has an appropriate evaluation or production license. Do this before building the complete configuration.
5. Confirm that the ACS server has IP connectivity to the router management address and that the router can reach the ACS server.

Protect the ACS administrative account and avoid displaying real passwords or shared secrets in screenshots, documentation, or command output.

Create the RoutersHQ Network Device Group

A Network Device Group is a logical classification for managed devices. A group can represent a site, device role, security zone, or operational function. Putting headquarters routers into RoutersHQ lets policies apply to that class of device without creating a separate rule for every router.

1. Open the ACS area for network device groups. Depending on the release, this may be under Network Resources or a similarly named configuration section.
2. Open the device-type portion of the NDG hierarchy.
3. Create a device-type group named RoutersHQ.
4. Save the group.
5. Verify that RoutersHQ is available for network-device classification and as an authorization-policy condition.

Add the Router as a Network Device or AAA Client

ACS must know which devices are allowed to send AAA requests. Each network-device entry normally includes a descriptive name, management IP address, device-group assignment, enabled protocol, and shared secret.

1. Open the network devices and AAA clients configuration area.
2. Create an entry with a descriptive ACS-side name, such as HQ-Router-1.
3. Assign its device type or NDG classification to RoutersHQ.
4. Enter the router's management IP address.
5. Enable the intended device-administration protocol, typically TACACS+.
6. Enter a strong, unique shared secret. The value must exactly match the secret configured on the router.
7. Save the entry and verify its classification.

The IP address registered in ACS must be the source address that the router uses for TACACS+ requests. If the router uses a loopback, routed interface, or another management interface as its source, register that address or configure the router to use an address already registered in ACS.

Create Identity Groups and Internal Users

An identity group is a logical collection of users. Group-based authorization is easier to maintain than creating a separate authorization rule for every person.

1. Open the ACS identity-management area.
2. Create an identity group named Admin.
3. Create a second identity group named HelpDesk.
4. Create an internal user named Administrator and assign it to Admin.
5. Create an internal user named Helpdesk and assign it to HelpDesk.
6. Assign strong, unique passwords according to your organization's credential policy.
7. Verify each user is in the intended group and that the internal identity store is enabled for the relevant access service.

Use a password manager or another approved secret-management process. Do not reuse the TACACS+ shared secret as a user password.

Create Shell Profiles

A shell profile is an authorization profile that returns device-administration attributes. For this lab, the important attribute is a static default Cisco IOS privilege level.

Administrator shell profile

1. Open the authorization-profile or shell-profile configuration area.
2. Create a custom profile for administrative users, such as Admin-Shell-15.
3. Enable the shell attribute for a static default privilege level.
4. Set the privilege level to 15.
5. Save the profile.

Help-desk shell profile

1. Create a separate profile, such as HelpDesk-Shell-1.
2. Set its static default privilege level to 1.
3. Save the profile.

IOS privilege levels range from 0 through 15. Level 15 traditionally provides privileged EXEC access, while level 1 provides standard user EXEC access. These levels are coarse controls; level 1 alone does not provide command-by-command role-based authorization. Production environments that require precise command control should use an appropriate command-authorization design.

Configure Device-Administration Authorization Policies

Use the Default Device Admin access service authorization-policy area. A policy should evaluate both the administrator's identity and the target device. In this example, the device condition is the RoutersHQ device type.

AdminRole policy

1. Create a policy named AdminRole.
2. Set the identity condition to Identity Group equals Admin.
3. Set the device condition to NDG Device Type equals RoutersHQ.
4. Set the result to the Admin-Shell-15 shell profile.
5. Save the policy.

HelpDeskRole policy

1. Create a policy named HelpDeskRole.
2. Set the identity condition to Identity Group equals HelpDesk.
3. Set the device condition to NDG Device Type equals RoutersHQ.
4. Set the result to the HelpDesk-Shell-1 shell profile.
5. Save the policy.

Policy order matters. ACS normally evaluates rules from top to bottom and uses the first applicable rule. Place specific identity-and-device rules before broad rules such as a catch-all result. Otherwise, a general rule may match first and prevent AdminRole or HelpDeskRole from being evaluated.

Configure the Router for TACACS+ AAA

Enable AAA, define ACS as a TACACS+ server, create a named server group, and apply authentication and exec-authorization method lists to the required access lines. The following is an illustrative configuration; syntax varies by IOS release.

aaa new-model
!
tacacs server ACS1
 address ipv4 <ACS_IP>
 key <SHARED_SECRET>
!
aaa group server tacacs+ ACS-GROUP
 server name ACS1
!
aaa authentication login ACS-LOGIN group ACS-GROUP local
aaa authorization exec ACS-EXEC group ACS-GROUP local if-authenticated
!
line vty 0 4
 login authentication ACS-LOGIN
 authorization exec ACS-EXEC
!
end
write memory

Replace <ACS_IP> and <SHARED_SECRET> with the values configured in ACS. The server address and shared secret must match exactly.

The local keyword provides a fallback to the router's local user database if the TACACS+ server is unavailable or does not return a successful result, depending on the method-list behavior. Maintain a known local emergency account and test the fallback before applying AAA to remote VTY lines. Apply the login method list to the console as appropriate for your operational design, but preserve a recovery path.

Using a named TACACS+ server group is preferable to relying only on older global TACACS+ commands because it makes server selection explicit and supports clearer designs when multiple AAA servers exist.

How an AAA Request Is Processed

Validate AAA Behavior

1. From a controlled test session, log in to the router as Administrator.
2. Confirm that authentication succeeds and that the session receives privilege level 15.
3. Log out and test the Helpdesk account.
4. Confirm that Helpdesk receives privilege level 1.
5. Verify that both results occur only when the user group and device group match the intended policy.
6. Review ACS monitoring or failed-and-successful authentication logs for the authentication result, matched policy, source address, and returned profile.
7. Use router verification commands to inspect the active AAA configuration and privilege state.

show running-config | section aaa
show running-config | section tacacs
show aaa servers
show privilege
show users

If necessary, use carefully scoped debugging during a controlled test:

debug aaa authentication
debug tacacs

Disable debugging after the test. Debug output may be disruptive and can expose sensitive operational details.

Troubleshooting AAA

Security and Operational Practices

• Use unique, strong TACACS+ shared secrets for each client where practical, and protect them as sensitive credentials.
• Restrict management-plane access to ACS and network devices with management VLANs, ACLs, firewalls, and appropriate source restrictions.
• Synchronize ACS and network-device clocks with reliable time sources so authentication and accounting logs can be correlated.
• Plan ACS availability with appropriate redundancy, monitoring, backups, and tested recovery procedures.
• Maintain local emergency access on each device and document how it is used if ACS is unavailable.
• Use role and command authorization appropriate to production requirements instead of depending only on IOS privilege levels.
• Document device groups, identity groups, policy order, shell profiles, shared-secret ownership, and fallback procedures.
• Test changes from console or an existing privileged session before disconnecting the recovery path.

Exam-Relevant Notes

• Authentication answers “Who are you?” Authorization answers “What may you do?” Accounting records activity.
• ACS must contain a network-device entry for the router, and the configured IP and shared secret must correspond to the router's TACACS+ request.
• Both the user identity group and the target device group can be conditions in a device-administration policy.
• Specific authorization rules must appear before broad fallback rules when policy processing is first-match based.
• Authentication alone does not guarantee the expected privilege level; exec authorization must be configured and applied.
• Privilege level 15 and privilege level 1 are broad IOS controls, not a complete command-level role system.
• A local fallback is a safety mechanism, but it must be paired with a known local account and a tested recovery procedure.

Summary

A basic ACS device-administration design connects four elements: a registered AAA client, an internal user and identity group, an authorization policy, and a shell profile. The router sends TACACS+ requests to ACS, ACS authenticates the user, matches both user and device conditions, and returns the appropriate privilege attribute. In the example, Administrator receives level 15 and Helpdesk receives level 1 when connecting to a router classified as RoutersHQ.

For a compact reference to this configuration, see Configure Cisco ACS for AAA Device Administration.