Microsoft’s patch on November 8th, 2022, created multiple Kerberos sign-In & authentication errors for users. The issues were caused after installing the patch on Windows Domain Controllers installing. Here are some examples of the issues caused by the patch:

The issue is affecting both server and client platforms:

Client: Windows 7 SP1, Windows 8.1, Windows 10 Enterprise LTSC 2019, Windows 10 Enterprise LTSC 2016, Windows 10 Enterprise 2015 LTSB, Windows 10 20H2 or later, and Windows 11 21H2 or later

Server: Windows Server 2003 or later, including the latest release, Windows Server 2022.

 

Identifying The Kerberos Sign-In & Authentication Error

The issue can be identified in the System Event Log for the Domain Controller computer. This specific failure is identified by the logging of Microsoft-Windows-Kerberos-Key-Distribution-Center Event ID 14 with this unique signature in the event message text:

“While processing an AS request for target service <service>, the account <account name> did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : <etype numbers >. The accounts available etypes : <etype numbers>. Changing or resetting the password of <account name> will generate a proper key.”

Where (a.)  “the missing key has an ID 1” and (b.) “4” is not listed in the “requested etypes” or “account available etypes” fields.

 

Resolving The Kerberos Sign-In & Authentication Issue

Microsoft released an optional out-of-band update 9 days later on November 17th, 2022. The fix does not require any updates or changes to other servers or client devices inside your environment. Further, Microsoft recommends that any workarounds or mitigation efforts to resolve the issue are removed at this time.

The out-of-band updates are available through the Microsoft Update Catalog and are not offered via the Windows Update. Installation guides can be found below:

 

What About Windows Server 2003 Environments?

Currently, Microsoft is not providing an update for Windows Server 2003 environments. This is in line with Microsoft’s goal of enforcing security hardening.

There is currently a workaround for 2003 environments, however, it poses a high-security risk. You can have Windows Server 2003 domain-joined machines in an Active Directory Domain Services (ADDS) 2019 environment if SMBv1 is enabled. You can learn how to detect, enable and disable SMBv1, SMBv2, and SMBv3 here.

It is highly recommended that you move your complete applications off Windows 2003 servers and not use the SMBv1 workaround. The SMBv1 protocol is almost 40 years old and is not safe to use. By using this old protocol, you lose protections such as pre-authentication integrity, secure dialect negotiation, encryption, disabling insecure guest logins, and improved message signing.

 

A Solution for Windows 2003 Server Environments

The best solution for your Windows 2003 Server environments is to migrate the complete applications to a modern supported environment. Neither an “upgrade-in-place” nor a “lift & shift” approach is recommended as the underlying 2003 Server environment continues to be a security vulnerability.

Since the patch, VirtaMove has been engaging with many organizations looking to rapidly resolve this issue, which we have. We have done this without creating security concerns and no business disruptions. We have already been helping clients modernize their server environments for over a decade and this issue is simply a server modernization challenge.

Please contact us to see how VirtaMove can help.