Authentication Protocols | Radioactive Directory

NTL

NTLM: Legacy Contamination

NTLM (NT LAN Manager) has been authenticating Windows systems since 1993. Like radioactive waste with a 30-year half-life, it refuses to decay. It's a challenge-response protocol that proves you know a password without sending the password itself. Simple, effective, and riddled with security issues that Microsoft has been trying to decommission for decades. Yet it persists, contaminating modern environments.

What Is NTLM?

NTLM is a challenge-response authentication protocol. Instead of sending your password over the network, the server sends you a random challenge, and you prove you know the password by encrypting that challenge with a hash derived from your password. If your response matches what the server expects, you're in.

The Core Components:

NT Hash: MD4 hash of your Unicode password. This is what Windows stores.
Challenge: 8-byte random number from the server.
Response: Challenge encrypted with your NT hash (plus some other data depending on version).

The critical insight: the NT hash is functionally equivalent to your password. If an attacker has your NT hash, they don't need your password. They can authenticate as you directly (pass-the-hash) because the hash is what's used to create the response, not the plaintext password.

The NTLM Handshake (3-Way)

NTLM authentication involves three messages between the client and server. Think of it like a Vault-Tec security checkpoint: identify yourself, prove your identity, get access.

The NTLM 3-way handshake: Negotiate → Challenge → Authenticate

NTLM Authentication Flow

1 Client → Server NEGOTIATE: Client announces it wants to authenticate and lists supported options Type 1 Message

2 Server → Client CHALLENGE: Server sends an 8-byte random challenge Type 2 Message

3 Client → Server AUTHENTICATE: Client sends response (challenge encrypted with NT hash) + username + domain Type 3 Message

If the client is domain-joined and the server isn't a DC, there's actually more going on. The server doesn't have your password hash, so it forwards your response to a DC for verification. This is called pass-through authentication, and it's how NTLM relay attacks work: the attacker sits in the middle, captures your response, and forwards it somewhere else.

NTLMv1 vs NTLMv2: The Versions Matter

Not all NTLM is created equal. The version determines how the response is calculated, and NTLMv1 has cryptographic weaknesses that make it trivially crackable.

NTLMv1 DANGEROUS

Uses DES encryption. The response can be cracked in seconds using rainbow tables or services like crack.sh. If an attacker captures an NTLMv1 response, they can recover the NT hash almost instantly.

The Math Problem:

DES has a 56-bit key. The NT hash is split into three 7-byte chunks, each used as a DES key. This is cryptographically weak by modern standards.

NTLMv2 BETTER

Uses HMAC-MD5. Includes client challenge and timestamp in the response, making rainbow tables useless. Still susceptible to offline cracking, but requires significant compute for strong passwords.

The Improvement:

Client contributes randomness (client challenge). Response is HMAC-MD5(NT hash, server challenge + client blob). Replay is harder, cracking requires brute force.

The LAN Manager Authentication Level setting controls which versions are accepted. Level 0-2 allow NTLMv1. Level 3-5 require NTLMv2. Many environments still allow NTLMv1 for "compatibility." Attackers can often downgrade connections to NTLMv1 if the server accepts it.

LM Hashes: Weapons-Grade Weakness

Before NT hashes, there were LM (LAN Manager) hashes. They're so cryptographically weak they're practically pre-cracked. Like storing nuclear launch codes in a shoebox, they offered the illusion of security while providing almost none.

Why LM Hashes Are Catastrophically Weak:

1. Password converted to uppercase (reduces keyspace dramatically)
2. Padded/truncated to exactly 14 characters
3. Split into two 7-character halves, hashed separately
4. Each half can be cracked independently (7 chars max = trivial)

If your password is "Password123", the LM hash treats it as "PASSWORD123" split into "PASSWOR" and "D123". Each half is cracked in seconds. A 14-character password becomes two 7-character problems.

Containment achieved: LM hashes are disabled by default since Windows Vista/Server 2008. But fallout remains: Legacy systems and misconfigurations can still create them, and old hashes may persist in AD until the password is changed. Check your environment for this residual contamination.

NTLM Attack Surface

NTLM's design creates several attack opportunities. These aren't bugs; they're consequences of the protocol's architecture.

Pass-the-Hash

The NT hash is used directly to compute the response. If you have the hash, you don't need the password. Authenticate as the user anywhere NTLM is accepted. The hash IS the credential.

