← Field Guides
Active DirectoryEvent ViewerHardeningKerberosNTLMProtected UsersSecuritySPN

Why Kerberos-to-NTLM Fallback Is a Problem in Active Directory (and How to Eliminate It for Real)

Context

In Active Directory, Kerberos is the preferred authentication protocol. NTLM is still supported for compatibility, but in many environments it is not used explicitly: it appears as a silent fallback when Kerberos cannot complete negotiation. Microsoft documents that when Kerberos cannot be used, Windows can fall back to other enabled protocols, including NTLM. 1 2 3

The key point is simple: fallback is not a healthy authentication strategy, it is a sign of weakness. If a service still works, it often means it is dropping to NTLM instead of using Kerberos as intended. That is why NTLM removal or Protected Users adoption surfaces problems that had been hidden for months.

The real point: you are not removing a protocol, you are uncovering hidden dependencies

Many hardening projects fail because they start from the wrong question. The useful question is not only "how do I block NTLM?". The useful question is: where is Kerberos not actually making it all the way through?

In practice, fallback shows up when the client cannot build a valid Kerberos context. Common causes are straightforward but widespread:

  • missing or duplicate SPNs
  • connections through IP addresses instead of hostnames
  • aliases, CNAMEs, or load balancers that were not modeled correctly
  • services running under accounts that do not match Kerberos configuration
  • stale keytabs, passwords, or config on non-Windows systems
  • legacy applications that always tolerated NTLM and were never tested without it

That list matters because it explains why the same problem appears in different forms. This is usually not "an NTLM bug". It is a design or configuration problem that NTLM has been masking.

Real-world cases worth fixing first

1. SQL Server reached by IP or with an incomplete SPN

Microsoft documents that if the SPN is not registered correctly, Kerberos is not used and authentication can fall back to NTLM. This is one of the most common enterprise cases, especially when SQL Server is reached by short name, alias, or IP rather than by the hostname that matches the SPN. 2 3

Practical guidance:

  • make sure the service is reached through a stable FQDN
  • verify that the SPN exists and is unique
  • use auth_scheme to confirm whether the session is really Kerberos
SELECT auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

If the result is not KERBEROS, the problem is usually not the client. It is almost always the service naming or SPN registration.

2. IIS, application pools, and HTTP services behind aliases or load balancers

An application can look fully healthy until you force Kerberos. If the HTTP service exposes a different name from the one used in the ticket, or if the app pool runs under an account that does not match the SPN, the browser will often drop to NTLM.

This case is deceptive because users only see that "the page loads". In reality, the environment is already degrading the authentication layer.

Check immediately:

  • HTTP/hostname and HTTP/fqdn SPNs
  • DNS aliases and CNAMEs used by the application
  • the application pool identity
  • delegation settings, if any

3. File servers, NAS appliances, and printers pointing at a non-matching name

Many legacy devices are not the real issue. The issue is how they are integrated: SMB paths configured with IPs, short names, or aliases that do not match the computer account SPN.

These systems are often the first to show fallback because they have older stacks, they do not negotiate cleanly, and they keep working only because NTLM is still tolerated.

Typical signs:

  • share access through \\IP\share
  • authentication works only with the short name, not the FQDN
  • devices fail as soon as NTLM is audited or restricted

4. Linux domain-joined servers with stale keytabs or mismatched Kerberos config

On Linux the problem is often twofold: the computer account in Active Directory must support AES and be configured consistently, while the local krb5.conf and keytab must reflect the same reality. If the keytab is stale or the Kerberos profile still allows undesired algorithms, authentication can degrade or fail in ways that are hard to read.

Here the fallback is not always to NTLM in the same way as on Windows, but the outcome is similar: the system remains dependent on a fragile and inconsistent configuration.

5. Protected Users exposing the problem immediately

What is the Protected Users group

Protected Users is a security group in Active Directory introduced by Microsoft to increase protection for privileged or critical accounts. Microsoft documents that members of this group are subject to strict and non-configurable restrictions on how they can authenticate. 4 5

The main restrictions for Protected Users members are:

  • No NTLM: the account cannot authenticate with NTLM, NTLMv2, Digest, or other weak authentication forms.
  • Kerberos with AES only: must use Kerberos and MUST support AES-CTS-HMAC-SHA1-96 or AES256-CTS-HMAC-SHA1-96. RC4, DES, and weak algorithms are not allowed.
  • No Kerberos delegation: cannot be subject to unconstrained or constrained delegation.
  • Shorter TGT lifetime: ticket duration from KDC is reduced.
  • Mandatory Kerberos pre-authentication: required, making tickets harder to obtain illegally.

These restrictions are absolute and cannot be bypassed. There are no workarounds, no exceptions, no registry keys to circumvent them.

