🔄 Topic

Studying the authentication, authorization, and accounting (AAA) framework alongside identity and access management (IAM), I worked through SSO, MFA, authorization mechanisms, and the MAC/DAC/RBAC models — then grounded all of it against a real access-control worksheet exemplar describing a contractor whose admin access outlived his contract by roughly four years.

🎯 Goal

Understand how authentication, authorization, and accounting work together as a framework, how SSO and MFA strengthen the authentication piece specifically, and how MAC, DAC, and RBAC differ as authorization models — then apply that understanding to a real access-control failure case.

🛠 What I Did

I built the AAA/IAM framework up piece by piece, then tested it against a worked incident example.

Main areas covered:

  • reviewed the three factors of authentication: knowledge (something you know), ownership (something you have), and characteristic (something you are)
  • learned single sign-on (SSO): combining multiple logins into one, reducing password fatigue (the tendency to reuse passwords across services) by shifting authentication trust to a third party, exchanged via LDAP (mostly on-premises) or SAML (mostly cloud/off-premises) protocols
  • learned SSO’s real limitation: it’s still one credential — a lost or stolen SSO password can expose access across every connected service at once, which is exactly why SSO alone isn’t considered sufficient
  • learned multi-factor authentication (MFA) as the complement: requiring two or more of the three authentication factors, the same logic as an ATM requiring both a physical card and a known PIN
  • learned the mechanisms of authorization specifically: separation of duties (nobody should hold enough authorization to misuse a system alone — the person approving IT purchases shouldn’t also approve their own department’s purchases) working alongside least privilege
  • learned HTTP basic auth versus OAuth: basic auth transmits credentials with every request and is now considered vulnerable since it exposes usernames/passwords over the network (superseded by HTTPS for transport security); OAuth instead exchanges API tokens — small blocks of encrypted code carrying identity and permission data — so a site can be granted limited access without ever handling the underlying password directly
  • studied IAM’s three authorization frameworks: Mandatory Access Control (MAC) — strict, centrally granted, non-discretionary, common in military/government, access granted only through a chain of command; Discretionary Access Control (DAC) — the data owner decides access, like sharing a Google Drive folder as viewer/editor/commenter; Role-Based Access Control (RBAC) — access determined by organizational role, like marketing having analytics access but not network admin access
  • learned user provisioning and deprovisioning as an IAM responsibility: creating a new user’s digital identity when they’re hired, and just as importantly, removing their access rights when they no longer need them — deprovisioning framed explicitly as “just as important” as provisioning, not an afterthought
  • reviewed a real access-control worksheet exemplar built around an actual incident: on October 3, 2023 at 8:29:57 AM, event 1227 recorded “Payroll event added. FAUX_BANK” under Legal\Administrator, from computer Up2-NoGud at IP 152.207.255.255 — the directory linked that IP to Robert Taylor Jr., a legal contractor whose listed end date was December 27, 2019, who still had Admin authorization nearly four years after his contract ended

🔗 Key Cybersecurity Connections

The Robert Taylor Jr. case is a textbook deprovisioning failure layered on top of a least-privilege failure: his access should have been revoked at offboarding in 2019, and separately, a legal contractor should never have had blanket Admin authorization to begin with — every employee and contractor in that directory did, which is a direct violation of least privilege regardless of the offboarding gap. The worksheet’s own honest caveat matters too: the IP match establishes a possible account link, not proof that Robert Taylor Jr. personally initiated the payroll event — credential reuse across services means a compromised password elsewhere could just as easily explain the activity, which is exactly the kind of nuance an investigation has to preserve rather than jumping to a convenient conclusion.

The recommendations attached to that worksheet map directly onto the frameworks studied today: revoke leavers promptly (deprovisioning), enforce RBAC so payroll/finance access is scoped to named finance personnel instead of “everyone gets Admin” (least privilege via RBAC instead of ambient trust), require MFA and individual accounts (authentication hardening), and require a second approver for new bank beneficiaries or payment releases (separation of duties). Every AAA/IAM concept from today’s study shows up as a concrete fix in this one real incident.

