Local AAA Configuration

Lab Objectives

• Configure local AAA on a router to authenticate administrative logins using a local user database.
• Create local usernames with specific privilege levels and apply them to console and vty lines.
• Verify and troubleshoot local AAA so you can confirm access control works as intended.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Enable local AAA and create administrative users

Create a local user called admin with secret password Lab@123 and privilege level 15. Create a second user operator with secret Lab@123 and privilege level 7. Enable AAA on the device so local authentication can be used.

Task 2: Apply local authentication to management lines

Configure the console and vty lines to require login using the local AAA database (the users you created). Ensure vty lines permit SSH and/or Telnet as necessary.

Task 3: Verify and demonstrate login restrictions

Show configuration and runtime state to prove:

• AAA is active
• Users exist with correct privilege levels
• Console and vty are configured to use local authentication

Think About It: Why would you use local AAA on a small branch router instead of integrating it with a central RADIUS/TACACS+ server? What are the trade-offs for security, resiliency, and management?

---

Lab Solution

First, the BASE LAB TOPOLOGY (use this EXACT topology for all CCNA labs). This diagram lists the router interface IP addresses used in this lab — keep it visible while configuring.

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 Gi0/0: 10.10.20.2 Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

IP SCHEME (for reference)

• 10.10.10.0/24 — R1-R2 link
• 10.10.20.0/24 — R1-R3 link
• 10.10.30.0/24 — R1-R4 link
• 10.10.40.0/24 — R2-S1 link
• 192.168.1.0/24 — VLAN 10 (Sales)
• 192.168.2.0/24 — VLAN 20 (Engineering)
• 192.168.3.0/24 — VLAN 30 (Management)
• 203.0.113.0/24 — Public/Internet simulation

Tip: Think of AAA like a gated building: Authentication checks someone's identity, Authorization decides which floors they may access (privilege level), and Accounting logs who came in and when. In small sites you often rely on local guards (local AAA); in larger networks you use a central security desk (RADIUS/TACACS+).

Task 1 Solution: Enable local AAA and create administrative users

What we are doing: Turn on AAA services on the router and create local accounts for administrative access. The admin account will be full-privilege (15). The operator account will have reduced privilege (7). Using local AAA lets the device validate usernames/passwords from its internal database.

conf t
aaa new-model
username admin privilege 15 secret Lab@123
username operator privilege 7 secret Lab@123
end

What each command does and why it matters:

• aaa new-model — Enables the AAA feature set on IOS. This is required before configuring authentication methods; without it, the subsequent AAA commands are not active.
• username admin privilege 15 secret Lab@123 — Creates a local user admin with the highest privilege (15) and a secret (stored hashed). This user can execute all privileged exec commands.
• username operator privilege 7 secret Lab@123 — Creates a local user operator with limited privileges (7). Operators can run a subset of commands (useful for safer operational tasks).
• Using secret instead of password stores the password hashed (more secure).

Verify:

show running-config | include aaa|username

Expected output (example; encrypted secret text will vary):

aaa new-model
username admin privilege 15 secret 5 $1$abcd$KJH5kd...
username operator privilege 7 secret 5 $1$efgh$UiO7rt...

Why this verification matters: it confirms AAA is active and the local usernames exist with the configured privilege levels.

---

Task 2 Solution: Apply local authentication to management lines

What we are doing: Configure the console and vty lines so admins must authenticate using the local AAA database. This replaces (or supplements) the older login local for AAA-aware configuration, and ensures both local and remote logins require valid credentials.

conf t
line con 0
 login authentication default
 exit
line vty 0 4
 login authentication default
 transport input telnet ssh
 exit
aaa authentication login default local
end

What each command does and why it matters:

• aaa authentication login default local — Defines an authentication method list named default that uses the local user database. When default is referenced on lines, the router will check local usernames for login.
• line con 0 and line vty 0 4 — Enters line configuration mode for console and vty (remote) sessions.
• login authentication default — Tells the line to use the AAA method list default. This links the line to the AAA configuration.
• transport input telnet ssh — Allows both Telnet and SSH on vty lines (SSH is preferable in production); keep Telnet only if lab/testing requires it.

Verify:

show running-config | section line
show running-config | include aaa authentication

Expected output:

line con 0
 login authentication default
line vty 0 4
 login authentication default
 transport input telnet ssh

aaa authentication login default local

Why this verification matters: It proves that the lines will use the local AAA database for authentication. Without login authentication default, AAA would not be used and a fallback could permit unauthenticated access.

---

Task 3 Solution: Verify and demonstrate login restrictions

What we are doing: Confirm the user accounts and that attempting interactive logins would require the created credentials. We will inspect the username list, AAA methods, and check current sessions (if any).

show username
show aaa
show users

What each command does and why it matters:

• show username — Lists local user accounts and privilege levels on the router. Use this to confirm usernames were created correctly.
• show aaa — Displays AAA service state and method lists; confirms default is mapped to local.
• show users — Displays connected users (current console and vty sessions). Useful to validate remote access behavior after testing.

Verify (expected sample output):

R1#show username
Default authentication mode is AAA
username admin privilege 15
username operator privilege 7

R1#show aaa
AAA: Authentication services:
     Method lists:
        login default -> local
AAA: Accounting services:
     No accounting method lists configured.

R1#show users
Line       User     Host(s)              Idle   Location
*?         admin    idle 00:00:02        0      con0

Why this verification matters: These outputs give you confidence the accounts exist and AAA is active. You can now test by attempting console or vty logins and using the admin / operator credentials.

---

Troubleshooting Scenario

Scenario: Console still allows access without credentials

Symptom: After configuring AAA, you can still access the console without being prompted for username/password. Your task: Find and fix the issue. Hint: Console has its own login setting or session may already be authenticated on an open console session. Solution:

• Confirm line con 0 contains login authentication default. If it does not, add it:

conf t
line con 0
 login authentication default
end

• If you are already on the console, the router will not prompt again; perform a new console session (physically disconnect/reconnect or use a terminal emulator reconnect) to test.

---

Verification Checklist

• aaa new-model is present in running configuration.
• Local users admin (priv 15) and operator (priv 7) exist.
• aaa authentication login default local is configured.
• line con 0 and line vty 0 4 use login authentication default.

Common Mistakes

Symptom	Cause	Fix
Console not prompting for login	line con 0 missing login authentication or you are still on an existing authenticated console session	Add login authentication default under line con 0. Reconnect console session to test
show running-config shows username but login fails	AAA method list not applied to lines (console/vty)	Apply login authentication default under the lines and ensure aaa authentication login default local exists
Unable to SSH in	SSH not configured / transport input does not include ssh	Add transport input ssh (or telnet ssh) under line vty and ensure SSH keys/config exist before production use

Challenge Task

On R2, create a local read-only user monitor with privilege 5 and ensure this account can access vty lines but cannot enter exec-level privileged commands (enable). Do not change global enable password. Show the verification proving monitor cannot access privilege 15 commands.

Real-world note: In production, local AAA is convenient for small sites or when central AAA servers are unreachable. However, for large networks you typically use RADIUS/TACACS+ for centralized credential management and better auditing. Local AAA is analogous to having the keys stored at each building rather than at a central security office.

Key takeaway: Local AAA + line binding is the foundation for device login security—understand how aaa new-model, method lists, and line configuration work together to control who can access your network devices.