What are the signs that Kerberos issues are forcing NTLM fallback?

How to recognise Kerberos-driven NTLM fallback

The most reliable sign is a failed Kerberos attempt immediately followed by a successful NTLM authentication to the same destination. In practice, that pattern means the client reached the service, but Kerberos could not complete the ticket path or service validation. When you see it repeatedly for one app or host, treat it as an application or directory configuration problem, not as a protocol preference issue.

Look for the failure to repeat under the same access path: same client, same target, same logon flow, same server name. That consistency helps separate a true Kerberos setup fault from a one-off network blip. The most common triggers are an incorrect SPN, the use of an IP address instead of the registered name, duplicate SPNs, time skew, or a service account setup that does not match the ticket the client is trying to request.

A practical clue is that the user experience often looks “successful” even when Kerberos is broken. NTLM fallback can hide the real defect because the connection still works, but the authentication method changes. That means the issue may only become visible in logs, in protocol traces, or when a team tries to disable NTLM and the same workflow starts failing.

What usually causes the fallback path

Kerberos depends on a clean name-to-service mapping and a ticket request that can be validated against the right account. When the service principal name is missing, duplicated, or bound to the wrong identity, the client cannot obtain a usable Kerberos ticket and often drops to NTLM instead. This is why “it still connects” is not a sign that Kerberos is healthy.

Another common cause is how the application is addressed. If users connect by IP address, alias, load balancer name, or an unexpected DNS name, the SPN lookup may not line up with the service that is actually listening. The same pattern can also appear when delegation, service account changes, or password rotation were done without updating the associated service registration.

The underlying issue is usually in the authentication plumbing, not in the security policy itself. For a broader control view, Active Directory and Entra ID Hardening Guide is useful because it ties service accounts, delegation, and hybrid identity together in the places where Kerberos failures often surface. For attack-chain context, the MITRE ATT&CK Enterprise Matrix helps place credential and lateral-movement behaviour in a defender’s mental model.

Why NTLM fallback matters operationally

Fallback matters because it masks the loss of Kerberos protections and can keep broken configuration in production for a long time. Teams often discover the problem only when they attempt a hardening project, after a password change, or when a service account is moved. At that point, the fallback has already become part of the application’s normal behaviour, which makes remediation slower and more disruptive.

Repeated fallback also raises the chance that a weak exception becomes embedded in a critical path. If the destination is a tiered administrative service, a sensitive internal application, or a system that should be using strong mutual authentication, the presence of NTLM is an indicator that the intended trust model is not being enforced. That is especially important in environments trying to reduce legacy authentication dependence.

From a control perspective, the issue is not “Kerberos versus NTLM” in the abstract. It is whether the intended authentication path matches the service name, account mapping, and deployment pattern. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because authentication, account management, configuration, and audit controls all intersect when a service silently falls back.

Risk and Threat Considerations

NTLM fallback is risky because it can preserve access while weakening the assurance that the connection is bound to the intended service principal. That creates hidden exposure: the system appears functional, but the authentication path may be less resistant to misuse, relay-style abuse, or legacy-authentication dependence.

Failure mechanism: Kerberos fails due to name, SPN, account, or deployment mismatch, and the application silently accepts NTLM as an alternate path.

Impact: The environment keeps working while the stronger authentication design is bypassed, which can delay detection of misconfiguration and increase reliance on a weaker legacy protocol.

Practitioner Guidance

What to verify: Confirm whether the destination is being reached by its registered service name, whether the SPN is unique and correctly bound, and whether the same flow still succeeds when NTLM is blocked. If the application only works because NTLM is available, treat that as a configuration defect to fix, not a stable operating state.

Decision rule: If Kerberos fails but NTLM succeeds for the same destination, fix the service registration or client naming path first. Do not start by removing NTLM until you can explain why Kerberos is failing and prove that the application can complete the intended Kerberos exchange.

Practitioner takeaway: The important signal is not simply “NTLM happened”, but “Kerberos should have worked and did not”. That distinction tells you where to investigate and prevents a legacy-authentication workaround from hiding a real identity and service-binding problem.

Related resources from NHI Mgmt Group

• Why do NTLM fallback paths create more risk than teams expect?
• Why do zero-click NTLM leaks still matter even after Microsoft issues a fix?
• What breaks when organisations keep NTLM enabled as a fallback for too long?
• Why do mixed NTLM and Kerberos environments create more relay exposure?