Differentiating Authentication, Authorization, and Accounting (AAA) Concepts

Imagine walking into a secure office building. First, a guard checks your ID to confirm who you are. Then, your ID badge determines which floors you’re allowed to enter. Finally, a logbook records what time you entered, which doors you used, and when you left.

This is exactly how AAA (Authentication, Authorization, and Accounting) works in networking and IT security. AAA is a framework used to control and monitor access to networks, systems, and services. It answers three separate but related questions:

1. Authentication — Who are you?
2. Authorization — What are you allowed to do?
3. Accounting — What did you actually do?

This article explains each concept from first principles, shows how they work together, and demonstrates real configuration examples on Cisco devices and Linux systems.

1. Authentication: Proving Identity

Authentication is the process of verifying that someone is who they claim to be. It’s the “front door check.”

1.1 Authentication Factors

Authentication typically relies on one or more of these factor categories:

1.2 Multi-Factor Authentication (MFA)

Using more than one factor dramatically increases security. For example:

• Password (something you know) + OTP code from an authenticator app (something you have) = 2FA.
• Banking apps often combine password + fingerprint + device recognition = 3FA.

1.3 Common Authentication Protocols

1.4 Real-World Example

When you log into a corporate VPN with your username and password, and then approve a push notification on your phone — that’s authentication using two factors: something you know (password) and something you have (your phone).

2. Authorization: Granting Permissions

Once identity is confirmed, authorization determines what that identity is allowed to do. Authentication and authorization are often confused, but they are distinct steps that happen in sequence.

Key distinction: Authentication asks “who are you?” Authorization asks “what can you do, now that we know who you are?”

2.1 Common Authorization Models

2.2 Real-World Example: Network Device Authorization

A network engineer logs into a Cisco router (authenticated), but authorization determines whether they can only view the configuration (show commands) or actually modify it (configure terminal privileges).

Cisco privilege levels illustrate this well:

2.3 Linux Authorization Example

Linux uses a DAC model through file permissions:

ls -l /etc/shadow
# -rw-r----- 1 root shadow 1245 Jul 20 10:03 /etc/shadow

ls -l /etc/shadow
# -rw-r----- 1 root shadow 1245 Jul 20 10:03 /etc/shadow

Only root and members of the shadow group can read this file — authorization enforced at the filesystem level, independent of authentication.

3. Accounting: Tracking Activity

Accounting (sometimes called auditing) records what an authenticated and authorized user actually did. This creates a trail used for billing, compliance, forensics, and troubleshooting.

3.1 What Accounting Typically Logs

• Login/logout timestamps
• Commands executed
• Resources accessed (files, network destinations)
• Data transferred (bytes sent/received) — historically used for ISP billing
• Session duration

3.2 Real-World Example

An ISP’s RADIUS accounting logs record how long a customer’s PPPoE session lasted and how much data was used — this is literally where “accounting” got its name, originally used for billing dial-up and broadband customers.

In an enterprise, accounting logs might show: “User jdoe logged into Router-Core-01 at 14:32, ran show running-config, and logged out at 14:41.” This is critical for security audits — if a config changes unexpectedly, accounting logs identify who did it and when.

4. How AAA Works Together: The RADIUS/TACACS+ Model

In enterprise networks, AAA services are typically centralized using a dedicated AAA server, rather than storing credentials locally on every device. The two dominant protocols are:

sequenceDiagram
    participant User
    participant NAS as Network Access Server (Router/Switch/AP)
    participant AAA as AAA Server (RADIUS/TACACS+)
    User->>NAS: Login attempt (username/password)
    NAS->>AAA: Authentication Request
    AAA-->>NAS: Accept/Reject
    NAS->>AAA: Authorization Request (what can this user do?)
    AAA-->>NAS: Permit specific commands/access
    User->>NAS: Performs actions
    NAS->>AAA: Accounting records (start/stop/update)

4.1 Why TACACS+ Is Preferred for Device Administration

TACACS+ separates authorization from authentication, allowing granular per-command control — for example, allowing a junior engineer to run show commands but blocking reload or write erase. RADIUS bundles authentication and authorization together, making this level of control harder.

5. Configuring AAA in Practice

5.1 Cisco IOS: Enabling AAA with TACACS+

! Enable AAA
aaa new-model

! Define TACACS+ server
tacacs server TACACS-SERVER1
 address ipv4 10.10.10.5
 key MySharedSecretKey

! Authentication: use TACACS+, fallback to local
aaa authentication login default group tacacs+ local

! Authorization: control which commands users can run
aaa authorization exec default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local

! Accounting: log all commands and exec sessions
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

! Enable AAA
aaa new-model

! Define TACACS+ server
tacacs server TACACS-SERVER1
 address ipv4 10.10.10.5
 key MySharedSecretKey

! Authentication: use TACACS+, fallback to local
aaa authentication login default group tacacs+ local

