[German]Microsoft's fix for vulnerability CVE-2022-21920 may block NTLM authentication if Kerberos authentication is not successful. A German blog reader has notified me in January 2022 about issues with Advanced Group Policy Management (AGPM). After installing January 2022 security updates , there are problems to reach the AGPM server. Microsoft has now confirmed these issues and a workaround is possible.
Issues with AGPM Server
Austrian blog reader Markus K. uses AGPM in a larger network environment in a university. He has already emailed me as of 1/23/2022 about a problem he posted on the patchmanagement.org mailing list under the title AGPM client fails to connect with 2022-01 CU. There he wrote:
just a heads up cause it might concern you.
We have a 20H2 machine with an AGPM client installed.
After installing 2022-01 CU the connection to the AGPM server failed.
After uninstalling the patch the connection to the server works again.
The 2019 server has the 2022-01 CU installed though.
The error on the clients log:
2022-01-13 10:21:23:1869726 [pid=8016,tid=3] [Error] Error in AgpmClient.Reconnect() System.ServiceModel.Security.SecurityNegotiationException: Either the target name is incorrect or the server has rejected the client credentials. —> System.Security.Authentication.InvalidCredentialException: Either the target name is incorrect or the server has rejected the client credentials. —> System.ComponentModel.Win32Exception: The logon attempt failed
— End of inner exception stack trace —
at System.Net.Security.NegoState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel)
at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeInitiator.OnInitiateUpgrade(Stream stream, SecurityMessageProperty& remoteSecurity)
— End of inner exception stack trace —
Seems the patch breaks the auth process. Not much we can do except waiting for a fix I guess.
However, in the discussion it turned out that hardly anyone on the list uses AGPM and others are not affected either. Markus was able to provoke this issue on a freshly installed Windows 10 20H2 client in a virtual machine.
What is AGPM?
AGPM stands for Microsoft's Advanced Group Policy Management. According to this Microsoft document, Microsoft Advanced Group Policy Management (AGPM) extends the capabilities of the Group Policy Management Console (GPMC). It will provide comprehensive change control and improved management for Group Policy Objects (GPOs). AGPM is available as part of the Microsoft Desktop Optimization Pack (MDOP) for Software Assurance. There are several versions available.
Blog reader Markus K. emailed me again on February 25, 2022 and wrote:
Problem solved myself, because the ticket at MS is a farce.
A few people on the NTSysadmin list should also be happy about this, as they are also affected.
We had entered the IP of the AGPM server. Split-DNS therefore delivers a FQDN outside the domain. Kerberos does not work then of course, so fallback to NTLM.
Microsoft released an update on January 11, 2022 to close the vulnerability CVE-2022-21920, which triggered the above effect. Markus K. pointed me to the Microsoft support article KB5011233: Protections in CVE-2022-21920 may block NTLM authentication if Kerberos authentication is not successful, where this is discussed. According to the support article, it affects all supported Windows versions.
Windows Server 2008
Windows 7 Service Pack 1
Windows Server 2008 R2 Service Pack 1
Windows Server 2012
Windows 8.1 Windows Server 2012 R2
Windows 10 Windows 10, version 1607,
all editions Windows 10, version 1809,
all editions Windows Server 2016
Windows 10, version 1909,
all editions Windows Server 2019
Windows 10, version 20H2,
all editions Windows 10, version 21H1,
all editions Windows 10, version 21H2,
all editions Windows 11 Windows Server 2022
Markus wrote: If you replace the IP with the correct FQDN of the domain, everything works again. Perhaps this is helpful for some affected administrators.
Cookies helps to fund this blog: Cookie settings