DES-Enabled Accounts: A Kerberos Security Risk
DES-Enabled Accounts: The Legacy Kerberos Setting Attackers Can Exploit
DES is a decades-old encryption standard that is sometimes found still use in modern Active Directory environments. When an account is configured to use only DES for Kerberos, it weakens the cryptographic protections around that identity and can make service accounts significantly easier to attack when combined with techniques such as Kerberoasting.
Quick Summary
When DES encryption is enabled on an Active Directory account, the account is restricted to an encryption standard that has been generally considered insecure for years. For service accounts in particular, weak Kerberos encryption can increase the risk of offline credential cracking and turn an overlooked legacy setting into a path toward lateral movement or privilege escalation.
| Priority | High |
| Risk | Legacy DES encryption significantly weakens Kerberos protection for affected accounts |
| Impact | Credential compromise, lateral movement, privilege escalation, and unauthorized access |
| Exploitation | Attackers may target DES-enabled service accounts and attempt to crack captured or requested Kerberos material offline |
| Fix | Remove the DES-only account setting, validate application compatibility, and transition Kerberos authentication to modern encryption such as AES |
What Is DES Encryption in Active Directory?
Data Encryption Standard, often referred to as DES, is a legacy symmetric encryption algorithm that uses a 56-bit effective key. It was developed decades before modern computing power made attacks against such a small key space practical.
Active Directory retains a legacy account setting named “Use only Kerberos DES encryption types for this account”. Behind the scenes, this corresponds to the USE_DES_KEY_ONLY flag in the userAccountControl attribute. This setting exists primarily for compatibility with older systems and applications. Microsoft has disabled DES support by default in Windows since Windows 7 and Windows Server 2008 R2, and current Microsoft guidance describes DES as highly insecure.
Modern Active Directory environments should rely on stronger Kerberos encryption types such as AES-128 and AES-256 where supported. Microsoft continues to recommend moving environments away from legacy Kerberos encryption and toward AES.
How DES-Enabled Accounts Can Pose a Risk
The concern is not simply that DES is old. It’s that when in use, the account has been explicitly configured to rely on a cryptographic mechanism that no longer provides acceptable security.
Common risks include:
- Weak cryptographic protection
DES uses a 56-bit key and is considered insecure. - Increased credential cracking exposure
Kerberos material protected by weaker encryption can make offline attack scenarios more practical, particularly when the affected identity is a service account. - High-value service account exposure
Legacy applications are one of the most common reasons DES remains enabled. Those same applications may rely on long-lived service accounts. - Lateral movement opportunities
If an attacker recovers the password of an affected account, the account’s existing permissions determine how far that access can be taken. - Legacy dependency risk
DES-enabled accounts often indicate that an application or authentication dependency has not been modernized, creating both security and operational risk.
Real-World Context
DES-enabled accounts frequently survive because nobody wants to touch the application using them. A service was deployed years ago, DES was enabled to make authentication work, and the configuration remained long after the original implementor or application owner moved on.
That makes these accounts particularly easy to overlook. The setting may have existed quietly for years, but if the account also has an SPN, an old password, or elevated access, what looks like a compatibility setting can become a much more meaningful credential exposure.
How Attackers Leverage DES-Enabled Accounts
Attackers actively enumerate accounts that support weak Kerberos encryption. The real danger appears when the weak encryption configuration overlaps with an attackable Kerberos use case.
Typical scenarios include:
- Identify accounts using DES
An attacker with authenticated access to the domain can enumerate account properties and look for identities configured with weak Kerberos settings. - Target service accounts
If a DES-enabled account also has a Service Principal Name, it may be a candidate for Kerberoasting. Any authenticated domain user can request a Kerberos service ticket for an SPN. - Request Kerberos service tickets
The attacker requests a TGS for the targeted service using normal Kerberos functionality. - Perform offline password cracking
The captured ticket material can be processed offline. The attack no longer needs to interact with the domain controller while password guesses are attempted, which avoids normal account lockout controls. - Reuse recovered credentials
If the password is cracked, the attacker authenticates as the service account and inherits whatever access that identity already possesses. - Escalate from the compromised account
A service account with administrative privileges, access to sensitive servers, or excessive Active Directory permissions can provide a direct path to broader compromise.
The weak encryption setting therefore matters most when combined with other account characteristics such as an SPN, excessive privilege, a stale password, or broad system access.
How to Detect DES-Enabled Accounts
DES-enabled accounts are straightforward to identify and should be included in routine Active Directory security reviews.
PowerShell Method
Run the following command from a system with the Active Directory PowerShell module:
# List user accounts configured to use only Kerberos DES encryption
Get-ADUser -Filter {UserAccountControl -band 0x200000} -Properties Name | Select-Object Name
What it does: This identifies accounts with the USE_DES_KEY_ONLY flag enabled
How to interpret results: Any returned account should be investigated. Determine why DES was enabled, whether the account is still in use, whether it has an SPN, and what systems or applications depend on it.
Active Directory Users and Computers (ADUC)
For manual verification:
- Open Active Directory Users and Computers (dsa.msc).
- Locate the affected user or service account.
- Open Properties.
- Select the Account tab.
- Review the account options.
- Look for Use Kerberos DES encryption types for this account.
If the option is checked, the account has the DES-only configuration enabled.
Event Logging
Account configuration tells you where DES is allowed. Kerberos event logs can help determine whether DES is actually being used.
On domain controllers, review:
- Event ID 4768, Kerberos authentication ticket requested
- Event ID 4769, Kerberos service ticket requested
Look for Ticket Encryption Type 0x1 and 0x3 as DES encryption types in these events. An account may still contain the DES-only flag even if it is no longer actively used, while event monitoring can reveal whether legacy Kerberos encryption remains part of actual authentication traffic.
Finding This Risk with Insight Recon
Insight Recon’s Active Directory security assessment identifies accounts configured to use DES encryption and surfaces them alongside the other account characteristics that influence their real-world risk.
It also provides:
- Visibility into DES-enabled accounts across the domain
- Account context to help determine which identities represent the greatest exposure
- Risk-based prioritization alongside other Active Directory findings
- Attacker-perspective insights explaining how the configuration can be abused
- Step-by-step remediation and validation guidance
Remediating DES-Enabled Accounts
Prerequisites
Before making changes:
- Identify the application or service associated with each affected account.
- Determine whether the account has one or more SPNs.
- Confirm the application supports modern Kerberos encryption (AES-128 and AES-256 where applicable).
- Document the existing configuration and obtain change approval.
- Plan testing for applications with legacy or non-Windows Kerberos dependencies.
Do not blindly disable DES across production service accounts without confirming compatibility. The security setting may exist because an older application cannot negotiate stronger encryption, and changing it without testing can cause authentication failures.
PowerShell Method
From an elevated PowerShell prompt, run the following command. Replace the username components to match your environment:
# Disable DES for a specific user account
Set-ADAccountControl -Identity "username" -UseDESKeyOnly $false
# Disable DES for all accounts with the setting enabled
Get-ADUser -Filter {UserAccountControl -band 0x200000} | ForEach-Object { Set-ADAccountControl -Identity $_.SamAccountName -UseDESKeyOnly $false }
Active Directory Users and Computers (ADUC)
To remove the setting manually:
- Open Active Directory Users and Computers.
- Locate the affected account.
- Open Properties.
- Select the Account tab.
- Clear Use Kerberos DES encryption types for this account.
- Select Apply.
Preventing DES Encryption from Returning
Removing the existing setting addresses today’s exposure. Preventing it from returning requires visibility into both account configuration and actual Kerberos usage.
- Audit weak encryption settings regularly
Periodically query Active Directory for UseDESKeyOnly and other legacy Kerberos configurations. Old service accounts are particularly important because they are easy to overlook during normal user lifecycle reviews. - Monitor Kerberos encryption types
Review Events 4768 and 4769 for DES ticket encryption types 0x1 and 0x3. This helps identify real authentication activity that still depends on legacy encryption. - Modernize legacy service accounts
Determine why DES was enabled rather than simply clearing the checkbox. Migrate or upgrade applications that cannot support modern Kerberos encryption. - Prefer AES-capable Kerberos configurations
Microsoft recommends modern Kerberos encryption and has been progressively moving Windows environments away from legacy encryption types. - Review SPN-bearing accounts separately
Service accounts with SPNs deserve greater scrutiny because they may be targetable through Kerberoasting. Combine encryption configuration with password age, privilege, and service dependencies when prioritizing remediation. - Control configuration changes
Administrators should understand that enabling DES to solve a compatibility problem introduces a security tradeoff. Require documented approval and a remediation plan whenever a legacy exception is unavoidable. - Monitor account changes
Event ID 4738 can record changes to user account properties, including changes reflected through userAccountControl, when the appropriate account-management auditing is enabled.
Quick Validation Checklist
Can you confidently answer “yes” to all of these?
✓ Do you know every account configured to use DES-only Kerberos encryption?
✓ Have you identified which DES-enabled accounts also have SPNs?
✓ Do affected applications support modern Kerberos encryption?
If any of these are unclear, legacy Kerberos configuration may be creating unnecessary credential exposure in your domain.
Risk & Compliance Mapping
Business Impact: Weak Kerberos encryption increases the risk that compromised or captured authentication material can be converted into usable credentials. A successful compromise may lead to unauthorized application access, lateral movement, privilege escalation, service disruption, or broader Active Directory compromise.
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | PR.AA-03 (Users, services, and hardware are authenticated) PR.DS-02 (confidentiality, integrity, and availability of data-in-transit are protected) |
| CIS Controls | Control 3 (Data Protection), Control 5 (Account Management) |
| MITRE ATT&CK | T1552 (Unsecured Credentials), T1558 (Steal or Forge Kerberos Tickets) |
| MITRE Mitigations | M1015 – Active Directory Configuration, M1041 – Encrypt Sensitive Information |
| DISA STIG | V-254473 |
| ANSSI | User accounts with weak Kerberos encryption [vuln_kerberos_properties_deskey] |
| Microsoft Security Baselines | Recommends disabling DES and enforcing AES for Kerberos authentication |
Frequently Asked Questions
No. DES is deprecated by NIST and should not be used in any modern environment. Its 56-bit key length provides inadequate security against current hardware and cracking techniques.
Active Directory still contains legacy account settings related to DES, but modern Windows versions do not support DES by default. Microsoft has disabled it by default since Windows 7 and Windows Server 2008 R2.
The most common reason is compatibility with a legacy application, service, appliance, or non-Windows Kerberos implementation that was configured many years ago.
It can. If an application genuinely depends on DES, removing support without first modernizing or reconfiguring the application may cause Kerberos authentication failures. Test legacy dependencies before making production changes.
Remove Legacy Encryption Before It Becomes an Attack Path
DES-enabled accounts are usually a sign of technology that was never revisited after deployment. The setting may have been necessary years ago, but leaving weak Kerberos encryption in place today creates unnecessary credential risk, particularly when it appears on service accounts with valuable access.
See exactly where your Active Directory is exposed and what to fix first.