NTLM Relay

Capture an authentication attempt and forward (relay) it to another server in real-time. You're not cracking anything; you're reusing a legitimate authentication before it expires. Works against SMB, LDAP, HTTP, and other protocols. Use Impacket's ntlmrelayx or similar tooling.

Poisoning & Capture

Tools like Responder poison broadcast name resolution (LLMNR, NBT-NS, mDNS), causing victims to authenticate to attacker-controlled servers. The captured challenge-response can be cracked offline, or used as the first step in a relay attack.

Downgrade Attacks

If the server accepts NTLMv1, an attacker can force a downgrade and capture the weaker response. NTLMv1 responses can be cracked in seconds to recover the NT hash, which then enables pass-the-hash everywhere.

Defenses exist: SMB signing prevents relay. EPA (Extended Protection for Authentication) binds authentication to the TLS channel. Disabling NTLM entirely forces Kerberos. But these break things, so most environments don't fully deploy them.

KRB

Kerberos: The Clearance System

Named after the three-headed dog guarding the gates of Hades, Kerberos is a ticket-based authentication protocol developed at MIT in the 1980s. The current version 5 specification is defined in RFC 4120 (2005), which superseded the original RFC 1510 (1993). Its core goal: allow two parties to prove their identities to each other and establish a shared secret, without ever revealing their long-term keys. The Key Distribution Center (KDC) makes this possible by being the trusted third party that knows everyone's keys.

The Cryptographic Goal

Kerberos solves a fundamental problem: how can two parties authenticate each other without sending passwords over the network and without needing to share secrets directly?

The Problem:

Alice wants to prove she's Alice to a service. The service wants to prove it's the real service to Alice. Neither should have to reveal their password, and an eavesdropper shouldn't learn anything useful.

The Solution:

A trusted third party (KDC) that knows everyone's keys creates encrypted "tickets" and session keys. The tickets prove identity; the session keys enable secure communication. The long-term keys never leave the KDC or the principal's machine.

Think of it like a high-security vault clearance system: get verified once at the entry checkpoint, receive a security badge, then use that badge to get keycards for specific restricted zones without ever showing your credentials again.

The Vault-Tec Security Clearance Model

Think of Kerberos like the security clearance system in a high-security fallout vault:

Kerberos as a vault security system: One security badge (TGT), unlimited zone keycards (service tickets)

The Entry Checkpoint (Authentication Service / AS): You arrive at the vault and show your credentials (password) to the security officer. They verify your identity against the master registry and issue you a security badge (TGT) that proves you're cleared to be in the facility.

The Zone Access Office (Ticket Granting Service / TGS): When you need to enter a restricted zone, you show your security badge (TGT) to the zone access office. They verify your badge and issue you a keycard (service ticket) for that specific zone. You never show your original credentials again.

The Restricted Zone (Service): You swipe your zone keycard at the door. The door's reader verifies the keycard is valid and grants access. It doesn't need to contact the entry checkpoint; the keycard itself is proof of authorization.

The Players

Kerberos involves three parties—hence the name, after the three-headed dog. In AD, the KDC runs on every Domain Controller.

Client (Principal)

The user or service that wants to authenticate. Has a secret key derived from their password (for users) or a randomly generated key (for machine accounts).

Key Distribution Center (KDC)

The trusted third party. In AD, this runs on Domain Controllers. Contains two services: the Authentication Service (AS) and the Ticket Granting Service (TGS). Knows everyone's keys.

Service (Server)

The resource the client wants to access. Has its own key (service account password hash or machine account key). Trusts tickets signed by the KDC.

The Kerberos Exchange: Technical Details

Now let's look at what's actually happening in each step (MS-KILE). Understanding these details is essential for understanding Kerberos attacks.

Step 1 & 2: AS Exchange (Getting the TGT)

1 Client → KDC AS-REQ: "I am user X, I want a TGT" Contains: Username, timestamp encrypted with user's key (pre-auth)

2 KDC → Client AS-REP: "Here's your TGT and a session key" TGT encrypted with KRBTGT key, session key encrypted with user's key

What's in the TGT:

• Client name and realm
• TGS session key (for talking to the ticket booth)
• Expiration time (default: 10 hours)
• PAC (Privilege Attribute Certificate) - your group memberships and SIDs
• All encrypted with the KRBTGT account's key

