Kerberos vs NTLM: which Windows protocol is your app using?

Kerberos is the preferred protocol in Active Directory: clients get tickets from a domain controller and servers verify them without a round trip. NTLM is a challenge response protocol that still appears with workgroups, local logons and some applications. If your app falls back to NTLM, find out why.

How Kerberos works in plain words

Kerberos involves three parties: the client, the service it wants, and the Key Distribution Center (KDC), which both trust. In Windows, the KDC runs on every domain controller and uses the Active Directory database as its account store.

When a user signs in, the client proves its identity to the KDC and receives a ticket-granting ticket (TGT). The TGT lets the client ask for access to services without presenting the password again. To reach a specific service, the client presents the TGT and gets a service ticket for that service. It hands that ticket to the service, which can verify the client without calling a domain controller on every connection.

How NTLM works

NTLM is a family of protocols built on challenge response. The server issues a challenge, and the client proves it knows the password for the account without sending the password itself. Microsoft notes that the family includes LAN Manager and NTLM versions 1 and 2.

With NTLM, the resource server must contact a domain authentication service on a domain controller, or check its local account database, whenever it needs a new access token. That is one reason Kerberos is described as more efficient for servers.

The differences that matter for security

• Mutual authentication: Kerberos lets each side verify the other. Microsoft states that NTLM does not let clients verify a server's identity, because it was designed for networks where servers were assumed to be genuine.
• Delegation: Kerberos supports delegation so a front end can act for a user toward a back end. That is powerful and needs careful configuration.
• Dependence on the directory: default Kerberos in a domain relies on Active Directory Domain Services.
• Where NTLM is required: Microsoft says NTLM must still be used for Windows authentication with workgroup members, and it is used for local logon on non-domain controllers.

Why apps fall back to NTLM

Common reasons include connecting by IP address instead of a name, since Kerberos needs a service name to find the right account. A missing or duplicate service principal name is another. Clients and servers in different, untrusting domains can also force it. Some applications simply use NTLM by design.

Microsoft's SMB signing guidance makes a related recommendation: use Kerberos instead of NTLMv2, and do not connect to shares using IP addresses. The same habits help everywhere.

Finding NTLM in your environment

Microsoft points to tools and settings for discovering how NTLM is used so you can selectively restrict it. The approach is the same one you would use for any protocol retirement:

1. Audit first. Turn on NTLM auditing and collect for a few weeks, so you capture monthly jobs.
2. List which servers and applications are the sources.
3. Fix the name, SPN or trust problem that forces the fallback.
4. Add restrictions in stages, starting with exceptions lists for the stragglers.
5. Retest after each stage with the owners of the affected apps.

Do not switch NTLM off in one step. Old file servers, scanners and line of business apps tend to break first.

What developers can do

• Connect with fully qualified host names, not IP addresses.
• Register service principal names correctly for services you run under a dedicated account.
• Prefer Negotiate based authentication in client libraries, so Kerberos is used when it is available.
• Do not hard code the NTLM scheme in a client unless a server forces you to.

Quick check

Sources

• Kerberos authentication overview, Microsoft Learn
• NTLM overview, Microsoft Learn
• Control SMB signing behavior, Microsoft Learn

Last reviewed: 19 October 2026.