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

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

“Falling back to NTLM” here does not mean that authentication stops with an error; it means switching to NTLM because Kerberos cannot be used. A business system can be running perfectly well and still not be using the authentication method you expect.

This article first compares, with diagrams, what NTLM and Kerberos use as their material and whose identity each one verifies. Once that difference is clear, the same mechanism explains both why authentication switches to NTLM depending on the destination name or the kind of account, and why relay attacks and Pass-the-Hash work.

The order of reading is how the mechanisms differ → the conditions that cause the switch → decisions about defense and migration. If your goal is troubleshooting, first separate “it is running on NTLM” from “authentication itself has stopped”, then use the guide by goal in Section 1 to move on to Section 6.

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?”.

1. The Bottom Line First

There are three things to grasp first: the material each protocol authenticates with, the conditions that switch authentication to NTLM, and the policy for security and migration.

Grasp How the Mechanisms Differ

NTLM builds a response from a hash; Kerberos uses a ticket that names the destination. NTLM credentials are a one-way hash of the domain name, user name, and password.¹ In NTLMv2, a key derived from that hash is used to compute an HMAC over the server challenge, a timestamp, a client-side challenge, and target information (Section 2.2).²

Kerberos, by contrast, issues a service ticket based on the SPN, the service name of the destination, and so establishes “who, to which service”.³ Three differences follow from this: mutual authentication, the query to a DC during domain-account authentication, and delegation to other services (Section 5).⁴

Separate a Fallback From an Authentication Error

“It runs on NTLM” and “it stops with a Kerberos error” start from different places in an investigation. The main causes of switching to NTLM are hard-coded IP addresses, unregistered SPNs, workgroups, and routes that cannot reach a DC. Whether an SPN can be resolved from the destination name matters most of all (Section 6).⁵⁶

Problems that arise after Kerberos has been selected, such as a clock skew, are a different matter: authentication itself stops. Do not assume that a failure is always retried with NTLM (Section 6.5).⁷

Grasp the Security and Migration Policy

Even with NTLMv2, relay attacks and Pass-the-Hash remain. Relaying comes from the authentication exchange not binding a destination; Pass-the-Hash comes from the hash itself being the material for authentication. Section 7 covers the conditions under which each of them works, including whether the destination requires SMB signing or channel binding.⁸¹

NTLMv1 has already been removed in Windows 11 version 24H2 and Windows Server 2025. NTLMv2 still works, but it is deprecated (Section 8).⁹ Applications should not name NTLM directly: they should use Negotiate, which prefers Kerberos, and then the names, SPNs, and network routes that let Kerberos work should be put in order.¹

Read by Goal or Symptom

This article explains the mechanisms and the decisions. For the procedures for configuring auditing and carrying out an inventory, go on to the practical companion article introduced at the top.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (35 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. What NTLM Actually Does

This section starts by separating the party that builds the response from the party that verifies it. After looking at the three-party exchange for a domain account, we examine what NTLMv2 actually computes and how a local account differs.

NTLM (Windows Challenge/Response) is, as the name says, a challenge/response authentication protocol. Summarizing 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

Consider a user who is already logged on accessing a resource on a server with a domain account. This is non-interactive authentication, and the following three parties are involved.¹

The key point is that the resource server does not verify a domain user’s response by itself: it asks the DC to do the computation.

Figure 1 and the seven steps below it are the conceptual procedure shown on Microsoft’s overview page. The exact response computation of NTLMv2 is covered in Section 2.2. Read Figure 1 for “who asks whom to verify” and Figure 2 for “how it is computed”, and the two will not get mixed up.¹

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

    Note over C: At logon, computes the hash of the<br/>password 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: Authentication succeeds if they match
    S-->>C: Grants access

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

Followed as a procedure, Figure 1 becomes these seven steps. The response computation of NTLMv2 itself is restated in Section 2.2 below.

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 to the client, and the response it received.
6. The domain controller uses the user name to retrieve the password hash from the SAM database and encrypts the challenge with it.
7. It compares the result it computed with the client’s response; if they are identical, authentication succeeds.

2.2. The Actual Computation — NTLMv2 Is Somewhat More Involved

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

Derive a Response Key, Then Compute an HMAC Over the Challenge and More

• The response key is NTOWFv2 = HMAC_MD5( MD4(UNICODE(password)), uppercased user name + domain name )
• The client builds temp, a concatenation of 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 )

Reduced to just the inputs and the flow of processing, it fits on a single page.

