Updates for Windows (Nov. 2022): Changes in Netlogon and Kerberos protocol – causing issues

Windows[German]Another small addendum to the November 2022 patchday. With the security updates of November 8, 2022, Microsoft has also initiated a gradual change to the Netlogon and Kerberos protocols. The whole thing will be carried out in several stages until October 2023. The reason is three vulnerabilities (CVE-2022-38023 and CVE-2022-37967) in Windows 8.1 to Windows 11 and the server counterparts. Administrators must react accordingly to ensure that these changes are taken into account in network communication. Addendum: Microsoft has released an out-of-band-update to fix the issue – see Out-of-band updates fixes Kerberos authentication issues on DCs (Nov. 17, 2022).


German blog reader Oli mentioned (thanks) within within this comment the topic, that has been also summarized within this German forum post.

Vulnerabilities in Windows

The November 8, 2022 Windows updates also address vulnerabilities related to security bypass and elevation of privilege through Privilege Attribute Certificate (PAC) signatures. The security updates in question address Kerberos vulnerabilities where an attacker can digitally alter PAC signatures to elevate privileges. The following Windows versions are affected:

  • Windows 8.1
  • Windows RT 8.1
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows 10  Version RTM bis 22H2
  • Windows 11 Version 22H1 – 22H2
  • Windows Server 2016 – 2022
  • Windows Server 2022 Azure Stack HCI Version 22H2
  • Windows 11 SE Version 21H2

where the above CVEs refer partly to Windows clients and servers, and partly to Windows servers only.  Microsoft has published various support articles on this.

Which Windows versions are affected by which CVE can be found in the KB articles linked above.

Installation procedure

Microsoft writes that the affected Windows updates must be installed on all devices, including Windows domain controllers, to protect your environment. It is important to note that all domain controllers in a domain must be updated first. Only then may you switch to enforced mode via update. Microsoft suggests the following procedure:


  1. Update the Windows domain controllers with a Windows update that was released on or after November 8, 2022.
  2. Put the Windows domain controller into audit mode by using the registry entries here.
  3. Monitor the events that are stored in audit mode to secure your environment.
  4. AEnable enforcement mode to fix CVE-2022-37967 n your environment.

By default, Step 1 does not fix the security issues in CVE-2022-37967 for Windows devices. To fully mitigate the security issue for all devices, you must enter scan mode (as described in Step 2) and then enter force mode (as described in Step 4) on all Windows domain controllers as soon as possible. In step 2, the following registry key is:


by adding the DWORD value KrbtgtFullPacSignature. The value can assume the following states:

  • 0 – Disabled
  • 1 – New signatures are added, but not verified. (Default setting)
  • 2 – Audit mode. New signatures are added, and verified if present. If the signature is either missing or invalid, authentication is allowed and audit logs are created.
  • 3 – Enforcement mode. New signatures are added, and verified if present. If the signature is either missing or invalid, authentication is denied and audit logs are created.

Starting in July 2023, enforcement mode will be enabled on all Windows domain controllers, blocking vulnerable connections from non-compliant devices.  At that time, you can no longer disable the update, but you can switch back to the Verification Mode setting. Verification mode will be removed in October 2023, as described in the Timeline of updates to address Kerberos vulnerability CVE-2022-37967.

Microsoft used a staged rollout to mitigate the security issues in CVE-2022-37967 for Windows devices. Here are the dates:

  • November 8, 2022 – First deployment phase
  • December 13, 2022 – Second deployment phase
  • April 11, 2023 – Third deployment phase
  • July 11, 2023 – First Enforcement Phase
  • October 10, 2023 – Full Enforcement Phase

Details and registration entries can be found in the three KB articles linked above.

Stop: Issues with gMSA and KDC

German blog reader contacted me by e-mail and pointed to the following Twitter post, where issues are addressed.

Kerberos Issues after Nov. 2022 updates

Kerberos pre-authentication fails because Kerberos-DC has no support for the encryption type. This only occurs if the msDS-SupportedEncryptionTypes property is set. The supported Encryption-Type flags are documented here.

Kerberos Issues after Nov. 2022 updates

Fabian Bader gives more hints in follow-up tweet (see above), and there is a larger discussion.

Kerberos Issues after Nov. 2022 updates

Test script to identify AD objects

Fabian Bader posted a link on Twitter to GitHub, where he published a PowerShell script. This script can be used to identify any AD object potentially affected by the CVE-2022-37966 bug.

Get-ADobject -LDAPFilter "(&(!(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4))(|(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=16)(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=8)))" -Properties msDS-SupportedEncryptionTypes | Select DistinguishedName, msDS-SupportedEncryptionTypes

He writes about this: Setting it to 28 (RC4+AES128+AES256) may be a workaround, but test this or hold off on patching. Anyone else with this problem?

Addendum: See the comment below, that the detection query form the script above should have 16 instead of 6. The author  of the original script has finxed that, and I've amended the code above as well.

Microsoft investigates the problem

Meanwhile, the problem has also reached Microsoft. Microsoft employee Steve Syfuhs has already responded on Twitter and writes:

Not official guidance, but we're seeing reports where certain auths are failing when users have their msDS-SupportedEncryptionTypes attribute explicitly being set to AES only (decimal 24, hex 0x18).

We have another update to the KB pending, with official guidance and cause of the issue. More to follow.

Currently, administrators in the domain controller area should be cautious with the installation of the updates.

