When you design a network, one of the most important goals is to control who can connect and what they’re allowed to do once they’re in. This is defined in the network security policy, which sets the rules for administrators, employees, remote users, and even business partners. A good policy also makes sure you have some kind of accounting system that logs who connected, when they logged in, and what they did while on the network.
Using just simple passwords in user mode or enable mode isn’t enough—it doesn’t scale well and isn’t very secure. Instead, Cisco devices support the AAA framework (Authentication, Authorization, and Accounting). AAA makes it possible to centralize login control, assign permissions, and track activity across all your devices.
On a small scale, you can set up AAA with a local username/password database on your router. This is more secure than just a single password and is easy to get started with. In bigger environments, network engineers usually connect AAA to a central server like Cisco Secure ACS (or a modern RADIUS/TACACS+ server), which lets all devices share one source of authentication and improves reliability by running multiple servers.
If you want to practice, the best way is to build a home lab. You don’t need to spend a fortune—older Cisco routers and switches are often available second-hand, or you can use virtualization tools like GNS3, EVE-NG, or Cisco Modeling Labs (CML). These let you configure real Cisco IOS images and test AAA setups in a safe environment. By experimenting with both local and server-based authentication, you’ll gain the hands-on experience that really makes the concepts stick.
Securing access to network devices is one of the most important responsibilities of a network administrator. Without proper safeguards, intruders can potentially gain control of sensitive equipment and services. Access control is the first line of defense—it defines who is allowed in, and what they can do once inside.
The most basic form of authentication is the use of simple passwords. These can be applied to console, auxiliary, and VTY (remote access) lines. While easy to configure, this method is weak because passwords can be guessed, stolen, or brute-forced. Even worse, password-only access provides no accountability—anyone with the password can log in and make changes without their actions being tied to a specific user.
A stronger approach is to use a local database of usernames and passwords on the device. For example:
username admin secret mypassword
This configuration provides two advantages: it requires both a username and password, and it logs which account was used to log in. Using secret instead of password is recommended because the secret is encrypted in the configuration.
However, local authentication has limitations. User accounts must be manually configured on every device. In a large network, this quickly becomes unmanageable, especially when accounts need to be added, removed, or updated. There is also the risk of being locked out if the administrator forgets the local credentials.
To solve these issues, networks often rely on a central authentication server. Cisco devices, for example, can be configured to use Authentication, Authorization, and Accounting (AAA) with protocols such as RADIUS or TACACS+. With this approach, all routers and switches authenticate against the same central database of accounts, making management far easier and more scalable.
You can think of AAA like a credit card system: the card authenticates who you are, authorizes how much you can spend, and keeps an account of every transaction. In networking, AAA ensures that administrators have fine-grained control and visibility over who is accessing resources and how they are being used.
AAA can be used to authenticate users for administrative access or it can be used to authenticate users for remote network access. These two access methods use different modes to request AAA services:
With the exception of accounting commands, all AAA commands apply to both character mode and packet mode. This topic focuses on securing character mode access. For a truly secure network, it is important to also configure the router for secure administrative access and remote LAN network access using AAA services as well.
Cisco provides two common methods of implementing AAA services.
Local AAA Authentication
Local AAA uses a local database for authentication. This method stores usernames and passwords locally in the Cisco router, and users authenticate against the local database. This database is the same one required for establishing role-based CLI. Local AAA is ideal for small networks.
Server-Based AAA Authentication
The server-based method uses an external database server resource that leverages RADIUS or TACACS+ protocols. Examples include Cisco Secure Access Control Server (ACS) for Windows Server, Cisco Secure ACS Solution Engine, or Cisco Secure ACS Express. If there are multiple routers, server-based AAA is more appropriate.
AAA Authorization
After users are successfully authenticated against the selected AAA data source (local or server-based), they are then authorized for specific network resources. Authorization is basically what a user can and cannot do on the network after that user is authenticated, similar to how privilege levels and role-based CLI give users specific rights and privileges to certain commands on the router.
Authorization is typically implemented using an AAA server-based solution. Authorization uses a created set of attributes that describes the user's access to the network. These attributes are compared to the information contained within the AAA database, and a determination of restrictions for that user is made and delivered to the local router where the user is connected.
Authorization is automatic and does not require users to perform additional steps after authentication. Authorization is implemented immediately after the user is authenticated.
AAA Accounting
Accounting collects and reports usage data so that it can be employed for purposes such as auditing or billing. The collected data might include the start and stop connection times, executed commands, number of packets, and number of bytes.
Accounting is implemented using an AAA server-based solution. This service reports usage statistics back to the ACS server. These statistics can be extracted to create detailed reports about the configuration of the network.
One widely deployed use of accounting is combining it with AAA authentication for managing access to internetworking devices by network administrative staff. Accounting provides extra accountability above and beyond authentication. The AAA servers keep a detailed log of exactly what the authenticated user does on the device. This includes all EXEC and configuration commands issued by the user. The log contains numerous data fields, including the username, the date and time, and the actual command that was entered by the user. This information is useful when troubleshooting devices. It also provides leverage against individuals who perform malicious actions.
Local AAA Authentication, also referred to as self-contained authentication, is best suited for smaller networks with one or two routers. This method uses usernames and passwords stored locally on the router. Administrators must populate the local security database by specifying username and password profiles for each user.
The Local AAA Authentication method is similar to using the login local command, with the added benefit that AAA allows configuring backup authentication methods.
login local
To enable AAA:
aaa new-model
To disable AAA:
no aaa new-model
Use the aaa authentication login command to define a named list of authentication methods. This list is sequential—if the first method fails, the router tries the next one.
aaa authentication login
local
local-case
enable
none
aaa authentication login TELNET-ACCESS local enable
This creates a list named TELNET-ACCESS. The router first checks the local user database. If unavailable, it falls back to the enable password.
To apply a method list to specific lines (vty, console, etc.):
aaa authentication login default local
Different lists can be applied to different interfaces. The default list applies everywhere unless overridden.
To lock user accounts after repeated failed login attempts:
aaa local authentication attempts max-fail <number>
To unlock users:
clear aaa local user lockout username <name>
or
clear aaa local user lockout all
show aaa local user lockout
show aaa user all
show aaa sessions
The Cisco router has debug commands that are useful for troubleshooting authentication issues. The debug aaa command contains several keywords that can be used for this purpose. Of special interest is the debug aaa authentication command.
The best time to understand debug output is when everything is working properly. Knowing how debug output displays when all is well helps identify problems when things are not working properly. Exercise caution when using the debug command in a production environment because these commands place a significant load on router resources and can affect network performance.
The debug aaa authentication command is instrumental when troubleshooting AAA problems. To disable this command, use the no form of the command or the all-encompassing undebug all statement.
Look specifically for GETUSER and GETPASS status messages. The Method message is also helpful when identifying which method list is being referenced.
When AAA is enabled, it is often necessary to monitor authentication traffic and troubleshoot configurations.
The debug aaa authentication command is a useful AAA troubleshooting command because it provides a high-level view of login activity.
debug aaa authentication
The command indicates a status message of PASS when a TACACS+ login attempt is successful. If the status message returned is FAIL, verify the secret key.
Two other very useful server-based AAA troubleshooting commands include the debug tacacs and debug radius commands. These commands can be used to provide more detailed AAA debugging information. To disable debugging output, use the no form of these commands.
debug tacacs
debug radius
no
Similar to the debug aaa authentication command, the debug tacacs also indicates status messages of PASS or FAIL.
To see all TACACS+ messages use the debug tacacs command. To narrow the results and display information from the TACACS+ helper process, use the debug tacacs events command in privileged EXEC mode. The debug tacacs events command displays the opening and closing of a TCP connection to a TACACS+ server, the bytes read and written over the connection, and the TCP status of the connection. Use the debug tacacs events command with caution, because it can generate a substantial amount of output. To disable debugging output, use the no form of this command.
debug tacacs events
Router# debug aaa authentication AAA Authentication debugging is on ! Attempt to login via TACACS+ ! Successful login output: AAA/AUTHEN/LOGIN (00000001): Pick method list 'default' AAA/AUTHEN/LOGIN (00000001): Method=TACACS+ TPLUS: Queuing AAA Authentication request (id=1) TPLUS: processing authentication start request id 1 TPLUS: Authentication start packet created for 1() TPLUS: Using server 192.168.1.100 TPLUS(00000001)/0/NB_WAIT/1234ABCD: Started 5 sec timeout TPLUS(00000001)/0/READ: read entire 12 bytes response TPLUS: Processed authentication reply for 1 AAA/AUTHEN (00000001): status = PASS ! Failed login example (wrong secret key): AAA/AUTHEN/LOGIN (00000002): Pick method list 'default' AAA/AUTHEN/LOGIN (00000002): Method=TACACS+ TPLUS: Queuing AAA Authentication request (id=2) TPLUS: processing authentication start request id 2 TPLUS: Authentication start packet created for 2() TPLUS: Using server 192.168.1.100 TPLUS(00000002)/0/NB_WAIT/5678EFGH: Started 5 sec timeout TPLUS(00000002)/0/READ: socket event error TPLUS: Unable to validate reply from server AAA/AUTHEN (00000002): status = FAIL ! Enable TACACS events debugging for detailed connection info Router# debug tacacs events TACACS+ events debugging is on ! TACACS events output showing TCP connection details: TPLUS: Opened TCP connection to 192.168.1.100/49 (FD=1) TPLUS: Sending packet (length=50) to server 192.168.1.100 TPLUS: Wrote 50 bytes to socket 1 TPLUS: Received packet (length=12) from server 192.168.1.100 TPLUS: Read 12 bytes from socket 1 TPLUS: TCP connection status: ESTABLISHED TPLUS: Closed TCP connection to 192.168.1.100/49 (FD=1) ! Disable debugging when troubleshooting is complete Router# no debug aaa authentication AAA Authentication debugging is off Router# no debug tacacs events TACACS+ events debugging is off ! Alternative: disable all debugging at once Router# undebug all All possible debugging has been turned off
Local implementations of AAA do not scale well. In enterprise environments, there may be dozens of Cisco routers, multiple administrators, and hundreds or thousands of users requiring access to corporate resources. Managing local user databases on every single device quickly becomes unmanageable.
To solve this challenge, one or more centralized AAA servers are typically deployed. Examples include Cisco ISE (Identity Services Engine), which has replaced Cisco Secure ACS, and open-source options such as FreeRADIUS. These servers provide a central repository for user and administrative credentials, greatly simplifying management and improving security. They can also integrate with external identity stores like Active Directory, LDAP, and even cloud identity services for seamless authentication.
The two main protocols used for AAA are TACACS+ and RADIUS. While both are widely supported across Cisco devices and security appliances, there are important differences:
In modern networks, the general best practice is to use TACACS+ for administrative access to routers, switches, and firewalls, and RADIUS for end-user access control (such as VPN or wireless authentication).
! Example of defining a TACACS+ server in Cisco IOS tacacs server My_TACACS address ipv4 192.168.1.10 key MySecretKey aaa new-model aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local
AAA communication between devices and centralized servers is primarily handled by TACACS+ and RADIUS. Both protocols support authentication, authorization, and accounting, but they differ in design, security, and use cases. Choosing between them depends on the organization’s needs.
For example, a large ISP may prefer RADIUS because it offers detailed accounting features required for subscriber billing. On the other hand, an enterprise network with multiple user groups may select TACACS+ because of its granular per-user or per-group authorization control.
Key characteristics of TACACS+ include:
Key characteristics of RADIUS include:
TACACS+, introduced by Cisco, is a complete redesign of the older TACACS protocol and is widely supported in Cisco devices starting with IOS Release 10.3. It provides a modular approach to AAA, meaning you can use TACACS+ for authorization and accounting while authenticating users through another method if desired. Its full-packet encryption makes it a strong choice for environments where security is paramount.
RADIUS, standardized by the IETF (RFC 2865, RFC 2866), is an open protocol commonly used in ISP and enterprise networks. It supports both local and roaming users, making it well-suited for mobile and distributed access scenarios. RADIUS has become the foundation for many modern access technologies such as Wi-Fi authentication (802.1X) and SIP-based VoIP systems.
RADIUS hides user passwords during transmission by applying MD5 hashing with a shared secret. However, other fields, such as usernames or accounting data, are transmitted in plaintext. This has led to the emergence of DIAMETER, the successor protocol to RADIUS, which uses modern transport methods (TCP or SCTP) and stronger security mechanisms.
Example: Configuring a Cisco device to use a TACACS+ server
aaa new-model tacacs server TACACS-SRV1 address ipv4 192.168.1.10 key MySecretKey ! aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local aaa accounting exec default start-stop group tacacs+
Example: Configuring a Cisco device to use a RADIUS server
aaa new-model radius server RADIUS-SRV1 address ipv4 192.168.1.20 auth-port 1812 acct-port 1813 key AnotherSecretKey ! aaa authentication login default group radius local aaa authorization network default group radius local aaa accounting network default start-stop group radius
These configurations illustrate how TACACS+ and RADIUS are integrated into enterprise devices to centralize authentication, authorization, and accounting across the network.
Unlike local AAA authentication, server-based AAA requires the network device to know which TACACS+ or RADIUS servers to contact when authenticating and authorizing users. This allows centralized management of credentials and policies.
Here are the basic steps to configure server-based authentication:
Configuring a TACACS+ Server
To configure TACACS+, define the server and key:
aaa new-model tacacs server My_TACACS address ipv4 192.168.1.10 key MySecretKey aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local
The single-connection option (on older IOS versions) keeps a persistent TCP session with the server to reduce overhead. In modern IOS, this is handled automatically by the tacacs server object.
single-connection
tacacs server
Configuring a RADIUS Server
RADIUS uses UDP instead of TCP, so there is no single-connection option. Define the server and shared key like this:
radius server My_RADIUS address ipv4 192.168.1.20 auth-port 1812 acct-port 1813 key MyRadiusKey aaa authentication login default group radius local aaa authorization network default group radius
Defining Method Lists
A method list defines the order of authentication sources. For example:
aaa authentication login default group radius group tacacs+ local
This tries RADIUS first, then TACACS+, and falls back to the local database if both fail. Method lists give you flexibility and redundancy in case a AAA server is unavailable.
Before installing Cisco Secure ACS, it is important to prepare the server. Third-party software requirements and the network and port requirements of the server and AAA devices must be considered.
Software products that are mentioned in the release notes are supported for interoperability by Cisco. Support for interoperability issues with software products that are not mentioned in the release notes might be difficult to attain. The most recent version of the Cisco Secure ACS release notes are posted on Cisco.com.
Keep in mind that in the Cisco Secure ACS application, a client is a router, switch, firewall, or VPN concentrator that uses the services of the server.
The network should meet specified requirements before administrators begin deploying Cisco Secure ACS:
After successfully installing Cisco Secure ACS, some initial configuration must be performed. The only way to configure a Cisco Secure ACS server is through an HTML interface.
To access the Cisco Secure ACS HTML interface from the computer that is running Cisco Secure ACS, use the Cisco Secure icon labeled ACS Admin that appears on the desktop or enter the following URL into a supported web browser: http://127.0.0.1:2002.
The Cisco Secure ACS can also be accessed remotely after an administrator user account is configured. To remotely access the Cisco Secure ACS, enter http://ip_address[hostname]:2002. After the initial connection, a different port is dynamically negotiated.
The home page of Cisco Secure ACS is divided into frames. The buttons on the navigation bar represent particular areas or functions that can be configured:
If the RADIUS options are not displayed, the AAA client that uses the RADIUS protocol must be added. Additionally, the interface configuration is directly affected by the settings in the network configuration.
Before configuring a router, switch, or firewall as a TACACS+ or RADIUS client, the AAA client must be added to the server with its IP address and encryption key. The Network Configuration page is where AAA clients are added, deleted, or modified.
Step 1. Click Network Configuration on the navigation bar. The Network Configuration page appears.
Step 2. In the AAA Clients section, click Add Entry.
Step 3. Enter the client host name in the AAA Client Hostname field. For example, enter the name of the router that will be a AAA client to the server. In the Cisco Secure ACS application, a client is a router, switch, firewall, or VPN concentrator that uses the services of the server.
Step 4. Enter the IP address in the AAA Client IP Address field.
Step 5. Enter the secret key that the client uses for encryption in the Shared Secret field.
Step 6. Choose the appropriate AAA protocol from the Authenticate Using drop-down list.
Step 7. Complete other parameters as required.
Step 8. Click Submit and Apply.
The options available from the Interface Configuration navigation button allow the administrator to control the display of options in the user interface. The specific options displayed depend on whether TACACS+ or RADIUS clients have been added to the server:
Cisco Secure ACS can be configured to forward authentication of users to one or more external user databases. Support for external user databases means that Cisco Secure ACS does not require duplicate user entries in its internal database. In organizations with existing user databases, such as Active Directory, ACS can leverage that investment without additional input.
For most database configurations, except for Windows databases, Cisco Secure ACS supports only one instance of a username and password. If multiple databases are configured with overlapping usernames, ACS only uses the first match found. Therefore, best practice is to maintain unique usernames across all external databases.
Step 1. Click the External User Databases button from the navigation bar. The External User Databases window appears with the following links:
Step 2. Click Database Configuration. The External User Database Configuration pane appears, displaying the following options:
Step 3. To use the Windows database as an external database, click Windows Database. The Windows External User Database Configuration pane appears.
Step 4. To configure the additional Windows database functionality, click Configure from the External User Database Configuration pane. The Windows User Database Configuration window appears.
Step 5. If more control over who is able to authenticate to the network is required, the Dialin permission option can also be configured. In the Dialin Permission section, check the Verify that "Grant dialin permission to user" setting has been enabled from within the Windows User Manager check box. Also ensure the Grant dialin permission option is enabled in the Windows user profile.
The Dialin Permissions option of Cisco Secure ACS applies to more than just dialup connections. If a user has this option enabled, it applies to any access attempt.
Another option available with the Windows external database is mapping databases to domains. Mapping allows an administrator to have the same username across different domains, each with a different password.
Today, Cisco Identity Services Engine (ISE) has replaced Cisco Secure ACS, but many of the concepts are the same. Both ACS and ISE provide centralized Authentication, Authorization, and Accounting (AAA) for users and devices. The difference is that ISE is more modern, integrates better with 802.1X, and provides advanced policy control. This section covers how ACS handles users and groups, followed by how ISE approaches the same tasks.
Authentication with External Databases
ACS and ISE can authenticate users with external databases (Active Directory, LDAP, ODBC, etc.) in two ways:
ACS – Configuring Unknown User Policy
ISE Equivalent: In ISE, this is configured under Administration → Identity Management → External Identity Sources. You can add Active Directory, LDAP, RADIUS token servers, or certificate-based authentication as identity sources.
Group Setup and Database Group Mappings
External databases often need different authorization levels. For example, Windows-authenticated users may have different privileges than LDAP-authenticated ones. In ACS, this is solved with Database Group Mappings, while in ISE the equivalent is Authorization Profiles and Policy Sets.
Example – ACS Group Command Authorization
show
deny running-config
This ensures group members can run most show commands but are blocked from revealing sensitive configs.
ISE Equivalent: Use Command Sets in ISE to define which CLI commands a user group can run. For example, create a Command Set that denies show running-config and apply it to a Policy Set for a specific user group.
show running-config
Adding User Accounts
ISE Equivalent: In ISE, local users are created under Administration → Identity Management → Identities. You can add users, assign them to identity groups, and apply policies based on these groups.
Before the introduction of Cisco Identity Services Engine (ISE), enterprises widely deployed Cisco Secure Access Control Server (ACS) as their central AAA platform. ACS provided unified support for both TACACS+ and RADIUS, giving organizations flexibility in managing network administrator logins, user access, and accounting within a single solution.
ACS was designed to scale across large enterprise environments, integrating with external identity stores such as Active Directory and LDAP. By centralizing user management, ACS simplified policy enforcement across hundreds or thousands of routers, switches, firewalls, and VPN concentrators.
Key benefits of Cisco Secure ACS included:
Advanced ACS features:
Cisco Secure ACS was a core component of the Identity-Based Networking Services (IBNS) architecture. It worked closely with standards such as 802.1X and EAP to enforce user-specific policies down to the port level. For example, ACS could dynamically assign VLANs, ACLs, or session quotas based on a user’s identity and posture assessment.
In Cisco’s Network Admission Control (NAC) framework, ACS validated whether devices complied with corporate policies (e.g., antivirus, OS patch level). Noncompliant endpoints could be quarantined or granted only limited access, reducing the risk of malware spread. These functions laid the foundation for modern zero-trust access models.
ACS was available in multiple form factors to meet different organization sizes and budgets:
While this course focuses on the Windows Server-based ACS, the same core concepts applied to the Solution Engine and Express appliances.
Example: Configuring a Cisco router to use ACS (TACACS+)
aaa new-model tacacs server ACS-SRV address ipv4 10.1.1.5 key MyACSKey ! aaa authentication login default group tacacs+ local aaa authorization exec default group tacacs+ local aaa accounting exec default start-stop group tacacs+
Example: Configuring ACS integration with Active Directory (simplified)
NetworkAdmins
As of 2017, Cisco Secure ACS has reached End-of-Life (EoL). Its features have been fully absorbed and expanded in Cisco Identity Services Engine (ISE). ISE builds on ACS’s foundation but adds capabilities like device profiling, posture assessment, BYOD onboarding, and deeper integration with modern zero-trust security models. Today, ISE is the recommended platform for all new AAA deployments.
Understanding Authorization
While authentication is concerned with ensuring that the device or end user is as claimed, authorization is concerned with allowing and disallowing authenticated users access to certain areas and programs on the network.
The TACACS+ protocol allows the separation of authentication from authorization. A router can be configured to restrict the user to performing only certain functions after successful authentication. Authorization can be configured for both character mode (exec authorization) and packet mode (network authorization). Keep in mind that RADIUS does not separate the authentication from the authorization process.
Another important aspect of authorization is the ability to control user access to specific services. Controlling access to configuration commands greatly simplifies the infrastructure security in large enterprise networks. Per-user permissions on the Cisco Secure ACS simplify network device configuration.
For example, an authorized user can be permitted to access the show version command but not the configure terminal command. The router queries the ACS for permission to execute the commands on behalf of the user. When the user issues the show version command, the ACS sends an ACCEPT response. If the user issues a configure terminal command, the ACS sends a REJECT response.
show version
configure terminal
TACACS+ by default establishes a new TCP session for every authorization request, which can lead to delays when users enter commands. Cisco Secure ACS supports persistent TCP sessions to improve performance.
Configuring Command Authorization
To configure command authorization, use the aaa authorization {network | exec | commands level} {default | list-name} method1...[method4] command. The service type can specify the types of commands or services:
aaa authorization {network | exec | commands level} {default | list-name} method1...[method4]
commands level
exec
network
Important Security Consideration
When AAA authorization is not enabled, all users are allowed full access. After authentication is started, the default changes to allow no access. This means that the administrator must create a user with full access rights before authorization is enabled. Failure to do so immediately locks the administrator out of the system the moment the aaa authorization command is entered. The only way to recover from this is to reboot the router. If this is a production router, rebooting might be unacceptable. Be sure that at least one user always has full rights.
aaa authorization
Creating Authorization Method Lists
To configure the router to use the Cisco Secure ACS server for authorization, create a user-defined authorization method list or edit the default authorization method list. The default authorization method list is automatically applied to all interfaces except those that have a user-defined authorization method list explicitly applied. A user-defined authorization method list overrides the default authorization method list.
Configuring Exec Authorization
To configure the default authorization method list for character mode (exec) access using the CLI:
aaa authorization exec default group tacacs+
This command configures the router to use the TACACS+ server group for exec authorization. The default keyword applies this authorization policy to all lines unless a custom method list is specified.
default
Configuring Network Authorization
To configure the default authorization method list for packet mode (network) access using the CLI:
aaa authorization network default group tacacs+
This command configures the router to use the TACACS+ server group for network service authorization, such as PPP, SLIP, and ARAP connections.
! Basic AAA Authorization Configuration Example ! Configure AAA authorization for TACACS+ server Router> enable Router# configure terminal ! First, ensure AAA is enabled Router(config)# aaa new-model ! Configure TACACS+ server (if not already done) Router(config)# tacacs-server host 192.168.1.100 key SecretKey123 ! Configure exec authorization (character mode) ! This controls access to exec shell commands Router(config)# aaa authorization exec default group tacacs+ local ! Configure network authorization (packet mode) ! This controls access to network services like PPP, SLIP, ARAP Router(config)# aaa authorization network default group tacacs+ local ! Configure command authorization for privilege level 15 (enable mode) ! This controls which commands users can execute Router(config)# aaa authorization commands 15 default group tacacs+ local ! Optional: Configure command authorization for privilege level 1 (user mode) Router(config)# aaa authorization commands 1 default group tacacs+ local ! Create a user with full access BEFORE enabling authorization ! This prevents lockout! Router(config)# username admin privilege 15 secret AdminPass123 ! End configuration Router(config)# end Router# write memory ! ============================================ ! Example: Custom Authorization Method List ! ============================================ Router(config)# aaa authorization exec VTY_LIST group tacacs+ local Router(config)# aaa authorization commands 15 VTY_LIST group tacacs+ local ! Apply custom method list to VTY lines Router(config)# line vty 0 4 Router(config-line)# authorization exec VTY_LIST Router(config-line)# authorization commands 15 VTY_LIST Router(config-line)# exit ! ============================================ ! Verification Commands ! ============================================ ! View current authorization configuration Router# show running-config | include aaa authorization ! View active AAA sessions Router# show aaa sessions ! Test authorization for a specific user Router# test aaa group tacacs+ admin SecretKey123 legacy ! Debug authorization (use with caution in production) Router# debug aaa authorization Router# debug tacacs authorization
Sometimes a company wants to keep track of which resources individuals or groups use. Examples of this include when one department charges other departments for access, or one company provides internal support to another company. AAA accounting provides the ability to track usage, such as dial-in access, to log the data gathered to a database, and to produce reports on the data gathered.
Although accounting is generally considered a network management or financial management issue, it is discussed briefly here because it is so closely linked with security. One security issue that accounting addresses is creating a list of users and the time of day they dialed into the system. If, for example, the administrator knows that a worker logs in to the system in the middle of the night, this information can be used to further investigate the purpose of the login.
Another reason to implement accounting is to create a list of changes occurring on the network, who made the changes, and the exact nature of the changes. Knowing this information helps the troubleshooting process if the changes cause unexpected results.
Cisco Secure ACS serves as a central repository for accounting information, essentially tracking events that occur on the network. Each session that is established through Cisco Secure ACS can be fully accounted for and stored on the server. This stored information can be very helpful for management, security audits, capacity planning, and network usage billing.
Accounting Method Lists
Like authentication and authorization method lists, method lists for accounting define the way accounting is performed and the sequence in which these methods are performed. After it is enabled, the default accounting method list is automatically applied to all interfaces, except those that have a named accounting method list explicitly defined.
Configuring AAA Accounting
To configure AAA accounting, use the aaa accounting {network | exec | connection} {default | list-name} {start-stop | stop-only | none} [broadcast] method1...[method4] global configuration mode command. The network, exec, and connection parameters are commonly used keywords.
aaa accounting {network | exec | connection} {default | list-name} {start-stop | stop-only | none} [broadcast] method1...[method4]
connection
As with AAA authentication, either the keyword default or a list-name is used.
list-name
Next, the record type, or trigger, is configured. The trigger specifies what actions cause accounting records to be updated. Possible triggers are none, start-stop, stop-only.
start-stop
stop-only
For example, to log the use of EXEC sessions and network connections, use the global configuration commands:
R1(config)# aaa accounting exec default start-stop group tacacs+ R1(config)# aaa accounting network default start-stop group tacacs+
Configuration Example
! Enable AAA accounting Router> enable Router# configure terminal ! Ensure AAA is enabled Router(config)# aaa new-model ! Configure TACACS+ server (if not already configured) Router(config)# tacacs-server host 192.168.1.100 key SecretKey123 ! Configure exec accounting (tracks user EXEC sessions) ! start-stop sends accounting record at start and end of session Router(config)# aaa accounting exec default start-stop group tacacs+ ! Configure network accounting (tracks network services like PPP) Router(config)# aaa accounting network default start-stop group tacacs+ ! Configure connection accounting (tracks outbound connections) Router(config)# aaa accounting connection default start-stop group tacacs+ ! Configure command accounting for privilege level 15 ! Tracks all commands executed by users Router(config)# aaa accounting commands 15 default start-stop group tacacs+ ! Optional: Configure stop-only accounting (only sends record at session end) ! This reduces server load compared to start-stop Router(config)# aaa accounting exec STOP_ONLY stop-only group tacacs+ ! Optional: Send accounting records to multiple server groups Router(config)# aaa accounting exec default start-stop group tacacs+ group radius ! End configuration Router(config)# end Router# write memory ! ============================================ ! Verification Commands ! ============================================ ! View current accounting configuration Router# show running-config | include aaa accounting ! View active accounting sessions Router# show aaa sessions ! View accounting statistics Router# show aaa servers ! Debug accounting (use with caution in production) Router# debug aaa accounting Router# debug tacacs accounting
AAA (Authentication, Authorization, and Accounting) provides a comprehensive framework for controlling and monitoring network access in Cisco environments. The three components work together to ensure that only legitimate users can access network resources, that users can only perform actions they are permitted to do, and that all network activity is properly tracked and logged.
Authentication verifies user identity before granting access to the network. This can be accomplished through various methods including local username databases, TACACS+ servers, or RADIUS servers. The authentication process ensures that users are who they claim to be by validating credentials such as usernames and passwords.
Authorization determines what authenticated users are allowed to do once they have gained access. This includes controlling access to specific commands, services, and network resources. For example, authorization can restrict a user to viewing configuration commands while preventing them from making changes. TACACS+ provides the advantage of separating authentication from authorization, allowing for more granular control over user permissions.
Accounting tracks and logs user activities on the network. This includes recording when users log in and out, what commands they execute, and what network services they access. Accounting data is essential for security audits, troubleshooting, capacity planning, and billing purposes. The accounting records can be configured to trigger at the start and stop of sessions or only at the end of sessions.
Implementing AAA requires careful planning to avoid accidentally locking administrators out of the system. Best practices include creating local administrator accounts with full privileges before enabling authorization, using method lists that include local fallback options in case remote servers become unavailable, and thoroughly testing configurations in a non-production environment first.
AAA can be configured using either TACACS+ or RADIUS protocols, with TACACS+ generally preferred in Cisco environments due to its ability to separate authentication, authorization, and accounting functions, its use of TCP for reliable communications, and its encryption of the entire authentication packet. Method lists provide flexibility by allowing different AAA policies to be applied to different interfaces or services.
Troubleshooting AAA configurations involves using debug commands such as debug aaa authentication, debug tacacs, and debug radius to monitor authentication traffic and identify configuration issues. These commands should be used carefully in production environments as they can generate significant output.
! Complete AAA Configuration Example Router> enable Router# configure terminal ! Enable AAA Router(config)# aaa new-model ! Configure TACACS+ server Router(config)# tacacs-server host 192.168.1.100 key SecretKey123 ! Create local admin user for fallback (CRITICAL - prevents lockout) Router(config)# username admin privilege 15 secret AdminPass123 ! Configure authentication Router(config)# aaa authentication login default group tacacs+ local Router(config)# aaa authentication enable default group tacacs+ enable ! Configure authorization Router(config)# aaa authorization exec default group tacacs+ local Router(config)# aaa authorization commands 15 default group tacacs+ local Router(config)# aaa authorization network default group tacacs+ local ! Configure accounting Router(config)# aaa accounting exec default start-stop group tacacs+ Router(config)# aaa accounting commands 15 default start-stop group tacacs+ Router(config)# aaa accounting network default start-stop group tacacs+ ! Apply to VTY lines Router(config)# line vty 0 4 Router(config-line)# login authentication default Router(config-line)# authorization exec default Router(config-line)# authorization commands 15 default Router(config-line)# accounting exec default Router(config-line)# accounting commands 15 default Router(config-line)# exit ! Apply to console (optional) Router(config)# line console 0 Router(config-line)# login authentication default Router(config-line)# exit Router(config)# end Router# write memory ! Verification commands Router# show running-config | include aaa Router# show aaa servers Router# show aaa sessions