The TGT is encrypted with the KRBTGT account's password hash. Only the KDC can decrypt it. The client can't read or modify their own TGT; they just present it to get service tickets.

Golden Ticket Attack [MITRE T1558.001]: If an attacker obtains the KRBTGT hash, they can forge TGTs for any user with any group memberships. The KDC will trust these forged tickets because they're encrypted with the correct key. This persists until KRBTGT is rotated twice.

Step 3 & 4: TGS Exchange (Getting a Service Ticket)

3 Client → KDC TGS-REQ: "Here's my TGT, I want a ticket for service Y" Contains: TGT, authenticator (timestamp encrypted with TGS session key), target SPN

4 KDC → Client TGS-REP: "Here's your service ticket" Service ticket encrypted with service's key, service session key encrypted with TGS session key

What's in the Service Ticket:

• Client name and realm
• Service session key (for talking to the service)
• Expiration time
• PAC (copied from TGT, or regenerated)
• All encrypted with the service account's key

The service ticket is encrypted with the service account's password hash (or machine account key). Only that service can decrypt it. The KDC looks up the target service by its SPN (Service Principal Name).

Kerberoasting: First presented by Tim Medin at DerbyCon 2014. Any authenticated user can request a service ticket for any SPN. The ticket is encrypted with the service account's hash. Request tickets for user-based service accounts, extract them, crack offline. Machine accounts have 120+ character random passwords (not crackable). User accounts often have weak passwords. See also: Sean Metcalf's detailed analysis and harmj0y's Kerberoasting without Mimikatz. [MITRE T1558.003]

Step 5: AP Exchange (Using the Service Ticket)

5 Client → Service AP-REQ: "Here's my ticket, let me in" Contains: Service ticket, authenticator (encrypted with service session key)

6 Service → Client AP-REP: (Optional) "I confirm I'm the real service" Mutual authentication - proves the service has the key to decrypt the ticket

The service decrypts the ticket, validates it hasn't expired, checks the authenticator to prevent replay, and reads the PAC to determine the client's group memberships and privileges. Authorization decisions are based on this.

Silver Ticket Attack [MITRE T1558.002]: If an attacker has a service account's hash, they can forge service tickets for that service. These tickets never touch the KDC, so there's no validation against the real user's status. The service just trusts the ticket.

The PAC: Authorization Data

The Privilege Attribute Certificate (PAC) is a Microsoft extension to Kerberos. It contains the user's authorization information: SIDs, group memberships, and other data the service needs to make access decisions.

PAC Contents:

• User SID
• Group SIDs (all groups the user belongs to)
• User account information (logon time, password last set, etc.)
• Server signature (signed with service key)
• KDC signature (signed with KRBTGT key)

The PAC is included in both the TGT and service tickets. When you forge a Golden Ticket, you write whatever group memberships you want into the PAC. The service reads the PAC and grants access based on those SIDs.

PAC Validation: Services can optionally validate the PAC with the KDC to confirm it's legitimate. This is rarely enabled because it adds latency. Without validation, forged tickets with arbitrary PACs are accepted.

Pre-Authentication: The First Line of Defense

By default, Kerberos requires "pre-authentication" in the AS-REQ. The client must prove they know the password by encrypting a timestamp with their key before the KDC issues a TGT.

With Pre-Auth (Normal):

Client sends: "I am user X" + timestamp encrypted with user's key
KDC verifies the timestamp decrypts correctly → user knows the password → issues TGT

Without Pre-Auth (Dangerous):

Client sends: "I am user X" (no proof)
KDC issues: AS-REP with part encrypted using user's key
Attacker extracts encrypted blob and cracks it offline

AS-REP Roasting [MITRE T1558.004]: Accounts with "Do not require Kerberos preauthentication" enabled can be targeted. Request an AS-REP for those accounts, extract the encrypted data, crack offline to recover the password. No authentication required to perform this attack.

Clock Skew: Kerberos's Achilles' Heel

Kerberos is time-sensitive. Timestamps are embedded in authenticators and tickets to prevent replay attacks. If the clocks between client, KDC, and service drift too far apart, Kerberos fails.

Default Tolerance:

5 minutes (configurable via "Maximum tolerance for computer clock synchronization" policy). If client and server clocks differ by more than this, authentication fails with KRB_AP_ERR_SKEW.

