AAA: Authentication, Authorization & Accounting

AAA is the security framework that answers three questions for every action on a system:

1. Authentication (AuthN) - Who are you? Proving identity
2. Authorization (AuthZ) - What are you allowed to do? Defining access rights
3. Accounting - What did you do? Recording actions for audit

These are distinct but tightly coupled - authentication always precedes authorization.

---

Authentication

Identification vs Authentication

Term	Meaning	Example
Identification	Claiming an identity	Entering a username or email
Authentication	Proving that claimed identity	Entering the correct password

A username alone proves nothing - authentication is the proof.

Password Security

Passwords remain the most common authentication factor. Their weakness is human behaviour, not the concept itself.

Password policy requirements (NIST SP 800-63B current guidance):

• Minimum 8 characters (NIST now discourages forced complexity rules - length matters more)
• Check against breached password lists (not just complexity rules)
• No forced periodic rotation unless compromise is suspected
• Allow paste into password fields (prevents discouraging password managers)
• Never store plaintext; use Argon2id/bcrypt (see: cryptography-fundamentals)

# Check if a password appears in known breach databases (Have I Been Pwned k-anonymity API)
# Sends only first 5 chars of SHA-1 hash - private
PASSWORD="hunter2"
HASH=$(echo -n "$PASSWORD" | sha1sum | cut -d' ' -f1 | tr 'a-z' 'A-Z')
PREFIX=${HASH:0:5}
SUFFIX=${HASH:5}
curl -s "https://api.pwnedpasswords.com/range/$PREFIX" | grep "$SUFFIX"
# If there's a match, the number after the colon is how many times it's been seen in breaches

/etc/security/pwquality.conf

# Enforce password policy on Linux with PAM
minlen = 12
minclass = 3          # at least 3 character classes (upper/lower/digit/symbol)
maxrepeat = 3         # no more than 3 repeating characters
dictcheck = 1         # check against cracklib dictionary

---

Multi-Factor Authentication (MFA)

One factor can be stolen. Multiple independent factors dramatically increase the cost of attack.

The Five Authentication Factors

Factor type	Examples	Common threat
Something you know	Password, PIN, security questions	Phishing, database breach, shoulder surfing
Something you have	TOTP app, hardware token, smart card, SMS OTP	SIM swap, device theft
Something you are	Fingerprint, face, iris, retina, voice	Spoofing, false accept rate
Somewhere you are	GPS geofencing, IP range, NFC proximity	Location spoofing, VPN bypass
Something you do	Gait analysis, swipe patterns, CAPTCHA, typing rhythm	Hard to attack, hard to implement

Note

SMS OTP is the weakest “have” factor. SMS is vulnerable to SIM-swapping attacks (attackers social-engineer your carrier to port your number). Use TOTP apps or hardware keys instead whenever possible.

TOTP - Time-Based One-Time Passwords

TOTP (RFC 6238) generates a new 6-digit code every 30 seconds using:

TOTP = HOTP(secret, floor(unix_time / 30))
HOTP = HMAC-SHA1(secret, counter) → truncated to 6 digits

• Client and server share a secret (encoded as a QR code during registration)
• Both compute the same TOTP independently - no network needed for generation
• Valid window is typically ±1 step (90 seconds) to account for clock skew

# Generate a TOTP from command line (for testing/scripting)
# Requires: apt install oathtool
TOTP_SECRET="JBSWY3DPEHPK3PXP"
oathtool --totp --base32 "$TOTP_SECRET"

FIDO2 / WebAuthn / Hardware Security Keys

FIDO2 is the current gold standard for phishing-resistant MFA:

Registration:
  Browser → request key registration for origin "example.com"
  Key → generates unique key pair: private (stays in key), public (sent to server)
  Server stores: public key + key ID   (no shared secret)

Authentication:
  Server → sends random challenge + origin
  Key → signs challenge with private key (only if user touches key)
  Browser → sends signature to server
  Server → verifies signature with stored public key

Why FIDO2 is phishing-resistant:

• The origin (example.com) is cryptographically bound to the key - a fake site (examp1e.com) gets rejected automatically
• No shared secret transmitted - replay attacks impossible
• Each key pair is site-specific - compromise of one site doesn’t affect others

Hardware keys: YubiKey, Google Titan Key, SoloKey

---

Biometric Authentication

Biometrics are “something you are” - measured and compared at authentication time.

How It Works

