VMware ESXi and vSphere Cluster Management

Configure Cisco Routers to Use ACS for TACACS+ AAA

Learn how to configure Cisco IOS routers for TACACS+ authentication and EXEC authorization through Cisco ACS, with secure local-account fallback and verification steps.

This lesson shows how to configure a Cisco IOS router to use Cisco Access Control Server (ACS) for centralized administrator authentication and authorization through TACACS+. The configuration also keeps a local emergency account available when the TACACS+ service cannot be reached.

The examples use placeholders such as <ACS_IP_ADDRESS> and <SHARED_SECRET>. Replace them with values from your management design. Syntax varies between IOS families and releases, so confirm commands on the target platform before applying them.

Prerequisites and terminology

You should understand Cisco IOS command modes, interface addressing, IP reachability, VTY lines, basic SSH configuration, local usernames, and the enable secret. The following terms are central to this configuration:

• AAA means Authentication, Authorization, and Accounting. It is the framework used to control and record administrative access.
• Authentication verifies who the administrator is.
• Authorization determines what the authenticated administrator may do, including whether an EXEC session may start.
• Accounting records selected administrative activity, such as login events or command usage. This lesson configures authentication and authorization, not accounting.
• TACACS+ is a Cisco-oriented AAA protocol commonly used for network-device administration. TACACS+ normally uses TCP port 49.
• Cisco ACS is a centralized identity and policy server that can provide TACACS+ services.
• A TACACS+ client is the router that sends AAA requests. ACS is the AAA server.
• A shared secret is the key configured on both the router and ACS to protect and validate TACACS+ communication.
• A method list is an ordered list of AAA methods, such as TACACS+ followed by local authentication.
• VTY lines are virtual terminal lines used for inbound remote sessions, including SSH and Telnet.

How centralized AAA works

Without centralized AAA, every router can validate administrator credentials against its own local username database. This may be adequate for a small lab, but it becomes difficult to manage consistently across many devices. An administrator who leaves the organization may need to be removed from every router individually.

With centralized AAA, the router delegates credential validation to ACS. The router still controls the management connection, but ACS maintains the identity and policy used to decide whether the administrator may log in. This supports consistent access control across multiple routers and switches.

Router-local accounts and ACS identities are different:

• A local account is configured directly in IOS with a command such as username localadmin privilege 15 secret <LOCAL_SECRET>.
• An ACS identity is maintained on ACS and is evaluated by an ACS device-administration policy.
• The router does not automatically copy ACS users into its local database.
• A local account can provide resilience when ACS is unavailable, but it does not replace the centralized identity store.

For a normal SSH login, the flow is:

1. The administrator connects to a router VTY line by SSH.
2. The router sends a TACACS+ authentication request to ACS.
3. ACS validates the identity and password against its configured identity source and policy.
4. The router applies EXEC authorization, which determines whether the user may receive an EXEC session.
5. If the TACACS+ service is unavailable or produces a communication error, the configured local method may be tried.

AAA configuration components

Plan local emergency access first

Before relying on centralized AAA, create at least one protected local administrative account and an enable secret:

username localadmin privilege 15 secret <LOCAL_SECRET>
enable secret <ENABLE_SECRET>

Use strong, unique secrets. The exact password-storage options differ between IOS releases; use a non-reversible secret format supported by the platform rather than a plain-text password where possible.

Local fallback protects access during an ACS outage, a routing failure, a blocked firewall rule, or a TACACS+ reachability problem. It does not mean that every rejected ACS password should automatically be accepted locally. A reachable ACS server that explicitly rejects a password normally returns a failure, and the router should not bypass that policy by trying the local account.

Plan console access separately from VTY access. Console access provides a recovery path if a VTY method list is incorrect or if remote AAA access fails. Do not apply an untested AAA policy simultaneously to every possible access path.

Enable the AAA framework

AAA method lists are evaluated only after the AAA subsystem is enabled. Enable it globally with:

aaa new-model

Enabling aaa new-model changes how IOS handles services that use AAA. The default method list is the implicit list named default. A supported service uses that list when no more specific named list is attached to it. Therefore, changing a default list can affect more access paths than the line currently being tested.

Named method lists are useful for staged changes. For example, a list named REMOTE-LOGIN can be created and applied only to selected VTY lines. The examples below use the default list because it is the classic configuration used in many Cisco courses.

Define the TACACS+ server

The router needs the ACS server address or hostname and the shared secret. The key configured on the router must exactly match the key configured for that network device in ACS. Connectivity, routing, filtering, and matching protocol settings must all be correct before ACS-based login can succeed.

Classic IOS host syntax

