[German]Microsoft has release various security updates on November 9, 2021 patchday. Beside the already known printing issues caused by previous updates, there are now authentication problems with domain controllers (DCs) in certain Kerberos delegation scenarios. Probably leads to entries in the log files. Some administrators also report that their WSUS cannot pull all updates.
Problems with WSUS update synchronization
I don't know if the problem still exists. But as of Nov 11, 2021, several administrators reported that WSUS can't pull all updates. Here's a German comment (translated) from the blog:
Our WSUS based on Windows Server 2016, only pulls the November updates of the server versions and the Windows Malicious Software Removal Tool. Multiple times already manually syncronized and rebooted the server, but without the effect of pulling the Windows 10 updates. We have changed absolutely nothing in the server settings and the required Win10 versions are definitely checked off as well.
Can anyone reproduce this as well? Is it possible that Microsoft has pulled the Win10 updates for November???
The behavior was confirmed by another administrator for Windows Servers 2016 (Windows Server 2019 does not seem to be affected). Anyone else with this problem?
Authentication issues with domain controllers
In my German Windows 11 blog post there is the following comment that the security updates should not be installed on domain controllers. Microsoft has since published the support post Authentication might fail on DCs with certain Kerberos delegation scenarios about this.
- After installing the November 9, 2021 security update on domain controllers (DCs), the specified server versions may experience authentication failures on servers related to Kerberos tickets purchased through S4u2self.
- The authentication failures are the result of Kerberos tickets acquired through S4u2self and used as proof tickets for protocol transition for delegation to backend services that fail signature validation.
- Kerberos authentication fails for Kerberos delegation scenarios where the front-end service retrieves a Kerberos ticket on behalf of a user to access a back-end service.
Major Kerberos delegation scenarios, where a Kerberos client provides an evidence ticket to the front-end service, are not affected. Pure Azure Active Directory environments are not affected by this issue.
Microsoft states that end users in your environment may not be able to log in to services or applications that use Single Sign On (SSO) with Active Directory on-premises or in a hybrid Azure Active Directory environment. Updates installed on client Windows devices will not cause or affect this issue, according to Microsoft. Microsoft cites the following server versions as affected – I've added the updates:
- KB5007206: Windows Server 2019
- KB5007192: Windows Server 2016
- KB5007247: Windows Server 2012 R2
- KB5007260: Windows Server 2012
- KB5007236: Windows Server 2008 R2 SP1
- KB5007263: Windows Server 2008 SP2
German blog reader MOM20xx writes here, that the problem does not only affect domain controllers. He had the first authentication problems on patched servers, when the domain controllers were not patched at all. Environments affected by the problems may be using the following features:
- Azure Active Directory (AAD) Application Proxy Integrated Windows Authentication (IWA) using Kerberos Constrained Delegation (KCD)
- Web Application Proxy (WAP) Integrated Windows Authentication (IWA) Single Sign On (SSO)
- Active Directory Federated Services (ADFS)
- Microsoft SQL Server
- Internet Information Services (IIS) using Integrated Windows Authentication (IWA)
- Intermediate devices including Load Balancers performing delegated authentication
Then the following errors should occur in the environment in question:
- Event Viewer might show Microsoft-Windows-Kerberos-Key-Distribution-Center event 18 logged in the System event log
- Error 0x8009030c with text Web Application Proxy encountered an unexpected is logged in the Azure AD Application Proxy event log in Microsoft-AAD Application Proxy Connector event 12027
- Network traces contain the following signature similar to the following:
- 7281 24:44 (644) 10.11.2.12 <app server hostname>.contoso.com KerberosV5 KerberosV5:TGS Request Realm: CONTOSO.COM Sname: http/xxxxx-xxx.contoso.com
- 7282 7290 (0) <hostname>. CONTOSO.COM <IP address of the application server making the TGS request>
I've noticed a thread about the event entries in System (at least according to my interpretation) today at German site administrator.de within this post. Microsoft is working on a fix.
Addendum: Fixes are out now – see Windows 10/Windows Server: Out-of-band updates fixes DC authentification error (2021/11/14).
Microsoft Oktober 2021 Patchday (November 9, 2021)
Patchday: Windows 10-Updates (November 9, 2021)
Patchday: Windows 8.1/Server 2012 Updates (November 9, 2021)
Patchday: Updates for Windows 7/Server 2008 R2 (November 9, 2021)
Patchday: Windows 11 Updates (November 9, 2021)
Patchday Microsoft Office Updates (November 9, 2021)
Cookies helps to fund this blog: Cookie settings
We have a internal application which relies on Kerberos two-hop authentication. Windows update domain controller patches were installed on Wednesday early morning and this application went unavailable for all logon users all day on 10/10
Thanks for your article here talking about this problem – uninstalling these patches for now has fixed the app problem.
Thanks for the article! Great information.
We had the same issues the whole day. None of our over 1400 apple devices had connection to exchange (zertificate based auth) and our WAP wasnt working anymore. We uninstalled the november-update only on the domain controllers and everything is working now.
What I've learned from German blog readers, was that Azure AD Connect Tool braok and restore it to a previous state didn't fix ADSync with Azure.
question do we need to only not install the updates on DC or any other servers will be affected.
Got the same question in my German blog. The major path:
– if you are affected on DC servers, try to install the patch
– if you are also affected on Windows Servers without DC role, try the patch
In all other cases I would omit the patch.