Master in Progress IT blog

Introduction

As organizations continue their journey toward stronger authentication security, eliminating RC4 and enforcing AES-only Kerberos configurations has become a common objective.

Recently, we worked on a case where everything appeared to be configured correctly for AES, yet the Key Distribution Center (KDC) continued issuing RC4-encrypted service tickets. What started as a straightforward troubleshooting exercise quickly turned into a deep dive into KDC decision logic and protocol implementation details.

This blog walks through the troubleshooting process, the dead ends we explored, and the unexpected root cause that ultimately explained the behavior.

---

The Scenario

The customer was hosting services on a Linux server joined to Active Directory.

The objective was simple: Ensure Kerberos tickets were issued using AES encryption.

Linux Configuration

The Linux server had been configured to allow only AES encryption types:

[libdefaults]

default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96

The team also:

• Regenerated the keytab.
• Rejoined the system to the domain.
• Verified the keytab contained only AES keys.
• Rotated the machine account password during the rejoin process.

Everything on the Linux side looked perfect.

---

Active Directory Validation

The corresponding computer object had been explicitly configured for AES only.

msDS-SupportedEncryptionTypes = 24

Which corresponds to:

0x08 = AES128

0x10 = AES256

0x18 = AES128 + AES256

24 decimal = 0x18 hexadecimal

Notably:

• RC4 (0x04) was not configured.
• Replication was healthy.
• Attribute values were consistent across all domain controllers.

At this point, nothing suggested the KDC should ever consider RC4.

---

The Strange Behavior

A Windows client requested a service ticket for a service hosted on the Linux server.

The request advertised AES:

EType: aes256-cts-hmac-sha1-96 (18)

The TGT itself was also AES encrypted:

KerbTicket Encryption Type:

AES-256-CTS-HMAC-SHA1-96

However, when examining the resulting service ticket

KerbTicket Encryption Type:

RC4-HMAC (23)

The session key remained AES:

Session Key Type:

AES-256-CTS-HMAC-SHA1-96

But the ticket itself was encrypted using RC4.

This distinction is important because many engineers immediately assume that if the session key is AES, the ticket encryption must also be AES. That assumption is not always correct.

---

Initial Troubleshooting

Several potential causes were investigated.

1. Replication Issues

Could one DC still have stale values?

No.

All domain controllers showed consistent metadata and identical attribute values.

---

2. Old Keys Existing on the Account

Could RC4 keys still exist for the computer account?

The machine had:

• Been rejoined.
• Rotated its password.
• Generated a fresh keytab.

This made stale key material unlikely.

---

3. Incorrect Client Configuration

Was the Windows client requesting RC4?

No.

Network traces showed the client advertising AES.

---

4. Service Principal Name Issues

Was the ticket targeting another object unexpectedly?

SPNs were verified and resolved correctly to the Linux computer account.

---

5. KDC Policy or Forest-Wide Configuration

Were there domain-level settings forcing RC4?

Nothing unusual was found.

The environment consistently pointed back to the same Linux computer object.

---

The Key Clue

Eventually, KDC debug logging revealed something unexpected:

SupportedEncryptionTypes 0x27

Instead of using the configured value:

0x18

the KDC was behaving as if the account supported:

0x27

Which expands to:

0x01 DES-CBC-CRC

0x02 DES-CBC-MD5

0x04 RC4

0x20 FAST

The question became:

Why would the KDC ignore the account’s actual msDS-SupportedEncryptionTypes value?

---

The Breakthrough

The answer was buried in the Microsoft Kerberos implementation documentation (MS-KILE).

According to the protocol behavior, under specific circumstances the KDC may ignore the msDS-SupportedEncryptionTypes attribute and instead use its default encryption type set.

One of those conditions involves the value stored in:

OperatingSystemVersion

For accounts where the OperatingSystemVersion attribute indicates an operating system version lower than 6, the KDC can treat the account as a legacy system and fall back to its default encryption type behavior.

In this scenario, the KDC effectively ignored:

msDS-SupportedEncryptionTypes = 0x18

and instead used:

0x27

resulting in RC4 being considered valid and ultimately selected for service ticket encryption.

---

Why This Was Difficult To Find

Most Kerberos troubleshooting guidance focuses on:

• Keytabs
• Password resets
• SPNs
• msDS-SupportedEncryptionTypes
• Client encryption preferences

All of those areas were configured correctly.

Very few engineers would think to investigate the OperatingSystemVersion attribute on a Linux computer account because:

1. The attribute is traditionally associated with Windows systems.
2. Linux administrators rarely manage it directly.
3. Most documentation surrounding Kerberos encryption type selection never mentions it.
4. The behavior is documented within protocol specifications rather than common troubleshooting guidance.

As a result, the investigation can easily become stuck because every visible configuration appears correct.

---

Lessons Learned

When troubleshooting Kerberos encryption type selection, don’t stop after validating:

• Client encryption types
• Keytab contents
• Password rotation
• SPNs
• msDS-SupportedEncryptionTypes

If the KDC appears to be ignoring a valid AES-only configuration, consider examining attributes that influence how the KDC classifies the account itself.

In our case, the decisive clue wasn’t found in the keytab, the client request, or the encryption types attribute. It was hidden in the account metadata and the KDC’s internal decision-making logic.

---

Final Thoughts

This case serves as a reminder that Kerberos troubleshooting often requires looking beyond the obvious configuration settings. Even when every component appears correctly configured for AES-only operation, subtle account attributes can influence how the KDC evaluates encryption support.

The most interesting part of this investigation was not the fix itself, but the realization that the KDC was behaving exactly as designed. The challenge was finding the design detail buried deep within the protocol specification.

Sometimes the hardest Kerberos issues are not caused by misconfiguration. They are caused by assumptions about how the KDC makes decisions.

And occasionally, the answer is hidden in a protocol document few people ever need to read.