flowchart TD
    PW["Password"] --> MD4["MD4(UNICODE(password))<br/>= NT hash"]
    UD["Uppercased user name<br/>+ domain name"] --> H1["HMAC_MD5"]
    MD4 -->|"used as the key"| H1
    H1 --> KEY["Response key NTOWFv2"]

    MAT["Response version / timestamp /<br/>8-byte client-side challenge /<br/>target information (AV pairs)"] --> TEMP["temp"]

    SC["Server challenge"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"used as the key"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

Figure 2: How an NTLMv2 response is produced (password → NT hash → response key → HMAC)

So what is actually computed is an HMAC that mixes in not only the server challenge but also a client-side random number, a timestamp, and target information. The verifying side reproduces the same computation. If the account lives 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 from the OWF it stores itself.²

Two Things That Do Not Change, However Complex the Computation Gets

What matters for the argument of this article is that the following two things do not change with the added complexity.

1. The material for the key is still the password hash. The starting point of NTOWFv2 is MD4(UNICODE(password)), which is 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 as well.⁴

Everything that follows rests on these two points.

2.3. With a Local Account, Two Parties Are Enough

With a local account, the right-hand side of Figure 1 — the domain controller — disappears.

A resource server queries the authentication service on a domain controller in that domain when the account is a domain account, but it consults the local account database when the account is local.¹⁰

So on a workgroup machine, or when a share is accessed 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 difference feeds directly into the inventory of “Kerberos cannot be used because this is a local account” dependencies covered in Section 6.3. NTLM taking this route does not show up in a domain controller’s audit logs.

2.4. Three Consequences of This Design

Three properties that lead to later failures and attacks can be drawn out of the exchange so far.

The query in the second row is needed every time the resource server requires a new access token. For a domain account it checks the authentication service on a DC; for a local account it checks the local account database.¹⁰

Also, because the challenge changes every time, the same response cannot simply be reused. But that alone does not prevent relaying the challenge and response of a live exchange to another server. Section 7 looks at this difference.

3. Why the Server Asks a Domain Controller

NTLM Asks Whoever Holds the Hash to Verify

The password hash of a domain user lives in the account database on the DC. The resource server does not know that user’s hash, so it cannot verify the response it received on its own.

Pass-through authentication is therefore handing the user name, the challenge, and the response to the DC and asking it to decide. This division of labor is why NTLM authentication with a domain account requires a query to a DC.¹⁰¹

For a local account, the hash is checked against the server’s own SAM. The statement “NTLM asks the DC” applies only to domain accounts.

Kerberos Replaces the Query With a Ticket

Kerberos replaces this pass-through authentication with renewable session tickets. Microsoft explains that with NTLM an application server had to connect to a DC every time it authenticated, whereas with Kerberos that query becomes unnecessary.⁴

There is an exception, though: when validation of the PAC (privilege attribute certificate) is required. It does not mean that with Kerberos there is no traffic at all from the server to a DC.

Migrating to Kerberos therefore has an operational benefit — reducing the dependency on a DC for every authentication — on top of the security improvement of being able to verify the peer. The next section looks at how a ticket fills that role.

4. What Kerberos Actually Does

Where NTLM has a response verified on every authentication, Kerberos proves identity up front, receives a ticket, and uses that ticket for the next authentication. Figure 3 shows the whole flow from the initial proof of identity through to connecting to a service.

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

Before Reading the Diagram, Separate Names From Tickets

Figure 3 has three stages: prove identity and obtain a TGT → specify an SPN and obtain a service ticket → present it to the service. The key is not to read the TGT and the service ticket as the same thing.

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

    Note over C,KDC: AS exchange — proving identity and obtaining a TGT
    C->>KDC: KRB_AS_REQ<br/>(user name + timestamp encrypted with the long-term key)
    Note over KDC: Genuine if it decrypts with the long-term key
    KDC-->>C: KRB_AS_REP<br/>TGT (encrypted with the krbtgt key) + session key

    Note over C,KDC: TGS exchange — obtaining 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 — presenting to the service
    C->>S: KRB_AP_REQ<br/>(service ticket + authenticator)
    Note over S: Decryptable with its own long-term key<br/>= the ticket is addressed to it
    S-->>C: KRB_AP_REP (when mutual authentication was requested)

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

Legend — AS = Authentication Service, TGS = Ticket Granting Service, AP = Application. In the message names, _REQ is a request and _REP is a reply. For example, KRB_TGS_REQ means “a request to the Ticket Granting Service”.

4.1. The AS Exchange — Proving Identity Once

What Is Sent: A Timestamp Encrypted With the Long-Term Key

The client sends the KDC its user name and domain name together with 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 that this is the genuine user.³

What Is Received: A TGT and a Session Key

The KDC returns two things with different roles. Both are “things the client receives”, but they differ in whether the client can read what is inside.³

Holding a TGT and being able to read what is inside it are two different things. That distinction leads to the next step, “make the request accompanied by the TGT and an authenticator”.

If Clocks Drift, Kerberos Itself Fails

The point to grasp here is that the timestamp is part of the authentication. That is why Kerberos is strict about clock synchronization: the tolerated time difference is five minutes by default.⁷ Outside that window pre-authentication does not pass, and Kerberos authentication itself fails with an error (time synchronization on Windows is covered in “Windows Time Synchronization (w32time) Guide”). This “Kerberos fails” and “falls back to NTLM” are two different things. Section 6.5 covers the distinction.

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

Once the client has a TGT, it requests a ticket for the destination service. Only at this point does the name that says which service you are connecting to, the SPN, take center stage.³

The client sends the KDC the destination SPN, the TGT, and an authenticator. The KDC finds the service account that corresponds to the SPN, encrypts a service ticket with that account’s long-term key, and returns it.³

Read this flow backwards and the problems covered in Section 6 come into view.

• If the SPN cannot be resolved, no ticket can be issued. If no SPN is registered on the service account, the KDC cannot determine whose key to use. Connecting by IP address is likewise a condition under which Kerberos is not attempted by default (Section 6.1).
• A ticket is made for its destination. Because it is encrypted with that service’s long-term key, a service holding a different long-term key cannot decrypt it. That is why a ticket cannot be reused against a different destination.

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

The last exchange is with the destination service rather than the KDC. Here too, read the service-side check and the client-side check separately.

On the Service Side: Opening a Ticket Addressed to It

The client presents the service ticket and an authenticator. The service decrypts the ticket with its own long-term key and extracts the session key and the authorization data. Being able to decrypt it with its own key is what confirms that the ticket is addressed to it.³

On the Client Side: Verifying the Peer When Mutual Authentication Was Requested

If the client requested mutual authentication, the service encrypts the timestamp it received with the session key and returns it. The client verifies that reply and confirms that the peer is the genuine service.³

Not only does the service verify the client, the client can also verify the service. This is the mutual authentication that NTLM lacks.

5. The Decisive Differences

This section compares the mechanisms of Sections 2 to 4 from the angles that matter in operations and design. The query to a DC differs between domain and local accounts, and Kerberos has an exception of its own in PAC validation. Read the conditions along with the rows.

A Design That Uses Delegation Has a Further Choice of Flavor

Delegation is the mechanism by which, for example, a front-end web application connects to a back-end SQL Server on the user’s behalf. Impersonating the user inside one server and carrying the user’s identity onward to another service are two separate things.⁴

Kerberos delegation comes in unconstrained delegation, constrained delegation, and resource-based constrained delegation (RBCD). Deciding to “use Kerberos” is not the end of it; which flavor of delegation to use is a design question in its own right.

This article does not go into the configuration of each flavor. Keep these three names as your next search terms when investigating a configuration that needs delegation.

The Name and Domain Conditions Lead Into the Next Investigation

The bottom two rows of this table are exactly the reasons authentication falls back to NTLM. The strengths of Kerberos — binding to a destination and verifying the peer — rest on names resolving correctly.

6. Why Authentication “Falls Back” to NTLM

This section investigates why “the business system is running, but authentication is on NTLM”. Check the destination name, the SPN registration, the account, and the route to the KDC, in that order. If authentication itself fails with an error, check Section 6.5 first to see whether a different line of investigation is needed.

NTLM gets used even when the application does not name NTLM directly, because that is how Negotiate behaves. Microsoft describes Negotiate as selecting either Kerberos or NTLM, and selecting Kerberos unless one of the systems involved in the authentication cannot use it.¹

So even when Negotiate is in use, NTLM is chosen if the conditions for Kerberos are not all met. An application supporting Kerberos and Kerberos actually being used on a given connection are two different things.

The diagram and table below show the typical branches in a configuration where NTLM is available. They do not mean that authentication always succeeds where NTLM itself is restricted. Investigate the reason for the switch first, then check restrictions on authentication methods together with Sections 8 and 9.

flowchart TD
    START["Authentication starts with Negotiate"]
    Q1{"A domain<br/>account?"}
    Q2{"Can an SPN be built from<br/>the destination name?"}
    Q3{"Is that SPN<br/>registered?"}
    Q4{"Is the KDC<br/>reachable?"}
    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 / accessed by an alias)"| NTLM
    Q3 -->|Yes| Q4
    Q4 -->|"No<br/>(branch site / VPN / firewall)"| NTLM
    Q4 -->|Yes| KRB

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

