Kerberos 4769 still using RC4 (0x17) even though AES is enabled – why?
Posted by maxcoder88@reddit | sysadmin | View on Reddit | 12 comments
Hi,
I’m investigating Kerberos Event ID 4769 where the service ticket is still being encrypted with RC4 (0x17), even though AES is enabled and advertised by all sides.
SQLCLS$ (Cluster computer account)
Here is the event:
A Kerberos service ticket was requested.
Account Information:
Account Name: ADMIN@CONTOSO.DOMAIN
Account Domain: CONTOSO.DOMAIN
Logon GUID: {8d7a3861-1771-7308-2117-75941ece4a7b}
Service Information:
Service Name: SQLCLS$
Service ID: CONTOSO\SQLCLS$
MSDS-SupportedEncryptionTypes: 0x27 (DES, RC4, AES-Sk)
Available Keys: AES-SHA1, RC4
Domain Controller Information:
MSDS-SupportedEncryptionTypes: 0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
Available Keys: AES-SHA1, RC4
Network Information:
Advertized Etypes:
AES256-CTS-HMAC-SHA1-96
AES128-CTS-HMAC-SHA1-96
Additional Information:
Ticket Encryption Type: 0x17
Session Encryption Type: 0x12
Failure Code: 0x0
So:
The client advertises AES128/AES256
The DC supports AES
The service account supports AES
But the ticket is still issued using RC4 (0x17)
Why would Kerberos choose RC4 in this case?
Is this typically caused by:
Old passwords / legacy keys on the service or user account?
Missing msDS-SupportedEncryptionTypes on the user?
What is the correct remediation path?
jtheh@reddit
Did you set DefaultDomainSupportedEncTypes?
maxcoder88@reddit (OP)
No, I did not set the
DefaultDomainSupportedEncTypesregistry key manually.That value does not exist on our DCs.
We configured Kerberos encryption types via Group Policy instead:
Domain Controllers Policy → Security Options →
“Network security: Configure encryption types allowed for Kerberos”
Currently the allowed types are:
jtheh@reddit
RC4 is allowed, so it will be used
is your SQLCLS$ service accounts msDS-SupportedEncryptionTypes set to AES?
The GPO does not affect domain controllers handling tickets, only the request
if you want your DC to not hand out RC4, set DefaultDomainSupportedEncTypes to 0x38 (after verifying all accounts can handle AES)
maxcoder88@reddit (OP)
I did not set the msDS-SupportedEncryptionTypes attribute
jtheh@reddit
Check it, and update it to support AES as well (should be the same value as for all other computer objects)
If it is not set at all (empty value), then the DefaultDomainSupportedEncTypes will be followed. If that is also not set to a custom value, the default is 0x27 (DES, RC4, AES Session Keys).
EducationAlert5209@reddit
No GPO set the Enctype in domain. But some objects got value and some not set. Noticed some users trying to access file server got blocked.
Do I need the GPO?
jtheh@reddit
I recommend to take a look at this comprehensive overview and guide regarding all required steps and more information.
https://strongwind1.github.io/Kerberos/security/quick-start.html
Massive-Reach-1606@reddit
you either didnt update the passwords when flipping cyphers or your missing your SPN for sql.
maxcoder88@reddit (OP)
By the way, this SQL is running under a cluster computer object. What needs to be done in this case?
If we need to set the
msDS-SupportedEncryptionTypesattribute, what value should be used?Massive-Reach-1606@reddit
https://techcommunity.microsoft.com/blog/coreinfrastructureandsecurityblog/decrypting-the-selection-of-supported-kerberos-encryption-types/1628797
Set-ADUser -Identity -Replace @{msDS-SupportedEncryptionTypes=#}
maxcoder88@reddit (OP)
In my case this is a SQL Failover Cluster, so the Kerberos principal is not a user account but a computer object:
Therefore,
Set-ADUseris not applicable here.Massive-Reach-1606@reddit
https://techcommunity.microsoft.com/discussions/windows-security/nov-2022-update-impacted-windows-failover-cluster/3676930
https://www.reddit.com/r/sysadmin/comments/188iq99/disabling_rc4_kerberos_encryption_type_in_your_ad/