CCNA Security online course

Configure Cisco Routers to Use ACS for AAA with TACACS+

Learn to configure a Cisco IOS router for ACS-based TACACS+ authentication and EXEC authorization, with local credentials as a controlled fallback.

Centralized AAA lets a Cisco IOS router use Cisco ACS to control administrative access. In this configuration, the router sends login and authorization requests to ACS through TACACS+, while a local administrator account provides a recovery path if ACS is unavailable.

This lesson assumes familiarity with IOS configuration modes, IP connectivity, VTY lines, SSH, local usernames, and basic ACS administration. For background, review AAA explained, what Cisco ACS is, and enabling SSH on a Cisco router.

AAA and centralized router administration

AAA is a framework containing three related functions:

• Authentication verifies who a user is, usually by checking a username and password.
• Authorization determines what an authenticated user may access or do.
• Accounting records access and activity for auditing and reporting.

With local-only administration, every router has its own username database. Adding, removing, or changing an administrator then requires changes on multiple devices. Centralized identity management puts users and access policies in one service, making consistent administration, auditing, and account removal easier.

Cisco ACS, or Cisco Access Control Server, acts as a centralized AAA server for network-device administration. It stores or references administrator identities and applies device-access and authorization policies.

Authentication and authorization are separate decisions. A user can supply valid credentials and still fail EXEC authorization. EXEC authorization determines whether IOS permits the user to start an EXEC session and which privilege or administrative attributes apply.

AAA functions in an IOS router

Authentication — Question: “Who is this user?” Example: checking an ACS username and password when an administrator starts SSH. Relevant configuration: aaa authentication login.

Authorization — Question: “What may this authenticated user access?” Example: permitting an IOS EXEC session and assigning a privilege level. Relevant configuration: aaa authorization exec.

Accounting — Question: “What access or activity should be recorded?” Example: recording login, logout, or command activity. Relevant configuration: aaa accounting.

TACACS+ between the router and ACS

TACACS+ is the AAA protocol used for communication in this example. The router is the TACACS+ client; ACS is the TACACS+ server. The client sends authentication and authorization requests, and ACS evaluates them against its users and policies.

A shared secret is configured for the router client in ACS and for the corresponding TACACS+ server definition on the router. Both values must match. The secret helps the two systems authenticate their relationship and protect TACACS+ exchanges. Use a strong secret and protect it like any other infrastructure credential.

The router must be able to reach the ACS address through its routing table and management path. Check interface state, routes, management VRFs, source addressing, firewalls, and ACLs. Any intervening control must permit TACACS+ traffic. ACS must also recognize the source address that the router uses for its requests.

Prepare a local recovery account first

Before enabling AAA, create at least one local administrative account. This account is the emergency path when ACS cannot be contacted. Give it a usable privilege level or other local authorization configuration.

configure terminal
username localadmin privilege 15 secret <LOCAL_SECRET>

Use a real secret in place of <LOCAL_SECRET>; do not reuse a TACACS+ shared secret. Keep console or out-of-band access available while changing AAA. Enabling AAA without a valid method list or fallback account can lock out remote administrators.

Basic ACS-first AAA configuration

The following example uses a router with management address 192.0.2.1 and an ACS TACACS+ address of 192.0.2.10. The syntax shown first is the legacy IOS TACACS+ style supplied in the scenario. Confirm syntax for the IOS release before deploying.

1. Define the ACS TACACS+ server

configure terminal
tacacs-server host 192.0.2.10 key <TACACS_SHARED_SECRET>

The address can be an IP address or, where supported and correctly resolved, a hostname. The shared secret must equal the secret configured for this router as a network device in ACS.

2. Enable the IOS AAA subsystem

aaa new-model

aaa new-model activates IOS AAA processing and makes AAA method lists available. Do not enter this command casually on a remotely managed device: if the resulting configuration has no usable authentication method or recovery path, existing access can be lost.

3. Create the default login authentication method list