In AD environments, the PDC Emulator is the authoritative time source. Domain members sync to it automatically. But VMs, disconnected laptops, or misconfigured NTP can cause drift.

The NTLM Fallback Trap: When Kerberos fails due to clock skew, Windows silently falls back to NTLM. Users don't notice; they still authenticate. But now they're using the weaker protocol. Attackers can intentionally manipulate time (via NTP poisoning or VM settings) to force this fallback. Monitor for unexpected NTLM usage.

Troubleshooting tip: If Kerberos "should" work but doesn't, check time sync first. Run w32tm /query /status to verify. Clock skew is one of the most common causes of mysterious authentication failures in AD environments.

Delegation: When Services Need to Act as You

Sometimes a service needs to access other services on your behalf. For example, a web server needs to query a database as you, not as the web server's service account. This is delegation.

Unconstrained Delegation DANGEROUS

The service receives and caches your TGT. It can impersonate you to ANY service. Domain Controllers have this by default. Compromise a server with unconstrained delegation, extract cached TGTs, impersonate anyone who connects.

Constrained Delegation RISKY

Service can only delegate to specific SPNs listed in msDS-AllowedToDelegateTo. Safer, but if you control a service with constrained delegation, you can impersonate any user to those target services (S4U2Proxy).

Resource-Based Constrained Delegation ABUSABLE

The target service controls who can delegate to it (msDS-AllowedToActOnBehalfOfOtherIdentity). If you can write to this attribute, you can configure the target to accept delegation from an account you control. RBCD abuse is a common privilege escalation path.

Protected Users: The Admin Bunker

The Protected Users security group, introduced in Server 2012 R2, fundamentally changes how authentication works for its members. It's the closest thing Windows has to a "make this account actually secure" button. But it comes with trade-offs.

What Protected Users Enforces:

No NTLM: Members cannot authenticate via NTLM. Period. Only Kerberos.
No DES/RC4: Only AES encryption for Kerberos. Weak ciphers blocked.
No Delegation: Account cannot be delegated. No unconstrained, constrained, or RBCD.
No Credential Caching: Plaintext credentials and NT hashes not cached in LSASS.
Short TGT Lifetime: 4-hour TGT lifetime (not the default 10 hours). Non-renewable.

At the protocol level: When a Protected Users member authenticates, the KDC enforces these restrictions regardless of other policy settings. The TGT is issued with a 4-hour lifetime and the non-forwardable, non-delegatable flags set. The account's credentials are handled differently by LSASS.

What It Prevents

Pass-the-Hash: No NT hash cached = nothing to pass.
NTLM Relay: No NTLM = nothing to relay.
Kerberos Delegation Abuse: Non-delegatable tickets can't be abused.
Credential Theft Window: 4-hour TGT limits exposure time.

What It Breaks

NTLM-only Apps: Any application requiring NTLM will fail.
Delegation Scenarios: Multi-hop scenarios (web→SQL) won't work.
RDP with Saved Creds: Credential Manager won't have cached creds.
Offline Access: No cached credentials for laptop offline logon.

Important Limitations: Protected Users only works when authenticating to Server 2012 R2+ domain controllers. If a member authenticates to an older DC, the protections don't apply. Also, the account's NT hash still exists in AD; it's just not cached on endpoints. DCSync can still extract it.

Who Should Be in Protected Users? High-privilege accounts: Domain Admins, Enterprise Admins, and other Tier 0 identities. Test thoroughly first. Service accounts generally can't be members due to NTLM and delegation requirements.

Kerberos Attack Summary

AS-REP Roasting

Target accounts without pre-auth. Request AS-REP, crack the encrypted portion offline to recover passwords. MITRE T1558.004

Kerberoasting

Request service tickets for SPNs (Tim Medin, 2014), extract with Rubeus or Impacket and crack offline. Target user-based service accounts with weak passwords. MITRE T1558.003

Golden Ticket

Forge TGTs with KRBTGT hash. Become any user with any groups. Persists until KRBTGT rotated twice. MITRE T1558.001

Silver Ticket

Forge service tickets with service account hash. Access that service as any user. Never touches KDC. MITRE T1558.002

Pass-the-Ticket

Steal existing tickets (TGT or service tickets) from memory using Mimikatz or Rubeus. Use them on another machine to impersonate that user. MITRE T1550.003

Delegation Abuse

Exploit unconstrained, constrained, or RBCD to impersonate users to services you shouldn't access.

