What does Windows error code 1937 (ERROR_NTLM_BLOCKED) mean?

 
Previous Next
ERROR_REMOTE_PRINT_CONNECTIONS_BLOCKED ERROR_PASSWORD_CHANGE_REQUIRED

ERROR_NTLM_BLOCKED

NTLM authentication is blocked by policy.

ERROR_NTLM_BLOCKED is Win32 error 1937 (0x791). The credentials may be correct, but the negotiation fell back to or explicitly requested NTLM where local, domain, server, client, or protocol policy forbids it. The durable fix is to make the intended stronger protocol work or to apply a narrowly reviewed exception—not to keep resubmitting the password.

Why an application falls back to NTLM

  • the service is addressed by IP address or an alias for which Kerberos cannot obtain the expected SPN
  • DNS, time, domain connectivity, delegation, or SPN registration prevents Kerberos negotiation
  • legacy software explicitly selects NTLM or does not support modern authentication
  • incoming, outgoing, domain, SMB, or application-specific policy has moved from audit to deny
  • a local account, workgroup path, or cross-boundary scenario has no Kerberos trust route

Authentication telemetry

Record client and server names as used by the caller, target SPN, selected package, account type, domain/workgroup context, policy scope, source and destination hosts, and events from the Microsoft-Windows-NTLM Operational log. Never log passwords, hashes, challenge responses, or tickets. Note whether the connection used an IP address, CNAME, load balancer, or direct host name.

Diagnostic sequence

Identify which side returned 1937 and which policy blocked the exchange. Review NTLM audit events and determine why Negotiate did not use Kerberos. Validate DNS, time, domain reachability, SPN ownership, service account, and the exact target name before considering an exception.

Test with the canonical host name and an account/protocol combination expected to support Kerberos. For SMB, also inspect current SMB NTLM blocking configuration. Avoid diagnosing the result as a generic network failure when the policy log records a deliberate authentication denial.

Recovery and migration

Correct SPNs, naming, service identity, delegation, or client capabilities so the approved authentication method succeeds. Use audit mode before broad enforcement and create only time-bounded, server-specific exceptions when a documented migration cannot finish immediately.

Developers should use Negotiate rather than forcing NTLM, expose the negotiated package in diagnostics, and avoid silent credential prompts. Administrators should inventory and remediate audit events before enabling deny policies.

Difference from authentication firewall failure

ERROR_AUTHENTICATION_FIREWALL_FAILED denies a particular account on a protected target. Error 1937 denies the NTLM mechanism; another permitted protocol may authenticate the same account to the same service.

Example

A file share is accessed through an IP address after incoming NTLM has been blocked. Kerberos cannot use the IP as the expected SPN, negotiation attempts NTLM, and access fails with 1937. Using the canonical server name and correcting SPN registration restores Kerberos.

References

Looking for a different code? Search another status or error code.