How to Disable Kerberos DES Encryption on AD Accounts

Use Kerberos DES encryption types for this account is a legacy Active Directory option (userAccountControl flag USE_DES_KEY_ONLY, 0x200000) that restricts an account to 56-bit DES keys. To fix it, clear the flag, remove the DES bits from msDS-SupportedEncryptionTypes, set it to AES (24), and reset the password so AES keys exist.

DES has been disabled by default since Windows 7 and Windows Server 2008 R2, and Microsoft lists it as removed from Windows 11 version 24H2 and Windows Server 2025. Accounts that still carry the option are usually leftovers, so the cleanup is low risk once you find the few that something still depends on.

What the scanner is actually detecting

DES can be enabled on an account in two places, and a clean result needs both fixed:

• The userAccountControl flag. USE_DES_KEY_ONLY (hex 0x200000, decimal 2097152) is the check box on the Account tab in Active Directory Users and Computers. In PowerShell it is the UseDESKeyOnly parameter of Set-ADAccountControl.
• The msDS-SupportedEncryptionTypes attribute. A bit mask where 1 is DES_CBC_CRC, 2 is DES_CBC_MD5, 4 is RC4, 8 is AES128 and 16 is AES256. Any value with bit 1 or 2 set (for example 3, 7 or 31) includes DES. AES only is 24 (0x18).

A common origin is ktpass. Microsoft’s ktpass reference notes that DES-only is set by default, so accounts mapped years ago for Java or Unix keytabs often carry the flag.

Real-world risk

Tenable rates the plugin Medium (CVSS 4.5), and that is fair. DES uses a 56-bit key, and Microsoft’s remediation guidance says even unspecialized hardware can break DES-encrypted content in less than two days. PingCastle’s explanation is that a DES-enabled account can be used in ticket requests, and a cracked ticket lets an attacker compromise the account.

The practical exposure depends on your domain controllers. Since Windows Server 2008 R2 the KDC does not issue DES tickets unless someone has enabled DES in the Kerberos encryption policy, and on Windows Server 2025 it is gone. In most domains, a DES-only account is therefore broken for Kerberos rather than exploitable: Microsoft’s KDC event 16/27 article describes these accounts failing to get tickets. Clients using Negotiate may then fall back to NTLM, which is one more dependency to clear before you can restrict NTLM safely. The risk becomes real where DES was re-enabled for an old application, or if someone re-enables it later to “fix” one.

How to confirm it

These commands are read-only and need the RSAT ActiveDirectory and GroupPolicy modules. The first is PingCastle’s detection query with extra columns:

Get-ADObject -Filter {UserAccountControl -band 0x200000 -or msDs-supportedEncryptionTypes -band 3} -Properties userAccountControl, 'msDS-SupportedEncryptionTypes', servicePrincipalName, pwdLastSet |
    Select-Object Name, ObjectClass, 'msDS-SupportedEncryptionTypes',
        @{n='DesOnlyFlag'; e={ [bool]($_.userAccountControl -band 0x200000) }},
        @{n='HasSPN'; e={ [bool]$_.servicePrincipalName }},
        @{n='PasswordLastSet'; e={ [datetime]::FromFileTime($_.pwdLastSet) }}

Next, check whether DES is enabled anywhere in policy. The Kerberos encryption policy writes a registry value; if it is absent, the OS default applies and DES is off. A value of 0x7FFFFFFF means all six check boxes were ticked, DES included.

# On each domain controller, and on servers hosting old applications
Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemKerberosParameters' -Name SupportedEncryptionTypes -ErrorAction SilentlyContinue

# GPOs that define the setting (open each to see which types are ticked)
Get-GPO -All | Where-Object {
    (Get-GPOReport -Guid $_.Id -ReportType Html) -match 'Configure encryption types allowed for Kerberos'
} | Select-Object DisplayName, Id

Finally, look for real usage on the domain controllers. Microsoft says a Ticket Encryption Type of 0x1 or 0x3 in events 4768 and 4769 means DES was used, and KDC events 16 and 27 show requests that failed because an account had no usable key. Get-WinEvent reports an error when nothing matches, which is the result you want.

Get-WinEvent -LogName Security -MaxEvents 50 -FilterXPath "*[System[(EventID=4768 or EventID=4769)] and EventData[Data[@Name='TicketEncryptionType']='0x1' or Data[@Name='TicketEncryptionType']='0x3']]"

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-Kerberos-Key-Distribution-Center'; Id=16,27} -MaxEvents 50

How to fix it

Step 1: export the list and find owners

Get-ADObject -Filter {UserAccountControl -band 0x200000 -or msDs-supportedEncryptionTypes -band 3} -Properties userAccountControl, 'msDS-SupportedEncryptionTypes', servicePrincipalName |
    Select-Object Name, DistinguishedName, ObjectClass, userAccountControl, 'msDS-SupportedEncryptionTypes',
        @{n='SPNs'; e={ $_.servicePrincipalName -join ';' }} |
    Export-Csv .des-before.csv -NoTypeInformation

Accounts with SPNs or keytabs on Linux or Java hosts need an owner’s sign-off. Disabled and orphaned accounts can often be deleted instead.

Step 2: clear the DES-only flag

# One account
Set-ADAccountControl -Identity svc-app01 -UseDESKeyOnly $false

# Every flagged user
Get-ADUser -Filter {UserAccountControl -band 0x200000} | Set-ADAccountControl -UseDESKeyOnly $false

In the GUI, open the account, go to the Account tab and clear Use Kerberos DES encryption types for this account.

Step 3: set AES in msDS-SupportedEncryptionTypes

