Why does Kerberos authorization depend on both the ticket and directory data in Active Directory?

Kerberos in Active Directory is not just about proving identity. The service ticket can carry authorization data, such as group-related information, that the target service uses to decide what the user can do. This means access decisions depend on both successful authentication at the KDC and the permissions embedded for the service to evaluate.

Why Kerberos authorization in Active Directory is a two-part decision

Kerberos in active directory separates proof of identity from the authorization context the service relies on. The ticket tells the service who authenticated, but the authorization data inside or alongside that ticket tells the service what groups, privileges, or claims are available for the access check. If either side is missing or stale, the service can authenticate a user yet still deny or misapply access.

That split matters because Active Directory is not just a ticket issuer, it is also the directory source for group membership, account state, and policy decisions. The practical outcome is that authorization depends on both the Kerberos exchange and the directory data that was current when the ticket was issued or later evaluated by the service.

In other words, the ticket is the transport for authenticated identity and authorization evidence, while directory data is the authoritative context that makes that evidence meaningful. That is why Kerberos-based access can succeed at logon but still fail when the target service checks group membership, nested groups, or account status in ways that differ from the original ticket snapshot.

What Active Directory contributes beyond the ticket itself

Active Directory contributes the directory view of entitlement. Group membership, nested groups, delegated admin groups, and account flags shape whether the service should trust the access request, and they often influence the authorization data packed into the ticket. A service that depends on directory-linked authorization is therefore evaluating both the presented ticket and the directory state behind it.

This is also why changes in AD do not always take effect immediately. If a user is added to or removed from a group, the old ticket may still reflect earlier authorization data until renewal or reauthentication occurs. That delay is a normal consequence of ticket-based authorization, but it becomes a risk when teams assume directory changes are instantly enforced everywhere.

For that reason, IAM and IGA Basics is useful background when you want to separate authentication, entitlement governance, and access review in one model. It clarifies why authorization evidence and entitlement source data must both be correct for reliable enforcement.

The same logic is visible in the way Active Directory and Entra ID Hardening Guide treats privileged groups, delegation, and hybrid identity as control points. Kerberos authorization becomes fragile when group design, delegation paths, or privileged memberships are poorly governed.

Why services must treat ticket data and directory data as complementary, not interchangeable

A ticket is not a live replacement for the directory. It is a signed statement about identity and authorization state at a point in time. The directory remains the source for ownership, membership, and policy administration, while the service uses the ticket to make an immediate access decision. That means access control can depend on both data plane evidence and directory plane truth.

This distinction explains several common outcomes. A user can authenticate successfully but still lack access because the service cannot find the required group in the ticket. The opposite can also happen if a stale or overbroad ticket still carries permissions that the directory has already removed. In both cases, the control issue is not Kerberos alone, but the relationship between the ticket snapshot and the directory source of authority.

Authorisation Models Guide is relevant here because it shows how RBAC-style group decisions differ from attribute or relationship-based checks. Kerberos in AD often feeds RBAC-like decisions, but the target service still has to interpret the authorization context correctly.

That is also why access recertification and entitlement hygiene matter. NHI Lifecycle Management Guide covers the same lifecycle principle from a broader identity perspective: when memberships, credentials, or ownership drift, the authorization outcome drifts with them.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	Kerberos authentication and downstream access decisions depend on verified organizational user identity.
	AC-2 — Account Management	AD group membership and account state drive the authorization context used by services.
	AC-6 — Least Privilege	Kerberos tickets often carry group-based privileges that should be minimized and tightly scoped.
Recommendation — Use IA-2 to require strong user authentication before directory-backed authorization is evaluated. Use AC-2 to govern account state, memberships and entitlement changes that affect Kerberos access. Use AC-6 to limit the privileges encoded in directory-linked access decisions.
ISO/IEC 27001:2022	A.5.15 — Access control	Kerberos authorization in AD is an access control problem that depends on controlled entitlements.
	A.5.16 — Identity management	The answer hinges on identity state and directory-managed group membership.
	A.5.18 — Access rights	Ticket and directory data both influence whether access rights remain valid.
Recommendation — Apply A.5.15 to define and enforce how directory-based access rights are granted and checked. Apply A.5.16 to keep identities and group relationships accurate across the authorization flow. Apply A.5.18 to review and revoke access rights when directory entitlements change.
CIS Controls v8	CIS-5 — Account Management	AD authorization depends on managed accounts, groups and timely entitlement changes.
Recommendation — Use CIS-5 to inventory, govern and remove stale account-based access paths.

Practitioner Guidance

What to verify: Confirm whether the service authorizes from ticket claims alone, from live directory lookups, or from both. That distinction determines whether a membership change takes effect only after renewal, immediately, or inconsistently across systems.

Decision rule: If access is sensitive, treat Kerberos ticket freshness and directory hygiene as separate controls. A valid ticket does not prove current entitlement, and current directory data does not guarantee the service is actually consuming it.

What practitioners underestimate: The hardest failures are often timing failures, not outright authentication failures. Stale tickets, nested groups, delegation, and hybrid directory sync can all produce access results that look “correct” from one system’s perspective and wrong from another’s.

Practitioner takeaway: Reliable Kerberos authorization in Active Directory comes from aligning the ticket snapshot, the directory source of truth, and the service’s authorization logic, not from trusting any one of them in isolation.