From NTLM to Passwordless: How Entra ID & Windows Hello for Business Protect Your Identity

Introduction

Identity and access management (IAM) has come a long way from simple username/password checks. Today, Microsoft networks rely on authentication protocols to verify who you are and what you can access ,even across complex hybrid or cloud environments.

Two of the most important protocols in the Windows world are:

• NTLM (NT LAN Manager) :- the “old guard” still hanging around for legacy reasons

• Kerberos :- the modern, more secure ticket-based system

NTLM still works in workgroup setups and untrusted domain scenarios, but it’s showing its age. Microsoft and security experts are pushing hard to phase it out in favour of Kerberos and modern authentication.

This Blog will break down how NTLM and Kerberos work (in plain language), where the risks are, and how Microsoft Entra ID and Defender for Identity can help you get rid of NTLM for good.

NTLM in Plain Language

Think of NTLM as a quiz at the door:

1. You say: “Hi, I’m Alice.”
2. The server gives you a puzzle (a random challenge).
3. You solve it using your password and send the answer back.
4. If your answer matches the server’s own, you get in.

Sounds fine, right? The problem is:

• Attackers can steal your answer (the hashed response) and reuse it without knowing your password (Pass-the-Hash).
• NTLM doesn’t verify the server’s identity, so attackers can trick you into talking to them and then relay your answer to a real server (NTLM Relay).
• No native MFA, no device checks, and weaker cryptography.

 Kerberos in Plain Language

Kerberos works more like a school hall pass system:

• You log in and get a Ticket Granting Ticket (TGT) from the “Kerberos Office” (Domain Controller).
• When you want to access a service (like a file share), you use your TGT to request a service ticket for that specific service.
• You present that ticket and because it’s issued by a trusted DC, the service lets you in.

Why it’s better:

• Supports mutual authentication (you and the server verify each other)
• Enables Single Sign-On (SSO)
• Works with MFA, smart cards, passwordless sign-in
• No password hashes sent for each authentication

Kerberos vs NTLM Fallback

When a user or computer tries to access a resource (like a file share or web app), Kerberos is attempted first because it’s the default and most secure method in Active Directory environments.

But if Kerberos authentication fails , for any reason ,Windows will silently fall back to NTLM (if NTLM is still allowed in the environment).

Why Would Kerberos Fail?

Here are common reasons:

What Happens During Fallback?

1. Client tries Kerberos

→ Client asks the Domain Controller for a ticket to the server (using SPN).

2. Kerberos fails

→ Maybe the SPN is missing or time is off.

3. Windows automatically falls back to NTLM

→ Client sends an NTLM authentication request instead, using challenge-response.

4. NTLM succeeds (if allowed)

→ The user is authenticated with NTLM, and access is granted.

Top lane (Kerberos): Client → DC (TGT) → Service Ticket → Resource 

Bottom lane (NTLM Fallback): Client → Server (Challenge) → Hash Response → Resource 

Risks in the Real World

NTLM Weaknesses:

You may think Kerberos is protecting everything, but if NTLM is allowed, attackers can exploit it (e.g., pass-the-hash, relay & Replay attacks).

• Pass-the-Hash: Steal a hash, skip the password
• Relay Attacks: Forward authentication to a real service
• Replay Attacks: Resend captured responses

It’s silent , fallback happens in the background unless explicitly logged. Attackers love environments where NTLM is still enabled as a backup.

How to Detect and Prevent NTLM Fallback

1. Enable NTLM Auditing

1. Group Policy: Network Security: Restrict NTLM
2. Log NTLM traffic
3. Block NTLM where possible

2. Use Defender for Identity

1. Get alerts when NTLM Based attacks happens
3. Configure Kerberos-only access for critical accounts
1. Add users to the Protected Users group (Blocks NTLM and forces Kerberos)
4. Fix SPNs and time sync
1. Use tools like setspn to validate and fix SPNs
2. Ensure NTP (Network Time Protocol) is configured correctly
5. Eventually block NTLM
1. Gradually enforce NTLM restrictions using GPO
2. Test in audit mode first to avoid breaking apps

Kerberos Weaknesses (if compromised):

A TGT (Ticket Granting Ticket) is a special ticket issued by a Domain Controller (KDC) when a user logs in. It allows users to request access (service tickets) to other resources without re-entering their password. It’s stored in memory (LSASS.exe) and valid for a default of 10 hours (configurable).

If an attacker can steal the TGT, they can pretend to be that user , even a domain admin.

 How Attackers Steal or Abuse TGTs

TGT Dumping (Kerberoasting / Ticket Extraction): Use tools like Mimikatz to dump credentials from LSASS on a compromised machine. The TGT is in memory and can be saved as a .kirbi file. The attacker can reuse this ticket to impersonate the user.

