Compare Authentication, Authorization, and Accounting (AAA) Concepts

Domain 5.8 | Security Fundamentals — 15% of exam

Learning Objectives

By the end of this lesson, you will be able to:

• Define authentication, authorization, and accounting, and explain why they’re treated as three distinct functions rather than one combined process.
• Describe the AAA architecture: the relationship between a client device, a network access server, and an AAA server.
• Compare TACACS+ and RADIUS across encryption scope, the separation of AAA functions, typical use case, and transport protocol.
• Explain how method lists provide fallback authentication when a centralized AAA server is unreachable.
• Correctly apply the exam’s TACACS+/RADIUS pattern-recognition guidance to a described scenario.

Key Terms Glossary

Three Distinct Questions, Not One Combined Process

It’s tempting to think of “logging in” as a single event, but AAA deliberately separates it into three distinct questions, each answered independently:

Authentication answers “who are you?” — verifying identity via a username/password, a certificate, a token, or some other credential. This is the piece most people intuitively associate with “logging in,” but it’s only the first of three separate functions.

Authorization answers “what are you allowed to do?” — once identity is confirmed, authorization determines the specific commands, resources, or access level that identity is actually permitted. Two authenticated users can have completely different authorization levels; successfully proving who you are doesn’t automatically grant unlimited access to everything.

Accounting answers “what actually happened?” — logging which commands were run, which resources were accessed, and when, creating a record used for auditing, billing, or compliance purposes after the fact. Accounting doesn’t grant or restrict access at all; it simply records what occurred once authentication and authorization have already done their jobs.

This separation matters because a real security posture genuinely needs all three functioning as distinct layers. A device could theoretically authenticate every user correctly but grant identical, unrestricted access to everyone regardless of role — a genuine authorization failure even with authentication working perfectly. Similarly, a device could authenticate and authorize correctly but keep no record of what happened afterward, leaving no audit trail if something goes wrong — an accounting gap. Treating these as three separate, independently verifiable functions, rather than one undifferentiated “login” step, is precisely why AAA is structured this way.

A Worked Example Across All Three Functions

Consider a network engineer named Priya logging into a core router to troubleshoot a routing issue. First, authentication confirms Priya is really Priya — she supplies her username and password (or certificate, depending on configuration), and the AAA system verifies this matches a known identity rather than an impostor. Second, authorization determines what Priya specifically can do now that her identity is confirmed — perhaps her role permits show commands for diagnostics but not configure terminal, since routing changes on this particular core device require a more senior engineer’s sign-off under this organization’s access policy.

Third, accounting logs that Priya logged in at a specific time, ran a specific sequence of show commands, and logged out — a record that exists regardless of whether anything went wrong, simply because accounting’s job is to capture what happened, not to judge whether it should have happened. If a routing issue later turns out to trace back to an unauthorized change, this accounting trail is exactly what allows an investigation to determine who did what and when, rather than starting from nothing.

AAA Architecture: Client, NAS, and AAA Server

AAA typically involves three parties working together. The client is the user or device attempting to gain access — someone connecting via SSH to manage a router, or a laptop connecting to a wireless network. The Network Access Server (NAS) — sometimes called the AAA client in this context, which can be a confusing overlap in terminology — is the device the client actually connects through: the router being managed, or the wireless controller/switch handling network access. The NAS doesn’t make authentication decisions itself; instead, it relays the client’s credentials to a centralized AAA server, which holds the actual authentication database, authorization policies, and accounting logs, and returns a decision back to the NAS.

This centralization is the entire point of moving beyond the local password approach covered in objective 5.3. Local passwords and login local accounts work fine for a handful of devices, but managing individual local accounts across hundreds or thousands of devices doesn’t scale — updating a single administrator’s credentials would require touching every device individually. A centralized AAA server lets that same change happen once, in one place, immediately reflected across every device that consults it.

TACACS+ vs. RADIUS: The Most Reliably Tested Comparison in This Domain

Two protocols dominate real-world AAA deployments, and comparing them directly is one of the most frequently tested pairings in the entire Security Fundamentals domain.

A Brief Note on Origins

TACACS+ is worth understanding as distinct from its similarly-named predecessors, TACACS and XTACACS — TACACS+ is a substantial redesign rather than a minor version update, and despite originating at Cisco, it’s since become an open, documented protocol implementable by other vendors, not a proprietary Cisco-only mechanism locked to Cisco equipment exclusively. RADIUS, by contrast, was developed as an open IETF standard from the outset, which partly explains its broader adoption across a wider range of vendors specifically for network access scenarios, where interoperability across many different types of access devices (wireless controllers, VPN concentrators, switches from multiple vendors) matters more than it typically does for device administration, which is more often a single-vendor, Cisco-centric context in practice.