Enrollment:    Biometric scan → extract features → hash/encrypt → store template
Authentication: New scan → extract features → compare against stored template
               → ACCEPT (within threshold) or REJECT

Biometric	Security notes
Fingerprint	Capacitive sensors; can be lifted from surfaces; dirt/moisture causes failures
Face recognition	Requires depth camera (IR liveness detection) to resist photo attacks; 2D-only is weak
Iris scan	2D iris photos can fool 2D scanners; pattern is extremely unique with depth
Retina scan	Blood vessel pattern; very secure; expensive; eye injury can lock out user
Voice	Spoofable with recordings; useful for call centres with voice print + liveness check

Caution

Biometric data cannot be rotated. If a password database is breached, you change your password. If a biometric template database is breached, you cannot change your fingerprints. Always store biometric templates as irreversible hashes/transforms - never as raw data.

---

Kerberos - Network Authentication Protocol

Kerberos provides mutual authentication across a network without transmitting passwords. Used as the default auth protocol in Windows Active Directory domains.

Mental Model: Timed Passes

You → Security Office: "I'm Alice" + (encrypted proof)
Security Office: validates, issues a Ticket Granting Ticket (TGT) - a signed pass
                 "Alice is authenticated until 10:00 AM"

You → Ticket Counter (TGS): show TGT + "I want access to File Server"
TGS: issues a Service Ticket for File Server

You → File Server: show Service Ticket
File Server: validates using its own key → grants access

Full Kerberos Flow

