Summary
Protections for CVE-2022-21920 are included in the January 11, 2022 Windows updates and later Windows updates. These updates contain improved logic to detect downgrade attacks for 3-part Service Principal Names when using the Microsoft Negotiate authentication protocol.
This article provides guidance when Kerberos authentication is not successful.
More information
Installing the January 11, 2022 Windows updates and later Windows updates may cause authentication to fail for 3-part SPNs where Kerberos authentication is not successful. For these environments, it is likely that Kerberos authentication for 3-part SPNs has not worked for some time. You may see the following event on Windows Client systems to help triage.
|
LSA Event 40970 Screenshot identifying an NTLM fallback for a specific SPN from a Microsoft test environment. |
LSA Event 40970 Text version |
|
|
The Security System has detected a downgrade attempt when contacting the 3-part SPN <SPN name> with error code "The SAM database on the Windows Server does not have a computer account for the workstation trust relationship (0x0000018b)" Authentication was denied. |
Action
Microsoft recommends that you triage why Kerberos authentication for the 3-part SPN failed. Some common reasons for Kerberos authentication failure include the following:
-
The SPN that is being used as the target for authentication is malformed. For more information, see Name Formats for Unique SPNs.
Note: Applications and APIs may have stricter or different definitions for what constitutes a legitimate SPN for their service.
Examples of a legitimate SPN
http/webserver
Host/machine2.contoso.com
Ldap/machine1.contoso.com/contoso.com
Service/machine1:10100
Examples of possibly malformed SPNsSPN
Reason
Host/host/machine1
Host/host is most likely a mistake since “host” is usually a service class and not a machine name. It’s possible that the legitimate SPN is host/machine1.
Ldap/machine/contoso.com:10100
Ports can be specified on the host name (“machine”) and not on the service instance name. It’s possible that the legitimate SPN is “ldap/machine:10100/contoso.com”
Ldap/dc-a/DC=CONTOSO,DC=COM
Certain APIs expect a DNS name instead of a FQDN. For example, DsBindA function (ntdsapi.h) expects to be passed in a DNS name. If a FQDN is passed, it may result in the malformed SPN.
The legitimate SPN may be “ldap/dc-a/contoso.com”To address these issues, consider either using the correct SPN or registering the malformed SPN to the correct service account.
-
SPN that is being used as the target for authentication does not exist. To address this issue, consider registering the SPN to the correct service account.
-
The Windows client machine does not have Line of Sight to a domain controller (such as the DCs are offline, cannot be discovered in DNS, or access to the KDC port is blocked).
-
You may be using NetBIOS names in a scenario where NetBIOS names do not work. An example is accessing domain resources from a non-domain-joined machine and NetBIOS name resolution is either disabled or not working.
Microsoft recommends using a User Principal Name (UPN) or a Domain Name System (DNS) name instead of the NetBIOS name.
Registering SPNs
Depending on the configuration of the application and your environment, SPNs may be configured on the Service Principal Name attribute of the service account or the computer account located in the Active Directory domain that the Kerberos client is trying to establish the Kerberos connection with. For Kerberos authentication to work correctly, the target SPN must be valid.
Consult deployment documentation or the support provider for each specific application for guidance on how to enable Kerberos authentication. Some application installers or applications register SPNs automatically. There are different options for both developers and administrators to register a SPN:
-
To manually register SPNs for a service instance, see Setspn.
-
To programmatically register SPNs for a service instance, see How a Service Registers its SPNs describing how to:
-
Call the DsGetSpn function to create one or more unique SPNs for the service instance. For more information, see Name Formats for Unique SPNs.
-
Call the DsWriteAccountSpn function to register the names on the service's logon account.
-
Known issues
Currently, there are no known issues with this update.