Many legacy course examples use the following format:

tacacs-server host <ACS_IP_ADDRESS> key <SHARED_SECRET>

This command identifies the ACS host and supplies the TACACS+ key. The tacacs-server host form is older syntax, but it remains important when working with legacy IOS material and platforms that support it.

Modern named-server and server-group syntax

Many newer IOS platforms use a named server and an explicit server group:

tacacs server ACS1
 address ipv4 <ACS_IP_ADDRESS>
 key <SHARED_SECRET>
!
aaa group server tacacs+ ACS-GROUP
 server name ACS1

The AAA method list can then refer to ACS-GROUP instead of the generic group tacacs+ keyword:

aaa authentication login default group ACS-GROUP local
aaa authorization exec default group ACS-GROUP local

Use the named-server style only when it is supported by the installed IOS family and release. A server group is useful when several TACACS+ servers must be listed, because the group defines which servers are tried by the AAA methods.

Choose a TACACS+ source interface when needed

If the router has several interfaces, ACS may see TACACS+ requests arriving from an address different from the one expected in its network-device definition. Select a stable source address when the design requires it:

ip tacacs source-interface Loopback0

The selected address must be reachable from ACS and registered or permitted as the router's device address on ACS. Platform syntax and the exact placement of source-interface settings vary, so verify the command for the IOS release in use.

Configure login authentication

Authentication determines whether the supplied credentials identify a valid administrator. The following classic configuration tries TACACS+ first and local authentication second:

aaa authentication login default group tacacs+ local

Read the list from left to right:

• aaa authentication login creates a login authentication method list.
• default is the list name.
• group tacacs+ selects the configured TACACS+ server group.
• local selects the router's local username database as the fallback method.

With modern named-server syntax, use:

aaa authentication login default group ACS-GROUP local

Fallback behavior depends on the result from the first method. Local authentication is intended for an unavailable or erroring TACACS+ service. It is not normally attempted after ACS has successfully received the request and explicitly rejected the credentials.

Configure EXEC authorization

Authentication alone may not be enough. EXEC authorization controls whether a successfully authenticated user is allowed to establish an EXEC shell, initially receiving user EXEC mode or another policy-defined administrative workflow.

Configure TACACS+ authorization first and local authorization as the resilience method:

aaa authorization exec default group tacacs+ local

For a named server group, use:

aaa authorization exec default group ACS-GROUP local

The ACS policy must return an authorization result that permits an EXEC session. A user can therefore enter valid credentials and still fail to receive an EXEC prompt if the ACS device-administration policy denies EXEC access, the user lacks the required shell profile, or the router's authorization method list is incorrect.

EXEC authorization is related to, but separate from, privileged EXEC mode. A user may be authorized to start an EXEC session and then use the enable command to reach privileged EXEC mode, depending on the configured privilege and authorization policy. The enable secret remains an important local recovery control.

Apply AAA to VTY lines

Enter VTY line configuration mode and attach the method lists:

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

Some IOS releases provide more VTY lines, such as line vty 0 15. Apply the policy to the line range used by the platform and management design.

• login authentication default attaches the default login authentication list.
• authorization exec default attaches the default EXEC authorization list.
• transport input ssh permits SSH and excludes Telnet on platforms where this command is supported as shown.

VTY configuration controls inbound remote terminal access through SSH and Telnet. SSH is recommended for production management because it encrypts the session. Telnet sends credentials and session data without adequate confidentiality and should generally be disabled for administrative access.

Use a VTY access control list and a dedicated management address or management network where appropriate. These controls reduce the set of hosts that can even attempt AAA authentication.

Complete representative configurations

Legacy Cisco IOS example

username localadmin privilege 15 secret <LOCAL_SECRET>
enable secret <ENABLE_SECRET>
!
aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
!
tacacs-server host <ACS_IP_ADDRESS> key <SHARED_SECRET>
!
line vty 0 4
 login authentication default
 authorization exec default
 transport input ssh

Modern named-server example

username localadmin privilege 15 secret <LOCAL_SECRET>
enable secret <ENABLE_SECRET>
!
tacacs server ACS1
 address ipv4 <ACS_IP_ADDRESS>
 key <SHARED_SECRET>
!
aaa group server tacacs+ ACS-GROUP
 server name ACS1
!
aaa new-model
aaa authentication login default group ACS-GROUP local
aaa authorization exec default group ACS-GROUP local
!
line vty 0 4
 login authentication default
 authorization exec default
 transport input ssh

On some releases, the order in which global commands are entered may be constrained by IOS parser behavior. If a command is rejected, consult the platform's command reference and confirm whether the server definition, AAA group, or AAA framework must be created first.

