Registry Settings¶
Every registry key that affects Kerberos encryption behavior on domain controllers
and clients. These settings interact with each other and with the
msDS-SupportedEncryptionTypes AD attribute -- understanding the precedence order
is critical.
Precedence Order¶
When the KDC selects an etype for a service ticket, it checks in this order:
msDS-SupportedEncryptionTypeson the target account (always wins if set).DefaultDomainSupportedEncTypeson the DC (used only when the attribute is 0 or absent).- The KDC's own allowed etype configuration (from Group Policy or
SupportedEncryptionTypeson the DC) acts as a final filter -- the KDC will never issue a ticket with an etype it is not configured to allow.
DefaultDomainSupportedEncTypes¶
The most important KDC-side registry key. It controls the assumed encryption types for
every account that does not have an explicit msDS-SupportedEncryptionTypes value.
| Property | Value |
|---|---|
| Path | HKLM\SYSTEM\CurrentControlSet\Services\KDC |
| Value name | DefaultDomainSupportedEncTypes |
| Type | REG_DWORD |
| Default (not set) | 0x27 (39) = DES + RC4 + AES-SK |
| Default (Server 2025) | 0x24 (36) = RC4 + AES-SK (DES removed) |
| Recommended | 0x18 (24) = AES128 + AES256 |
| Takes effect | Immediately (no reboot required) |
How It Works¶
When the KDC processes a TGS-REQ and the target account has msDS-SupportedEncryptionTypes = 0
(or not set), the KDC substitutes this registry value. The etype selection then proceeds as
if the account had this value in its AD attribute.
Common Values¶
| Value | Hex | Meaning |
|---|---|---|
| 24 | 0x18 |
AES128 + AES256 (recommended AES-only — blocks RC4 for unconfigured accounts) |
| 56 | 0x38 |
AES128 + AES256 + AES256-SK (AES-only with session key upgrade) |
| 60 | 0x3C |
RC4 + AES128 + AES256 + AES256-SK (recommended transitional — RC4 fallback with AES session key upgrade) |
| 28 | 0x1C |
RC4 + AES128 + AES256 (transitional without AES-SK; prefer 0x3C) |
| 36 | 0x24 |
RC4 + AES256-SK (Server 2025 default — RC4 ticket, AES session key) |
| 39 | 0x27 |
DES + RC4 + AES256-SK (pre-April 2026 internal default) |
Setting It¶
# Set to AES-only (recommended)
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\KDC" `
-Name "DefaultDomainSupportedEncTypes" `
-Value 24 -PropertyType DWord -Force
# Verify
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\KDC" `
-Name "DefaultDomainSupportedEncTypes"
Set this on ALL domain controllers
This registry key is per-DC, not replicated through AD. You must set it on every DC in
the domain. If one DC has 0x18 and another has 0x27, clients will get different
ticket etypes depending on which DC they reach. Use Group Policy Preferences to push
registry values consistently.
Explicit msDS-SupportedEncryptionTypes always overrides
If an account has msDS-SupportedEncryptionTypes explicitly set to any non-zero value,
DefaultDomainSupportedEncTypes is completely ignored for that account.
DDSET is filtered by the KDC's SupportedEncryptionTypes
DefaultDomainSupportedEncTypes and SupportedEncryptionTypes (GPO) are two
independent mechanisms. DDSET determines what etypes the KDC considers for the
account; SupportedEncryptionTypes filters what the KDC will actually issue.
The interaction is asymmetric (matrix-tested on the enforced build 20348.5020). For a
msDS-SupportedEncryptionTypes = 0 account (the DDSET / enforcement fallback), the filter
can upgrade the result to AES: if the filter allows only AES and DDSET says RC4, the KDC
issues an AES ticket, not an error. But it does not downgrade a fallback to RC4: if the
filter allows only RC4 and the computed fallback is AES, the KDC returns
KDC_ERR_ETYPE_NOSUPP (auth failure) — it does not silently issue an RC4 ticket. For an
account with an explicit msDS-SupportedEncryptionTypes, the filter never overrides it:
if the account's declared etypes and the filter share no etype (msDS RC4-only under an
AES-only filter, or msDS AES-only under an RC4-only filter), the result is
KDC_ERR_ETYPE_NOSUPP.
The Event 4769 msDSSET field reflects DDSET, but the actual ticket etype comes from
the filter. If these two values disagree, the msDSSET field and the ticket etype
will show different etypes — this is expected behavior, not a bug.
KdcUseRequestedEtypesForTickets¶
Controls whether the KDC honors the client's etype preference list when selecting the ticket etype (not the session key).
| Property | Value |
|---|---|
| Path | HKLM\SYSTEM\CurrentControlSet\Services\Kdc |
| Value name | KdcUseRequestedEtypesForTickets |
| Type | REG_DWORD |
| Default | Not present (equivalent to 0) |
| Value | Behavior |
|---|---|
1 |
KDC uses the client's etype preference list to select the ticket etype. Picks the first entry in the client's list that the KDC supports, overriding the target account's msDS-SupportedEncryptionTypes (reach is build-dependent — see the danger note below). |
0 or not set |
KDC ignores the client's list and picks the strongest etype that the KDC and target account both support. |
KdcUseRequestedEtypesForTickets=1 bypasses per-account etype protection
When set to 1, the KDC honors the client's requested etype for the ticket instead of
picking the strongest the account supports. An attacker can then force an RC4 ticket for
any account that still lists RC4 in msDS-SupportedEncryptionTypes (or that relies on a
DDSET/internal default which includes RC4), making Kerberoasting trivial against those
accounts.
The reach of the bypass is build-dependent. On a pre-enforcement build (validated on
20348.3207), KdcUseRequestedEtypesForTickets=1 forced RC4 even for an explicitly
AES-only account (svc_val_03, msDS-SET=24). On an enforced build (re-tested live on
20348.5020) the same RC4 request returned AES256 for an AES-only account — there the
bypass only reaches accounts that actually list RC4 (msDS-SET=28 downgraded to RC4;
msDS-SET=24 stayed AES256). Event 206 is logged when the override is applied.
Never set this to 1 in production. If this key exists in your environment,
remove it immediately.
When to Use It¶
Never. Leave this at the default (0) or remove it entirely. The documented use
case (debugging interoperability) does not justify the security risk. Any debugging need
can be addressed with Wireshark captures or Event 4769 analysis instead.
SupportedEncryptionTypes (GPO / KDC Filter)¶
Controls what encryption types the Kerberos client will advertise in AS-REQ and TGS-REQ messages. This affects what the client requests, not what the KDC issues.
| Property | Value |
|---|---|
| Path | HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters |
| Value name | SupportedEncryptionTypes |
| Type | REG_DWORD |
| Default | Not present (client advertises all available etypes) |
The Group Policy Network security: Configure encryption types allowed for Kerberos writes to this path. This is the only supported location for this setting.
Two filter paths — and Server 2025 keeps Lsa, drops Policies
There is a second path at HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
Both paths act as a KDC etype filter and require a KDC restart. Which one the KDC actually
reads is OS-version dependent, matrix-tested live with a value written straight to the
registry (an RC4-only filter against an AES-only account; KDC_ERR_ETYPE_NOSUPP means the
filter was honored):
| Filter path | Server 2022 (20348.5020) | Server 2025 (26100.32522) |
|---|---|---|
...\Policies\System\Kerberos\Parameters |
honored | ignored |
...\Lsa\Kerberos\Parameters |
honored | honored |
On Server 2022 both paths filter. On Server 2025 only the Lsa path filtered — a
value written directly to the Policies path was ignored (registry write confirmed present,
result reproduced). This is the reverse of the widely-repeated "Server 2025 drops the
Lsa path" claim, which is unsourced (no KB / MS-KILE reference) and was never lab-tested
when written. The Configure encryption types GPO writes to the Policies path on Server
2025 too — confirmed live by building such a GPO and applying it to a 2025 DC (the value landed
at the Policies path; Lsa stayed empty). So the standard Kerberos-encryption GPO does not
filter etypes on a Server 2025 DC at all — it writes a value the 2025 KDC never reads. To
filter on a 2025 DC the value must reach the Lsa path (a registry-preference GPO targeting
Lsa, or a manual Lsa value).
Common Values¶
| Value | Hex | Meaning |
|---|---|---|
| 24 | 0x18 |
Client requests AES only (blocks RC4 client-side) |
| 28 | 0x1C |
Client requests RC4 + AES (default behavior) |
Client-side vs. server-side
Setting SupportedEncryptionTypes on a client workstation only affects what that
client requests. It does not prevent the KDC from issuing RC4 tickets for services. To
block RC4 tickets, you must configure the target account (msDS-SupportedEncryptionTypes)
or the DC (DefaultDomainSupportedEncTypes). Setting it on a DC affects both its
client behavior and, via GPO, the KDC's allowed etypes.
Timing: When Changes Take Effect¶
Not all registry changes take effect at the same time. Failing to account for this is a common source of "I changed the value but nothing happened."
| Registry Value | Timing | Evidence |
|---|---|---|
DefaultDomainSupportedEncTypes |
Immediate — takes effect on the next TGS-REQ, no restart required. | Lab-validated: setting DDSET=24 changed ticket etype from RC4 to AES256 within seconds. Removing the value reverted immediately. |
SupportedEncryptionTypes (Policies path) |
KDC restart required — the KDC reads this value only at service start. | Lab-validated: Pol\SET=24 had no effect until Restart-Service kdc. Removing the value also had no effect until the next restart. This filter affects both AS (pre-auth) and TGS exchanges -- setting AES-only blocks RC4 pre-auth for new logon sessions. |
SupportedEncryptionTypes (Lsa path) |
KDC restart required — same as the Policies path. | Lab-validated: identical behavior to Pol path. |
RC4DefaultDisablementPhase |
KDC restart required — unlike DDSET, enforcement phase changes are not picked up live. | Lab-validated: Phase=2 did not change ticket etype until KDC restart. |
DDSET for quick changes, GPO for persistent policy
DefaultDomainSupportedEncTypes changes are immediate — useful for testing and
emergency remediation. SupportedEncryptionTypes (GPO) changes require a KDC
restart but are managed centrally through Group Policy. Use both together for defense
in depth.
RC4DefaultDisablementPhase¶
Part of the CVE-2026-20833 rollout. Controls whether the KDC applies the RC4 deprecation audit or enforcement behavior.
| Property | Value |
|---|---|
| Path | HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters |
| Value name | RC4DefaultDisablementPhase |
| Type | REG_DWORD |
| Value | Behavior |
|---|---|
0 |
No change -- RC4 behavior unchanged from pre-2026. |
1 |
Audit phase -- RC4 is still allowed, but Kdcsvc events 201-209 are logged when RC4 would be used by default. This is the default after the January 2026 update. |
2 |
Enforcement -- KDC assumes AES-only (0x18) for accounts without explicit msDS-SupportedEncryptionTypes. RC4 is blocked unless the account explicitly declares it. |
Timeline¶
| Date | Default Value |
|---|---|
| January 2026 | 1 (audit) |
| April 2026 | 2 (enforcement), can be rolled back to 1 |
| July 2026 | Registry key removed -- enforcement is permanent |
The registry value is usually absent — 'Default Value' means implicit behavior
RC4DefaultDisablementPhase is normally not present in the registry. The rollout
changes how the KDC behaves when the value is absent; it does not write a number. "April
2026 -> 2" therefore means an absent value behaves as Phase 2 once KB5078763+ is
installed — not that you will read a 2 back from the registry. A DC behind on patches
reads the same absent value but still behaves as Phase 0. You cannot determine a DC's
enforcement state from this value alone; check the build number or a live msDS-SET = 0
ticket request.
KDC restart required
Unlike DefaultDomainSupportedEncTypes (which takes effect immediately),
RC4DefaultDisablementPhase requires a KDC restart to take effect. After setting or
changing this value, run Restart-Service kdc on the DC.
Setting It Manually¶
# Enable enforcement early
New-ItemProperty `
-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" `
-Name "RC4DefaultDisablementPhase" `
-Value 2 -PropertyType DWord -Force
# Roll back to audit (only before July 2026)
Set-ItemProperty `
-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" `
-Name "RC4DefaultDisablementPhase" `
-Value 1
DefaultEncryptionType¶
A legacy key that sets the default encryption type for pre-authentication.
| Property | Value |
|---|---|
| Path | HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters |
| Value name | DefaultEncryptionType |
| Type | REG_DWORD |
| Default | 0x17 (23) = RC4-HMAC |
This key is rarely needed. It was introduced to work around specific pre-authentication failures (e.g., the NETWORK SERVICE account failing pre-auth after certain patches). In modern environments, leave it at the default or remove it entirely.
LogLevel (Debugging)¶
Enables verbose Kerberos event logging on the client side.
| Property | Value |
|---|---|
| Path | HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters |
| Value name | LogLevel |
| Type | REG_DWORD |
| Default | 0 (disabled) |
| Value | Behavior |
|---|---|
0 |
Normal logging |
1 |
Verbose Kerberos logging in the System event log |
# Enable debug logging
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" `
-Name "LogLevel" -Value 1 -PropertyType DWord -Force
# Disable after debugging (performance impact)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters" `
-Name "LogLevel" -Value 0
Disable after troubleshooting
Verbose Kerberos logging generates a high volume of events and can impact performance on
busy systems. Enable it only for the duration of your troubleshooting session, then set
it back to 0.
Commonly Confused Keys¶
These registry values have similar names but different purposes, paths, and timing. Confusing them is the most common cause of "I set AES-only but services still get RC4."
| Key | Full Path | Scope | Set By | Purpose | Timing |
|---|---|---|---|---|---|
SupportedEncryptionTypes |
...\Policies\System\Kerberos\Parameters |
Any machine | Group Policy | Controls what etypes the machine's Kerberos client requests/accepts. On a DC, also acts as the KDC's allowed-etype filter. | KDC restart |
SupportedEncryptionTypes |
...\Lsa\Kerberos\Parameters |
Any machine | Manual | Same KDC filter as the Policies path. Honored on Server 2022; on Server 2025 the KDC reads this path and ignores the Policies path (lab-tested 26100.32522). | KDC restart |
DefaultDomainSupportedEncTypes |
...\Services\KDC |
DC only | Manual / GPP | Sets the assumed etypes for accounts with no msDS-SupportedEncryptionTypes. Not set by any GPO -- must be configured manually or via Group Policy Preferences. |
Immediate |
For the full list of non-functional value/path combinations (6 of 9 tested), see Registry Audit Results — Non-Functional Registry Paths.
GPO does not set DefaultDomainSupportedEncTypes
Applying the Configure encryption types allowed for Kerberos GPO to domain controllers
writes SupportedEncryptionTypes (the GPO policy cache path). This restricts what etypes
the KDC will issue (after KDC restart), but it does not change what etypes the KDC
assumes for unconfigured accounts. To change the default assumption, you must also set
DefaultDomainSupportedEncTypes on every DC.
Example: You apply an AES-only GPO to DCs and restart the KDC. An account has
msDS-SupportedEncryptionTypes = 0. DefaultDomainSupportedEncTypes is still 0x27
(includes RC4). The KDC considers RC4 for the account (DDSET says so), but the GPO filter
overrides this and issues an AES ticket instead. No authentication failure occurs — the
filter takes precedence. However, for clarity and forward compatibility, you should still
align both settings by setting DefaultDomainSupportedEncTypes = 0x18.
Quick Reference Table¶
| Key | Path | Default | Scope | Timing | Purpose |
|---|---|---|---|---|---|
DefaultDomainSupportedEncTypes |
...\Services\KDC |
0x27 |
KDC (per-DC) | Immediate | Default etype for accounts with empty msDS-SET |
KdcUseRequestedEtypesForTickets |
...\Services\Kdc |
Not set (= 0) |
KDC (per-DC) | Immediate | Whether to honor client etype preference (never set to 1) |
SupportedEncryptionTypes |
...\Policies\...\Kerberos\Parameters |
Not set | Any machine | KDC restart | Machine's etype config (written by GPO). On a DC, also the KDC's allowed-etype filter. |
SupportedEncryptionTypes |
...\Lsa\Kerberos\Parameters |
Not set | Any machine | KDC restart | Same KDC filter as the Policies path. Honored on Server 2022; on Server 2025 the KDC reads this path, not Policies (lab-tested 26100.32522). |
RC4DefaultDisablementPhase |
...\Policies\...\Kerberos\Parameters |
Not set (CU-gated) | KDC (per-DC) | KDC restart | RC4 deprecation phase |
DefaultEncryptionType |
...\Lsa\Kerberos\Parameters |
0x17 |
Client | — | Default pre-auth etype (no effect on KDC ticket issuance) |
LogLevel |
...\Lsa\Kerberos\Parameters |
0 |
Client/Server | — | Verbose Kerberos logging |