The four main factors are set out first in three columns: the condition, why it causes a fallback, and how to fix it. The details follow from Section 6.1 onward.

6.1. The Connection Uses an IP Address

The Default Behavior: Kerberos Is Not Attempted for an 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.⁵

The reason this happens is listed as well: applications that use an IP address rather than a DNS name because of a misconfiguration or vendor documentation.⁵ In practice it is extremely common to find a setting that someone rewrote to an IP address years ago “because name resolution was unreliable” and that has stayed that way ever since.

The Exception: Set TryIPSPN and the SPN That Is Actually Requested

Not attempting Kerberos for an IP address is the default behavior, not an absolute constraint. From Windows 10 version 1507 and Windows Server 2016 onward, there is a mechanism that allows an IP address as the host name in an SPN.¹¹

Both of the following are required.

1. Set the registry value TryIPSPN to 1 on the client.
2. Manually register an SPN that uses the IP address, in the form Setspn -s <service class>/<IP address> <account>.

The SPN you register must match the service class the client actually requests. Even for the same destination IP address, the name required differs from service to service.

Registering only host/ will not make Kerberos work if it does not match the SPN that is requested. Microsoft positions this feature as a way to reduce the compatibility impact of disabling NTLM.¹¹

Fix It to an FQDN First, and Keep the Exception as a Last Resort

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

