I had this happen to a customer today and none of the above fixed the issue.
It turns out some November 2022 patches were the culprit. To fix the issue, I first followed the instructions on this blog:
https://dirteam.com/sander/2022/11/09/knowledgebase-you-experience-errors-with-event-id-42-and-source-kdcsvc-on-domain-controllers/
i.e., I did these steps:
Step 1:
If the Active Directory Domain Functional Level (DFL) is set to Windows Server 2003, upgrade it to Windows Server 2008, or up.
In the process, the password for the krbtgt account is reset, so do not reset the password for the krbtgt account as part of step 2 (within a week’s time span).
Skip to step 3.
Step 2:
To reset the password for the krbtgt account, use Microsoft’s New-KrbtgtKeys.ps1 PowerShell script from Github and run it on the Domain Controller holding the Primary Domain Controller Emulator (PDCE) Flexible Single Master Operations (FSMO) role.
Step 3:
Configure the affected user object(s) to no longer explicitly use RC4_HMAC_MD5.
When people sign out and sign in again after they’ve changed their passwords, their session keys will be AES encrypted and no longer be vulnerable in the context of CVE-2022-37966.
When RC4 is needed for the account, turn to Step 3 of the below alternative method.
Step 4:
Optionally, when no new errors with event ID 42 occur, configure the Network Security: Configure encryption types allowed for Kerberos setting in a Group Policy object targeting the domain to explicitly disable the DES_CBC_CRC, DES_CBC_MD5 and RC4_HMAC_MD5 encryption types and explicitly enable the AES128_HMAC_SHA1, AES256_HMAC_SHA1 and Future encryption types.
Next, I rotated the computer account password on the affected member server/system(s):
Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount
Finally, I installed one of the following updates on the domain controllers, depending on the version of Windows Server:
Source: https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2022#november-2022
According to the doc linked above, installing the above updates on member servers/systems is not necessary. I can confirm that I did not need to do so to resolve the issue in this environment.
Once all of the above was done, disabling and re-enabling the NIC (or rebooting) the affected member server/system(s) did the trick.