NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM

Even on a corporate network described as “a Kerberos environment”, auditing always turns up NTLM. And what turns up is usually an application that is supposed to support Kerberos.

Why that happens becomes obvious the moment you put the two protocols side by side and ask what each is trying to prove. This article covers how NTLM and Kerberos behave, with diagrams, then under what conditions authentication falls back to NTLM and why Microsoft is trying to get rid of NTLM — all backed by the official documentation.

The procedure for inventorying your own estate (configuring audit policies, following the events, the order in which to fix things) is set out in the companion article “Will NTLM Deprecation Stop Your Business Apps? — How to Collect Audit Logs, and the Order in Which to Kill Dependencies”.

1. The Bottom Line First

• NTLM proves only that you hold the password hash. The credentials are a one-way hash of the domain name, user name, and password,¹ and in NTLMv2 — what today’s Windows uses — a key derived from that hash is used to compute an HMAC over “the server challenge + a timestamp + a client-side challenge + target information” (Section 2.2).²
• Kerberos proves “who, to which service”. Tickets are issued keyed on the destination service name (the SPN), so a ticket for a different destination cannot be used.³
• There are three decisive differences: whether there is mutual authentication, whether (for domain-account authentication) the server queries a domain controller, and whether delegation is possible. Microsoft states all three explicitly (Section 5).⁴
• The biggest reason for falling back to NTLM is “names”. Kerberos cannot begin unless an SPN can be resolved from the destination name. Hard-coded IP addresses, unregistered SPNs, workgroups, and routes that cannot reach a DC are the four main factors (Section 6).⁵⁶
• Relay attacks work because NTLM has no mechanism binding “who you are authenticating to”. Pass-the-Hash works because what authentication needs is the hash itself (Section 7).⁷¹
• NTLMv1 has already been removed. Windows 11 version 24H2 and Windows Server 2025 are the versions concerned. NTLMv2 is deprecated but still works (Section 8).⁸
• What applications should write is Negotiate. Negotiate selects either Kerberos or NTLM, and selects Kerberos unless one of the systems involved in the authentication cannot use it.¹

2. What NTLM Actually Does

NTLM (Windows Challenge/Response) is, as the name says, a challenge/response authentication protocol. Summarising Microsoft’s description: the credentials consist of a one-way hash of the domain name, user name, and password obtained at interactive logon, and in order to authenticate without sending the password over the wire, the party requesting authentication performs a computation that proves it “can access the securely stored NTLM credentials”.¹

The important point here is that the material for authentication is not the password itself but the hash of the password. That single fact is what makes Pass-the-Hash possible, as we will see later.

2.1. With a Domain Account, Three Parties Are Involved

When an already-logged-on user accesses a resource on a server using a domain account (non-interactive authentication), three parties are involved: the client, the server, and the domain controller. The distinctive part is that the server itself does not perform the authentication computation — it has the domain controller do it on its behalf.¹

sequenceDiagram
    autonumber
    participant C as Client
    participant S as Server
    participant DC as Domain controller

    Note over C: At logon, hashes the password<br/>and discards the password itself
    C->>S: User name (plaintext)
    S->>C: 8-byte random number (challenge)
    Note over C: Encrypts the challenge<br/>with the password hash
    C->>S: Response
    S->>DC: User name / challenge / response
    Note over DC: Retrieves the hash from the SAM<br/>and performs the same computation
    DC-->>S: If they match, authentication succeeds
    S-->>C: Access granted

Figure 1: NTLM non-interactive authentication (with a domain account)

The procedure Microsoft presents conceptually is as follows (the actual computation changes with NTLMv2, as described below, but the cast and the division of labour are exactly as in the diagram).¹

1. (Interactive authentication only) The user enters a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.
2. The client sends the user name to the server in plaintext.
3. The server generates an 8-byte random number (the challenge, a nonce) and sends it to the client.
4. The client encrypts this challenge with the hash of the user’s password and returns the result (the response).
5. The server sends three things to the domain controller: the user name, the challenge it sent the client, and the response it received.
6. The domain controller looks up the password hash for that user name in the SAM database and encrypts the challenge with it.
7. It compares its own result with the client’s response; if they are identical, authentication succeeds.