6.2. No SPN Is Registered

The next thing to look at is whether the name actually used for access is registered as an SPN. Microsoft lists applications whose SPN is not configured correctly as one category of application that uses NTLM despite supporting Kerberos.⁵

In the TGS exchange in Figure 3, the KDC looks up the service account from the SPN and encrypts the ticket with its long-term key. Without an SPN, “that service’s key” cannot be identified.

The same thing happens when the connection uses a DNS alias (CNAME) or a custom host name and no SPN is registered for that name. Being able to reach the server by a name and being able to obtain a Kerberos ticket for that name are two different things.

What to check is the name written in the application’s connection setting, and the SPN for the service class requested against that name. The application can be working perfectly while only the name it uses is missing from the register.

6.3. You Are Outside Active Directory to Begin With

Find the Routes That Genuinely Need NTLM Today

Machines in a workgroup configuration, and share access with a local account, are not on Kerberos’ playing field at all. Microsoft says that NTLM is used, and must be used, for Windows authentication on systems configured as members of a workgroup and for local logon authentication on machines other than domain controllers.¹⁰

Separate What the Local KDC Will Cover From What It Will Not

This is why NTLM cannot simply be banned. The local KDC planned for phase 2 is precisely the feature meant to fill this gap.⁶

Assume, though, that it fills the gap only between Windows versions that support it. Local-account authentication against older Windows, or against third-party devices such as NAS boxes and multifunction printers, will not automatically become Kerberos when the local KDC arrives. Sections 5 and 6 of the practical companion article cover this sorting.

6.4. The KDC Cannot Be Reached

A branch site or VPN from which the DC cannot be reached, or a firewall that blocks the traffic Kerberos needs, is also a cause of switching to NTLM.⁶ That is because where the required ticket cannot be obtained from the KDC, the groundwork for using Kerberos cannot be laid.

Here, break “can the DC be reached” down by who originates the traffic.

“The client cannot reach the KDC” and “NTLM does not need a DC” are not the same statement. As Section 3 showed, NTLM with a domain account requires a query from the server to a DC.¹⁰ Even when NTLM is chosen, authentication cannot complete if that verification route has been lost as well.

6.5. Do Not Confuse a Kerberos Failure With a Fallback to NTLM

Kerberos Never Starting Versus Kerberos Failing After It Was Chosen

Finally, let us separate out something easy to confuse but genuinely different. Sections 6.1 to 6.4 are all cases where Kerberos could not be started. Because it cannot be started, Negotiate chooses NTLM.

Problems where Kerberos fails after being chosen are investigated separately. The classic example is the clock skew mentioned in Section 4.1.

If the SPN resolves and the KDC is reachable, Negotiate chooses Kerberos first. But if the time difference exceeds the tolerance, five minutes by default, pre-authentication does not pass and it fails as a Kerberos error.⁷

