RBAC vs ABAC: Which Access Control Model Is Right for Your Organisation?

RBAC vs ABAC is ultimately a question about how granular your organisation’s access decisions need to be, but understanding either model properly starts one layer beneath it, with Kerberos, the authentication protocol carrying the identity data both models depend on. If you have evaluated RBAC and ABAC in isolation without understanding what actually authenticates the user first, a genuine gap in that evaluation is worth closing directly.

Access Control Starts With Authentication: What Is Kerberos in Cryptography?

Kerberos is a network authentication protocol using tickets and symmetric-key cryptography to verify identity without transmitting passwords directly across the network. It underpins authentication in most Windows Active Directory environments and remains foundational to how identity gets established before any access control decision, RBAC or ABAC, ever applies.

This distinction matters directly because access control models determine what an authenticated user can do, while Kerberos determines whether that user genuinely is who they claim to be in the first place. A compromise at the authentication layer, covered directly in the next sections, can undermine even a perfectly designed access control model sitting on top of it.

How Kerberos Authentication Works, Step by Step

A client first sends an authentication request to the Key Distribution Center, proving knowledge of their password without transmitting it directly. The KDC’s Authentication Service validates this and returns a Ticket Granting Ticket, encrypted specifically with the KRBTGT account’s own password hash, a special service account existing solely to protect this ticket-issuing process.

The client then presents this TGT to the KDC’s Ticket Granting Service whenever requesting access to a specific resource, and the TGS, able to decrypt the TGT using that same KRBTGT hash, issues a service-specific ticket the client presents directly to the target system. This service ticket includes a PAC, covered fully later in this guide, carrying the authorization data the target system actually uses to decide what the authenticated user can access. This entire flow depends on one single account’s password hash, KRBTGT, remaining genuinely secret, precisely the dependency the next section’s attack exploits directly.

The Golden Ticket Attack

Here is the specific mechanism worth understanding precisely, not a vague description of “a Kerberos vulnerability.” An attacker who obtains the KRBTGT account’s password hash, typically requiring prior Domain Admin-level access, can forge a completely fraudulent Ticket Granting Ticket directly, without ever authenticating through the legitimate Authentication Service at all.

Since the Ticket Granting Service validates any presented TGT purely by confirming it decrypts correctly with the KRBTGT hash, an attacker holding that hash can craft an artificial ticket claiming any username, any group membership including Domain Admin, and an arbitrarily extended validity period, historically set to ten years in the original tooling that popularized this technique. This is precisely why the attack is called a golden ticket: it functions as a master key granting persistent, essentially unlimited access across the domain, bypassing normal authentication entirely and remaining valid until the underlying KRBTGT hash itself gets genuinely invalidated. MITRE ATT&CK tracks this specifically as technique T1558.001, reflecting how well-documented and consistently observed this attack pattern remains across real incidents.

Why Signature-Based Tools Can’t Catch This, and What Actually Can

A forged golden ticket structurally resembles a legitimate ticket in every way a signature-based tool checks, since it decrypts correctly with the genuine KRBTGT hash and follows the standard Kerberos ticket format precisely. There is no malicious file, no unusual executable, nothing a traditional antivirus signature was ever built to recognize.

Detecting this specifically requires behavioral analysis instead, watching for anomalies signature matching structurally cannot see: a ticket with an abnormally long lifetime far exceeding your organisation’s normal policy, a Windows Security Event ID 4768 or 4769 showing ticket activity inconsistent with the claimed user’s actual behavior pattern, or a ticket granting group membership that doesn’t structurally align with what that account’s genuine history would suggest. This is precisely why golden ticket compromises often persist undetected for extended periods, since the attack was specifically designed to look legitimate at the protocol level, meaning your detection capability has to watch for behavioral inconsistency in how tickets get used, not simply whether a ticket exists or appears technically valid. Cyber Security Solutions Ltd builds exactly this behavioral monitoring layer for clients specifically because signature-based tools alone leave this precise gap genuinely open.

The PAC: Where Authorization Decisions Live Inside a Kerberos Ticket