On reddit.com there is this mega-thread about problems (thanks to 1ST1 for the link), where you can find hints about the Kerberos problem – including integration of Redhat Linux.

Microsoft has confirmed Kerberos authentication issues after Nov. 2022 update – see Microsoft confirms Kerberos authentication issues after Nov. 2022 updates.

Similar articles:
Microsoft Office Updates (November 1, 2022)
Microsoft Security Update Summary (November 8, 2022)
Patchday: Windows 10-Updates (November 8, 2022)
Patchday: Windows 11/Server 2022-Updates (November 8, 2022)
Windows 7/Server 2008 R2; Windows 8.1/Server 2012 R2: Updates (November 8, 2022)
Patchday: Microsoft Office Updates (November 8, 2022)

Cookies helps to fund this blog: Cookie settings

This entry was posted in Allgemein. Bookmark the permalink.

13 Responses to Updates for Windows (Nov. 2022): Changes in Netlogon and Kerberos protocol – causing issues

  1. Leo de Groot says:

    We have been facing the exact same issue.
    Based in several articles in forums and the update information from Microsoft, we are currently testing if a value of 0x1c or 0x3c will work for the following registry value introduced in the update, that actually limits the default supported encryption types:

    DefaultDomainSupportedEncTypes (DWORD)
    value 0x27

    0x27 would only allow non AES encryption types, which would result in no available encryption types in Kerberos…

  2. Penn Guine says:

    In my case the new registry value was not present on the DC's after the update.

    DefaultDomainSupportedEncTypes (DWORD)

    I suspect this led the KDC to believe no encryption types were trusted. Waiting for Microsoft to comment. Did not attempt manual entry and reverted update.

  3. Indy Admin says:

    What a nightmare. I've been pulling my hair for the last several hours dealing with authentication failures from our firewall service accounts. Found this page and disabled explicit AES settings on the accounts and things are working again. It's frustrating that it's easier to find this on third party site than it is from Microsoft.

  4. Advertising

  5. Chris says:

    For me the workaround to enable RC4 worked.
    However, instead of increasing the Kerb security, MS has now lowered it.

    They should better test their stuff. In general, the layered approach of first introduce it, then audit it and then enforce is fine but this has lead to a complete stop of all business activity as no one was able to logon after the update.

  6. mdx says:

    In my test and prod RC4 was totally disabled couple months ago and only AES128/256 was supported. After installing November 2022 updates test env was dead. It broke my mind.
    After all, my test env (AD DC, AD CA, Exchange and Skype) successfully bring up after next three key was configured on each DC:
    Registry key

    Data type: REG_DWORD
    Value: 0x18

    Data type: REG_DWORD
    Value: 2

    Data type: REG_DWORD
    Value: 0

    I'm sure that last key mainly helped me fix this shit
    Waiting for news from MS

    • Daniel says:

      I can confirm the last key "ApplyDefaultDomainPolicy" will help to fix the nightmare. It is also the MS quick fix for this issue from MS support. This is a nightmare from the November 2022 updates.

      I also run into that issue in our test environments.


  7. Hoppy Bunny says:

    The detection query has an error. The 6 should be changed to 16:

    Get-ADobject -LDAPFilter "(&(!(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=4))(|(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=16)(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.803:=8)))" -Properties msDS-SupportedEncryptionTypes | Select DistinguishedName, msDS-SupportedEncryptionTypes

    • guenni says:

      Thanks, I've seen, that the author als has changed the parameter – I've amended the above code within the article.

  8. Mike Salomon says:

    So my query shows a list of servers and the supported encryption type as 24. What does that mean?

    • mdx says:

      Decimal 24 or hex 0x18 means supported encryption type is AES-128-CTS-HMAC-SHA1-96 and AES-256-CTS-HMAC-SHA1-96

  9. mdx says:

    MS reports problem is fixed, download and install on each DC new OOB cumulative updates:
    ​Windows Server 2022: KB5021656
    ​Windows Server 2019: KB5021655
    ​Windows Server 2016: KB5021654

    If you used any workaround or mitigations for this issue, they are no longer needed, and MS recommends you remove them.

  10. Sam_@ne says:

    Has anyone understood the registry key DefaultDomainSupportedEncTypes.
    It says that if not present the default value is : 0x27 or decimal 39
    "Note If this Registry Key is not set already, this update will assume that the value is set to 0x27.  "
    the article is here if we clic on the value DefaultDomainSupportedEncTypes. :

    But 0x27 is decimal 39 witch means 32 (unreconized bit) + 7 (4+2+1 = DES_CBC_CRC, DES_CBC_MD5, RC4)
    So the decimal 27 is more logical but why still enabling DES.

    It is described here for msDS-SupportedEncryptionTypes :

    While searching a workaround, i was wondering if this registry key introduced with the upadte has any utility.
    The key DefaultDomainSupportedEncTypes does not seem to be like msDS-SupportedEncryptionTypes. Do you know how to use it ?

    If msDS-SupportedEncryptionTypes is empty it search the default configuration for the domain but we can change it only by GPO…

    Here is a good article about RC4 disablement for Kerberos :

  11. Morgan Willcock says:

    I also thought that 0x27 as a default value must be an error, but there is an errata document which contains changes to the lookup table:

    So the value of 0x27 does seem to make sense, it selects the new J value (AES256-CTS-HMAC-SHA1-96-SK) over the previous AES options.

Leave a Reply

Your email address will not be published. Required fields are marked *