“Choosing NTLM because Kerberos is unavailable” and “retrying with NTLM because the chosen Kerberos failed” are not the same. Negotiate does not necessarily go as far as the latter, and a case where the application explicitly retries with another method has to be considered separately.

Separate the Symptoms Before Choosing Logs and Commands

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

Separate “has it fallen back to NTLM” from “is Kerberos broken” before you investigate. The “it works, but on NTLM” symptom described here assumes a configuration in which NTLM is available. Restrictions on NTLM and blocking of NTLM are checked separately, in Section 8 and Section 9.

7. The Difference Seen From the Attack Side — Relay and Pass-the-Hash

Relay and Pass-the-Hash are both discussed as NTLM problems, but what each one uses is different.

Section 7.1 looks first at the conditions under which relaying gets through, then Section 7.2 at the problem that arises when a hash is stolen.

Microsoft states explicitly 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.⁸ Figure 1 explains why.

7.1. Relay Attacks — The Consequence of Not Binding a 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 a key derived from the hash)
    A->>T: Forwards that response unchanged
    Note over T: When neither signing nor channel<br/>binding is required
    T-->>A: Authentication succeeds → connection established as the victim

Figure 5: How an NTLM relay works (against a peer with neither signing nor channel binding)

A Relay Works Without Stealing a Password or a Hash

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

Whether It Works Depends on the Destination’s Defenses

Relaying does not get through to just any peer, though. Whether a relayed exchange turns into a usable session depends on the destination’s defenses.

• It does not get through to a peer that requires SMB signing. Microsoft states that the signature attached to every SMB message contains a hash of the whole message and confirms the identities of the sender and the receiver, which prevents relay attacks.¹² Note that domain controllers require SMB signing by default from anything that connects to them.¹²
• Nor does it get through to a service that enforces Extended Protection for Authentication (channel binding). Because that binds the authentication to the TLS channel underneath, authentication relayed onto a different channel no longer passes.

Figure 5 assumes a peer that accepts NTLM and requires neither signing nor channel binding. Do not read it as meaning that this relay gets through unconditionally on every connection that uses NTLM.

What to check here is not just whether the defensive features are “supported” but whether they are actually required and enforced. Alongside the NTLM inventory, it is worth checking whether the configuration requires SMB signing.

Consider Migration to Kerberos Together With the SMB-Side Defenses

With Kerberos, a relay of the same shape is not possible in the first place. A service ticket is encrypted with the destination service’s long-term key, so carrying it to another service leaves it undecryptable.³ On top of that, mutual authentication lets the client check whether the peer is genuine.⁴

This is exactly why Microsoft provided NTLM blocking on the SMB client. Its stated purpose is to prevent techniques that get NTLM requests sent to a malicious server.¹³

Among its recommendations around SMB signing, Microsoft also lists 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 means NTLM is used instead of Kerberos.¹² This is the same point 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 the response key<br/>and compute an HMAC"| R["Response"]
    R --> AUTH["Authentication succeeds"]
    STEAL["Hash stolen<br/>from a machine"] --> H
    NOTE["The plaintext password<br/>is not needed"] -.-> STEAL

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

The Problem Is That a Response Can Be Built From the Hash

The material of NTLM credentials is a one-way hash of the password.¹ In NTLMv2 as well, the response key is derived using MD4(UNICODE(password)) as the key, and the response is built by computing an HMAC with that key.²

So the starting point does not change however complex the computation becomes. An attacker who obtains the hash can perform the computation needed to authenticate as that user without cracking the plaintext password.

Password Complexity Alone Does Not Close This Route

Making passwords long and complex is a different matter from stopping a stolen hash from being used. Complex passwords still leave open the route of stealing the hash and using it. Microsoft lists Pass-the-Hash, alongside brute force and cracking, among the attacks that NTLM blocking on SMB counters.¹³

Kerberos has long-term keys too. What is exchanged in day-to-day authentication, though, is tickets and session keys that expire.³ The comparison has to extend to how far what was stolen actually gets the attacker.

8. NTLMv1, NTLMv2, and “Removal”

NTLM is not a single protocol but a family of authentication protocols that includes LAN Manager versions 1 and 2 and NTLM versions 1 and 2.¹⁰

The distinction to draw here is between deprecation and removal. Deprecated means outside active feature development; removed means unusable in the versions concerned.

