Last active
November 14, 2022 11:27
-
-
Save jhawkwind/5603bfc4cc08b3772ab8f9c0bf6a915e to your computer and use it in GitHub Desktop.
This is to fix MS's F'up for the Kerberos patch.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| In reference to https://dirteam.com/sander/2022/11/11/knowledgebase-you-experience-errors-with-event-id-14-and-source-kerberos-key-distribution-center-on-domain-controllers/ | |
| When you get Event ID 14 all the time because, of Microsoft's November 2022 updates, getting the following error message: | |
| While processing an AS request for target service krbtgt, the account … did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes were: …. The accounts available etypes were 23 18 17. Changing or resetting the password of … will generate a proper key. | |
| Run the following command on the Domain Controllers to strip out all the support Encryption type settings to whatever is set on the KDC: | |
| Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x18 -and -not msDS-supportedEncryptionTypes -bor 0x7 -and (objectClass -eq 'user' -or objectClass -eq 'computer')" | Set-ADObject -Clear "msDS-SupportedEncryptionTypes" | |
| Workaround solution is on a domain controller, run the following: | |
| Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x18 -and -not msDS-supportedEncryptionTypes -bor 0x7 -and (objectClass -eq 'user' -or objectClass -eq 'computer')" | Set-ADObject -Clear "msDS-SupportedEncryptionTypes"; repadmin /syncall /APed; | |
| This clears the Supported Encryption Types flag on each computer account, and then pushes it to the other domain controllers. Which will allow use of the RC4 algorithm. | |
| For some reason the patch screwed things up due to a mismatch of behaviors. On the domain controller side, disabling RC4 will tell the KDC to authenticate with RC4 first, then AES 256, then AES 128; enabling RC4 will permit RC4 Kerberos authentication as normal (along with any other options). Fine. | |
| But on the non-domain controllers, the patch is set to reset computer account passwords and remove the RC4 keys from the computer account and changing the defaults to use AES 128 and AES 256. Thus disabling the RC4 keys for the computer account; which of course triggers the inappropriate domain controller behavior. | |
| So each time a computer restarts, the flags gets set correctly but a non-working state. Clearing the flags will permit any logins. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment