Kerberos Security Overview

A sysadmin-focused summary of Kerberos security posture in Active Directory: what is at risk today, how to audit your environment, and what the 2026 RC4 deprecation means for your domain.

Already familiar with Kerberos and just need to migrate? Jump to the Standardization Guide.

New to Kerberos encryption?

Start with the Quick Start Guide for a 5-minute overview with diagrams.

---

Why This Matters

• RC4 was the default for 20+ years. Until April 2026, every AD account without an explicit msDS-SupportedEncryptionTypes value received RC4 service tickets. Enforcement is now active, but most environments still have accounts that were configured (or left unconfigured) during the RC4 era.
• RC4 is fast to crack. The RC4 key is the NTLM hash (MD4(UTF-16LE(password)), no salt). It cracks at roughly 800 times the speed of AES. See Algorithms & Keys for benchmarks.
• Any domain user can Kerberoast. Any authenticated user can request a service ticket for any SPN, take it offline, and crack the user service account password. See Kerberoasting.
• RC4 key = pass-the-hash. Because the RC4 Kerberos key is identical to the NTLM hash, a compromised RC4 key doubles as a pass-the-hash credential.

If you have user service accounts with SPNs and no explicit msDS-SupportedEncryptionTypes, they are exposed right now.

---

RC4 Deprecation Timeline (CVE-2026-20833)

Microsoft is eliminating RC4 as the implicit default encryption type for Kerberos service tickets. This table tracks the full rollout:

Date	Phase	What Changes	Rollback?
November 2022	CVE-2022-37966	AES session keys become the default. DefaultDomainSupportedEncTypes registry key introduced.	N/A
January 2025	Enhanced auditing	New fields added to events 4768/4769: msDS-SupportedEncryptionTypes, Available Keys, Advertized Etypes, Session Encryption Type.	N/A
January 2026	Audit	Kdcsvc events 201-209 begin logging when RC4 is used by default. RC4DefaultDisablementPhase = 1.	N/A
April 2026	Enforcement	KDC defaults to AES-only (0x18) for accounts without explicit msDS-SupportedEncryptionTypes. Accounts relying on implicit RC4 will fail.	RC4DefaultDisablementPhase = 1
July 2026	Permanent	RC4DefaultDisablementPhase registry key removed. No rollback available. RC4 only works if explicitly enabled per-account or per-DC.	None

What this change is actually doing

Most accounts in AD have msDS-SupportedEncryptionTypes set to 0 (blank) — they don't declare which encryption types they support. When the KDC issues a ticket for one of these accounts, it has to pick a default. The entire 2026 change is about what that default is.

Period	Implicit default for blank accounts	In practice
Before April 2026	0x27 — RC4 ticket, AES session key	Every blank account gets RC4 service tickets. AES keys may exist but are never used for ticket encryption because the default doesn't include the AES bits.
April → July 2026	0x18 — AES-only	Blank accounts get AES tickets. RC4 is blocked. You can roll back to the old default via RC4DefaultDisablementPhase = 1.
After July 2026	0x18 — AES-only	Same as above, but the rollback key is removed. Permanent.

Accounts with an explicit msDS-SupportedEncryptionTypes (any non-zero value) are not affected by any of this — the KDC uses their declared value, not the default.

What actually happens to each account type

The KDC always picks the strongest etype from the account's declared set that the account has a key for. AES256 beats RC4. The only time RC4 appears is when AES is not possible.

Service tickets (the part enforcement controls):

Keys in AD	msDS-SET	Before enforcement	After enforcement (no DDSET)	After enforcement (DDSET = 0x3C)
AES + RC4	0 (blank)	RC4 ticket	AES256 ticket	AES256 ticket
RC4 only	0 (blank)	RC4 ticket	FAILS — KDC tries AES, no key exists	RC4 ticket (fallback)
AES + RC4	24 (AES)	AES256 ticket	AES256 ticket	AES256 ticket
AES + RC4	28 (RC4+AES)	AES256 ticket	AES256 ticket	AES256 ticket
AES + RC4	4 (RC4 only)	RC4 ticket	RC4 ticket	RC4 ticket
RC4 only	24 (AES)	FAILS — misconfig	FAILS — misconfig	FAILS — misconfig

Row 1 is the happy path — most modern accounts. AES keys exist, the KDC picks AES256 regardless of the default. The enforcement change is invisible to these accounts.

Row 2 is the dangerous case — old accounts with passwords that predate AES key generation (DFL 2008). Before enforcement, they got RC4 tickets. After enforcement with no DDSET, they break. Setting DDSET = 0x3C keeps them alive until you can reset their passwords to generate AES keys.

Rows 3-5 have explicit msDS-SET values — the enforcement default is irrelevant. The KDC uses the declared value.

Row 6 is a misconfiguration — someone set AES-only on an account that has no AES keys. This fails regardless of enforcement or DDSET. Fix: reset the account password to generate AES keys.

TGTs / login (not affected by enforcement — controlled by DC GPO and user's stored keys):

User's keys in AD	DC GPO includes RC4?	Pre-auth	TGT ticket
AES + RC4	Yes or No	AES256 (strongest key)	AES256 (always)
RC4 only	Yes	RC4 (only available key)	AES256 (always)
RC4 only	No (AES-only GPO)	FAILS — no AES key for AS-REP	—
RC4 only	No GPO set	RC4 (no filter blocking it)	AES256 (always)

The TGT ticket itself is always AES256 (encrypted with krbtgt's key). The enforcement phase has no effect on login. The risk for users with only RC4 keys is the DC GPO — if you set an AES-only GPO on domain controllers, those users cannot log in.

Override the implicit default with an explicit one

You do not have to accept Microsoft's implicit default. The DefaultDomainSupportedEncTypes (DDSET) registry key on each DC overrides it. An explicit DDSET takes precedence over the enforcement default — before and after July.

Set on EVERY DC — not replicated, must be set individually

# Value 60 (0x3C) = RC4 + AES128 + AES256 + AES session keys
# The KDC picks the strongest etype (AES256) but RC4 stays available as a fallback
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' `
  -Name 'DefaultDomainSupportedEncTypes' -Value 60 -Type DWord

Takes effect immediately — no KDC restart needed. With DDSET = 0x3C on every DC:

• The KDC picks AES256 for every blank account that has AES keys (strongest always wins)
• RC4 remains available as a fallback for accounts that can only do RC4 (no AES keys, legacy keytabs)
• The July 2026 enforcement is irrelevant to you — your explicit DDSET takes precedence over the internal default
• Monitor Event 4769 for Ticket Encryption Type = 0x17 (RC4) to find the accounts still using RC4 — those are the ones that need AES keys or explicit configuration

DDSET is a domain-wide blunt instrument

Setting DDSET to include RC4 re-enables RC4 for every account with blank msDS-SupportedEncryptionTypes. This is the right transitional step, but the goal is to set explicit msDS-SupportedEncryptionTypes on each account and eventually remove RC4 from DDSET. See the Standardization Guide for the full migration path.

April 2026 can break authentication

Any SPN-bearing account that has no msDS-SupportedEncryptionTypes set and either lacks AES keys or has clients that only support RC4 will fail to authenticate after the April 2026 update — unless DDSET is set to include RC4 on the DC handling the request.

If you need an immediate rollback during an outage (before July 2026 only):

Roll back RC4 enforcement to audit mode

Set-ItemProperty `
  -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" `
  -Name "RC4DefaultDisablementPhase" -Value 1
Restart-Service kdc

For the full event ID reference and pre-enforcement checklist, see RC4 Deprecation.

---

Four Layers That Control Encryption

Kerberos encryption behavior is controlled at four layers. Misunderstanding the interaction between them is the most common cause of encryption-related authentication failures.

Priority	Setting	Where	What It Controls	Target Value
1 (wins)	msDS-SupportedEncryptionTypes	AD attribute on each account	Which etypes the KDC uses for this account's service tickets. Always overrides layers below.	0x18 (24) = AES
2 (fallback)	DefaultDomainSupportedEncTypes	Registry on each DC	Assumed etypes for accounts with msDS-SupportedEncryptionTypes = 0. Per-DC, not replicated.	0x18 (24) = AES
3 (filter)	SupportedEncryptionTypes / GPO	Registry on each machine	Hard filter: the KDC will not issue a ticket with an etype absent from this list. On clients, controls what the Kerberos client requests.	AES-only on DCs
4 (2026)	RC4DefaultDisablementPhase	Registry on each DC	Overrides the KDC's internal default for accounts without explicit config. 1 = audit, 2 = enforce.	2 (enforce)

Layer 1 always wins. If msDS-SupportedEncryptionTypes is set on an account, layers 2-4 are irrelevant for that account's ticket encryption. When the GPO (layer 3) is set on a DC, it acts as a hard KDC filter (after KDC restart) that overrides DefaultDomainSupportedEncTypes (layer 2) for ticket issuance — the filter takes precedence, not an intersection. For clean configuration, align both layers.

For the full 12-input decision logic with 14 worked examples, see Encryption Type Negotiation and Etype Decision Guide.

---

Assess Your Environment

Run these five checks from a Domain Controller with RSAT to assess your current exposure.

1. SPN-Bearing Accounts by Encryption Configuration

How many accounts are using which etype configuration? This cross-type overview covers all five AD object types that can hold an SPN (user service accounts, computer accounts, gMSA, MSA, dMSA):

The following query covers all five AD object types that can hold a servicePrincipalName and groups the results by type and current msDS-SupportedEncryptionTypes value:

Get-ADObject -LDAPFilter '(servicePrincipalName=*)' `
  -Properties objectClass, objectCategory, 'msDS-SupportedEncryptionTypes' |
  ForEach-Object {
    $oc = $_.objectClass
    $type = if     ($oc -contains 'msDS-DelegatedManagedServiceAccount') { 'dMSA' }
            elseif ($oc -contains 'msDS-GroupManagedServiceAccount')     { 'gMSA' }
            elseif ($oc -contains 'msDS-ManagedServiceAccount')          { 'MSA' }
            elseif ($oc -contains 'computer')                            { 'Computer' }
            elseif ($_.objectCategory -like '*Person*')                  { 'User service account' }
            else                                                          { 'Other' }
    [PSCustomObject]@{ Type = $type; SetDec = [int]$_.'msDS-SupportedEncryptionTypes' }
  } |
  Group-Object Type, SetDec |
  Sort-Object { ($_.Group[0]).Type }, { ($_.Group[0]).SetDec } |
  Select-Object Count,
    @{N='Type';           E={ ($_.Group[0]).Type }},
    @{N='msDS-SET (dec)'; E={ ($_.Group[0]).SetDec }},
    @{N='msDS-SET (hex)'; E={ '0x{0:X}' -f ($_.Group[0]).SetDec }} |
  Format-Table -AutoSize

Accounts showing msDS-SET = 0 are using the domain default — which is AES-only (0x18) under enforcement, or whatever your explicit DDSET is set to. Accounts showing msDS-SET = 4 are explicitly RC4-only. Both need explicit msDS-SupportedEncryptionTypes values set.

For user service accounts specifically -- the primary Kerberoasting target -- find those with no config or RC4 enabled:

Find SPN-bearing user accounts exposed to Kerberoasting

Get-ADUser -Filter 'servicePrincipalName -like "*"' `
  -Properties msDS-SupportedEncryptionTypes, servicePrincipalName |
  Where-Object {
    [int]$_.'msDS-SupportedEncryptionTypes' -eq 0 -or
    [int]$_.'msDS-SupportedEncryptionTypes' -band 4
  } |
  Select-Object sAMAccountName,
    @{N='msDS-SET (dec)'; E={[int]$_.'msDS-SupportedEncryptionTypes'}},
    @{N='msDS-SET (hex)'; E={'0x{0:X}' -f [int]$_.'msDS-SupportedEncryptionTypes'}},
    @{N='SPNs'; E={($_.servicePrincipalName | Select-Object -First 2) -join '; '}}

See msDS-SupportedEncryptionTypes for the full per-type breakdown and bulk remediation commands.

2. DefaultDomainSupportedEncTypes on All DCs

Every DC must have the same value. If any DC shows 0x27 (39) or blank, that DC still permits RC4 as the fallback for unconfigured accounts.

Check DefaultDomainSupportedEncTypes across all DCs

Get-ADDomainController -Filter * | ForEach-Object {
  $val = Invoke-Command -ComputerName $_.HostName -ScriptBlock {
    (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\KDC" `
      -Name DefaultDomainSupportedEncTypes -ErrorAction SilentlyContinue
    ).DefaultDomainSupportedEncTypes
  }
  [PSCustomObject]@{
    DC = $_.HostName
    'DDSET (dec)' = $val
    'DDSET (hex)' = if ($val) { '0x{0:X}' -f [int]$val } else { '(not set)' }
  }
} | Format-Table -AutoSize

See Registry Settings for the setting commands and the full list of commonly confused registry keys.

3. Accounts with Old Passwords (Possibly Missing AES Keys)

The RID 521 group (Read-Only Domain Controllers) is created when the domain functional level is raised to 2008 — the earliest point at which password changes generate AES keys. Any account whose passwordLastSet predates that timestamp may lack AES keys entirely.

$AESdate = (Get-ADGroup -Filter * -Properties SID, WhenCreated |
  Where-Object { $_.SID -like '*-521' }).WhenCreated

Write-Host "AES keys available since: $AESdate"

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

This is an approximation — it identifies accounts that may lack AES keys based on password age, not by reading the stored keys directly. For definitive results (four methods, including offline ntds.dit analysis), see Auditing Kerberos Keys.

Accounts in this list may lack AES keys entirely. Setting msDS-SupportedEncryptionTypes = 0x18 on an account without AES keys causes ticket requests to fail. Reset passwords before changing etype configuration. For definitive key verification (four methods including offline ntds.dit analysis), see Auditing Kerberos Keys.

4. Kdcsvc Events 201-209 (RC4 Deprecation Audit)

These events fire on DCs running the January 2026+ update whenever the KDC would use RC4 by default. Any events here identify accounts that will break under enforcement.

Check for RC4 deprecation audit events on DCs

Get-WinEvent -FilterHashtable @{
  LogName = 'System'; ProviderName = 'Kdcsvc'; Id = 201, 202, 205, 206, 207
} -MaxEvents 50 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message |
  Format-Table -AutoSize

See RC4 Deprecation — Kdcsvc Event IDs for the full event reference and remediation steps.

5. Kerberos Auditing Enabled

Without audit policies enabled, DCs do not generate the 4768/4769 events needed to identify RC4 usage.

Verify Kerberos audit subcategories on a domain controller

auditpol /get /subcategory:"Kerberos Authentication Service"
auditpol /get /subcategory:"Kerberos Service Ticket Operations"

Both must show Success and Failure. If not, configure via GPO -- see Group Policy — Kerberos Auditing Policies.

---

Who Is Exposed

Five AD object types can hold a servicePrincipalName. Their risk profiles differ:

Type	Kerberoastable?	Password	Default msDS-SET	Action
User service account	Yes -- human-set password	Human-set	0 (unset)	Set 0x18; enforce 25+ char passwords; or migrate to gMSA
Computer account	No -- machine password	Auto-rotated 30 d	0x1F (GPO-managed)	Managed by GPO automatically
gMSA	No -- 240-char auto	Auto-rotated	0x1C	Set 0x18 to eliminate RC4 traffic
MSA	No -- auto password	Auto-rotated	0x1C or 0	Set 0x18
dMSA (Server 2025+)	No -- auto password	Auto-rotated	0 or 0x1C	Set 0x18

User service accounts are the primary target. They are the only SPN-bearing type with human-set passwords and no automatic etype management. gMSA/MSA/dMSA passwords are uncrackable, but setting msDS-SupportedEncryptionTypes = 0x18 on them eliminates RC4 traffic and satisfies the 2026 deprecation requirements.

For the full account type taxonomy and bulk update commands, see SPN-Bearing Account Types.

---

What to Monitor

Configuration Values

Setting	Where	Target	Risk if Wrong
msDS-SupportedEncryptionTypes	AD attribute on every SPN-bearing account	0x18 (24)	RC4 tickets issued; any SPN is Kerberoastable but RC4 cracks ~800x faster than AES
DefaultDomainSupportedEncTypes	HKLM\...\Services\KDC on every DC	0x18 (24)	Unconfigured accounts fall back to RC4
SupportedEncryptionTypes (GPO)	HKLM\...\Kerberos\Parameters on DCs	AES-only	KDC may issue RC4 tickets if allowed by this filter
RC4DefaultDisablementPhase	HKLM\...\Kerberos\Parameters on DCs	2 (enforce)	RC4 remains the implicit default for unconfigured accounts

Event Log Monitoring

Event ID	Log	Source	What to Look For
4768	Security	Kerberos KDC	TGT request -- check Ticket Encryption Type for 0x17 (RC4)
4769	Security	Kerberos KDC	Service ticket request -- check Ticket Encryption Type for 0x17 (RC4)
4771	Security	Kerberos KDC	Pre-auth failure -- may indicate password spray or Kerberoasting
201-209	System	Kdcsvc	RC4 deprecation audit/enforcement events (January 2026+)
14, 16	System	KDC	Etype mismatch -- account lacks keys for configured encryption type
26, 27	System	KDC	KDC etype not supported -- GPO filter blocking the needed etype

For diagnostic techniques and error code reference, see Troubleshooting. For the full Kdcsvc 201-209 event reference, see RC4 Deprecation — Kdcsvc Event IDs.

---

The Goal

A hardened Kerberos deployment has three properties:

1. AES-only encryption -- RC4 and DES are never used for tickets or session keys. See Standardization Guide.
2. Strong user service account passwords -- 25+ character random passwords, or (better) Group Managed Service Accounts with auto-rotating 240-character passwords. See Mitigations.
3. Least-privilege delegation -- no unconstrained delegation outside domain controllers, Resource-Based Constrained Delegation (RBCD) preferred, and SPNs removed from any account that does not need them. See Mitigations — Delegation Lockdown.

Just need to migrate to AES?

If you already understand Kerberos and just need the operational playbook, jump to the Standardization Guide. Prerequisites: RC4 Deprecation (timeline) and Auditing Kerberos Keys (finding accounts without AES keys).

---

Reading Order

For the full technical reference, the following pages are designed to be read in sequence. Each page builds on concepts from the previous one.

Understanding Encryption

Page	What You Will Learn
Encryption Type Negotiation	How the KDC decides which algorithm to use for each part of the AS and TGS exchanges.
Etype Decision Guide	Visual map of every input that determines which encryption type is used -- from account keys to registry to GPO. Includes 14 worked examples validated against a live DC.

Keys and Algorithms

Page	What You Will Learn
Algorithms & Keys	Every encryption type family, key derivation (MD4 vs PBKDF2), cracking speed comparison, how keys are stored in AD, the double-reset problem, and KRBTGT considerations.

Configuration Reference

Page	What You Will Learn
msDS-SupportedEncryptionTypes	The AD attribute that drives etype selection. Bit flags, defaults, and how to set it.
Registry Settings	Every KDC and client registry key that affects Kerberos encryption.
Group Policy Settings	GPO paths for etype control, ticket lifetimes, and auditing.

Migration

Page	What You Will Learn
RC4 Deprecation (CVE-2026-20833)	Timeline, event IDs, and a step-by-step migration plan.
Auditing Kerberos Keys	Four methods to find accounts missing AES keys: PowerShell date comparison, DSInternals, impacket secretsdump, and ntdsutil + ntdissector.
Standardization Guide	Step-by-step playbook for moving your domain to AES-only, with every registry key, AD attribute, and PowerShell command.

Operations

Page	What You Will Learn
Mitigations	Priority-ordered best practices: gMSA, Protected Users, SPN hygiene, and more.
Troubleshooting	Diagnostic tools, event IDs, error codes, and Wireshark tips.