Blog Post

Ask the Directory Services Team
2 MIN READ

November 2022 Out of Band update released! Take action!

JR_Nieves's avatar
JR_Nieves
Icon for Microsoft rankMicrosoft
Nov 18, 2022

Greetings from the Windows Directory Services team!

The team wanted to bring to your attention the November 17th, 2022 release of an Out of Band (OOB), non-security update that addresses the Kerberos authentication issues experienced in some environments after installing November 8, 2022 (or later) updates on domain controllers.

 

After installing Windows Updates released on November 8, 2022 on Windows domain controllers, you might have issues with Kerberos authentication.

This specific failure is identified by the logging of Microsoft-Windows-Kerberos-Key-Distribution-Center Event ID 14 in the System event log of DC role computers 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.

Some scenarios that might be affected:

For important details about how to obtain and install the November OOB update, please see the following link on Windows Release Health Message Center at:
Published Nov 18, 2022
Version 1.0

26 Comments

Show More
  • Alban1998's avatar
    Alban1998
    Iron Contributor
    Nov 21, 2022

    cgaurav20 

    I suggest to make sure all you DC have an identical configuration (including patch versioning), as it is really a recommend setting, avoiding unsupported scenarios.

    As for your issue, if it's not a bug, then you may have a real issue there - try investigating operating system, apps and accounts related to the error message to see if something is actively using RC4.

  • Finalnet's avatar
    Finalnet
    Copper Contributor
    Nov 21, 2022

    cgaurav20: In our case, only a few users were affected. A new user (Not copied) can be created for testing.
    If the new user has no problems, it is probably the AES128 and AES256 bit options under <UserObject>->Account-> Scroll down a little.

     

    We have not modified any policies to solve the problem.

     

    I have testet in a VM once for the user "msDS-SupportedEncryptionTypes" is set the problems appear until option is reverted.

    You can check with: 

     

    Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | ft msDS-SupportedEncryptionTypes, name, UserPrincipalName -AutoSize

     

    The eventlog will show the entries as soon as one affected users does anything with kerberos...

     

    If you see Tickets (elevated cmd) "klist –li 0x3e7"

    But none (non-elevated cmd) for "klist"

    It's likley to be a user problem.

     

    I suspect that the options in the user object from the bitmask still contain the old disabled protocols. However, this is only a guess.

  • cgaurav20's avatar
    cgaurav20
    Copper Contributor
    Nov 21, 2022

    Alban1998 Finalnet We already have this security feature enabled for the DC's "Network security: Configure encryption types allowed for Kerberos" which is only restricting Kerberos to AES128/AES256 & Future keys. No DES & RC4 is allowed in our environment. Neither we have any per account setting configured for AES or other types. 

     

    We just have 2 DC in that particular forest, one is patched with November updates (Including 17th Nov OOB patch) other one is not and there are no authentication failures for the unpatched DC with exact same configuration. So, it's definitely the issue post patching.

    So, is it really required to change this setting "Network security: Configure encryption types allowed for Kerberos" as not defined? Will it not make RC4 encryption to be allowed for use if some application want it? I don't think our security team would approve to remove these settings. Any other suggestion?

  • Alban1998's avatar
    Alban1998
    Iron Contributor
    Nov 21, 2022

    cgaurav20 Hello, did you check if DES encryption is enabled for this account ?

     

    JR_Nieves Hello, could you confirm if this update will prevent OS older than Vista to authenticate with domain controllers ? There are still customers with Windows Server 2000/2003 out there, and it could be the last push to trigger a migration.

  • Finalnet's avatar
    Finalnet
    Copper Contributor
    Nov 21, 2022

    What helped us:
    Uncheck the AES 128 bit and AES 256 bit boxes under Account for the affected users.
    Under the attributes, check that msDS-SupportedEncryptionTypes = Not set or 0.

     

    No need to reenable RC4

    I'm not 100% sure if related to the problem.

  • cgaurav20's avatar
    cgaurav20
    Copper Contributor
    Nov 20, 2022

    Apparently after installing this out of band update still we are facing issue but with slight change this event 14 is fixed and now we have an issue logged with event id 27 at stage of generating TGS ticket as follows.

    While processing a TGS request for the target server ****, the account **** did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 9). The requested etypes were 23 3 1. The accounts available etypes were 23 18 17.

    To fix this I still had to apply the workaround of allowing RC4 encryption, can you suggest please if there is a permanent fix available for this too so I can revert this setting?