2.2. The Real Computation — NTLMv2 Is a Bit More Involved

The seven steps above are the basic form described on Microsoft’s overview page. NTLMv2, which today’s Windows actually uses, is one step more complex than “encrypt the challenge with the password hash”. The specification ([MS-NLMP]) defines it as follows.²

• The response key is NTOWFv2 = HMAC_MD5( MD4(UNICODE(password)), uppercased user name + domain name )
• The client builds temp by concatenating the response version, a timestamp, an 8-byte challenge generated on the client side, and target information (AV pairs)
• The core of the response is NTProofStr = HMAC_MD5( response key, server challenge + temp )

In other words, what is actually computed is an HMAC that mixes in not only the server challenge but also a client-side random value, a timestamp, and destination information. The verifying side reproduces the same computation. If the account is in Active Directory, the challenge/response pair is sent to a domain controller for verification; if the account is local to the server, the server computes the expected value using the OWF it stores itself.²

What matters for the discussion in this article is that even with the added complexity, two things do not change.

1. The key material is still the password hash. The starting point of NTOWFv2 is MD4(UNICODE(password)) — the NT hash itself.² That is why Pass-the-Hash works (Section 7.2).
2. The client does not verify that the server is genuine. Microsoft’s statement that NTLM has no mutual authentication holds for NTLMv2 too.⁴

Everything that follows rests on those two points.

2.3. With a Local Account, Two Parties Suffice

With a local account, the right-hand side of the diagram disappears. A resource server queries the authentication service on a domain controller for that account’s domain if the account is a domain account, but consults its local account database if the account is local.⁹ So on a workgroup machine, or when connecting to a share with a local account on a file server, no domain controller appears: it is a two-party exchange in which the server looks at its own SAM and decides for itself.

This distinction feeds directly into the inventory of “Kerberos is unavailable because it’s a local account” dependencies discussed in Section 6.3. NTLM on this route does not show up in the domain controllers’ audit logs at all.

2.4. Three Consequences of This Design

Look at Figure 1 and you can read off the properties that become a problem later.

• The server proves nothing to the client. The exchange is one-way, with no step anywhere in which the server shows that “I am genuine”.
• The server can only decide when it holds the hash itself. Each time it needs a new access token, a resource server must query the authentication service on a domain controller for a domain account, or consult its local account database for a local account.⁹ That is why authentication with domain accounts is dependent on a domain controller.
• The response is “for that challenge only”, but it does not bind the destination. Because the challenge differs every time, the same response cannot be reused. But there is no element proving “which server this response is for”, so it can be passed on to a different server without anyone noticing.

3. Why the Server Asks a Domain Controller

When authenticating a domain account, the only thing holding the password hash is the account database on the domain controller side. The resource server does not know that user’s hash, so it cannot verify it on its own. Hence it must query a domain controller every time it authenticates (pass-through authentication).⁹¹ (With a local account, the server consults its own SAM and decides for itself. Everything below about dependency on a domain controller applies to domain accounts.)

This has costs both in security and in operations. Microsoft explains that with pre-Kerberos NTLM authentication an application server had to connect to a domain controller every time it authenticated a client or a service, whereas with Kerberos renewable session tickets replace pass-through authentication and the server does not need to go to a domain controller except when PAC (privilege attribute certificate) validation is required.⁴

So migrating to Kerberos is, at the same time as being a security matter, a matter of reducing dependency on domain controllers.

4. What Kerberos Actually Does

Kerberos starts from a distinctly different idea. Rather than redoing identity verification on every authentication, you verify identity once at the outset, receive a “ticket”, and present that ticket thereafter.

The KDC (Key Distribution Center) runs on a domain controller and uses the Active Directory Domain Services database as its security account database.⁴