aaa authentication login default group tacacs+ local

A method list is an ordered policy describing which authentication sources IOS should try. This list tries the TACACS+ server group first and the local username database second.

default is the special default method-list name. Services that use the default list automatically use this policy unless a named list is explicitly configured. The order matters: TACACS+ is preferred, and local authentication is the fallback.

Fallback generally occurs when the TACACS+ service is unavailable or cannot be contacted. An explicit TACACS+ rejection, such as an invalid centralized password or a policy denial, normally should not be treated as permission to bypass ACS with a local account. This distinction prevents a local account from circumventing a deliberate centralized denial.

4. Create the default EXEC authorization method list

aaa authorization exec default group tacacs+ local

This policy asks TACACS+ to authorize an EXEC session and uses local authorization if ACS is unavailable. Authentication alone does not guarantee an IOS shell. ACS must return an authorization result that permits EXEC access and, when required, supplies an appropriate privilege level or related attribute.

5. Apply both policies to the VTY lines

line vty 0 4
 login authentication default
 authorization exec default
 transport input ssh

VTY lines control inbound remote terminal sessions, including SSH and Telnet according to the configured transport settings. The example permits SSH only, which is preferred for administrative access. On platforms with more VTY lines, configure the complete applicable range, such as line vty 0 15, after checking the device.

Complete legacy-style example

configure terminal
username localadmin privilege 15 secret <LOCAL_SECRET>
tacacs-server host 192.0.2.10 key <TACACS_SHARED_SECRET>
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
line vty 0 4
 login authentication default
 authorization exec default
 transport input ssh
end
copy running-config startup-config

Save only after reviewing the configuration and testing the recovery plan. Avoid testing a new AAA policy by closing the only working remote session.

Modern named-server syntax

Newer IOS releases may use named TACACS+ server objects and explicit server groups instead of the older tacacs-server host syntax. The concepts remain the same: define the server and key, place it in a group, then reference that group in the method lists.

tacacs server ACS1
 address ipv4 192.0.2.10
 key <TACACS_SHARED_SECRET>
!
aaa group server tacacs+ ACS-GROUP
 server name ACS1
!
aaa authentication login default group ACS-GROUP local
aaa authorization exec default group ACS-GROUP local

Legacy style — Common on older IOS configurations. Server definition uses tacacs-server host. Method lists reference group tacacs+.

Modern named-server style — Available on many newer IOS releases. A named tacacs server object is placed in a named server group. Method lists reference that group, such as group ACS-GROUP.

Operational rule — Do not mix syntax based only on memory. Use the commands supported by the installed IOS release and verify the resulting running configuration.

Prepare ACS

1. Add the router as a TACACS+ network device or client in ACS.
2. Enter the same router client address that ACS will see. If the router uses a loopback or management interface as its source, register that address as appropriate.
3. Enter the exact shared secret configured on the router.
4. Create or assign an administrator identity in ACS.
5. Associate the identity with a device-administration policy, authorization result, or privilege assignment that permits the intended access.
6. Review ACS authentication and authorization logs during testing.

The ACS account must be authorized for device administration, not merely valid as an identity. A valid password without an appropriate authorization policy can produce authentication success followed by EXEC authorization failure.

AAA configuration components

AAA activation — Feature or command family: aaa new-model. Purpose: enables IOS AAA. Primary source: none. Fallback source: recovery depends on later method lists and local access.

Login authentication — Feature or command family: aaa authentication login. Purpose: validates the user's identity. Primary source: TACACS+ or a named TACACS+ group. Fallback source: local.

EXEC authorization — Feature or command family: aaa authorization exec. Purpose: permits and attributes an IOS EXEC session. Primary source: TACACS+ or a named TACACS+ group. Fallback source: local.

Remote access binding — Feature or command family: VTY login authentication and authorization exec. Purpose: applies the policies to remote terminal sessions. Primary source: the referenced default or named list. Fallback source: the fallback specified in that list.