NTLM vs Kerberos: When Each Is Used

Windows doesn't always use Kerberos. Sometimes it falls back to NTLM. Understanding when each protocol is used explains why NTLM won't die and why certain attacks work in certain situations.

The Decision Tree

Windows tries Kerberos first, but falls back to NTLM in several situations:

Scenario	Protocol Used	Why
Access by hostname (\\server\share)	Kerberos	Can look up SPN for the hostname
Access by IP address (\\192.168.1.10\share)	NTLM	No hostname means no SPN lookup possible
Target not domain-joined	NTLM	No Kerberos realm, no KDC to issue tickets
Client not domain-joined	NTLM	Client can't get tickets from a KDC
Local account authentication	NTLM	Local accounts aren't in AD, no Kerberos principals
Cross-forest with NTLM trust	NTLM	Some external trusts only support NTLM
Application explicitly requests NTLM	NTLM	Legacy apps may hardcode NTLM
Kerberos fails (clock skew, DC unreachable)	NTLM	NTLM is the fallback when Kerberos can't work

The IP address trap: Attackers often coerce authentication to an IP address specifically to force NTLM. NTLM can be relayed; Kerberos (usually) cannot. When you see attack tools specifying IP addresses, this is why.

Protocol Comparison

Feature	NTLM	Kerberos
Authentication Type	Challenge-response	Ticket-based
Trusted Third Party	None (or DC for pass-through)	KDC (Domain Controller)
Mutual Authentication	No (by default)	Yes (optional but supported)
Delegation Support	Limited	Full (unconstrained, constrained, RBCD)
Offline Cracking	Yes (capture response, crack)	Yes (Kerberoasting, AS-REP roasting)
Relay Attacks	Yes (major vulnerability)	Harder (but not impossible)
Pass-the-Hash	Yes	N/A (Pass-the-Ticket instead)
Requires DC Contact	For domain auth, yes	Only for ticket requests
Clock Sensitivity	None	Yes (5-minute tolerance by default)

Why NTLM Won't Die

Microsoft has been working to deprecate NTLM for years, formally announcing it as a deprecated feature in Windows 11 Insider builds in 2023. It's still everywhere. Why?

Backward Compatibility

Legacy applications, old devices, and non-Windows systems often only support NTLM. Breaking them is unacceptable for many organizations.

IP-Based Access

Any time you access something by IP address instead of hostname, NTLM is used. This is extremely common in scripts, automation, and admin workflows.

Local Accounts

Local administrator accounts (not domain accounts) use NTLM. LAPS-managed local admin passwords still authenticate via NTLM.

Fallback Behavior

NTLM is the safety net when Kerberos fails. Disabling it can cause authentication failures that are hard to troubleshoot.

LDP

LDAP Authentication

LDAP is the protocol for querying and modifying Active Directory. But it also supports authentication through a process called "binding." How you bind determines your security posture.

LDAP Bind Types

Simple Bind INSECURE

Username and password sent in cleartext. Only acceptable over LDAPS (LDAP over TLS on port 636) or with StartTLS. Over plain LDAP (port 389), credentials are visible to anyone sniffing the network.

SASL Bind SECURE

Uses SASL (Simple Authentication and Security Layer) mechanisms. In AD, this typically means GSSAPI (Kerberos) or NTLM. Credentials are not sent in cleartext; the underlying protocol handles authentication securely.

Anonymous Bind LIMITED

Connect without credentials. AD allows very limited anonymous access by default (rootDSE only). Older configurations or misconfigurations may allow more. Rarely useful for attackers in modern AD.

LDAP Signing and Channel Binding

Even with SASL bind, LDAP traffic can be intercepted or relayed without additional protections.

LDAP Signing:

Cryptographically signs LDAP messages to prevent tampering. Configured via "LDAP server signing requirements" policy. Options: None, Require signing. Signing doesn't encrypt; it prevents modification.

LDAP Channel Binding:

Binds the authentication to the TLS channel. Prevents relay attacks where an attacker intercepts authentication and forwards it over a different TLS connection. Configured via "LDAP channel binding token requirements."

LDAP Relay: If signing and channel binding aren't enforced, attackers can relay captured NTLM authentication to LDAP using tools like Impacket's ntlmrelayx. This allows modifying AD objects: setting RBCD, adding shadow credentials, changing group memberships. Windows Server 2025 finally enables LDAP signing by default for new deployments.

