How Access Is Actually Granted After Active Directory Authentication

Read time: 12 minutes | Level: Intermediate | Updated: February 2026

Who Should Read This

This article is for:

• Security engineers seeking to understand Windows authentication mechanics beyond surface-level descriptions
• Penetration testers who need accurate mental models for credential theft and lateral movement
• System administrators transitioning into security roles
• Anyone confused about what Active Directory actually does after you log in

Prerequisites: Basic familiarity with Windows domains, authentication concepts, and network protocols. You should know what a domain controller is and have heard of Kerberos and NTLM.

The Core Misconception

Active Directory is often described as the system that “controls access” in Windows environments. This description is convenient, but it is also fundamentally inaccurate in ways that matter operationally and defensively. Many of the most common misconceptions about Kerberos, NTLM, lateral movement, and credential theft stem from an incorrect mental model of what Active Directory actually does once a user has authenticated.

This article addresses a single, deceptively simple question: how is access granted to services after Active Directory authentication?

The answer requires separating authentication from authorization and understanding where identity proof lives after the login process completes. Get this wrong, and you’ll misunderstand how modern attacks work and why traditional defenses fail.

Active Directory as an Identity Authority

Active Directory is best understood as a centralized identity authority. It stores security principals (users, computers, groups), verifies credentials, and provides a common trust anchor for machines and services within a domain.

What it does not do is participate in day-to-day access decisions. After authentication, Active Directory is not consulted for file access, email access, database queries, or application requests. It does not proxy traffic, and it does not maintain live user sessions.

This distinction is critical: Active Directory confirms identity, but it does not grant access. That responsibility is delegated entirely to the services that rely on it.

Key Term: A security principal is any entity that can be authenticated — typically a user account, computer account, or service account.

Authentication as a Point-in-Time Event

When a user logs on to a domain-joined system, authentication is performed against a domain controller. The client proves knowledge of valid credentials, the domain controller verifies that proof, and authentication succeeds or fails. At that point, the interaction with Active Directory ends.

There is no persistent connection to the directory and no ongoing validation loop. Authentication is a point-in-time event whose result is the issuance or validation of cryptographic material that the client can later present to services. From this moment forward, Active Directory is no longer in the access path.

Let me show you what this looks like in practice.

Illustrative Example:

Scenario: Alice logs into her workstation at 9:00 AM and at 2:00 PM needs to access a file on \\fileserver\hr\payroll.xlsx.

Here’s what actually happens:

9:00 AM — Initial Logon

1. Alice enters her password on her workstation
2. Workstation contacts domain controller DC01
3. DC01 verifies Alice's credentials against Active Directory
4. DC01 issues Alice a Ticket Granting Ticket (TGT) encrypted with a key only DC01 knows
5. The TGT is stored in Alice’s workstation memory (in LSASS)
6. Active Directory’s job is now complete

2:00 PM — Accessing the File Share

1. Alice’s workstation needs to access \\fileserver\hr
2. Workstation contacts DC01 again, presenting Alice's TGT
3. DC01 issues a service ticket specifically for fileserver
4. Workstation presents this service ticket to fileserver
5. **fileserver validates the ticket locally** using its own secret key
6. fileserver checks its ACLs (Access Control Lists) to see if Alice can read payroll.xlsx
7. Access is granted or denied by fileserver, not by Active Directory

Critical observation: At 2:00 PM, Active Directory was only involved in issuing the service ticket. It did not decide whether Alice could read the file. It did not see the file access request. It has no record that Alice accessed that file.

The file server made the access decision, not Active Directory.

Kerberos vs NTLM: Two Models, One Goal

Active Directory supports multiple authentication mechanisms, most notably Kerberos and NTLM. Both exist to answer the same question — “is this identity valid?” — but they answer it in fundamentally different ways.

Kerberos: The Ticket-Based System

Kerberos is a ticket-based system. After authentication, the client receives a Ticket Granting Ticket (TGT), which can later be exchanged for service-specific tickets. Each service ticket is:

• Cryptographically bound to a particular service (the Service Principal Name)
• Time-limited (typically 10 hours for TGTs, configurable per-service for service tickets)
• Encrypted with a secret known only to the intended service