Validate the deployment

Check configuration and reachability

show running-config | section aaa
show running-config | section tacacs
show running-config | section line vty
show aaa servers
show tacacs
ping 192.0.2.10

Confirm that AAA is enabled, the correct server and key are present, both default method lists contain the intended fallback, and the VTY lines reference those lists. Check that the ACS server is reachable from the correct management context.

Test ACS authentication and authorization

1. From an authorized workstation, start an SSH connection to the router.
2. Sign in with the ACS-defined administrator account.
3. Confirm that authentication succeeds.
4. Confirm that the user receives an EXEC session.
5. Check the resulting privilege level and test only the commands that the ACS policy is intended to permit.
6. Confirm the login and authorization events in ACS logs.

Test local fallback safely

In a lab or controlled maintenance window, make ACS genuinely unreachable, or otherwise disable the TACACS+ service path without changing unrelated production traffic. Then test localadmin. Restore ACS and confirm that normal ACS authentication works again.

This test demonstrates the difference between unavailability and rejection. If ACS actively rejects a username or password, local fallback should not normally override that decision.

Use debugging carefully

debug aaa authentication
debug aaa authorization
debug tacacs
undebug all

Troubleshooting ACS and TACACS+

All remote logins fail after AAA is enabled — Likely causes: missing or incorrect method list, no local account, or an unconfigured management path. Check the AAA and VTY sections, test from console or out-of-band access, and create a tested local emergency account.

ACS credentials are rejected — Likely causes: missing ACS user, incorrect router client address, shared-secret mismatch, or a policy that does not permit device administration. Check ACS logs, the router definition, the secret, and the authorization policy.

User authenticates but receives no IOS shell — Likely causes: missing EXEC authorization, wrong method-list reference, or insufficient ACS authorization. Check aaa authorization exec, VTY configuration, ACS authorization results, and privilege-related attributes.

Local fallback does not occur — Likely causes: missing local method, missing local user, an active ACS rejection, or a test that did not actually make ACS unavailable. Verify the list order and test a true unreachable condition in a controlled environment.

Router cannot contact ACS — Likely causes: wrong address, routing failure, interface or VRF issue, ACL or firewall filtering, or an unrecognized source address. Verify routes and interfaces, test reachability, inspect controls, and ensure ACS identifies the router's actual source address.

Authentication fails with a reachable ACS server — A shared-secret mismatch is a common cause. Compare the secret configured in the router's TACACS+ server definition with the secret for that network device in ACS, then correct one side so they match.

Security and deployment practices

• Prefer SSH over Telnet because Telnet does not protect the management session in transit.
• Restrict VTY access with management-plane ACLs where appropriate, allowing only approved administration sources.
• Use strong, protected TACACS+ shared secrets and limit who can view router and ACS configuration.
• Keep a console or out-of-band recovery path while changing AAA.
• Maintain a tested local emergency account, but protect and monitor its use.
• Do not close the only active remote session immediately after changing AAA. Open a second controlled test session first.
• Confirm the router's source address, routing context, and ACS device registration before diagnosing user credentials.
• Remember that command syntax varies by IOS release; newer releases commonly use named TACACS+ objects and server groups.

Exam-relevant points

• aaa new-model enables the IOS AAA subsystem.
• The router is the TACACS+ client, and ACS is the TACACS+ server.
• aaa authentication login default group tacacs+ local prefers TACACS+ and uses the local database when the server is unavailable.
• aaa authorization exec default group tacacs+ local controls authorization for the IOS EXEC session after authentication.
• The word default identifies the automatically used default method list.
• Local fallback is not the same as bypassing an explicit TACACS+ credential rejection.
• The TACACS+ shared secret must match on both the router and ACS.
• VTY lines must reference the authentication and EXEC authorization method lists for remote access to use them.

For related management-plane controls, see protecting the management plane, passwords on IOS devices, and Cisco ACS setup.