PKI

Certificate Authentication (PKINIT)

PKINIT (Public Key Cryptography for Initial Authentication) lets you use certificates instead of passwords for Kerberos authentication. Instead of proving you know a password, you prove you possess a private key. This is the foundation of smart card logon and many ADCS attacks.

How PKINIT Works

In normal Kerberos, the client proves identity by encrypting a timestamp with their password-derived key. With PKINIT, the client signs the AS-REQ with their private key instead.

PKINIT AS Exchange

1 Client → KDC AS-REQ: Signed with client's private key + certificate KDC validates certificate chain and signature

2 KDC → Client AS-REP: TGT + session key encrypted to client's public key Only the private key holder can decrypt the session key

The KDC maps the certificate to an AD account using either the UPN (User Principal Name) in the certificate's SAN (Subject Alternative Name) or explicit certificate mapping attributes. Once mapped, the client receives a TGT just like password-based authentication.

Why Certificates Are Dangerous

Certificates seem more secure than passwords, but they introduce new attack surfaces:

Certificates Are Credentials

A certificate with private key is equivalent to knowing the user's password. If you obtain a certificate for a user, you can request TGTs as that user until the certificate expires or is revoked.

Long Validity Periods

Certificates often valid for 1+ years. Password changes don't invalidate existing certificates. An attacker with a certificate has persistent access even if the password is rotated.

ADCS Misconfigurations

Certificate templates that allow low-privileged users to request certificates for any user, or that include weak name mappings, can be exploited to gain certificates for privileged accounts. See Certified Pre-Owned research.

Shadow Credentials

Attackers can write to msDS-KeyCredentialLink on accounts they control, adding their own "shadow" credentials. They can then authenticate as that account using PKINIT without knowing or changing the password. See Elad Shamir's original research and the Whisker tool.

ESC1-ESC8 and beyond: The SpecterOps "Certified Pre-Owned" research by Will Schroeder and Lee Christensen revealed numerous misconfigurations (ESC1 through ESC8, now expanded further) that allow privilege escalation through certificate abuse. ADCS is a complex attack surface that many organizations don't audit properly. Use Certify (Windows) or Certipy (Linux) to enumerate your environment.

FED

Modern Protocols: Federation & Beyond

As organizations moved to the cloud and needed to authenticate across organizational boundaries, new protocols emerged. These don't replace NTLM or Kerberos for on-premises AD; they extend authentication to web applications, SaaS services, and hybrid environments.

SAML (Security Assertion Markup Language)

SAML is an XML-based protocol for exchanging authentication and authorization data between parties. It enables Single Sign-On (SSO) across organizational boundaries.

The Players:

Identity Provider (IdP): Authenticates users and issues assertions (e.g., ADFS, Azure AD/Entra ID)
Service Provider (SP): Relying party that trusts the IdP's assertions (e.g., Salesforce, AWS)
Principal: The user being authenticated

The Flow (SP-Initiated):

1. User accesses SP → 2. SP redirects to IdP → 3. User authenticates at IdP (often with Kerberos/NTLM) → 4. IdP issues signed SAML assertion → 5. User presents assertion to SP → 6. SP grants access

Golden SAML: If an attacker compromises the ADFS token signing certificate, they can forge SAML assertions for any user to any federated service. Like Golden Tickets, but for cloud services. This was a key technique in the SolarWinds/SUNBURST attack. See the original CyberArk Golden SAML research by Shaked Reiner.

OAuth 2.0 & OpenID Connect (OIDC)

OAuth 2.0 is an authorization framework (not authentication). OIDC adds an authentication layer on top. Together, they power "Login with Google/Microsoft/etc." buttons everywhere.

OAuth 2.0:

Grants access tokens that allow applications to act on behalf of users. The application never sees the user's password. Tokens have scopes that limit what the application can do.

OIDC:

Adds an ID token (JWT) that contains claims about the user's identity. The application can verify who the user is, not just that they authorized access.

How Modern Protocols Connect to AD

These protocols don't operate in isolation. In hybrid environments, they often sit on top of traditional AD authentication:

Typical Hybrid Flow:

1. User accesses cloud app → 2. Redirected to Azure AD/Entra ID → 3. Azure AD/Entra ID checks if federated → 4. Redirected to on-prem ADFS → 5. ADFS authenticates via Kerberos/NTLM against AD → 6. SAML assertion issued → 7. Exchanged for OAuth tokens → 8. User accesses cloud app

