Windows Server Summit 2024
Mar 26 2024 08:00 AM - Mar 28 2024 04:30 PM (PDT)
Microsoft Tech Community
LIVE

re: KB5005389 / KB5005408 mitigation ending Feb 8 2022 - any new information?

Copper Contributor

We have this problem re: the KB's listed in subject, where I work, using smartcards w/PIV and thin clients. We've been informed by Dell Engineering after extensive troubleshooting that this will be the case for the foreseeable future due to current RDP design. Whether Microsoft will change this in the future is unknown, so our only option to continue using compliant smart cards and thin clients is to switch to a non-RDP protocol (eg Horizon, Citrix). This is fine - but our timeline to do this is extremely limited as the deadline is Feb 8. 

KB5005389 says: "Important You must have your noncompliant devices updated and compliant or replaced by February 8, 2022. After that, the mitigation will not work in security updates. For more information, see KB5005408."

Is there some way I can find out *exactly* which upcoming patch will remove the mitigation? At the very least we could temporarily prevent our on-premise WSUS server from releasing it for a little while, until we get everyone migrated to new infrastructure. 

Thanks very much for your help. 

10 Replies
February 8, 2022

Updates will log audit events on Active Directory domain controllers that identify printers that are RFC-4456 incompatible printers that fail authentication once DCs install the July 2022/August 2022 or later updates.

Windows Server 2016
Windows Server 2012 R2
Windows Server 2012
Windows Server 2008 R2 SP1
Windows Server 2008 SP2

So the update in februari will enable logging of printers that are RFC-4456 incompatible. On the 19th of July there will be an optional preview update that removes the option to have temporarily mitigation in place. Not sure what that KB number will be, on august 9 there will be an update removing the option to use mitigation completely.

To use the temporary mitigation in your environment, follow these steps on all domain controllers:

On the domain controllers, set the temporary mitigation registry value listed below to 1 (enable) by using Registry Editor or the automation tools available in your environment.

Note This step 1 can be done before or after steps 2 and 3.

Install an update that allows the temporary mitigation available in updates released July 27, 2021 or later (below are the first updates to allow the temporary mitigation):

Windows Server 2019: KB5005394
Windows Server 2016: KB5005393
Windows Server 2012 R2: KB5005391
Windows Server 2012: KB5005389
Windows Server 2008 R2 SP1: 5005392
Windows Server 2008 SP2: KB5005390

Restart your domain controller.

Registry value for temporary mitigation:

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require you to reinstall the operating system. Microsoft cannot guarantee that these problems can be resolved. Modify the registry at your own risk.

Registry subkey HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Value Allow3DesFallback
Data type DWORD
Data 1 (Enable temporary mitigation)
or
Data 0 (Enable default behavior, requiring your devices into compliance with section 3.2.1 of RFC 4556 specification.)

Restart required? No

The above registry key can be created and the value and dataset using the following command:

reg add HKLM\System\CurrentControlSet\Services\Kdc /v Allow3DesFallback /t REG_DWORD /d 1 /f

https://support.microsoft.com/en-au/topic/kb5005408-smart-card-authentication-might-cause-print-and-...
Thanks very much for the info, Harm! This is very useful. May I ask where you found this information? I would like to be able to direct my supervisor to it. Regarding the mitigation, yes, we have it in place, as I mentioned, but thanks for reposting it anyway. But I am confused since Microsoft previously said:

"KB5005389 says: "Important You must have your noncompliant devices updated and compliant or replaced by February 8, 2022. After that, the mitigation will not work in security updates. "

Your information implies that the mitigation will continue working until July or August of 2022. ?
I got that from the link at the end of my post :) There's a time-table in it
Wow. That's the same exact KB I posted above. A bunch of that information was not in that article the last 50 times I looked in the last 3 months. Hmmm.
Don't know, it's always good to recheck I guess ;) Hope that you have enough information and that you have less weight on your shoulders...

@Harm_Veenstra I'm assuming it's game over today (as opposed to February when they started indicating it was eventually going to be over, today), as Microsoft, it appears, does not want to do anything but plug this hole. In our case, this mitigation allowed our smart cards to keep functioning with Wyse thin clients. Admittedly was not ideal. Still, Dell confirms same;
*if you use RDP and smart cards (as opposed to VDI and smart cards), they will no longer work with thin clients. At least, this is what we've been told from multiple vendors.

Be that as it may - seems unlikely the KB released to patch this away will match these. Any ideas as to which ones they might be for patch Tuesday release (or how to find them)?

Thx once again! : )  

No problem, I think that they will show up here? https://docs.microsoft.com/en-us/windows/release-health/windows-message-center Could you mark my answer as the solution to mark it as solved?

Will do. Tangentially important (which is the reason I asked this question in the first place) - I don't suppose you have any idea why this affects smartcards with thin clients and RDP as well? A system engineer at Dell suspects the AVD/RDP client from Microsoft for Linux (which Dell's Wyse ThinOS, on their thin clients, is a flavor of) - is not supported. Yet even after a year, somehow, this is not mentioned in this kb even though they are affected exactly the same way. Thanks again for the quick response!
It's in the software (RDP clients) or just in the ThinOS itself I guess? The device sends the request using the certificate on the smartcard and if it can't encrypt it correctly, it will be discarded. Firmware/software/client, not sure what the deciding factor is