When to use Protected Users

Protected Users is useful mainly in two scenarios:

  1. Testing and validation phase: add a test account to the group to immediately discover which services, applications, or network aliases depend on NTLM or misconfigured Kerberos. It is the most direct way to "stress test" your Kerberos infrastructure.

  2. Critical accounts that can tolerate controlled migration: domain admin accounts, backup accounts, security monitoring accounts. If the account is important but you can manage a failure during a test window, Protected Users is excellent.

When NOT to use Protected Users

Microsoft explicitly warns against Protected Users in certain contexts:

  • Service accounts: do not add service accounts to Protected Users without thorough testing. If the service is not properly configured for Kerberos, the entire service stops working.
  • Computer accounts: computer accounts rarely go into Protected Users because local protections do not make sense for machines.
  • Managed Service Accounts (MSA) or virtual accounts: if you use MSA or virtual accounts, testing must be even more thorough before adding Protected Users.
  • Bulk addition: do not add accounts in bulk to the group without case-by-case testing. Restrictions have no workarounds and can cause total lockouts.
  • Environments with unknown legacy dependencies: if you do not have a complete map of who accesses what and how, Protected Users risks blocking critical paths.

Why NTLM is not available (this is the key point)

When an account is a member of Protected Users, the system enforces it this way:

  1. The client attempts Kerberos: the Windows client activates the Kerberos path and generates a ticket request.
  2. The KDC validates Protected Users constraints: the Domain Controller verifies that the account is a group member and applies restrictions.
  3. NTLM is explicitly blocked: if for any reason Kerberos fails (missing SPN, IP used instead of FQDN, misaligned service account), the system does not fall back to NTLM. The fallback is completely disabled. 4

The error message you will see is usually cryptic: "The referenced account is a member of the Protected Users group in Active Directory Domain Services. Your computer cannot use Kerberos to authenticate to it." Or the application just sees an authentication error with no reason given.

Which services break and why

When you add an account to Protected Users, these services often start failing:

SQL Server with service account in Protected Users:

  • If the SPN is registered incorrectly or if clients connect via IP, the connection fails immediately.
  • NTLM is not available as a fallback, so there is no tolerance.
  • SQL Server logs an authentication error.

IIS and web applications with app pool account in Protected Users:

  • If the CNAME or alias does not match the SPN, clients (browsers, API callers) cannot authenticate.
  • Kerberos delegation does not work, which especially breaks multi-tier applications.
  • Windows clients often see a 401 (Unauthorized) error even though credentials are correct.

Backup and replication services (SQL replication, DFS, Backup Exec, Commvault):

  • These services often use service accounts with complex SPNs or legacy configurations.
  • With Protected Users, the NTLM fallback is blocked and the service stops communicating with targets.

File sharing and SMB (file servers, Hyper-V live migration, replica storage):

  • If the service account is in Protected Users and the file server does not have the correct SPN registered, access fails.
  • It is not permitted to downgrade authentication to a weaker protocol.

Integration and middleware services (SAP connectors, Oracle database links, JEE application servers):

  • Many of these services were written when Kerberos was not well supported and depend on NTLM.
  • With Protected Users, the fallback is removed and the service discovers it never truly worked with Kerberos.

How the operational impact occurs

The impact of adding an account to Protected Users is immediate and total:

  1. Phase 0 - Nothing changes until the account is in Protected Users: the service works normally, likely using NTLM as a silent fallback.

  2. Phase 1 - Add the account to Protected Users: change made, the group replicates across DCs in minutes.

  3. Phase 2 - First connection attempt (within minutes): the client attempts to authenticate, the KDC verifies the account is in Protected Users, applies restrictions, and blocks NTLM.

    • If Kerberos works → authentication OK, nothing changes for the user.
    • If Kerberos fails → authentication fails, the service is down.

  4. There is no "almost working": either Kerberos works completely, or the service is completely blocked. There are no intermediate states.

How to test Protected Users in a controlled way

The correct way to use Protected Users as a validation tool is this:

  1. Create a test account that is not critical (example: TEST_KERB_VALIDATION) in an isolated OU.

  2. Assign the test account the same SPNs and privileges that a real account would have (for example, if you want to test SQL Server, register the same SPN).

  3. Add the test account to Protected Users.

  4. Try to use the services that depend on that account:

    # Example: test SQL Server
runas /user:domain\TEST_KERB_VALIDATION cmd.exe
# Then from that prompt: sqlcmd -S server.domain.com -E

  5. If it fails, log the exact error:

    • Check that the SPN is registered correctly
    • Verify that the client uses the name consistent with the SPN
    • Check that the service account supports the right Kerberos algorithms

  6. After testing, remove the account from Protected Users:

    Remove-ADGroupMember -Identity "Protected Users" -Members TEST_KERB_VALIDATION