You can see your current Kerberos tickets using the klist command on Windows:

> klist

Current LogonId is 0:0x3e7

Cached Tickets: (3)

#0>     Client: alice @ CORP.LOCAL
        Server: krbtgt/CORP.LOCAL @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000
        Start Time: 2/4/2026 9:00:00
        End Time:   2/4/2026 19:00:00

#1>     Client: alice @ CORP.LOCAL
        Server: cifs/fileserver.corp.local @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Start Time: 2/4/2026 14:00:00
        End Time:   2/4/2026 19:00:00

NTLM: The Challenge-Response System

NTLM, by contrast, relies on challenge-response authentication. Instead of issuing tickets:

1. The client requests access to a service
2. The service sends a random challenge
3. The client computes a response using its password hash
4. The service forwards this to a domain controller
5. The domain controller validates the response

NTLM does not issue reusable, service-bound credentials. Each authentication requires a new challenge-response exchange.

Side-by-Side Comparison

Key Differences:

The implications of this difference become apparent after authentication completes and when attacks occur.

What Replaces the Password After Authentication

A common misconception is that passwords remain relevant after login. In reality, once authentication succeeds, the password is no longer used. It is replaced by cryptographic proof.

In Kerberos, this proof takes the form of tickets issued by the domain controller. In NTLM, it takes the form of computed responses derived from password hashes. In both cases, services never see the password itself. They only see evidence that the client has already proven its identity.

This shift — from passwords to proof — is what enables single sign-on. It is also what makes credential theft so effective.

Where Authentication Proof Actually Lives

After authentication, the most sensitive material does not reside in Active Directory. It resides on the endpoint.

Kerberos tickets, NTLM hashes, and derived session secrets are stored in memory by the Local Security Authority Subsystem Service (LSASS), the Windows process responsible for security policy enforcement and credential management.

Key Term: LSASS (lsass.exe) is a critical Windows system process that handles authentication, stores credentials in memory, and enforces security policies. It runs with SYSTEM privileges.

Cached domain credentials may exist on disk to support offline logon. Unlike NTLM hashes which function as password-equivalent authenticators, cached credentials serve only for local validation and cannot be used directly for network authentication — they must be cracked offline first, though strong passwords make this computationally impractical.

Active Directory does not retain client tickets, session state, or live credential material. From a defensive perspective, this explains why compromising endpoints is often more valuable to an attacker than attacking domain controllers directly.

Tools like Mimikatz target LSASS memory specifically because that’s where the reusable authentication proof lives.

NTLM’s Architectural Weakness (And Why NTLMv2 Didn’t Fix It)

NTLM’s core weakness is architectural. The NTLM hash functions as a password-equivalent credential. Anyone who possesses it can compute valid authentication responses without knowing the underlying password.

This is the Pass-the-Hash attack: an attacker extracts the NTLM hash from LSASS memory and uses it directly to authenticate to other services, never needing to crack the password.

NTLMv2 improved the cryptographic construction of the response (adding mutual authentication and stronger hashing), but it did not change this fundamental property. Authentication proof remains insufficiently bound to a specific service or connection, enabling both Pass-the-Hash and NTLM relay attacks.

NTLM Relay Explained

Because NTLM responses aren’t cryptographically bound to a specific service, an attacker can intercept a response intended for Service A and replay it to Service B.

Example attack flow:

1. Victim authenticates to attacker-controlled service (Service A)
2. Attacker captures the NTLM response
3. Attacker forwards this response to a different service (Service B)
4. Service B accepts it because it has no way to know the response wasn’t intended for it

This works even without knowing the password or hash. The attacker is simply relaying valid authentication material.

Kerberos avoids these issues by issuing service-specific, time-limited tickets that are encrypted with secrets known only to the intended service. A ticket for cifs/fileserver cannot be used to access http/webserver. This difference is why Kerberos resists replay and relay attacks that are trivial under NTLM.

Kerberos Is Not Perfect Either

While Kerberos is significantly more secure than NTLM, it is not immune to credential theft:

• Ticket reuse: Stolen TGTs can be used until they expire (typically 10 hours)
• Golden Ticket: If an attacker compromises the krbtgt account hash, they can forge TGTs for any user with arbitrary validity periods
• Silver Ticket: If an attacker compromises a service account hash, they can forge service tickets for that specific service
• Overpass-the-Hash: NTLM hashes can be used to request Kerberos TGTs, bridging both protocols

The defensive advantage of Kerberos is not immunity to theft, but reduced reusability and better forensic visibility through shorter validity windows and service binding.

Practical Defensive Measures

Because NTLM remains present in many environments for compatibility reasons, and because Kerberos tickets can still be stolen, defense requires multiple layers.

• Protocol-Level Controls
• Credential Protection
• Architectural Controls
• Monitoring and Detection

Smart Card / Certificate-Based Authentication

PKI-based authentication using smart cards or Windows Hello for Business eliminates passwords entirely:

• The private key never leaves the secure hardware (smart card chip or TPM)
• Authentication uses challenge-response with asymmetric cryptography
• No password hash exists to steal

This is the strongest authentication model, though it requires significant infrastructure (PKI, card readers, enrollment processes).

How Access Is Actually Granted: The Complete Picture

With all of this in place, the original question can be answered precisely.

After Active Directory authentication, access is granted by the service itself, not by Active Directory.

The sequence is:

1. Identity verification (Active Directory): “This user is who they claim to be”
2. Proof issuance (Active Directory): “Here is cryptographic evidence of that identity”
3. Proof storage (Client endpoint): The evidence is cached in LSASS memory
4. Proof presentation (Client → Service): The client shows the evidence to the service
5. Proof validation (Service): The service verifies the evidence cryptographically
6. Access decision (Service): The service checks its own ACLs and grants or denies access

Active Directory confirms who you are. The client carries that proof. The service decides what you may do.

This is not a semantic distinction. It is the architectural reality that determines:

• Where credentials must be protected (endpoints, not just domain controllers)
• How attacks work (steal proof from endpoints, reuse it elsewhere)
• Why lateral movement succeeds (services trust proof without re-verifying with AD)
• Where logging must occur (at services, not just at domain controllers)

Why This Matters: The Defensive Shift

Most Windows security failures are not failures of authentication, but failures of proof handling. When authentication artifacts are reusable, insufficiently bound, or poorly protected, access control collapses regardless of how strong the directory itself may be.

Traditional security thinking:

• “We have strong passwords and account lockout policies”
• “Our domain controllers are well-protected”
• “We monitor AD for suspicious authentications”

Reality:

• Passwords don’t matter after initial authentication
• Attackers target endpoints, not domain controllers
• Most malicious access never touches AD after initial ticket issuance

The defensive mindset must shift from protecting the directory to protecting authentication proof throughout its lifecycle:

Understanding how access is granted after Active Directory authentication is therefore the foundation for understanding lateral movement, credential theft, and modern defensive strategy.

Summary: Key Takeaways

1. Active Directory authenticates; it does not authorize. Services make access decisions independently.
2. Authentication is point-in-time. After issuing tickets or validating credentials, AD is no longer involved.
3. Passwords are replaced by proof. Kerberos tickets and NTLM hashes become the credentials that matter.
4. Proof lives on endpoints. LSASS memory is the most valuable target, not domain controllers.
5. NTLM’s weakness is architectural. Hashes are password-equivalent and reusable; NTLMv2 didn’t fix this.
6. Kerberos is better but not perfect. Tickets can still be stolen and reused within validity windows.
7. Defense requires protecting proof. Credential Guard, PPL, tiered administration, and monitoring are essential.
8. The attack surface is the endpoint. Securing Windows environments means securing every machine that handles credentials.

Further Resources

Hands-On Tools:

• klist - View cached Kerberos tickets (built into Windows)
• Mimikatz — Demonstrates credential extraction (research/testing only)
• Wireshark — Capture and analyze Kerberos/NTLM traffic
• Bloodhound — Visualize AD attack paths
• Rubeus — Kerberos abuse toolkit (red team research)

About This Article: Last updated February 2026. Windows security mechanisms evolve continuously; always verify current best practices for your environment.