The chain is only as strong as its weakest link. Compromise on-prem AD, and you potentially compromise all federated cloud services. This is why hybrid identity is both powerful and dangerous.

STK

The Protocol Stack: Layers of Risk

Authentication doesn't happen in isolation. When you access a file share, multiple protocols work together. Understanding this stack reveals why hardening one layer while ignoring others creates a false sense of security.

Anatomy of a File Share Access

Let's trace what happens when a user accesses \\fileserver\share from a domain-joined workstation:

Each layer depends on the layers below. Compromise any layer, disrupt everything above.

The Full Sequence

1 DNS Query Workstation queries DNS for "fileserver" → Gets IP address Risk: DNS poisoning redirects to attacker

2 Kerberos TGS Workstation requests service ticket for cifs/fileserver from KDC Risk: None for standard file servers (machine account)

3 TCP Connect Workstation connects to file server on port 445 Risk: Man-in-the-middle if connecting to wrong IP

4 SMB Negotiate Client and server negotiate SMB dialect and capabilities Risk: Downgrade to SMBv1, disable signing

5 SMB Session Client presents Kerberos ticket, session established Risk: Relay if signing not required (NTLM only)

6 Authorization Server extracts PAC, checks permissions against ACLs Risk: ACL misconfiguration grants excessive access

Why Step 2 says "None" for file servers: Standard file servers use machine accounts, not user-based service accounts. The cifs/fileserver SPN is registered to the computer account, which has a 120+ character randomly generated password that rotates every 30 days. This is computationally infeasible to crack. Kerberoasting only works against user-based service accounts (e.g., SQL Server running as svc_sql) where a human set a potentially weak password.

The Fallacy of Single-Layer Hardening

Organizations often harden one protocol while ignoring others. This creates dangerous gaps:

Hardened Kerberos, Weak DNS

You've enforced AES encryption and disabled RC4. But DNS is unsigned and unauthenticated. Attacker poisons DNS to redirect "fileserver" to their machine. Client requests a Kerberos ticket for the real fileserver, connects to the attacker, and the attacker relays to the real server. Your Kerberos hardening didn't help.

SMB Signing Enabled, LDAP Unsigned

SMB relay is blocked by signing. But LDAP signing isn't required. Attacker coerces authentication (PetitPotam, PrinterBug/SpoolSample) and relays to LDAP. They modify AD objects: set RBCD, add shadow credentials, change group memberships. SMB hardening didn't protect AD.

NTLM Disabled, But Fallback Exists

You've "disabled NTLM" via GPO. But one legacy application has an exception. Attacker targets that system, captures NTLM, relays or cracks. One exception undermines the entire policy.

Strong Auth, Weak Authorization

Perfect authentication doesn't help if ACLs are misconfigured. User authenticates securely, but has WriteDACL on a privileged group because of inherited permissions from 15 years ago. Authentication worked exactly as designed; authorization was the problem.

The lesson: Security requires defense in depth across ALL layers. Hardening Kerberos while ignoring DNS, SMB, and LDAP is like building a vault door on a house with open windows. Attackers will find the weakest link.

What If DNS Is Compromised?

DNS is the foundation. If an attacker controls name resolution, they control where your traffic goes:

Attack Scenario:

1. Attacker poisons DNS or performs ARP spoofing
2. "fileserver" now resolves to attacker's IP
3. Client connects to attacker, thinking it's the file server
4. If using NTLM: Attacker relays authentication to real server or cracks it
5. If using Kerberos: Client has a ticket for the real server, presents it to attacker who relays it

Kerberos mutual authentication is supposed to prevent this. The client should verify the server knows the service's key. But in practice, applications often don't verify AP-REP, and ticket relay attacks exist. DNSSEC and secure DNS are critical but rarely deployed in enterprise environments.

DEF

Securing Authentication: The Containment Protocol

Hardening authentication requires a comprehensive approach across all protocols. Like containing radioactive material, every layer needs proper shielding. Here's the defense-in-depth approach.

NTLM Hardening

Disable NTLM Where Possible

Use "Network security: Restrict NTLM" policies to audit and then block NTLM. Start with audit mode to identify dependencies, then progressively restrict. Goal: NTLM only where absolutely required.