🔍 Investigation Questions

  • Does every account’s authorization level actually match least privilege, or does “give everyone Admin” describe how access is really granted?
  • Is deprovisioning tied to a documented, enforced offboarding process, or does former-contractor access linger indefinitely?
  • Does authentication rely on SSO alone, or is MFA layered on top to cover SSO’s single-point-of-failure risk?
  • Are payroll, bank-detail, or payment changes gated behind a second, independent approver — separation of duties in practice, not just in policy?
  • Does an IP-to-identity match in an event log get treated as definitive proof of who acted, or as one piece of evidence requiring further verification?

🚨 Detection Opportunities

Checks for AAA/IAM implementation review:

  • a former employee or contractor’s account still active past their documented end date
  • broad Admin authorization granted to roles or contractors that don’t need it (RBAC violation)
  • authentication relying on SSO with no MFA layered on top
  • a payment, payroll, or bank-detail change with only one authorizer, no second independent check
  • an investigation treating an IP-to-account match as proof of individual action without further corroboration

Example:

project=iam-offboarding-audit
signal=contractor_account_active_past_documented_end_date
risk_area=deprovisioning_failure_with_excess_privilege
triage=disable_account_immediately_review_all_access_granted_since_end_date

🧭 MITRE ATT&CK Techniques

Possible mapping for the risk described in the worksheet:

  • T1078 — Valid Accounts (an active, over-privileged former-contractor account is exactly the kind of valid-but-illegitimate access this technique covers)

🗺 Visual Investigation Diagram

Contractor end date: 27-12-2019
    ↓
Account never deprovisioned
    ↓
Retains blanket Admin authorization (no RBAC scoping)
    ↓
Event 1227, 03-10-2023: payroll change from Legal\Administrator
    ↓
IP links to Robert Taylor Jr. — possible, not proven, link
    ↓
Recommendations: prompt deprovisioning, RBAC, MFA, second-approver payment checks

⚠ Challenges

The hardest part conceptually was resisting the pull to treat the IP-address match as case-closed. The worksheet itself is careful about this — “the IP match does not establish who personally initiated the action” — and internalizing that distinction between a corroborating signal and proof is a discipline worth practicing deliberately, not just reading past.

📚 What I Learned

I learned that AAA and IAM aren’t abstract frameworks — the Robert Taylor Jr. case shows exactly how each missing piece (no prompt deprovisioning, no least privilege, no separation of duties, no second-approver check) compounds into a real incident that’s hard to fully attribute after the fact, precisely because the access controls that would have made attribution clean were never in place.

➡ Next Steps

  • Practice separating “corroborating evidence” from “proof” explicitly when reviewing any access-control incident
  • Review whether RBAC is actually enforced anywhere I have admin responsibilities, or whether broad default access is the norm
  • Connect deprovisioning discipline back to the offboarding process itself — who owns triggering it, and how promptly
  • Move on to vulnerability management and CI/CD security, and watch for the same least-privilege theme reappearing in a different context

🧠 Reflection

A four-year-old contractor account with Admin access is the kind of finding that sounds almost too simple to be realistic — until you remember that deprovisioning is a process step, not a technical control, and process steps are exactly the kind of thing that quietly fails to happen when nobody owns making sure it did.

🧩 Lessons Learned

What worked

Studying SSO, MFA, authorization mechanisms, and IAM frameworks together, then immediately testing the framework against a real, specific incident rather than leaving it abstract.

What broke

In the worksheet’s scenario: a contractor’s access was never revoked at offboarding, and blanket Admin authorization was granted to every employee and contractor regardless of role.

Why it broke

Deprovisioning had no enforced process, and authorization was granted by default rather than scoped to actual job need.

Fix / takeaway

Revoke access immediately at contract or employment end, enforce RBAC so authorization matches actual role need, require MFA on top of SSO, and require a second approver for sensitive financial changes.

📈 Skill Progression Context

This supports my cybersecurity progression because AAA and IAM are the frameworks behind virtually every real access-control incident, and working a genuine worksheet exemplar (with a real timestamp, event ID, and IP) is direct practice in the kind of evidence-based, appropriately-cautious analysis a security analyst actually does.

😄 TL;DR

A legal contractor’s contract ended in 2019; his Admin access didn’t — and by the time a 2023 payroll event traced back to his account, the real lesson wasn’t about him, it was about every access-control step that should have caught this years earlier.