Why the Encryption Difference Matters in Practice

TACACS+ encrypting the entire packet body — not just credentials, but the full content of the exchange — provides meaningfully stronger confidentiality for the whole conversation between the NAS and the AAA server. RADIUS encrypting only the password field leaves other attributes in the exchange (including, in some configurations, details about what’s being authorized) potentially visible to anyone observing the traffic, even though the password itself remains protected. This connects directly back to the confidentiality principle from objective 5.1 — TACACS+’s broader encryption scope is a stronger confidentiality control by design, not merely an implementation detail.

Why the Authentication/Authorization Separation Matters in Practice

TACACS+’s separation of authentication and authorization into distinct steps has a genuinely practical consequence: it enables granular, per-command authorization on network devices. An administrator authenticated via TACACS+ can be authorized for a specific, limited set of commands — perhaps permitted to run show commands for troubleshooting but explicitly denied configure terminal access — because authorization is checked as its own separate step, potentially per-command, rather than being bundled with the initial login. This is exactly why TACACS+ is the typical choice for device administration: administrators often need this fine-grained command-level control over what different support tiers or roles can actually do on a device.

RADIUS combining authentication and authorization into a single step fits its typical use case well: network access control, such as 802.1X port authentication or VPN access. In these scenarios, the practical question is usually binary — is this user/device allowed onto the network at all, and with what basic access parameters (a VLAN assignment, for instance) — rather than needing granular, evolving, per-command control the way device administration does. A single combined Access-Accept response carrying both the authentication result and basic authorization attributes together is sufficient for this simpler use case.

The Exam’s Direct Pattern-Recognition Guidance

Worth stating explicitly, since it’s exactly how this comparison tends to be tested: “encrypts the whole packet” and “used for administrative device access” both point to TACACS+; “encrypts only the password” and “used for network access authentication” both point to RADIUS. These pairs of clues reliably travel together, and recognizing either half of a pair should immediately suggest the other.

Method Lists: Fallback When the AAA Server Is Unreachable

A centralized AAA server introduces an obvious risk: what happens if that server becomes unreachable? A method list addresses this directly — it’s an ordered list of authentication methods a device tries in sequence, falling back to the next method if the current one fails or is unavailable.

aaa new-model
aaa authentication login default group tacacs+ local

Reading this: aaa new-model enables AAA globally on the device (a required first step before any AAA configuration takes effect at all). The authentication method list here says: for login authentication, first try the TACACS+ server group; if that group is unreachable, fall back to the device’s own local username/password database — the exact login local-style local authentication covered in objective 5.3.

This fallback behavior is precisely why local accounts remain relevant even in an organization with fully centralized AAA — they function as a resilient backup, ensuring an administrator can still get into a device during a genuine emergency (the centralized AAA server being down, a network partition isolating the device from that server) rather than being permanently locked out the moment centralized infrastructure has any kind of outage.

Common Misconceptions

• “Authentication, authorization, and accounting are really just one combined ‘login’ step.” They’re three genuinely distinct functions, each independently verifiable — a system can authenticate correctly while still failing at authorization or accounting.
• “TACACS+ and RADIUS are interchangeable, with the choice being purely a matter of vendor preference.” They differ in genuinely functional ways — encryption scope and the authentication/authorization separation — that make one or the other objectively better suited to a specific use case, not just a stylistic preference.
• “RADIUS’s password-only encryption means the rest of the exchange is completely insecure.” It means the rest of the exchange isn’t encrypted by RADIUS itself, which is a real, meaningful limitation compared to TACACS+ — but this doesn’t mean RADIUS deployments have no other security considerations at all, just that this specific protection is narrower in scope.
• “Local accounts become irrelevant once centralized AAA is deployed.” Local accounts remain important as a method-list fallback, ensuring access continuity if the centralized AAA server becomes unreachable.
• “The NAS is the same thing as the AAA server.” The NAS is the device the client connects through and relays credentials from; the AAA server is the centralized system that actually holds the authentication database and makes the decision — they are distinct roles, even though a single small deployment might blur this distinction in practice.

Configuration and Verification at a Conceptual Level

Beyond the method list example already shown, a slightly fuller illustrative configuration grounds the theory:

aaa new-model
tacacs server MAIN-TACACS
 address ipv4 10.1.1.50
 key SharedSecretKey123
!
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local
aaa accounting exec default start-stop group tacacs+

