Understanding Kerberos Encryption Type Selection When msDS-SupportedEncryptionTypes = 28 (RC4 + AES128 + AES256)

Question

Hello Experts,

I am trying to understand how Active Directory and Kerberos choose the encryption type when a service account supports multiple encryption types.

For example, the msDS-SupportedEncryptionTypes attribute can have the following values:

• RC4 = 0x4
• AES128 = 0x8
• AES256 = 0x10
• AES128 + AES256 = 0x18
• RC4 + AES128 + AES256 = 0x1C (28 decimal)

If a service account is configured with RC4 + AES128 + AES256 (28), I would like to understand how the Key Distribution Center (KDC) decides which encryption type is actually used when issuing a Kerberos service ticket.

Specifically, I am trying to understand the following:

1. What is the negotiation mechanism between the client, KDC, and service account when multiple encryption types are available?
2. How does the KDC determine which encryption type to use?
3. Does the client advertise its supported encryption types, and does the KDC always choose the strongest common encryption type?
4. In what scenarios would RC4 still be selected even though AES128 and AES256 are also enabled on the service account?
5. Is there a documented priority order (for example, AES256 → AES128 → RC4), or are there other factors involved in the selection process?

I am looking for a conceptual explanation of the selection and negotiation process rather than just the bitmask values.

Thanks!

Nidhi

Answer 1

Hi Nidhy Priya,

The key concept to understand is that Kerberos does not perform a two-way encryption negotiation in the same way that TLS does. When a client requests a service ticket, the final encryption type is selected by the Key Distribution Center (KDC) based on the encryption types that are available and allowed within the environment.

A. How the KDC selects the encryption type

When the client requests a service ticket (TGS-REQ), it includes a list of encryption types that it supports.

• The KDC then evaluates:
• The encryption types advertised by the client.
• The encryption types allowed by Kerberos policy and supported by the KDC.
• The encryption types available for the target service account, including the actual cryptographic keys present for that account.

The KDC selects the strongest encryption type that is supported by all parties and for which a valid key exists.

• Client Supported Types -> KDC Allowed Types -> Service Account Available Keys -> Strongest Common Encryption Type

B. What does msDS-SupportedEncryptionTypes do?

This attribute does not define a preference order and does not force the KDC to use a particular encryption type. It simply indicates which encryption types the account is configured to support.

For example:

• RC4 = 0x4
• AES128 = 0x8
• AES256 = 0x10
• AES128 + AES256 = 0x18
• RC4 + AES128 + AES256 = 0x1C (28 decimal)

A value of 28 (0x1C) means that RC4, AES128, and AES256 are all potentially available. The KDC will still determine the final encryption type based on the strongest common option that is actually usable.

C. Does the KDC prefer AES over RC4?

Yes.

In modern Active Directory environments, when valid keys exist and both the client and KDC support AES, Windows Kerberos generally prefers:

• AES256 > AES128 > RC4

Therefore, if the client, KDC, and service account all support AES256, the service ticket is typically issued using AES256.

D. Why might RC4 still be selected when AES is enabled?

Even if a service account is configured with 0x1C (28), RC4 may still be used in several situations:

• 1. The client only supports RC4

If the requesting client or application advertises only RC4, then RC4 becomes the only common encryption type available.

• 2. The service account does not have valid AES keys

This is one of the most common causes.

Although the account may be configured to support AES through msDS-SupportedEncryptionTypes, Active Directory can only use AES if valid AES keys have been generated from the account password.

If the service account password has not been reset since AES support was introduced or enabled, the required AES keys may not exist. In that case, the KDC may fall back to RC4 even though AES appears to be enabled.

• 3. Kerberos policy restrictions

Group Policy settings such as "Network security: Configure encryption types allowed for Kerberos" can restrict the encryption types available to the client, server, or KDC. If AES is disabled through policy, RC4 may be selected instead.

• 4. Legacy applications or interoperability requirements

Some older operating systems, non-Windows Kerberos implementations, or legacy applications may only support RC4 and therefore drive the selection toward RC4.

=====================

I hope this conceptual breakdown clarifies the internal KDC logic!

If this resolves your query, please consider hitting "Accept Answer" so other users facing this scenario can easily find the solution as a reference.