The Privilege Attribute Certificate is a Microsoft-specific extension embedded within a Kerberos ticket, carrying the authorization data a target system actually reads to make access decisions, the user’s security identifier, group memberships, and other authorization-relevant attributes.

This is genuinely where authentication hands off to authorization within the protocol itself. Kerberos proves who you are; the PAC embedded in your ticket tells the receiving system what you’re allowed to do, information that RBAC and ABAC systems, covered directly next, both ultimately draw from as their own underlying data source.

RBAC vs ABAC: How Your Access Model Connects to This Underlying Protocol

Criteria	RBAC	ABAC
PAC data used	Group membership directly	Group membership plus external attributes
Decision logic	Static role check	Dynamic, context-aware evaluation

RBAC reads the group membership data embedded in a ticket’s PAC directly, checking whether a user’s group membership matches a predefined role granting access to a specific resource, a genuinely straightforward, predictable lookup drawing on exactly the authorization data Kerberos already provides.

ABAC uses that same PAC-derived group membership as one input among several, combining it with additional external attributes, time of day, device compliance status, resource sensitivity, to make a considerably more granular, context-dependent decision the PAC’s group data alone could never express on its own. This connection matters directly for understanding both models honestly: neither RBAC nor ABAC exists independently of the authentication layer beneath it. Both depend on genuinely trustworthy PAC data arriving through an uncompromised Kerberos ticket, meaning a golden ticket attack forging arbitrary group membership directly undermines RBAC and ABAC identically, since both models trust the same underlying authorization data a forged ticket can fabricate entirely.

Full Remediation: Why Resetting the KRBTGT Password Once Isn’t Enough

Here is a genuinely important, often-missed nuance worth stating directly. The KRBTGT account maintains two passwords simultaneously by design, current and previous, specifically to avoid service disruption during routine password rotation, since tickets issued just before a reset still need to validate briefly afterward.

This design choice creates a real remediation trap. Resetting the KRBTGT password only once leaves the previous hash still valid during that transition window, meaning an attacker’s golden ticket, forged using that now-previous hash, may continue working until the older hash cycles out entirely on its own. Genuine, complete remediation requires resetting the KRBTGT password twice, ensuring both the current and previous hash get fully invalidated, closing the specific gap a single reset leaves open. Organizations treating a single KRBTGT reset as complete remediation after a confirmed golden ticket compromise are very likely leaving the exact same forged ticket still functional, precisely the kind of incomplete response that turns a contained incident into a prolonged, undetected re-compromise.

A Worked Timeline: From Compromise to Detection to Recovery

An attacker first achieves Domain Admin-level access through a separate, initial compromise, then extracts the KRBTGT hash directly from a domain controller. They forge a golden ticket offline, granting themselves persistent, arbitrary access, and begin using it to move through the environment weeks or months later, deliberately separated in time from the original compromise specifically to avoid triggering correlation between the two events.

Detection typically occurs through the behavioral anomalies covered earlier, an unusually long ticket lifetime, activity inconsistent with the claimed account’s normal pattern, rather than any single, obvious alert. Genuine recovery then requires the double KRBTGT reset covered above, alongside a full review of what access that forged ticket may have granted during its active period, since the ticket’s arbitrary group membership claims mean the actual scope of compromise often extends considerably beyond what initial detection alone reveals.

What Does UK Guidance Recommend Here?

NCSC’s own guidance consistently emphasizes behavioral, anomaly-based threat detection specifically for exactly this category of attack, recognizing that credential and ticket-forgery techniques structurally evade signature-based tools regardless of how current those signatures remain.

This directly reinforces the detection approach covered throughout this guide, monitoring for genuine behavioral inconsistency in authentication and access patterns, rather than relying solely on tools built to recognize known-malicious files or signatures a golden ticket attack was specifically designed never to produce in the first place.

Conclusion

Choosing between RBAC and ABAC genuinely matters, but both depend entirely on the Kerberos authentication layer beneath them remaining uncompromised, since a golden ticket attack undermines either model identically by forging the same authorization data both ultimately trust. Start by confirming your own KRBTGT password rotation policy accounts for the dual-reset requirement covered directly above.