Primary users with SPN not supporting AES encryption on Kerberos - AD Vulnerabilities

Question

Hello Experts,

I am currently working on an Active Directory remediation project. During our assessment using Purple Knight, we identified the following vulnerability:

Finding: Primary users with SPNs not supporting AES encryption on Kerberos

Description:

This indicator shows all primary users with SPNs that do not support AES-128 or AES-256 encryption types.

Recommended Remediation:

Best practice is to enable AES encryption support on service accounts.

I am a bit confused by the description and the recommended remediation.

The finding states that these accounts do not support AES, while the remediation recommends enabling AES.

1. My question is: if an account or the application using that account does not currently support AES, how can we simply enable AES without potentially breaking authentication?
2. From my understanding, before enabling AES on any service account, we should first validate with the application or service owner that the application supports AES-based Kerberos authentication. Otherwise, enabling AES without verification could result in authentication failures or service outages. My questions are: a. Is my understanding correct? b. What is the recommended validation process before enabling AES on service accounts? c. What questions should we ask the application or service owners to confirm that their application supports AES and that enabling AES will not impact authentication? d. Are there any Microsoft-recommended validation steps or best practices for performing this assessment?

I would appreciate any guidance or real-world experience on handling this remediation safely in production environments.

Thanks in advance!

Answer 1

Hello @Nidhi Priya

Your understanding is correct. The recommendation to enable AES should not be interpreted as "turn it on for every service account immediately." The finding simply indicates that the account is currently not configured to use AES encryption types, which may expose it to weaker Kerberos encryption (such as RC4), but compatibility must be validated first.

A typical remediation approach is:

• Identify the service account and associated application (via the SPN).
• Confirm with the application owner/vendor that the application supports Kerberos AES (AES128 and/or AES256). Most modern Windows-based applications do, but some legacy applications may still rely on RC4.
• Enable AES by updating the account's msDS-SupportedEncryptionTypes attribute (or via the account properties in ADUC if available).
• Reset the service account password after enabling AES so new AES Kerberos keys are generated. This is an important step that is often overlooked.
• Restart the service (if required) and validate authentication by checking Kerberos events (for example, Event IDs 4768/4769) to confirm AES tickets are being issued.
• Roll out the change gradually, starting with non-production systems where possible.

Before enabling AES, it's worth asking the application owner:

• Is the application Kerberos-aware, or does it rely on NTLM?
• Is the application or service vendor certified to support AES128/AES256?
• Are there any legacy clients or operating systems that still require RC4?
• Is there a rollback plan if authentication issues occur?

Microsoft generally recommends moving away from RC4 toward AES, but production environments should validate compatibility before enforcing the change. If you have older operating systems, Java applications with outdated Kerberos libraries, or third-party appliances, they should be tested first.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.