Require NTLMv2

Set LAN Manager Authentication Level to "Send NTLMv2 response only. Refuse LM & NTLM." This prevents downgrade to crackable NTLMv1 responses.

Enable EPA

Extended Protection for Authentication binds NTLM auth to the TLS channel. Prevents relay attacks by ensuring authentication can only be used on the channel where it was performed.

Disable LM Hash Storage

"Network security: Do not store LAN Manager hash value on next password change" should be enabled (it is by default on modern systems). Verify it's not overridden.

Kerberos Hardening

Disable RC4 Encryption

RC4 (arcfour-hmac) is weak. Configure "Network security: Configure encryption types allowed for Kerberos" to require AES only. Note: This can break older systems that don't support AES.

Enable Kerberos Armoring (FAST)

Flexible Authentication Secure Tunneling protects pre-authentication exchanges. Prevents AS-REP roasting and provides additional protection for the initial exchange.

Use Protected Users Group

Members cannot use NTLM, delegation, or DES/RC4. TGTs have 4-hour lifetime. Add privileged accounts. Prevents many credential theft and lateral movement techniques.

Rotate KRBTGT Regularly

KRBTGT password should be rotated at least annually and immediately after any suspected compromise. Requires two rotations to fully invalidate old Golden Tickets.

LDAP Hardening

Require LDAP Signing

"Domain controller: LDAP server signing requirements" = Require signing. Prevents LDAP relay attacks and message tampering. Finally default in Server 2025.

Require Channel Binding

"Domain controller: LDAP server channel binding token requirements" = Always. Binds authentication to the TLS session, preventing relay over different channels.

Enforce LDAPS

Where possible, require LDAPS (port 636) instead of LDAP (port 389). Encrypts traffic and provides channel for binding. Requires proper certificate deployment.

Disable Anonymous Binds

Should be default, but verify. Anonymous binds allow unauthenticated LDAP queries. Even limited information leakage helps attackers enumerate the environment.

SMB Hardening

Require SMB Signing

"Microsoft network server: Digitally sign communications (always)" = Enabled. Prevents SMB relay attacks. Has minor performance impact but critical for security.

Disable SMBv1

SMBv1 is deprecated and dangerous (EternalBlue, WannaCry). Should be disabled everywhere. Use "Get-SmbServerConfiguration" to verify and "Disable-WindowsOptionalFeature" to remove.

Enable SMB Encryption

SMB 3.0+ supports encryption. "Set-SmbServerConfiguration -EncryptData $true" encrypts all SMB traffic. Provides confidentiality beyond just signing.

Require Secure Negotiate

Prevents downgrade attacks during SMB negotiation. "Set-SmbServerConfiguration -RequireSecuritySignature $true" on servers.

Certificate/PKINIT Hardening

Audit Certificate Templates

Review all templates for ESC1-ESC8+ vulnerabilities. Tools like Certify and Certipy can identify misconfigurations. Remove unnecessary enrollment permissions.

Require Manager Approval

For high-privilege certificate templates, require CA manager approval. Prevents automated abuse of misconfigured templates.

Enable Strong Mapping

Use explicit certificate mapping instead of implicit UPN mapping. Prevents certificate spoofing attacks where attackers create certs with arbitrary UPNs.

Monitor Certificate Issuance

Log and alert on certificate requests, especially for privileged templates. Unexpected certificate issuance may indicate compromise.

The Complete Picture

Protocol/Layer	Primary Threat	Key Mitigation	Server 2025 Default
NTLM	Relay, Pass-the-Hash, Cracking	Disable or restrict NTLM; EPA	Still allowed (for compatibility)
Kerberos	Kerberoasting, Golden/Silver Tickets	AES only, Protected Users, FAST	RC4 still allowed
LDAP	Relay, Credential theft	Signing + Channel Binding	Signing required
SMB	Relay, EternalBlue	Signing, disable SMBv1	DCs require signing (inbound + outbound); member servers require signing as client — inbound unsigned still allowed
ADCS/PKINIT	ESC1-ESC8+, Shadow Credentials	Template audit, strong mapping	No significant changes
DNS	Poisoning, spoofing	DNSSEC (rarely deployed)	Unsigned by default

The uncomfortable truth: Most environments haven't implemented even half of these controls. Every unhardened protocol is an attack path. Defense requires treating the entire protocol stack as an interconnected system, not isolated components.