For user and service accounts, Set-ADUser writes the attribute for you:

# AES only: 24 (0x18)
Set-ADUser -Identity svc-app01 -KerberosEncryptionType AES128,AES256

# AES plus RC4 while you confirm every client supports AES: 28 (0x1C)
Set-ADUser -Identity svc-app01 -KerberosEncryptionType AES128,AES256,RC4

Do not edit this attribute on computer accounts. Microsoft documents that a computer’s value is managed automatically from its Kerberos encryption policy, so fix the GPO in step 5 and restart the machine; it rewrites the attribute itself.

Step 4: reset the password

Microsoft’s event documentation says that at a domain functional level of 2008 or higher, AES keys are available once the account has had at least one password rotation. DES-only accounts are usually old, so reset every one you changed:

Set-ADAccountPassword -Identity svc-app01 -Reset -NewPassword (Read-Host -AsSecureString 'New password')

Then update every service, scheduled task and application config that uses the account. For a non-Windows service that uses a keytab, let ktpass set the password and write a new AES keytab in one step. The -desonly switch releases the DES-only restriction instead of setting it:

ktpass /princ HTTP/app01.contoso.com@CONTOSO.COM /mapuser svc-app01 /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL -desonly /pass * /out app01.keytab

Step 5: remove DES from the Kerberos encryption policy

If step 1 found the setting in a GPO, edit it at:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos

Clear DES_CBC_CRC and DES_CBC_MD5. Once you have confirmed nothing needs RC4, keep only AES128_HMAC_SHA1 and AES256_HMAC_SHA1, as Microsoft’s RC4 guidance describes. Restart the affected machines so the change applies.

How to verify the fix and rescan

1. Rerun the detection query from the confirmation section. It should return nothing.
2. From a client, request a ticket for the service and check its type. klist should show KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96:

   klist purge
   klist get HTTP/app01.contoso.com
   klist

3. On domain controllers running Windows Server 2016 or later with the January 2025 or later cumulative update, the Available Keys field of event 4769 should list AES-SHA1 for the service account.
4. Rescan. Rerun the Nessus scan that includes plugin 150481, and run a new PingCastle healthcheck. Tenable Identity Exposure re-evaluates on its own. Defender for Identity updates the exposed entities within minutes, but Microsoft says scores and statuses update every 24 hours.

What can break and how to roll back

• Keytabs. Keytabs created before the reset stop working. Deploy the new AES keytab at the same time.
• Applications hard-coded to DES. Microsoft lists this as a known scenario. On current Windows these already fail, so the answer is a vendor update, not DES.
• Service accounts. A reset that misses one service or scheduled task causes an outage.
• The AES-only policy. Devices or accounts that support only RC4 fail with KDC_ERR_ETYPE_NOTSUPP (0xE) in event 4769. Microsoft shows this as SMB network errors and WinRM error 0x80090342.

To roll back, restore msDS-SupportedEncryptionTypes from des-before.csv (for example Set-ADUser svc-app01 -Replace @{‘msDS-SupportedEncryptionTypes’=28}, or -Clear msDS-SupportedEncryptionTypes if it was empty), and put RC4 back in the GPO before anything else. Set-ADAccountControl -UseDESKeyOnly $true restores the flag, but DES only works if every domain controller, client and server allows it, which is impossible on Windows Server 2025 or Windows 11 24H2. A password reset cannot be undone; issue a new keytab instead.

Common false positive reasons

• Different counts per tool. Nessus reports user accounts and skips disabled ones by default. PingCastle also includes computer accounts and the attribute bits.
• DES plus AES values. An attribute of 31 (0x1F) includes AES, so the KDC will normally pick AES. PingCastle still flags it, correctly; set 24.
• Computer accounts that come back. A GPO still ticks the DES boxes, and the machine rewrites its attribute at restart.
• Event log noise. Microsoft notes that on Windows Server 2022 and earlier the processed MSDS-SupportedEncryptionTypes field in events 4768 and 4769 always shows DES and RC4, whatever your settings. That is not evidence of this finding.
• A different Kerberos problem. Tenable’s indicator also covers disabled preauthentication, so it can stay red after the DES fix.
• Stale data. The scan ran before the change replicated.

FAQ

Is clearing the check box enough?

Not always. PingCastle also reads msDS-SupportedEncryptionTypes, and an old password may have no AES keys. Clear the flag, set the attribute and reset the password.

Can Windows still use DES at all?

Barely. It has been off by default since Windows 7 and Windows Server 2008 R2, and is removed from Windows 11 version 24H2 and Windows Server 2025.

Should every account get msDS-SupportedEncryptionTypes 24?

Set it on service accounts with SPNs. Microsoft says user accounts without an SPN do not need a value, and computer accounts are managed by policy.

Is this the same as the RC4 or Kerberoasting findings?

No, they are separate findings. The same two steps, AES in msDS-SupportedEncryptionTypes and a fresh password, are part of the fix for both.

Tracking this finding across many hosts

Directory findings like this usually arrive from more than one tool. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, with Nessus results uploaded as .nessus exports, and merges duplicates per scanner rather than across scanners, so expect one entry per tool. For Nessus findings it can retest a single finding after the fix, and its AI triage suggests false positives with evidence for a human to confirm.

Sources

• Tenable: Nessus plugin 150481, AD Starter Scan – Weak Kerberos encryption
• Tenable: Kerberos Configuration on User Account indicator of exposure
• Microsoft Learn: Defender for Identity accounts security posture assessments
• Microsoft Learn: KDC event ID 16 or 27 is logged if DES for Kerberos is disabled
• Microsoft Learn: Detect and remediate RC4 usage in Kerberos