| Previous | Next |
| STATUS_SMARTCARD_IO_ERROR | STATUS_SMARTCARD_CERT_REVOKED |
STATUS_DOWNGRADE_DETECTED
The final text can look like DC unavailability even when the security decision is to prevent fallback
STATUS_DOWNGRADE_DETECTED is an authentication-protection result, not merely a synonym for network timeout. Microsoft documents a concrete password-change case where security updates prevent Negotiate from falling back to NTLM when Kerberos fails because no logon server can be reached; the client can receive STATUS_DOWNGRADE_DETECTED instead.
Trace the selected package and the failure that occurred before the downgrade result. Determine whether Kerberos failed because of domain-controller discovery, DNS, connectivity, SPN, time, or encryption policy, then identify which fallback the client attempted. The root incident is often earlier in the log than the final status.
Do not re-enable NTLM or relax negotiation policy just to make the operation succeed. Restore the intended Kerberos/domain path or explicitly document a supported exception. Comparing a working site with a failing site is useful: check KDC reachability and package selection before the point at which Negotiate would otherwise change mechanisms.
What to inspect
- The authentication package initially selected and the precise Kerberos or domain-controller error immediately before this status.
- DNS/DC discovery, KDC reachability, time, SPN and encryption-policy evidence for the failed Kerberos path.
- NTLM restriction and Negotiate policy, plus whether only password-change operations or all integrated authentication is affected.
References
- Microsoft: MS16-101 authentication changes and downgrade detection
- Microsoft: Kerberos authentication overview
- Microsoft: Restrict outgoing NTLM traffic policy
- Microsoft: SSPI architecture
- Microsoft Open Specifications: NTSTATUS values
Looking for a different code? Search another status or error code.