Legacy and modern TACACS+ syntax

Verify the configuration and test login

Start with configuration and reachability checks:

show running-config | section aaa
show running-config | section tacacs
show aaa servers
show tacacs
ping <ACS_IP_ADDRESS>

Perform the test in this order:

1. Confirm the router can reach the ACS address and that routing permits the management path.
2. Confirm the ACS network-device definition uses the router source address and the same shared secret.
3. Open a separate SSH session to the router using an ACS-defined administrator account.
4. Verify that successful authentication produces the expected EXEC session according to the ACS authorization policy.
5. In a controlled lab, make ACS unavailable while keeping a console or privileged backup session active.
6. Attempt a VTY login with the local emergency account and verify the intended fallback behavior.
7. Restore ACS connectivity and verify that an ACS identity is again the preferred authentication method.

After a controlled debugging session, disable debugging:

undebug all

Troubleshooting common failures

The login does not contact ACS

Confirm that aaa new-model is present, that the login method list exists, and that the VTY lines reference the correct list name. Also verify that the administrator is testing the expected access path. A console session, a VTY session, and another line type may use different settings.

The router cannot communicate with ACS

Check the ACS address, routing table, interface status, and management ACLs. TACACS+ uses TCP port 49, so intervening firewalls and router ACLs must permit TCP/49 in both directions as required by the design. A successful ping alone does not prove that TCP/49 is permitted.

If a source interface is configured, confirm that its address is routed to ACS and registered as the router's network-device address. An unexpected source address can cause ACS to reject the request as an unknown client.

ACS reports an unknown client or shared-secret failure

Compare the ACS network-device definition with the actual router source address. Then compare the shared secret character by character. A mismatch prevents the TACACS+ exchange from being validated. Avoid copying secrets into logs, tickets, or screenshots.

Credentials are accepted but no EXEC session is provided

Review aaa authorization exec and the VTY attachment. Then inspect the ACS device-administration policy, user or group assignment, and shell or privilege attributes. Use authentication and authorization debugging separately so you can determine whether identity validation succeeded but EXEC authorization failed.

Administrators are locked out after an AAA change

Common causes include a missing local fallback account, an unreachable ACS server, a method list omitted from the VTY lines, or an overly broad change to the default list. Use console access or the still-open privileged session to restore a known-good configuration. This is why a local break-glass account and a separate test session should exist before modifying AAA.

Security and operational practices

• Use strong, non-reversible secrets where the IOS version supports them.
• Use SSH rather than Telnet for production management.
• Restrict VTY access with management-plane ACLs and dedicated management addressing where appropriate.
• Permit only the required TACACS+ traffic, especially TCP port 49, through ACLs and firewalls.
• Register the router's actual TACACS+ source address in ACS.
• Protect the local emergency account, document its ownership, and monitor its use.
• Back up the configuration and follow change-control procedures before modifying default AAA method lists.
• Test a new policy from a separate session before ending the existing privileged session.
• Remember that Cisco ACS is a legacy product in many environments. The AAA concepts and much of the IOS configuration also apply to a supported TACACS+ service, subject to platform syntax and server-policy differences.

Exam-relevant distinctions

• Authentication asks, “Who are you?” Authorization asks, “What may you do?” Accounting records activity.
• The router is the TACACS+ client; ACS is the AAA server.
• The TACACS+ shared secret must match on the router and the ACS network-device definition.
• aaa new-model enables the IOS AAA framework.
• group tacacs+ local expresses TACACS+ as the preferred method and the local database as the resilience method.
• Local fallback is for an unavailable or erroring AAA server, not normally for an explicit ACS password rejection.
• Authentication success does not guarantee an EXEC prompt when EXEC authorization is enabled.
• VTY lines control inbound SSH and Telnet sessions. Production administration should use SSH.
• TCP port 49 is the normal TACACS+ port.

Summary configuration checklist

1. Create and protect a local emergency user and enable secret.
2. Confirm the ACS network-device address, TACACS+ service, and shared secret.
3. Enable AAA with aaa new-model.
4. Define the TACACS+ server using the syntax supported by the IOS release.
5. Configure TACACS+ first and local fallback for login authentication.
6. Configure TACACS+ first and local fallback for EXEC authorization.
7. Attach both method lists to the intended VTY lines.
8. Permit SSH and restrict management access.
9. Verify reachability, TCP/49 filtering, server status, authentication, and EXEC authorization.
10. Test local fallback in a controlled lab, restore ACS, save the validated configuration, and document the change.

For a related reference, see Configure Routers to Use ACS.