Skip to content

Kerberos Encryption: The Short Version

This is the 5-minute version. No protocol specs, no packet traces, no 14-step decision guides. Just the big picture, what's changing, and what you need to do about it.

Need the full deep-dive? Head to the Security overview. Already know the deal and just want the migration playbook? Jump to the Standardization Guide.

The 30-Second Version

  • Every Kerberos ticket is encrypted. The encryption type matters.
  • RC4 has been the default for 25 years. It's weak and getting killed off.
  • AES is the replacement. It's been available since Server 2008.
  • April 2026: Microsoft flips the switch. Accounts without explicit encryption settings stop getting RC4 tickets. If your services aren't ready, authentication breaks.
  • Your move: set msDS-SupportedEncryptionTypes = 24 on every SPN-bearing account and DefaultDomainSupportedEncTypes = 24 on every DC. That's 90% of the work.

How Kerberos Authentication Works

You log in. Your workstation talks to the Domain Controller (the KDC) and gets a Ticket-Granting Ticket (TGT). Think of the TGT as an all-day wristband at an amusement park -- it proves you already showed your ID at the gate.

When you need to access a service (file share, SQL server, web app), your workstation shows the TGT to the DC and gets a service ticket for that specific service. Think of service tickets as ride tickets -- one per ride, and each one is locked with the service account's encryption key.

The service ticket is encrypted with the service account's key. That's the part that matters for this page -- because the encryption type determines how hard that ticket is to crack if someone grabs it off the wire.

sequenceDiagram
    participant W as Your Workstation
    participant DC as Domain Controller
    participant S as Service

    W->>DC: 1. I'm Alice, here's proof (password-derived key)
    DC-->>W: Here's your TGT (all-day wristband)

    W->>DC: 2. I have a TGT, I need access to SQL01
    DC-->>W: Here's a service ticket for SQL01

    W->>S: 3. Here's my service ticket
    S-->>W: You're in

Why does the encryption type matter?

Any authenticated domain user can request a service ticket for any SPN. An attacker grabs the ticket and tries to crack it offline. With RC4, that takes hours. With AES, it takes centuries. That's the whole game -- see Kerberoasting for the attack details.

Why RC4 Is a Problem

RC4 has been the implicit default for user service accounts since Windows 2000. Here's why that's bad:

RC4 AES
Key derivation MD4 hash of password (one pass, no salt) PBKDF2 with salt + 4,096 iterations
Key = NTLM hash? Yes -- same key, same attack surface No -- completely separate key
Cracking speed ~800x faster than AES Baseline
Rainbow tables Work (no salt) Don't work (salted per account)
Status Deprecated, being removed Current standard

The bottom line: if a service account uses RC4 and an attacker grabs its ticket, they can crack weak passwords in minutes. With AES, even mediocre passwords hold up much longer. Full algorithm comparison at Algorithms & Keys.

The 4 Controls That Decide Encryption

There are exactly four settings that determine which encryption a Kerberos service ticket uses. They have a strict pecking order -- the one at the top always wins.

flowchart TD
    A["<b>1. msDS-SET</b>\nPer-account AD attribute\nWins when non-zero"]
    B["<b>2. DDSET</b>\nRegistry on each DC\nFallback when #1 is unset"]
    C["<b>3. GPO Filter</b>\nGroup Policy on DCs\nBlocks etypes not listed"]
    D["<b>4. RC4 Kill Switch</b>\nApril 2026 enforcement\nDefaults to AES-only"]

    A -->|"If unset"| B
    B -->|"Filtered by"| C
    C -->|"Overridden by"| D

    style A fill:#16a34a,stroke:#15803d,color:#fff
    style B fill:#2563eb,stroke:#1d4ed8,color:#fff
    style C fill:#d97706,stroke:#b45309,color:#fff
    style D fill:#dc2626,stroke:#b91c1c,color:#fff

  1. msDS-SupportedEncryptionTypes -- an AD attribute on each SPN-bearing account (service accounts, computers, gMSAs). If it's set, the KDC uses it. End of story. Target: 24 (0x18 = AES128 + AES256). Full reference

  2. DefaultDomainSupportedEncTypes (DDSET) -- a registry key on each DC. This is the fallback for accounts that don't have #1 set. Takes effect immediately, no restart needed. Target: 24. Full reference

  3. SupportedEncryptionTypes (GPO) -- a Group Policy setting applied to DCs. Acts as a hard filter on top of #1 and #2. If it says "AES only," the KDC won't issue RC4 tickets even if the account asks for them. Requires a KDC restart. Full reference

  4. RC4DefaultDisablementPhase -- the April 2026 kill switch. When enforcement kicks in, accounts with neither #1 nor #2 set automatically get AES-only tickets instead of RC4. Full reference

