I've got some domain controllers that are fully updated with the latest Windows patches, but I'm facing a bit of a head-scratcher. I've enabled Kerberos auditing, yet I'm not seeing any Event IDs from 201 to 209 in the System event logs. An article I read suggested this should indicate that everything is functioning correctly. However, running the script ".Get-KerbEncryptionUsage.ps1 -Encryption RC4" shows that a few computers and service accounts are still using RC4 encryption. It seems like the SessionKey is set to AES256-SHA96, but the Ticket is still RC4. I'm considering adjusting the "RC4DefaultDisablementPhase" registry key for a temporary fix while I figure this out. Can anyone clarify which resources are reliable for understanding this situation?
6 Answers
If you haven't already, check out the resource on Kerberos in Active Directory. It's packed with useful info that could help clarify what you're dealing with regarding encryption types and the negotiation process.
Interestingly, my results from the script were reversed. My QNAP NAS reported as Ticket: AES256-SHA96 with SessionKey: RC4, which shouldn't happen. I’m still working out the details of why that is, but it certainly adds to the confusion!
You should manually edit the AD object using Active Directory Users and Computers or PowerShell to change the msDS-SupportedEncryptionTypes to 0x18 (which is 24 in decimal). This will make sure you start using AES encryption instead of RC4.
I encountered something similar. In my case, tickets were encrypted with RC4, but I had AES keys available for the service account and the account using them. I didn’t see any 20x events in the logs either. I manually configured the SPN accounts to support only AES (using Set-ADUser with the -KerberosEncryptionType option), and afterward, I had no issues with AES tickets being used instead of RC4. Just make sure to double-check your setup. You might find that it all works out fine!
Sounds like a smart move! I've seen changes in ticketing like that too, so it’s worth looking into all the encryption types on your accounts.
I recommend setting the RC4DefaultDisablementPhase to 1. Also, what version of your domain controllers are you using? Are you seeing any Event IDs 4768 or 4769? Sometimes just regenerating the service accounts' passwords can help too. That might resolve the RC4 issues you're facing.
One thing to consider is the age of the passwords for your service accounts. If they haven’t been updated in a while, the keys for AES won’t have been generated even if the account is allowed to use it. I recently reset passwords for some service accounts and after that, I noticed they started using SHA encryption. You might want to check those account passwords to ensure they’re not too old, as that can affect your results.
You can also manage this through Group Policy or tools like IISCRYPTO, which might be easier.