This configures a TACACS+ server, sets authentication to try that server first with local fallback, sets authorization for EXEC-level access similarly, and enables accounting that logs the start and stop of EXEC sessions to the TACACS+ server. Verification at a conceptual recognition level uses test aaa to manually verify a set of credentials against the configured AAA method, and debug aaa authentication to observe the authentication process in real time during troubleshooting — full command syntax and detailed verification workflow for these sit beyond this particular objective’s comparative, conceptual scope.

Troubleshooting Patterns

“Users can no longer log in after AAA was configured, even with correct credentials.” Confirm aaa new-model is actually enabled — AAA configuration commands have no effect until this global command is present, and its absence is a common oversight when AAA configuration is copied from one device to another without checking prerequisites.

“Administrators can authenticate but retain full access regardless of intended role restrictions.” This points to an authorization gap — confirm authorization method lists are actually configured and applied, since authentication succeeding says nothing about whether authorization is separately enforcing the intended access restrictions.

“AAA-based login stopped working entirely when the central server had an outage, despite a method list being configured.” Confirm the method list actually includes a fallback method (like local) and that local accounts genuinely exist and are current — a method list pointing only at the unreachable server, with no fallback configured, provides no resilience despite technically being a “method list.”

“A security review can’t find any record of who ran a specific configuration change.” This points to a missing or misconfigured accounting method list — accounting must be explicitly configured to log the relevant activity; it isn’t automatically enabled just because authentication and authorization are working correctly.

Frequently Asked Questions

Can an organization use both TACACS+ and RADIUS simultaneously, for different purposes?

Yes, and this is common practice — TACACS+ for device administration (controlling who can configure routers and switches) alongside RADIUS for network access control (802.1X, VPN), each protocol used where its specific strengths fit best.

Does accounting only matter for compliance and auditing, or does it have operational value too?

Both — beyond formal compliance requirements, accounting logs are genuinely useful for operational troubleshooting, helping reconstruct what configuration changes were made and by whom when diagnosing an unexpected issue after the fact.

Is a method list limited to exactly two methods (primary and one fallback)?

No — a method list can include more than two methods in sequence, trying each in order until one succeeds or all are exhausted, though a primary centralized method plus a local fallback is the single most common practical pattern seen in real deployments.

Why would TACACS+’s per-command authorization matter if an administrator is already trusted enough to have login access at all?

Different administrative roles often warrant different levels of trust — a junior support technician might reasonably need read-only troubleshooting access without full configuration privileges, and per-command authorization is exactly the mechanism that makes this kind of role-based restriction practically enforceable rather than all-or-nothing.

How does AAA relate to the certificate-based authentication discussed in objective 5.4?

They can work together rather than being mutually exclusive — a RADIUS server can authenticate a device or user based on a presented certificate rather than a traditional password, particularly common in 802.1X deployments, meaning the AAA framework and the specific authentication mechanism (password, certificate, token) are somewhat independent layers that combine in practice.

What kinds of activity can accounting actually track, beyond just login and logout events?

Accounting can be configured to log a wide range of activity depending on the deployment: EXEC session start/stop times, individual command execution (particularly relevant alongside TACACS+’s per-command authorization), network connection details, and even resource usage metrics in some configurations. The specific scope of what gets logged is itself a configuration choice, not a fixed, all-or-nothing behavior — an organization can log only session-level events for lighter overhead, or log every individual command for maximum audit detail, depending on how much granularity their compliance or troubleshooting needs actually require.

Summary

• Authentication, authorization, and accounting are three distinct functions — verifying identity, determining permitted access, and logging what happened — rather than a single combined login process, and a real deployment needs all three functioning correctly and independently to be considered genuinely secure.
• AAA architecture involves a client, a Network Access Server (NAS) that relays credentials, and a centralized AAA server that holds the authentication database and makes decisions — three distinct roles that shouldn’t be conflated with each other even in smaller deployments.
• TACACS+ encrypts the entire packet body, separates authentication and authorization into distinct steps, and is typically used for device administration; RADIUS encrypts only the password field, combines authentication and authorization, and is typically used for network access control like 802.1X and VPN authentication.
• Method lists provide fallback authentication — commonly falling back to local accounts, from objective 5.3 — ensuring access continuity if a centralized AAA server becomes unreachable, which is exactly why local accounts remain a deliberate, permanent part of a well-designed AAA deployment rather than a temporary stepping stone to be removed once centralization is complete.
• The exam’s reliable pattern: “whole packet encryption” and “device administration” point to TACACS+; “password-only encryption” and “network access” point to RADIUS — and both protocols can coexist in the same organization, each applied where its strengths fit best.