sequenceDiagram
    autonumber
    participant C as Client
    participant KDC as KDC (domain controller)
    participant S as Service (identified by SPN)

    Note over C,KDC: AS exchange — prove identity and get a TGT
    C->>KDC: KRB_AS_REQ<br/>(user name + timestamp encrypted with long-term key)
    Note over KDC: If it decrypts with the long-term key, it is them
    KDC-->>C: KRB_AS_REP<br/>TGT (encrypted with krbtgt's key) + session key

    Note over C,KDC: TGS exchange — get a service ticket
    C->>KDC: KRB_TGS_REQ<br/>(TGT + destination SPN + authenticator)
    Note over KDC: Looks up the service account from the SPN<br/>and encrypts the ticket with its long-term key
    KDC-->>C: KRB_TGS_REP<br/>service ticket + session key

    Note over C,S: AP exchange — present it to the service
    C->>S: KRB_AP_REQ<br/>(service ticket + authenticator)
    Note over S: Decrypts with its own long-term key<br/>= the ticket is addressed to it
    S-->>C: KRB_AP_REP (if mutual authentication was requested)

Figure 2: The three Kerberos exchanges (AS / TGS / AP)

4.1. The AS Exchange — Proving Identity Once

The client sends the KDC its user name and domain name, plus a timestamp encrypted with its own long-term key (the key derived from the password). This is pre-authentication. If the KDC can decrypt it with that long-term key and the timestamp is valid, it concludes “this is them”.³

The KDC returns a TGT (ticket-granting ticket). The TGT is encrypted with the KDC’s own long-term key (the krbtgt account’s key), so the client cannot read its contents. Along with it, a session key for use between the client and the KDC is handed over, encrypted with the client’s long-term key.³

The thing to hold on to here is that the timestamp is part of the authentication. That is why Kerberos is strict about time synchronisation; the default tolerated skew is five minutes.¹⁰ Exceed it and pre-authentication fails, so Kerberos authentication itself fails with an error (Windows time synchronisation is covered in “A Guide to Windows Time Synchronisation (w32time)”). “Kerberos fails” and “it falls back to NTLM” are two different things. The distinction is covered in Section 6.5.

4.2. The TGS Exchange — Declaring Which Service You Are Connecting To

This is the decisive divergence from NTLM. The client tells the KDC the name of the service it wants to connect to (the SPN) and requests a service ticket, attaching the TGT and an authenticator.³

The KDC finds the service account corresponding to that SPN and returns a service ticket encrypted with that account’s long-term key.³ Therefore:

• If the SPN cannot be resolved, no ticket is issued. If no SPN is registered on the service account, the KDC cannot identify the peer. The same applies when the destination is specified as an IP address — by default Kerberos is not even attempted (Section 6.1).
• A ticket is “for that destination only”. It cannot be decrypted with another service’s long-term key, so it cannot be reused against a different destination.

4.3. The AP Exchange — Presenting to the Service, and Mutual Authentication

The client presents the service ticket and an authenticator to the service. The service decrypts the ticket with its own long-term key and extracts the session key and authorisation information inside. The fact that it decrypted at all is proof that “this ticket is addressed to me”.³

If the client requested mutual authentication, the service encrypts the timestamp it received with the session key and returns it. By verifying that, the client can confirm that the peer is the genuine service.³ There is no such step in NTLM.

5. The Decisive Differences

The bottom two rows of this table are, directly, “the reasons authentication falls back to NTLM”. Kerberos’s strengths (binding the destination, verifying the peer) rest on names being resolvable correctly.

6. Why Authentication “Falls Back” to NTLM

Even when an application does not specify NTLM directly, NTLM gets used — because that is how Negotiate behaves. As Microsoft explains, Negotiate selects either Kerberos or NTLM, and selects Kerberos unless one of the systems involved in the authentication cannot use it.¹

In other words, “it became NTLM” is, in most cases, another way of saying “Kerberos could not be used”.

flowchart TD
    START["Authentication starts with Negotiate"]
    Q1{"A domain<br/>account?"}
    Q2{"Can an SPN be built<br/>from the destination name?"}
    Q3{"Is that SPN<br/>registered?"}
    Q4{"Can we reach<br/>the KDC?"}
    KRB["Authenticate with Kerberos"]
    NTLM["Fall back to NTLM"]

    START --> Q1
    Q1 -->|"No<br/>(workgroup / local account)"| NTLM
    Q1 -->|Yes| Q2
    Q2 -->|"No<br/>(hard-coded IP address)"| NTLM
    Q2 -->|Yes| Q3
    Q3 -->|"No<br/>(SPN not registered / access via alias)"| NTLM
    Q3 -->|Yes| Q4
    Q4 -->|"No<br/>(site / VPN / firewall)"| NTLM
    Q4 -->|Yes| KRB

Figure 3: The branches by which Negotiate falls back to NTLM

6.1. You’re Connecting by IP Address

This is the most common cause. Microsoft states explicitly that by default, when the host name is an IP address, Windows does not attempt Kerberos authentication against that host and falls back to another valid authentication protocol such as NTLM.¹¹ The audit guidance says the same from its side: Kerberos is not used if the “Target Server” in event 8001 is in neither NetBIOS nor FQDN form.⁵

And the reasons this happens are listed too: applications that use IP addresses rather than DNS names because of a misconfiguration or the vendor’s documentation.⁵ In practice we very often see settings rewritten to an IP in the past “because name resolution was flaky” and never reverted.

That said, this is the default behaviour, not an absolute constraint. From Windows 10 version 1507 and Windows Server 2016 onwards there is a mechanism for using IP addresses as SPN host names. Set the client-side registry value TryIPSPN to 1 and manually register an SPN for the IP address in the form Setspn -s <service class>/<IP address> <account>, and Kerberos will work even against an IP address. What you register is the service class the client actually requests: things that map to HOST, such as shared folders, are covered by host/192.168.1.1, but the web needs HTTP/192.168.1.1 and SQL Server needs a different SPN including the port, such as MSSQLSvc/192.168.1.1:1433. Registering only host/ will not match the requested SPN, and Kerberos will not work. Microsoft positions this feature precisely as a means of reducing the impact of disabling NTLM.¹¹

Even so, it is not the first choice. Microsoft itself says IP addresses are transient and can cause conflicts and authentication failures as leases expire and renew, so they should not normally be used in place of host names, and that IP-address-based SPN registration is manual work to be used only when switching to a DNS-based host name is impossible.¹¹ For hard-coded IP addresses found in an audit, think first about changing them to FQDNs. TryIPSPN is the last resort for peers where that is genuinely impossible.

6.2. No SPN Is Registered

This is the second most common cause. Microsoft lists applications whose SPN is not correctly configured as a category of application that uses NTLM even though it supports Kerberos.⁵

As we saw in the TGS exchange in Figure 2, the KDC looks up the service account from the SPN and encrypts the ticket with it. With no SPN, the KDC cannot identify “that service’s key”. The same thing happens when access uses a DNS alias (CNAME) or a custom host name and no SPN is registered for that name. The application is working perfectly well; only the name is missing from the register.

6.3. You’re Outside Active Directory to Begin With

Machines in a workgroup configuration, and share access with local accounts, are not on the Kerberos playing field at all. Microsoft states that NTLM is, and must be, used for Windows authentication on systems configured as members of a workgroup and for local logon authentication on non-domain controllers.⁹

That is why NTLM cannot simply be banned. The local KDC planned for phase 2 is precisely the feature intended to fill this hole.⁶ But assume that it only fills it between supporting Windows systems. Local-account authentication where the peer is an older Windows machine, or a third-party device such as a NAS or an MFP, will not automatically become Kerberos when the local KDC arrives. This sorting is handled in Sections 5 and 6 of the practical companion article.

6.4. You Can’t Reach the KDC

Fallback also happens for routing reasons — a branch office or VPN link that cannot reach a domain controller, or a firewall blocking the ports Kerberos needs.⁶ Without being able to talk to the KDC there is no way to obtain a ticket, so Negotiate picks the remaining option, NTLM.

6.5. Don’t Confuse “Kerberos Failed” With “It Fell Back to NTLM”

Finally, let’s separate out something confusingly similar but quite different. Sections 6.1 to 6.4 are all cases where Kerberos could not be started. Because it cannot be started, Negotiate chooses NTLM.

The case where Kerberos was chosen and then failed is a different story. The classic example is clock skew. If the SPN resolves and the KDC is reachable, Negotiate will pick Kerberos first. If the clock is then off by more than the tolerance (five minutes by default), pre-authentication does not pass and it fails as a Kerberos error.¹⁰ The fact that the chosen protocol failed does not mean Negotiate automatically switches to NTLM and retries (except where the application explicitly retries with a different method).

The practical implication is simple. You will not find a clock-skew failure by hunting for event 8001. The symptoms differ too.

Decide first whether “it fell back to NTLM” or “Kerberos is broken”, and investigate accordingly.

7. The Difference From an Attacker’s View — Relay and Pass-the-Hash

In its policy setting documentation, Microsoft states explicitly that NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks.⁷ Why that is so can be explained from Figure 1.

7.1. Relay Attacks — The Consequence of Not Binding the Destination

sequenceDiagram
    autonumber
    participant V as Victim's PC
    participant A as Attacker's server
    participant T as Real server

    Note over V,A: The victim is lured to the attacker's server
    V->>A: Starts authentication (user name)
    A->>T: Starts authentication as the same user
    T-->>A: Challenge
    A-->>V: Forwards that challenge unchanged
    Note over V: Cannot tell whether it came<br/>from the real server
    V->>A: Response (computed with the hash-derived key)
    A->>T: Forwards that response unchanged
    Note over T: If it requires neither signing<br/>nor channel binding
    T-->>A: Authentication succeeds → session established as the victim

Figure 4: How an NTLM relay succeeds (against a peer with no signing or channel binding)

The attacker needs to know neither the password nor the hash. They simply pass the challenge and response from one side to the other. This works because the client has no way to check whether the response is really going to the intended peer.

That said, relaying does not get through to just anyone. Whether a relayed exchange turns into a usable session depends on the destination’s defences.

• It does not get through to a peer that requires SMB signing. Microsoft states explicitly that the signature attached to every SMB message includes a hash of the whole message and confirms the identity of the sender and the receiver, thereby preventing relay attacks.¹² Note that domain controllers require SMB signing from connecting clients by default.¹²
• Nor does it get through to a service enforcing Extended Protection for Authentication (channel binding). Because authentication is bound to the underlying TLS channel, authentication relayed onto a different channel does not pass.

So what Figure 4 depicts is the path to success under the condition of a peer that accepts NTLM with neither signing nor channel binding. Turned around, that means there is something you can do right now in the field: it is worth checking the state of SMB signing requirements in parallel with the NTLM inventory.

With Kerberos, the same shape of relay is not possible in the first place. A service ticket is encrypted with the destination service’s long-term key, so it cannot be decrypted if taken to a different service.³ On top of that, the client can confirm whether the peer is genuine through mutual authentication.⁴

Microsoft’s reason for providing NTLM blocking on the SMB client is exactly this: the stated purpose is preventing techniques that get NTLM requests sent to malicious servers.¹³ On SMB signing, Microsoft also recommends using Kerberos rather than NTLMv2 so that the session key starts out strong, and not connecting to shares by IP address or CNAME record (because doing so causes NTLM to be used instead of Kerberos).¹² That is the same story as Sections 6.1 and 6.2.

7.2. Pass-the-Hash — The Hash Is Equivalent to the Password

flowchart LR
    P["Password"] -->|"one-way hash"| H["Password hash"]
    H -->|"derive response key<br/>and compute HMAC"| R["Response"]
    R --> AUTH["Authentication succeeds"]
    STEAL["Steal the hash<br/>from a machine"] --> H
    NOTE["The plaintext password<br/>is not needed"] -.-> STEAL

Figure 5: What authentication needs is the hash, not the plaintext password

NTLM credentials are a one-way hash of the password.¹ In NTLMv2, that MD4(UNICODE(password)) is used as the key to derive the response key, and that key is then used to compute an HMAC to build the response.² The shape of the computation has changed, but the starting point is still the hash. That is, what authentication needs is the hash, not the plaintext password.

This has serious operational implications. Making passwords longer and more complex does not close the route by which the hash is stolen. Microsoft lists Pass-the-Hash alongside brute force and cracking as attacks that SMB NTLM blocking counters.¹³

Kerberos has long-term keys too, but what flies around during everyday authentication is time-limited tickets and session keys.³ The blast radius when they are stolen is different.

8. NTLMv1, NTLMv2, and “Removal”

NTLM is not a single protocol but a family of authentication protocols including LAN Manager versions 1 and 2 and NTLM versions 1 and 2.⁹

Their current status divides as follows.

So it is not “we’re on NTLMv2, so we can leave it for now”. The priority is clear, however: devices and hosts that can only speak NTLMv1 come first. Hosts recorded with NTLM V1 in an audit will fail authentication if you upgrade them as-is to a newer Windows. How to tell the versions apart (looking at “Package Name (NTLM only)” in the Security log) is covered in Section 4.4 of the practical companion article.⁵

Note that the audit and block policies for restricting NTLM have the same effect on both NTLMv1 and NTLMv2.⁵ Behaviour does not vary by version when you apply restrictions.

9. What Happens Next

Microsoft has indicated three directions.

First, use Negotiate on the application side. The instruction to replace calls to NTLM with calls to Negotiate is part of the deprecation notice itself.⁸ It is also stated explicitly that applications should not access the NTLM security package directly.¹

Second, reduce the situations that require NTLM in the first place. IAKerb and the local KDC, planned for phase 2 (second half of 2026), are this.⁶ They are an attempt to fill, at the protocol level, the two holes seen in Section 6.3 — “Kerberos is unavailable because it’s a local account” and “Kerberos is unavailable because the domain controller is unreachable”. But there is a limit to what gets filled. What IAKerb solves is reachability to a domain controller, not whether the peer supports anything. The local KDC likewise only works between supporting Windows systems. If the peer is a third-party NAS or MFP, waiting for phase 2 will change nothing, so you have to choose for yourself between replacing the device, joining the domain, switching to another protocol, or managing an exception.

Third, change the defaults. In phase 3, network NTLM authentication is planned to be disabled by default in the next major release.⁶ It is also stated, though, that it can be re-enabled by policy.

There is a reason for this order. Because it is “remove the reasons to use it, then change the default”, sorting the NTLM dependencies you have left into those you can expect phase 2 to solve (local-account authentication between supporting Windows systems, DC reachability) and those you must fix yourself (hard-coded IP addresses, unregistered SPNs, and local-account authentication where the peer is an older Windows machine or a third-party device) saves you from wasted work. Classify that last group as “waiting for phase 2” and it will surface as an outage when disabling by default arrives. The concrete sorting procedure is set out in the practical companion article.

10. Summary

• NTLM is a protocol that proves “you hold the password hash” via challenge/response. The decision is delegated to a domain controller for domain accounts, and made by the server itself from its own SAM for local accounts.¹⁹
• Kerberos proves “who, to which service”. A service ticket is encrypted with the destination service’s long-term key, so it cannot be reused against a different destination.³
• The decisive differences are mutual authentication, the per-authentication DC query, and whether delegation is possible.⁴
• Falling back to NTLM almost always means Kerberos could not be started. The four main causes are hard-coded IP addresses, unregistered SPNs, being outside Active Directory, and not reaching the KDC.⁵⁶¹¹
• By contrast, problems where Kerberos was chosen and then failed — clock skew, for instance — appear as authentication errors, not as a fallback to NTLM. Hunting for event 8001 will not find them.¹⁰
• Relay attacks work because an NTLM response does not bind the destination. Pass-the-Hash works because what authentication needs is the hash itself.⁷¹¹³
• NTLMv1 has already been removed (Windows 11 24H2 / Windows Server 2025), and all versions including NTLMv2 are deprecated.⁸
• What applications should write is Negotiate. On top of that, standardising destination names on FQDNs and registering SPNs is the practical substance of making Kerberos work.¹⁵

Related Articles

• Will NTLM Deprecation Stop Your Business Apps? — How to Collect Audit Logs, and the Order in Which to Kill Dependencies
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• A Guide to Windows Time Synchronisation (w32time)
• Investigating Event Logs Practically with Get-WinEvent — Filtering Speed Determines Investigation Time
• Handling Credentials Safely in PowerShell — Banishing Plaintext Passwords From Your Scripts
• What Is the TPM in Windows? — An Illustrated Guide to the “Safe That Never Lets Keys Out” and Measured Boot
• Information Security 10 Major Threats 2026 — How to Read the Ranking, and What SMEs Should Actually Guard Against

Related Consulting Areas

KomuraSoft LLC handles modification of Windows business applications arising from a review of authentication methods, and root-cause investigation of authentication problems around Kerberos and NTLM.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Legacy Asset Reuse & Migration Support
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What's the actual difference between NTLM and Kerberos?

The biggest difference is whether you can verify who you're talking to. Microsoft states explicitly that with NTLM a client cannot verify a server's identity, nor can one server verify another server's identity. NTLM was designed for environments where servers can be assumed genuine; Kerberos makes no such assumption. The second difference is whether the server has to query a domain controller. With NTLM, when authenticating a domain account, the application server connects to a domain controller every time it authenticates a client (for an account local to the server, the server consults its own account database and decides for itself, and no domain controller appears at all). With Kerberos, renewable session tickets replace this pass-through authentication, so the server does not go to a domain controller except when PAC validation is required. The third is that Kerberos supports delegation by services — a mechanism for connecting to another service on the client's behalf.

Why do we end up on NTLM when the application supposedly supports Kerberos?

Kerberos issues tickets keyed on "the name of the destination", so it cannot work if the name cannot be resolved. The client presents the destination's SPN (service principal name) to the KDC to request a service ticket, but by default Windows does not attempt Kerberos authentication when the host name is an IP address, and if no SPN is registered on the service account the KDC cannot issue a ticket. Microsoft's audit guidance likewise says that Kerberos is not used if the "Target Server" in event 8001 is in neither NetBIOS nor FQDN form. (For IP addresses, you can make Kerberos work as an exception by setting TryIPSPN on the client and manually registering an SPN for the IP address, but this is described as a last resort for cases where a DNS name is impossible.) Other conditions under which Kerberos cannot work are authentication on workgroup machines or with local accounts (outside Active Directory altogether), sites that cannot reach a domain controller, and authentication to a peer with no trust relationship. Negotiate chooses NTLM when Kerberos is unavailable, which is what "falling back" means in these cases.

What is an NTLM relay attack, and why does it work?

The attacker lures a victim to a server of their own and relays the NTLM authentication exchange that arrives there straight through to the real server, impersonating the victim. It works because NTLM's challenge/response has no mechanism binding "who you are authenticating to". The client simply computes a response from the challenge the server issued and returns it, with no way to check whether that response is destined for the real server or is being relayed by an attacker. Microsoft itself states in its policy setting documentation that NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks. That said, relaying does not get through to just anyone. If the destination requires SMB signing, the signature confirms the identity of the sender and receiver, so the relay fails; the same is true of services that enforce Extended Protection for Authentication (channel binding). Conversely, the targets are peers that accept NTLM with neither signing nor channel binding in place. With Kerberos, a service ticket is encrypted with that service's long-term key, so a ticket destined for one service cannot be decrypted by another.

Does Pass-the-Hash mean you can impersonate someone without cracking their password?

Exactly. NTLM credentials consist of a one-way hash of the domain name, user name, and password. In NTLMv2, which is what today's Windows uses, the response key is derived as an HMAC keyed on the MD4 hash of the password (the NT hash), and that key is then used to compute an HMAC over a bundle of the server challenge, a timestamp, a client-side challenge, and target information. It is not simply encrypting the challenge, but the starting point is still the password hash. In other words, what authentication needs is the hash, not the plaintext password. So an attacker who can extract the hash from, say, a machine's memory can authenticate as that user without cracking the password. Making passwords longer and more complex does not close this route. One of Microsoft's stated reasons for providing NTLM blocking on the SMB client is countering Pass-the-Hash attacks.

If we're using NTLMv2, aren't we safe for the time being?

NTLMv2 is stronger than NTLMv1, but it is not excluded from deprecation. Microsoft's list of deprecated features says that all versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are outside active feature development and deprecated. The restriction policies behave the same way: the audit and block policies are described as having the same effect on both versions. NTLMv1 is treated differently, however: it has moved past deprecation into removal, and has been removed from Windows 11 version 24H2 and Windows Server 2025. So the framing is not "we're on NTLMv2, so we can leave it" but "NTLMv1 is a deadline right now; NTLMv2 needs an inventory in preparation for being disabled by default".

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.