Client                    AS (Auth Server)          TGS                    Service
  │── 1. AS-REQ ─────────→│                          │                       │
  │   (username, timestamp │                          │                       │
  │    encrypted with      │                          │                       │
  │    password-derived key│                          │                       │
  │                        │                          │                       │
  │←── 2. AS-REP ─────────│                          │                       │
  │   (TGT encrypted with  │                          │                       │
  │    TGS key + session   │                          │                       │
  │    key enc. w/ client  │                          │                       │
  │    key)                │                          │                       │
  │                        │                          │                       │
  │── 3. TGS-REQ ─────────────────────────────────→│                       │
  │   (TGT + service name  │                          │                       │
  │    + authenticator     │                          │                       │
  │    enc. w/ session key)│                          │                       │
  │                        │                          │                       │
  │←── 4. TGS-REP ────────────────────────────────│                       │
  │   (Service Ticket +    │                          │                       │
  │    service session key)│                          │                       │
  │                        │                          │                       │
  │── 5. AP-REQ ──────────────────────────────────────────────────────────→│
  │   (Service Ticket +    │                          │                       │
  │    authenticator)      │                          │                       │
  │←── 6. AP-REP ─────────────────────────────────────────────────────────│
  │   (mutual auth: server │                          │                       │
  │    proves its identity)│                          │                       │

Key properties:

• Password never transmitted - only used locally to derive encryption keys
• Tickets are time-limited (default 8–10 hours) - limits window of stolen ticket use
• Mutual authentication - client and server authenticate each other

Kerberos Weaknesses

Weakness	Detail
Single point of failure	KDC goes down → nobody can authenticate to new services
KDC compromise = total compromise	Attacker can forge valid tickets for any user (Golden Ticket attack)
Strict clock sync required	Client and server clocks must be within 5 minutes → NTP is a security dependency
Trust boundary problem	Requires pre-established trust; BYOD/cloud systems are incompatible or complex
Pass-the-Ticket attacks	Stolen TGT can be reused until expiry from any machine

# Check Kerberos ticket cache on Linux
klist

# Destroy all current tickets
kdestroy

# Get a Kerberos ticket (MIT krb5)
kinit [email protected]

# On Windows - view tickets
klist

---

RADIUS vs TACACS+

Both are AAA protocols - but they serve different primary purposes:

Feature	RADIUS	TACACS+
Primary use	Network access AAA (Wi-Fi, VPN, dial-in)	Device administration AAA (router/switch CLI)
Transport	UDP (ports 1812 auth, 1813 accounting)	TCP (port 49)
Reliability	UDP - fire-and-forget, client handles retransmit	TCP - connection-oriented, reliable
Encryption	Only encrypts the password field	Encrypts the entire payload
Auth/Authz separation	Combined in one exchange	Fully separated (more granular control)
Per-command authorization	Not supported	✅ Supported
Open standard	RFC 2865	Released as open standard 1993 (Cisco-original)
Common servers	FreeRADIUS, Microsoft NPS, Cisco ISE	Cisco ISE, TACACS+ daemon

RADIUS typical flow:
Client → [NAS/AP] → RADIUS server
                     ↓ verify against: flat file / SQL / LDAP / AD
                     ↓ response: Access-Accept / Access-Reject / Access-Challenge
                 ← grants or denies network access

TACACS+ typical flow:
Admin SSH → [Switch] → TACACS+ server
                        ↓ authenticate admin
                        ↓ for each command typed: authorize or deny
                        ↓ log every command executed

# Test RADIUS authentication from command line
# Requires: apt install freeradius-utils
radtest alice "password" radius-server 0 shared-secret

# Check FreeRADIUS server status
sudo freeradius -X        # debug mode - shows full auth flow
sudo systemctl status freeradius

---

Single Sign-On (SSO)

SSO allows one authentication event to grant access to many services - the user authenticates once; subsequent service access auto-authenticates via token.

SSO Flow

User → Service A (unauthenticated)
      ↓ redirect to SSO Identity Provider (IdP)
User enters credentials at IdP
      ↓ IdP creates session + issues token (cookie or assertion)
      ↓ redirect back to Service A with token
Service A validates token with IdP → grants access

User → Service B (unauthenticated)
      ↓ redirect to IdP
      IdP: "user already has a session" → issues token immediately
      ↓ redirect to Service B with token
Service B validates → grants access (no credential re-entry)

SSO Protocols Compared

Protocol	Type	Mechanism	Common use
Kerberos	Enterprise	Ticket-based, symmetric crypto	Windows domains, internal services
SAML 2.0	Enterprise/Web	XML-based assertions, signed	Enterprise SSO, ADFS, Okta
OpenID Connect	Web/Consumer	JWT tokens over OAuth 2.0	”Sign in with Google/Apple/Microsoft”
OAuth 2.0	Authorization delegation	Access tokens with scopes	API access, “Login with…”
LDAP + Kerberos	Enterprise	Directory service + tickets	Linux/AD integration

Caution

SSO token theft = access to all services. If an attacker steals a valid SSO session token, they inherit access to every service that trusts that IdP. Always protect SSO sessions with short expiry, token binding, and MFA. A compromised SSO account is far more damaging than a single-service compromise.

OAuth 2.0 vs OpenID Connect

OAuth 2.0:    "I authorise GitHub to post on my behalf to Twitter"
               → Delegation of PERMISSIONS (what you can DO)
               → Returns an Access Token (for API calls)

OpenID Connect: "I want to log in to Notion using my Google account"
               → Authentication of IDENTITY (who you ARE)
               → Returns an ID Token (JWT containing user claims)
               → Built on top of OAuth 2.0

OAuth scopes limit what a token can access:

scope: "read:email profile"          # can only read email + profile
scope: "repo:write user:email"       # can write to repos and read email

Users can revoke OAuth grants at any time - allows trusted access without credential sharing.

---

Authorization

Authorization answers “what is this authenticated identity allowed to do?” - separate from and always following authentication.

Access Control Models

Model	How it works	Best for
DAC (Discretionary)	Resource owners set permissions; users can grant access to their own files	General purpose filesystems
MAC (Mandatory)	System enforces labels (Top Secret, Confidential); users can’t override	Government, military
RBAC (Role-Based)	Permissions assigned to roles; users assigned roles	Enterprise systems, cloud IAM
ABAC (Attribute-Based)	Policy decisions based on user + resource + environment attributes	Fine-grained dynamic control
ReBAC (Relationship-Based)	Access based on graph of relationships between subjects/resources	Google Zanzibar, social apps

Access Control Lists (ACLs)

An ACL is a list of (principal, permission) pairs attached to a resource.

File system ACLs (Linux):

# View ACL on a file
getfacl /etc/important-config

# Grant specific user read+write (without changing owner/group)
setfacl -m u:alice:rw /etc/important-config

# Grant a group read access
setfacl -m g:developers:r /var/www/html

# Set a default ACL (new files in directory inherit these permissions)
setfacl -d -m u:alice:rw /var/data/shared/

# Remove specific ACL entry
setfacl -x u:alice /etc/important-config

# Remove all ACL entries
setfacl -b /etc/important-config

Network ACLs (on routers/firewalls - evaluated top-to-bottom, first match wins):

# iptables as stateless ACL
iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT  # allow SSH from LAN
iptables -A INPUT -p tcp --dport 22 -j DROP                        # deny SSH from everywhere else
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP                          # prevent reach to internal ranges

Note

ACL order matters. Entries are evaluated sequentially - the first matching rule wins. Always structure ACLs from most specific to least specific. “Deny all” should be the last rule (implicit deny).

OAuth Authorization Scopes

OAuth 2.0 implements authorization via scopes - granular permissions tokens carry:

Access Token claims:
{
  "sub": "user123",
  "scope": "documents:read calendar:read",  ← what this token permits
  "exp": 1741234567,                         ← expiry
  "aud": "api.example.com"                   ← intended audience
}

The resource server validates:

1. Token signature is valid
2. Token is not expired
3. Token’s scope covers the requested operation
4. Token’s aud matches this service

---

Accounting

Accounting is the systematic recording of who did what, when, and from where - the raw material for audits, incident response, and compliance.

What Gets Recorded

RADIUS accounting (network access):

Field	Example value
Acct-Session-Id	Unique session identifier
User-Name	[email protected]
NAS-IP-Address	10.0.0.1 (the AP or VPN concentrator)
Acct-Session-Time	3600 (seconds connected)
Acct-Input-Octets	104857600 (bytes received by user)
Acct-Output-Octets	52428800 (bytes sent by user)
Acct-Terminate-Cause	User-Request / Session-Timeout / Admin-Reset

RADIUS accounting is used by ISPs for billing and by enterprises to enforce data/time quotas. It records connection-level data - not what sites were visited or what commands ran.

TACACS+ accounting (device administration):

Records far more granular data because it tracks per-command actions on network devices:

Accounting record for admin session:
  User:     alice
  Device:   10.0.0.254 (core-router-01)
  Session:  2026-03-11 07:15:00 UTC
  Commands:
    07:15:12  show running-config
    07:15:45  interface GigabitEthernet0/1
    07:15:48  no shutdown
    07:16:02  exit
    07:16:10  write memory

This level of logging is essential for change management - knowing exactly what was changed, by whom, and when - critical for rollback and compliance audits.

Log Management Best Practices

/etc/rsyslog.conf

# Centralise logs with rsyslog (forward to SIEM)
*.* @siem.internal:514      # UDP
*.* @@siem.internal:514     # TCP (reliable)

# Audit authentication events on Linux (PAM logging)
# /etc/pam.d/sshd - add pam_tty_audit
session required pam_tty_audit.so enable=*

# View audit log for auth failures
ausearch -m USER_LOGIN --success no

# View all sudo commands in auth log
grep "sudo" /var/log/auth.log | grep "COMMAND"

# Watch for failed SSH attempts in real time
journalctl -f -u sshd | grep "Failed"

Audit Review Workflow

1. Collection    → Centralise logs from all sources (RADIUS, TACACS+, OS, apps)
2. Normalisation → Convert to common format (syslog CEF, JSON)
3. Correlation   → Match events across systems (same user, similar timeframe)
4. Alerting      → Rule-based: "5 failed logins in 60s" → alert
5. Review        → Human reviews alerts + flagged anomalies
6. Response      → Investigate, contain, remediate
7. Retention     → Keep logs for compliance period (SOC 2: 1yr, PCI DSS: 1yr, HIPAA: 6yr)

Tip

Normalisation is critical. A firewall log saying src=10.0.0.1, a RADIUS log saying NAS-IP=10.0.0.1, and a syslog saying host 10.0.0.1 are all talking about the same device - but automated correlation requires them to be in the same format. A SIEM (Splunk, Elastic SIEM, Microsoft Sentinel) does this normalisation automatically.

---

AAA Protocol Quick Reference

Network access control (VPN, Wi-Fi, dial-up):
  → RADIUS (FreeRADIUS, Cisco ISE, Microsoft NPS)
  → Combined auth + authz + accounting in one protocol
  → 802.1X uses RADIUS as the backend

Device administration (routers, switches, firewalls):
  → TACACS+ (Cisco ISE, open-source tac_plus)
  → Separate auth / authz / accounting channels
  → Per-command authorisation + full command logging

Enterprise single sign-on:
  → Kerberos (Windows AD, MIT krb5) - internal services
  → SAML 2.0 (Okta, ADFS) - enterprise web apps
  → OpenID Connect (Google, Azure AD) - consumer + cloud apps

Fine-grained API authorization:
  → OAuth 2.0 with JWT access tokens + scopes