The table below places the June 2024 deprecation announcement alongside the subsequent removal of NTLMv1. Do not read the “still works” wording in the first row as meaning that NTLMv1 is usable on the operating systems in the second row. For NTLMv1, the later removal applies.⁹

Find the Peers That Can Only Do NTLMv1 First

So “we’re on NTLMv2, so we can leave it for now” does not hold. The priority order is clear, though: devices and hosts that can only speak NTLMv1 come first. A host recorded as NTLM V1 in an audit will stop authenticating once it is moved to a newer Windows as it stands. How to tell the versions apart, by looking at “Package Name (NTLM only)” in the Security log, is covered in Section 4.4 of the practical companion article.⁵

The Restriction Policies Apply to Both v1 and v2

Note that the audit and block policies that restrict NTLM have the same effect on both NTLMv1 and NTLMv2.⁵ Behavior does not change by version when you apply a restriction.

9. Where This Is Heading

The direction of the migration is easiest to grasp in this order: change what applications call → reduce the situations that need NTLM → change the default for network authentication.

The delivery timing of IAKerb and the local KDC below, and the change of default, are described as plans in the Microsoft roadmap cited here. They are not to be treated as shipped features, or as features that will automatically work on every device.⁶

First: Use Negotiate on the Application Side

Replacing calls to NTLM with calls to Negotiate is an instruction contained in the deprecation announcement itself.⁹ It is also stated explicitly that applications should not access the NTLM security package directly.¹

Second: Reduce the Situations That Need NTLM at All

IAKerb and the local KDC planned for phase 2 (the second half of 2026) fall under this.⁶ They are an attempt to fill, at the protocol level, the two gaps seen in Section 6.3: “Kerberos cannot be used because this is a local account” and “Kerberos cannot be used because the domain controller cannot be reached”.

What they fill is limited, though. What IAKerb solves is reachability of the domain controller, not whether the peer supports the protocol. The local KDC, too, works only between Windows versions that support it.

When the peer is a third-party NAS or multifunction printer, waiting for phase 2 changes nothing, so you have to choose for yourself between replacing the device, joining it to the domain, switching to a different protocol, and managing it as an exception.

Third: Change the Default for Network NTLM Authentication

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

What to Do Now: Sort Dependencies Into Those the New Features May Cover and Those You Must Fix Yourself

The plan follows the order “remove the reasons to use NTLM, then change the default”. Sorting your own dependencies the same way keeps what to wait for separate from what to fix first.

The important thing is not to sweep authentication with older Windows and third-party devices into a single “waiting for phase 2” bucket. It will not turn into Kerberos on its own, and left alone it will surface as a failure when the default is switched off.

The concrete procedure for inventorying and sorting is set out in the practical companion article.

10. Summary

Finally, here is a recap in the order of the decisions.

Mechanism: A Hash-Based Response, or a Ticket for a Destination

NTLM builds a response to a challenge from the password hash. What verifies it is a DC for a domain account, or the server’s own SAM for a local account.¹¹⁰

Kerberos uses a ticket encrypted with the destination service’s long-term key.³ Grasping the differences in mutual authentication, the DC query on every authentication, and delegation reveals the premises for choosing between the two methods.⁴

Triage: Is It Running on NTLM, or Has Authentication Stopped?

If authentication has switched to NTLM, check the four conditions: hard-coded IP addresses, unregistered SPNs, being outside Active Directory, and reachability of the KDC.⁵⁶¹¹

Problems that produce an authentication error after Kerberos was chosen, such as a clock skew, are a separate matter. Rather than chasing only event 8001 in NTLM/Operational, examine the Kerberos events and clock synchronization.⁷ The starting point of the investigation is not to conclude “it works, so it must be Kerberos” or “it stopped, so it must have fallen back to NTLM”.

Response: Check the Defenses, Then Move On to Negotiate and Names

Relay, which forwards an NTLM exchange, and Pass-the-Hash, which uses a stolen hash, differ both in why they work and in what they need.⁸¹¹³ Check the defensive conditions at each destination while reducing the NTLM dependency itself.

NTLMv1 has been removed in Windows 11 24H2 and Windows Server 2025, and all versions including NTLMv2 are deprecated.⁹ In applications, use Negotiate, standardize destinations on FQDNs, and register SPNs.¹⁵ Then carry the migration forward with the dependencies the new features may cover kept separate from the dependencies you have to fix yourself.

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
• Windows Time Synchronization (w32time) Guide
• Investigating Event Logs in Practice with Get-WinEvent — Filtering Speed Decides How Long the Investigation Takes
• 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.