! Authorization: control which commands users can run
aaa authorization exec default group tacacs+ local
aaa authorization commands 15 default group tacacs+ local

! Accounting: log all commands and exec sessions
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+

5.2 Cisco IOS: RADIUS for Wireless 802.1X

aaa new-model
radius server RAD-SERVER1
 address ipv4 10.10.10.6 auth-port 1812 acct-port 1813
 key MyRadiusSecret

aaa authentication login default group radius local
aaa accounting network default start-stop group radius

aaa new-model
radius server RAD-SERVER1
 address ipv4 10.10.10.6 auth-port 1812 acct-port 1813
 key MyRadiusSecret

aaa authentication login default group radius local
aaa accounting network default start-stop group radius

5.3 Linux: PAM (Pluggable Authentication Modules)

Linux uses PAM to implement AAA-like behavior locally.

# /etc/pam.d/sshd (simplified example)
auth       required     pam_unix.so          # Authentication
account    required     pam_unix.so          # Authorization (account validity)
session    required     pam_limits.so        # Session/resource restrictions
session    required     pam_lastlog.so       # Accounting - logs last login

# /etc/pam.d/sshd (simplified example)
auth       required     pam_unix.so          # Authentication
account    required     pam_unix.so          # Authorization (account validity)
session    required     pam_limits.so        # Session/resource restrictions
session    required     pam_lastlog.so       # Accounting - logs last login

Checking login accounting logs:

last -a          # Shows login history (accounting)
lastb             # Shows failed login attempts
sudo journalctl _COMM=sshd  # SSH authentication/authorization logs

last -a          # Shows login history (accounting)
lastb             # Shows failed login attempts
sudo journalctl _COMM=sshd  # SSH authentication/authorization logs

5.4 Python: Simulating a Basic AAA Check

This simplified example demonstrates the logic of AAA — not a production system.

users_db = {
    "jdoe": {"password": "Secure123!", "role": "readonly"},
    "admin": {"password": "AdminPass!", "role": "full"}
}

permissions = {
    "readonly": ["show_config"],
    "full": ["show_config", "edit_config", "reload_device"]
}

def authenticate(username, password):
    user = users_db.get(username)
    if user and user["password"] == password:
        return True
    return False

def authorize(username, action):
    role = users_db[username]["role"]
    return action in permissions[role]

def account(username, action):
    with open("audit.log", "a") as log:
        log.write(f"User={username} performed action={action}\n")

# Simulated session
username, password, action = "jdoe", "Secure123!", "edit_config"

if authenticate(username, password):
    if authorize(username, action):
        print(f"{action} permitted")
        account(username, action)
    else:
        print(f"{action} DENIED for {username}")
else:
    print("Authentication failed")

users_db = {
    "jdoe": {"password": "Secure123!", "role": "readonly"},
    "admin": {"password": "AdminPass!", "role": "full"}
}

permissions = {
    "readonly": ["show_config"],
    "full": ["show_config", "edit_config", "reload_device"]
}

def authenticate(username, password):
    user = users_db.get(username)
    if user and user["password"] == password:
        return True
    return False

def authorize(username, action):
    role = users_db[username]["role"]
    return action in permissions[role]

def account(username, action):
    with open("audit.log", "a") as log:
        log.write(f"User={username} performed action={action}\n")

# Simulated session
username, password, action = "jdoe", "Secure123!", "edit_config"

if authenticate(username, password):
    if authorize(username, action):
        print(f"{action} permitted")
        account(username, action)
    else:
        print(f"{action} DENIED for {username}")
else:
    print("Authentication failed")

Output:

edit_config DENIED for jdoe

edit_config DENIED for jdoe

This tiny script mirrors the real-world flow: authenticate first, check permission second, log the outcome third.

6. Real-World Example: Enterprise VPN Access

A remote employee connecting to a corporate VPN experiences AAA end-to-end:

1. Authentication: Employee enters username/password + approves an MFA push notification.
2. Authorization: The AAA server checks the employee’s group membership (e.g., “Finance Department”) and permits access only to the finance subnet, not the entire corporate network.
3. Accounting: The VPN concentrator logs the connection start time, IP address assigned, duration, and total bytes transferred, all searchable later during a security audit.

7. Comparison Table: RADIUS vs TACACS+

8. Best Practices

• Always centralize AAA with a dedicated server (RADIUS/TACACS+) rather than local-only accounts on every device — this simplifies revoking access for one person across the whole network instantly.
• Use TACACS+ for network device administration due to granular command authorization.
• Use RADIUS for network access control (Wi-Fi, VPN, dial-in).
• Always configure a local fallback account in case the AAA server is unreachable — but restrict and monitor its use.
• Enforce MFA wherever possible for authentication.
• Apply the principle of least privilege during authorization — give users only the access they need.
• Enable accounting/logging on all critical systems and forward logs to a centralized SIEM for long-term retention and analysis.
• Regularly audit accounting logs for anomalies (logins at odd hours, unusual command sequences).