The GPO does NOT set DDSET

This trips everyone up. The Kerberos GPO and the DefaultDomainSupportedEncTypes registry key are two separate things. Setting the GPO does not populate DDSET, and setting DDSET does not require a GPO. They work independently. See Registry Settings for the details.

The RC4 Deprecation Timeline

timeline
    title RC4 Deprecation Timeline
    section Already happened
        Nov 2022 : AES session keys become default
                 : DDSET registry key introduced
        Jan 2025 : New fields in Event 4768/4769
        Jan 2026 : Audit phase begins
                 : Kdcsvc events 201-209 log RC4 usage
    section Coming soon
        Apr 2026 : Enforcement with rollback
                 : Unconfigured accounts default to AES
        Jul 2026 : Permanent enforcement
                 : No rollback possible

What happens in April 2026 if you do nothing

Any SPN-bearing account that doesn't have msDS-SupportedEncryptionTypes explicitly set and doesn't have a DefaultDomainSupportedEncTypes fallback on the DC will stop getting RC4 tickets. If those accounts don't have AES keys (because the password was never reset since DFL 2008), authentication fails. No ticket, no access, service down.

Full timeline and event reference at RC4 Deprecation.

What You Need to Do

flowchart TD
    START["SPN-bearing account"] --> Q1{"msDS-SET\n= 24?"}
    Q1 -->|Yes| Q2{"Has AES keys?"}
    Q1 -->|No| FIX1["Set msDS-SET = 24"]
    Q2 -->|Yes| SAFE["Ready for\nApril 2026"]
    Q2 -->|Unsure| FIX2["Reset password\nto generate AES keys"]
    FIX1 --> Q2
    FIX2 --> SAFE

    style SAFE fill:#16a34a,stroke:#15803d,color:#fff
    style FIX1 fill:#d97706,stroke:#b45309,color:#fff
    style FIX2 fill:#dc2626,stroke:#b91c1c,color:#fff

Step 1: Find all SPN-bearing accounts

These are the accounts that service tickets get encrypted with. Five types exist: user service accounts, computer accounts, gMSA, MSA, and dMSA.

