Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 5.8 — Compare AAA functions

AAA divides access control into authentication, authorization, and accounting. Authentication answers who or what is requesting access. Authorization decides what an authenticated identity may do. Accounting records relevant activity. The functions reinforce one another, but success at one stage does not imply success at the others.

Authentication establishes identity

Credentials, certificates, tokens, or other factors can support authentication. The process needs a defined identity store and a failure policy. A device might consult a centralized service first and use a tightly controlled local account only when the service is unreachable. A fallback must not silently turn every rejected centralized login into a successful local bypass.

TACACS+ and RADIUS can provide centralized AAA capabilities, although their common deployments and protocol details differ. For CCNA reasoning, focus on which device is the client, which system holds policy, how reachability is protected, and what happens when the server is unavailable.

Authorization limits action

After an identity is accepted, authorization can assign a privilege level, permit commands, select a network role, or constrain resources. Least privilege grants only what the job needs. A valid administrator credential should not automatically provide unrestricted access to every device and command.

Authorization decisions need consistent group membership and policy. Emergency access may require broader permissions, but it should be exceptional, time-bounded where practical, and heavily monitored.

Accounting creates evidence

Accounting can record login attempts, session start and stop times, executed commands, assigned addresses, or resource usage. Useful records need synchronized time, stable identity, protected transport and storage, controlled access, and a retention policy. Accounting is evidence; it does not itself block an unauthorized command.

Worked scenario

An engineer successfully logs in to a switch through a central AAA server but cannot enter a configuration command. Authentication succeeded; authorization denied the action. The operator should inspect the assigned role and command policy rather than resetting the password. If the attempt appears in a central record with identity, device, time, and outcome, accounting also worked.

Plan availability safely

Central AAA improves consistent control and offboarding, but it creates service and network dependencies. Maintain a tested recovery account, restrict its use, monitor activation, and ensure management routing can reach the AAA service. Test server-unreachable behavior separately from explicit credential rejection; they should not necessarily follow the same fallback path.

Verification evidence

Test a permitted user, a denied user, a permitted command, a prohibited command, and a simulated service failure through an approved lab. Inspect active method lists, server reachability, policy assignments, and accounting records. Confirm time synchronization and avoid recording secrets.

Common traps

• Treating successful login as proof of authorization.
• Saying accounting prevents an action.
• Designing fallback that bypasses a valid rejection.
• Ignoring the management path to centralized servers.
• Keeping logs without synchronized timestamps or stable identities.

Readiness checklist

• I can distinguish all three AAA functions.
• I can reason about centralized service and local recovery.
• I understand least privilege and command authorization.
• I can identify useful accounting evidence.