9. Troubleshooting AAA Issues

Cisco debug commands:

debug aaa authentication
debug aaa authorization
debug tacacs
test aaa group tacacs+ jdoe Secure123! legacy

debug aaa authentication
debug aaa authorization
debug tacacs
test aaa group tacacs+ jdoe Secure123! legacy

10. Summary

• Authentication verifies identity — “who are you?”
• Authorization determines permissions — “what can you do?”
• Accounting tracks activity — “what did you do?”

Together, these three pillars form the foundation of secure, auditable access control across networks, servers, and applications. Whether you’re configuring a Cisco router with TACACS+, hardening a Linux server with PAM, or designing a corporate VPN policy, thinking in terms of AAA helps you build systems that are secure, controllable, and accountable.

11. Deep Dive: Single Sign-On (SSO) and Federated Identity

Modern organizations rarely stop at basic AAA for one device or one application — they need users to authenticate once and gain access across many systems. This is where Single Sign-On (SSO) and federated identity protocols come in, extending the core AAA concepts into web-scale environments.

11.1 SAML (Security Assertion Markup Language)

SAML is an XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP) — like Okta or Azure AD — and a Service Provider (SP), such as a SaaS application. When a user logs into the IdP once, the IdP issues a signed “assertion” that the SP trusts, granting access without requiring the user to log in again.

11.2 OAuth 2.0 and OpenID Connect

OAuth 2.0 is fundamentally an authorization framework — it lets a user grant a third-party application limited access to their resources without sharing their password. OpenID Connect (OIDC) is built on top of OAuth 2.0 and adds an authentication layer, issuing an ID token that proves who the user is. Together, OAuth 2.0 and OIDC are the backbone of “Sign in with Google/Microsoft/GitHub” experiences seen across the modern web.

11.3 Why This Matters for AAA

SSO doesn’t replace AAA — it centralizes the Authentication piece across many applications while each individual application still enforces its own Authorization rules (what that authenticated user can actually do inside that specific app), and typically still generates its own Accounting logs. Understanding SSO as an extension of AAA, rather than a separate concept, helps clarify why a compromised SSO account is so dangerous: it doesn’t just expose one system, but potentially every system trusting that identity provider.

12. AAA in Cloud Environments

Cloud platforms like AWS, Azure, and Google Cloud implement AAA concepts through their own Identity and Access Management (IAM) systems, though the terminology sometimes differs slightly:

A common real-world cloud AAA pattern: a developer authenticates to AWS using MFA-backed SSO, assumes a specific IAM role scoped only to the resources their team manages (authorization via least privilege), and every API call they make is recorded in CloudTrail (accounting) for later security review. This is architecturally identical to the RADIUS/TACACS+ model discussed earlier, just implemented with cloud-native tooling instead of on-premises network hardware.

13. Common Misconceptions

• “Authentication and authorization are the same thing.” This is the single most common confusion in the field. Authentication only proves identity; a perfectly authenticated user can still be authorized for absolutely nothing, or for everything, depending entirely on separate authorization policy.
• “If someone is authenticated, they must be trustworthy.” Authentication says nothing about intent — a legitimate, correctly authenticated user can still misuse their access, which is exactly why accounting/logging exists as an independent safety net.
• “Accounting is just a ‘nice to have’ for compliance paperwork.” In practice, accounting logs are often the single most valuable resource during an actual security incident, since they may be the only record of what an attacker (who successfully authenticated using stolen credentials) actually did once inside.
• “RADIUS and TACACS+ are interchangeable.” While both are AAA protocols, their design goals differ meaningfully — RADIUS bundles authentication and authorization together and is optimized for network access scenarios, while TACACS+ cleanly separates all three functions and is built for granular device administration control.

14. Extended Real-World Scenario: Insider Threat Detection

Consider a mid-size company where a disgruntled employee in the IT department still has valid, authenticated access to network devices (they haven’t been offboarded yet). One evening, they authenticate to a core switch, then attempt to run write erase (which would wipe the device’s configuration).

Here’s how each AAA pillar plays a distinct defensive role:

1. Authentication correctly confirms this is indeed the known employee — nothing suspicious here, since their credentials are valid.
2. Authorization, configured with granular TACACS+ command-level restrictions, denies the write erase command because this employee’s role was scoped to read-only diagnostic commands, not destructive configuration changes.
3. Accounting logs the denied attempt, including the exact timestamp, device, and command — triggering an alert to the security team via the centralized syslog/SIEM pipeline, prompting immediate review and account suspension.

This scenario illustrates why all three pillars matter together: authentication alone would have let a legitimate-but-malicious action through; only layered authorization and accounting caught and recorded the actual threat.

Further Reading

• RFC 2865 — RADIUS Protocol
• Cisco TACACS+ Configuration Guide
• Linux PAM Documentation
• NIST Digital Identity Guidelines (SP 800-63)
• Kerberos Protocol Overview (MIT)
• Cisco AAA Overview