Golden Ticket Attack: Once an attacker has the KRBTGT account hash (Kerberos service account), they can forge any TGT — even one for a domain admin. These forged tickets are called Golden Tickets. They are trusted by all domain controllers.

Silver Ticket Attack: Similar to Golden Ticket, but targets specific services (e.g., CIFS, MSSQL) by forging service tickets, not TGTs. Requires access to the service account hash instead of KRBTGT.

Pass-the-Ticket (PTT) :Use a stolen .kirbi ticket and inject it into memory using Mimikatz or Rubeus. You now impersonate the user without needing a password or hash

Kerberoasting : Request service tickets (TGS) for SPNs exposed in AD (e.g., SQL service). Offline brute-force the encrypted part to recover service account passwords. Works even if the TGT is valid and untouched.

Why TGT-Based Attacks Work

Tickets are in memory : If LSASS is compromised, TGTs are easily extracted.

TGTs act as identity proof : A valid TGT lets you get access to nearly any service the user has rights to , no password needed.

Long validity: TGTs can last 10+ hours, or longer if forged

TGTs are reusable : Once stolen, they can be reused across sessions or systems (unless specifically blocked or expired)

Summary: TGT Attack Flow (Example)

1. Attacker compromises a user’s machine.
2. Dumps TGT from memory using Mimikatz.
3. Uses Pass-the-Ticket to access file servers or DCs as that user.
4. Installs persistence or laterally moves to higher-privileged accounts.
5. (If KRBTGT hash is available) → Generates Golden Ticket → Owns the domain.

Role of SPN in Kerberos

SPNs (Service Principal Names) is critical to making Kerberos authentication work properly and misconfigurations are one of the top causes of NTLM fallback and security issues.

What is an SPN (Service Principal Name)?

An SPN is like a unique ID or alias used by Kerberos to identify a service running on a server in Active Directory.

 It's a mapping between:

• A service (e.g., SQL, HTTP, CIFS)
• A host (server name or FQDN)
• And the account running that service (computer account or service account)

Think of SPN Like This: Imagine you walk into a hotel and ask for Room Service. The front desk (Domain Controller) needs to know: 

• Which room?
• Which staff member is responsible?
• Is this service valid?

SPN tells the domain: The HTTP service running on webserver01.contoso.com belongs to the WebAppSvc account.

Why SPNs Are Important in Kerberos

SPNs enable Kerberos to work by allowing a client to:

1. Ask the Domain Controller for a Kerberos ticket (TGS) for a specific service (SPN).
2. The DC finds which account the SPN belongs to.
3. Issues a ticket encrypted with that account’s secret key.
4. The client sends the ticket to the service, which decrypts it and allows access.

If the SPN is missing or misconfigured:

• The client can’t request a Kerberos ticket.
• Authentication fails silently.
• Windows falls back to NTLM.
• You lose SSO, MFA support, and security features.

What Is Kerberos Delegation?

Kerberos delegation allows a service to act on behalf of a user to access other services.

Imagine this:

You log into a web app, and that app needs to access a file server or SQL database as you, not as itself. This is where delegation comes in ,the web app can impersonate you to access downstream services.

Types of Kerberos Delegation

1. Unconstrained Delegation ( Legacy & Risky)

• Service can impersonate any user to any service.
• When a user connects to a server, their TGT (Ticket Granting Ticket) is stored in memory on that server.
• The server can reuse that TGT to access any service as the user.

Risk: If that server is compromised, an attacker can extract the TGT from memory and impersonate any user, even domain admins.

This is how Golden Ticket, Pass-the-Ticket, and printer bug attacks are often enabled.

2. Constrained Delegation (More Secure)

• Allows a service to impersonate users only to specific services.
• Controlled using SPNs ,you define which services the app is allowed to delegate to.

Example: WebAppServer is trusted to delegate to MSSQLSvc/sqlserver.contoso.com

This limits misuse only to the allowed SPNs.

3. Resource-Based Constrained Delegation (RBCD) (Modern & Safer)

Delegation is controlled on the target resource, not on the calling service.
Example: The file server says: Only WebAppServer is allowed to delegate users to me.

• Great for cross-domain, cloud, and automated deployments.
• Used by Azure AD joined devices, Hybrid Join, and Kerberos Cloud Trust.

Why SPNs Are Required for Delegation

Delegation works by forwarding Kerberos tickets, and SPNs tell the KDC (domain controller):

• What service is being accessed
• What service account to encrypt the ticket for

If SPNs are missing or misconfigured, delegation fails, and fallback to NTLM may occur or worse, authentication errors.

Best Practices to Secure Delegation

Avoid Unconstrained Delegation : Use Constrained or RBCD instead

Validate SPNs Regularly : Prevent duplicate or incorrect mappings