Get-ADObject -LDAPFilter '(servicePrincipalName=*)' `
  -Properties objectClass, 'msDS-SupportedEncryptionTypes' |
  Select-Object Name, objectClass, 'msDS-SupportedEncryptionTypes'

For a grouped summary by account type, see the full SPN overview query.

Step 2: Check their encryption type settings

Look at the msDS-SupportedEncryptionTypes value. You want 24 (AES128 + AES256). Common values you'll see:

Value Meaning Action needed?
0 or blank Not set -- falls back to DDSET or RC4 default Yes -- set to 24
4 RC4 only Yes -- set to 24
7 DES + RC4 Yes -- set to 24
24 (0x18) AES128 + AES256 No -- you're good
28 (0x1C) RC4 + AES128 + AES256 OK for now, but consider dropping RC4

Use the Encryption Type Calculator to decode any value you find.

Step 3: Set msDS-SET = 24 on all SPN-bearing accounts

# User service accounts
Get-ADUser -Filter 'servicePrincipalName -like "*"' |
  Set-ADUser -Replace @{'msDS-SupportedEncryptionTypes' = 24}

For gMSA, MSA, and dMSA bulk scripts, see the Standardization Guide. Computer accounts are handled automatically by GPO -- don't set them manually.

Step 4: Make sure accounts have AES keys

An account only gets AES keys when its password is set (or reset) at domain functional level 2008 or higher. If the account password hasn't been changed since before that, it only has RC4 keys. Setting msDS-SET = 24 on an account without AES keys = authentication failure.

# Find accounts with passwords older than AES key availability
$AESdate = (Get-ADGroup -Filter * -Properties SID, WhenCreated |
  Where-Object { $_.SID -like '*-521' }).WhenCreated

Get-ADUser -Filter 'Enabled -eq $true' -Properties passwordLastSet |
  Where-Object { $_.passwordLastSet -lt $AESdate }

For definitive key auditing (not just date-based), see Auditing Kerberos Keys.

Step 5: Set DDSET = 24 on every DC

This is the safety net for any SPN-bearing account you missed (or that gets created with msDS-SET = 0 by default).

# Run on every DC, or push via GPO preferences
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' `
  -Name 'DefaultDomainSupportedEncTypes' -Value 24 -Type DWord

Takes effect immediately. No restart needed.

Step 6 (optional): Go further

  • Apply an AES-only GPO to your DC OU to hard-filter RC4 at the KDC level. See Group Policy. Requires a KDC restart.
  • Migrate to gMSA wherever possible. 240-character auto-rotating passwords, impossible to crack. See Mitigations.
  • Enable Kerberos auditing (Event 4768/4769 with Success+Failure) and watch for Kdcsvc events 201-209 after the January 2026 updates.

Common Gotchas

  • Three registry paths, only two work. There are multiple places in the registry where "SupportedEncryptionTypes" appears. Only two of them actually affect ticket issuance. Setting the wrong one does nothing. The Registry Audit page maps which paths are functional and which are dead ends.

  • GPO and DDSET are separate things. The Kerberos GPO creates a filter (blocks certain etypes). DDSET sets a default (what etypes to use when the account doesn't specify). They stack independently. Setting one does not set the other.

  • Old accounts might not have AES keys. If a user service account's password was last set before the domain was raised to functional level 2008, the account only has RC4 keys stored in AD. Telling the KDC "give me AES" for an account with no AES keys = failure. Reset the password first.

  • Computer accounts take care of themselves. When you apply the Kerberos GPO to computers, they auto-update their own msDS-SupportedEncryptionTypes in AD. You don't need to manually set it on computer accounts.

Never set KdcUseRequestedEtypesForTickets = 1

This registry key tells the KDC to ignore the target account's msDS-SupportedEncryptionTypes and use whatever the client asks for instead. It completely defeats per-account AES enforcement. An attacker can request RC4 tickets for any account, regardless of its settings. See Registry Settings for the details.

Emergency rollback (April - July 2026)

If enforcement breaks something, you can roll back to audit-only mode until July 2026: 

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
  -Name 'RC4DefaultDisablementPhase' -Value 1 -Type DWord
# Restart the KDC service
Restart-Service KDC
After July 2026, this key is removed and rollback is no longer possible.

Quick Reference

Setting Where Target value Takes effect Details
msDS-SupportedEncryptionTypes AD attribute on each SPN account 24 (0x18) Immediately msDS-SET reference
DefaultDomainSupportedEncTypes Registry on each DC (Services\KDC) 24 (0x18) Immediately Registry reference
SupportedEncryptionTypes (GPO) Group Policy on DC OU AES128 + AES256 After KDC restart GPO reference
RC4DefaultDisablementPhase Registry on DCs (Policies\...\Kerberos) 0 (off) or 1 (audit) After KDC restart RC4 deprecation

What's Next