It is not invasive, does not block the real service, and gives you all the information you need.

Why Protected Users is the best test for Kerberos-to-NTLM fallback

In short: Protected Users is the most direct way to discover where your environment is still depending on NTLM to mask Kerberos problems.

Without Protected Users, a service continues to "work" but is actually using NTLM as an invisible safety net. With Protected Users, the safety net is removed and you see exactly what was not configured correctly. For this reason, if you want to do serious Kerberos hardening in enterprise environments, Protected Users is not just an additional security control: it is a fundamental auditing tool. 4 5

How to tell whether NTLM is still in use

Microsoft provides dedicated auditing both at the domain controller layer and the member server layer.

For domain controllers, "Network security: Restrict NTLM: Audit NTLM authentication in this domain" lets you see NTLM traffic without blocking it. For member servers, "Network security: Restrict NTLM: Audit incoming NTLM traffic" serves the same purpose for inbound traffic. Microsoft is explicit: audit first, then block. 8 9

Event ID 4776 is also useful because it records credential validations performed through NTLM on domain controllers. If you want to find what is still dropping to NTLM, this is one of the best starting points. 10

If your goal is to find the last NTLMv1 remnants, Microsoft also documents Event ID 4624 and the Package Name (NTLM only) field to identify NTLM V1. But for serious hardening, the issue is not only NTLMv1: it is all NTLM traffic that should no longer exist. 11

NTLMv1 and NTLMv2: the distinction that actually matters

It is worth separating the two, but without changing the focus of the article.

NTLMv1 is the older and weaker residue, and Microsoft treats it as something to identify and remove. NTLMv2 is definitely better, but it does not solve the core problem: it is still a fallback that should be audited, reduced, and, where possible, eliminated. In other words, NTLMv2 is not the end state. It is only a less weak version of the same dependency.

If you want to close this topic properly in enterprise environments, the useful sequence is: find where Kerberos is failing, remove the reason it fails, and only then tighten NTLM. The NTLMv1/NTLMv2 distinction matters, but it should not distract from the real goal, which is to make Kerberos work without a safety net.

HOST or FQDN for Kerberos?

Your memory is basically right: FQDN is the recommended choice.

For Kerberos, it is not enough to use any hostname. The name used by the client must match a valid, unique SPN. In some cases a short HOST name can work, but only if the SPN is registered consistently for that name. When you want to minimize ambiguity and alias problems, FQDN is the safer and more standard form, and it is what Microsoft uses in SPN examples. IP addresses are the problematic case because Windows does not attempt Kerberos by default for IP hosts and may fall back to NTLM. 2 3

How to eliminate fallback in a realistic way

The right sequence is not "turn everything off and hope". It is this:

  1. Audit where NTLM is still used. 8 9
  2. Fix the technical causes of fallback: SPNs, naming, aliases, IP usage, service accounts, keytabs, inconsistent configuration. 2 3
  3. Validate with protected accounts or test profiles that can no longer use NTLM. 4 5
  4. Restrict NTLM gradually only after the dependency map is clear. 8 9

This is the part that often goes missing in enterprise projects: you do not just need a blocking policy, you need a reconstruction of the real dependencies.

Practical advice you can apply immediately

  • Prefer consistent FQDNs and avoid IP-based connections when you expect Kerberos.
  • Verify and document the SPNs of critical services before changing policies.
  • Treat SQL Server, IIS, file servers, and legacy appliances as high priority because those are the places where fallback tends to stay hidden the longest.
  • Use Protected Users as a diagnostic tool, not only as a security control.
  • Do not treat NTLMv2 as the final goal: it is still a dependency, not the end of the problem.

The most useful lesson

Kerberos-to-NTLM fallback matters not because NTLM still exists, but because it reveals what Kerberos is failing to do.

If you remove NTLM before cleaning up SPNs, naming, service accounts, and legacy dependencies, the whole problem surfaces at once. If you use audit, real-world cases, and protected accounts properly, fallback becomes a concrete remediation list instead of a vague unknown.

In short: the real goal is not just to switch NTLM off. It is to make sure Kerberos truly works as the standard, not just as an assumption.

Need Help?

Kerberos-to-NTLM fallback is one of those problems that seems complex until you get it in focus. If you are dealing with hard-to-trace authentication incidents, accounts locked after enabling Protected Users, or simply want to validate that your Kerberos infrastructure is ready for hardening, often a few hours of log and configuration analysis can unlock the situation.

Contact me: I will be happy to help you navigate SPNs, Protected Users, Event ID 4776 and everything else in the puzzle.

Appreciation

If this guide is useful, leave a like.

LinkedIn