Remove Old Delegation Configs : Don’t leave unused delegation entries

Monitor Ticket Usage : Use Defender for Identity or Sentinel to detect suspicious delegation patterns

Use Credential Guard : Protect TGTs in memory from extraction

Audit Accounts with TrustedToAuthForDelegation : Identify high-risk service accounts

Unified Best Practices for Securing Kerberos and Retiring NTLM

Protect Credentials and Keys

• Enable LSASS Protection: Turn on Credential Guard or LSA Protection to block memory dumping of LSASS where TGTs and NTLM hashes can be stolen.
• Use Passwordless Sign-in: Implement Windows Hello for Business or FIDO2 keys to remove reusable passwords entirely; keys are secured in the TPM.
• Protect KRBTGT Account: Rotate the KRBTGT password at least twice in succession when suspected compromise or annually as a preventive measure to invalidate forged Golden Tickets.

Harden Kerberos

• Shorten TGT Lifetimes: Reduce ticket validity (e.g., from the default 10h to 4h) to shrink the attack window.
• Fix SPNs: Ensure all services have correct Service Principal Names so Kerberos works without falling back to NTLM.
• Use Strong Encryption Only: Enforce AES for Kerberos tickets; disable RC4 and DES.

Retire NTLM

• Audit Before Blocking: Use “Network Security: Restrict NTLM” in Audit mode on DCs, member servers, and clients to identify dependencies.
• Block for High-Value Accounts: Add admins to the Protected Users group , prevents NTLM, WDigest, and other legacy protocols.
• Gradually Enforce Deny Mode: Move from Audit → Deny for incoming, outgoing, and domain NTLM traffic, keeping exceptions minimal.

Reduce Legacy Attack Surfaces

• Disable Weak Protocols: Turn off NTLMv1, LM, and WDigest to prevent downgrade/fallback abuse.
• Require Modern Auth: Move apps to Entra ID with SAML, OAuth 2.0, or OIDC; disable Basic Auth in cloud services.

Network & Admin Hygiene

• Tiered Administration Model: Use separate, hardened admin workstations for domain admin accounts , never sign in to lower-tier systems.
• Isolate Domain Controllers: Restrict direct RDP to DCs; manage via jump hosts or secure admin VMs.
• Segment Networks: Limit lateral movement paths with firewall rules and segmentation.

Continuous Monitoring and Response

• Monitor Ticket Usage: Use Defender for Identity or Microsoft Sentinel to detect unusual TGT usage, Pass-the-Ticket attempts, or lateral movement.
• Investigate Alerts Quickly: Respond to signs of Pass-the-Hash, Golden Ticket creation, or NTLM tampering immediately.
• Correlate Cloud & On-Prem Data: Integrate Entra ID sign-in logs with Defender for Identity to spot cross-environment compromise.

How Microsoft Entra ID & Windows Hello for Business Strengthen Security

• Entra Kerberos Cloud Trust :- Allows Entra-joined devices to obtain Kerberos tickets for on-premises resources directly from the cloud — eliminating the need for NTLM.
• Passwordless Authentication (Windows Hello for Business, FIDO2) :- Removes the reliance on stored password hashes, reducing credential theft risk.
• Conditional Access:- Validates device compliance and user risk signals before granting access.

How It Works:

• The user signs in to Windows with Windows Hello for Business, authenticating against Microsoft Entra ID.
• Entra ID checks for a Kerberos server key that matches the user’s on-premises AD domain.
• Entra ID issues a partial Kerberos Ticket-Granting Ticket (TGT) containing only the user’s Security Identifier (SID), without authorization data like group memberships.
• The partial TGT is returned to the client along with the Entra ID Primary Refresh Token (PRT).
• The client contacts the on-premises AD Domain Controller to exchange the partial TGT for a full TGT (following the same protocol flow as Read-Only Domain Controller scenarios).
• The client now holds both an Entra ID PRT and a full AD TGT, enabling secure access to both cloud and on-premises resources without passwords or NTLM fallback.

Want to set up Windows Hello for Business? Check out my step-by-step guide here: Deploying Windows Hello for Business"

How Defender for Identity Protects You

• Detects Pass-the-Hash, Pass-the-Ticket, and NTLM tampering
• Alerts on suspicious Kerberos ticket creation (e.g., possible Golden Ticket activity)
• Correlates on-prem and cloud sign-in data for a complete view of risky activity

More insights on Microsoft Defender for Identity coming soon , stay tuned!

Conclusion

NTLM is history, and Kerberos still needs guarding. The future is clear:

Retire NTLM. Secure Kerberos. Go passwordless with Entra ID–joined devices using Windows Hello for Business. Continuously monitor your local identity infrastructure with Microsoft Defender for Identity.

Follow this path, and you’ll shrink your attack surface while building an identity security foundation built to last.