Troubleshooting Kerberos Errors: Understanding KDC Event IDs 16 & 27 (DES Disabled)

Table of Contents

This article provides a comprehensive guide on managing and resolving Kerberos authentication issues stemming from the deprecation of Data Encryption Standard (DES) encryption in modern Windows environments. Specifically, it details how to navigate scenarios where DES encryption is still required and how to enable it on Windows 7 and Windows Server 2008 R2 systems. Understanding these configurations is crucial for maintaining compatibility with legacy systems while ensuring robust security practices.

Since Windows 7, Windows Server 2008 R2, and all subsequent Windows operating systems, DES encryption for Kerberos authentication has been disabled by default. This change reflects a broader industry move towards stronger cryptographic standards, as DES has known vulnerabilities that can be exploited by modern computing power. However, this default setting can lead to authentication failures in environments that still rely on DES-only configurations, resulting in specific KDC (Key Distribution Center) event logs that IT professionals must understand and address.

Overview of DES Deprecation and Kerberos Challenges¶

The decision to disable DES encryption by default was a critical security enhancement. DES, an older symmetric-key algorithm, utilizes a 56-bit key, which is now considered insufficient to withstand brute-force attacks. As computational power increased, the time required to crack DES encryption diminished significantly, posing a substantial risk to sensitive data. Microsoft’s move aligns with recommendations from security experts to migrate to more secure encryption types like Advanced Encryption Standard (AES) or RC4.

However, this transition is not always seamless, particularly in complex enterprise environments. Legacy applications, older operating systems, or specific service configurations might still be hardcoded to use or only support DES. When modern Windows clients or domain controllers interact with these DES-dependent entities, authentication attempts can fail because they no longer support the weaker encryption type by default. This incompatibility is the root cause of the Kerberos errors discussed in this article, manifesting as specific Event IDs in system logs.

Symptoms of DES-Related Kerberos Failures¶

When DES encryption is disabled, but a service or account relies solely on it, various authentication failures can occur across your network. These issues often arise in specific scenarios involving older configurations or applications. Identifying these scenarios is the first step toward effective troubleshooting.

Consider the following common situations where DES-related Kerberos authentication problems typically surface:

• Service Utilizing DES-Only Accounts: A service running on a Windows 7 or Windows Server 2008 R2 computer, or within a domain with Windows Server 2008 R2 domain controllers, uses a user or computer account that is explicitly configured for only DES encryption. The KDC will be unable to issue a Ticket Granting Service (TGS) ticket because it cannot find a mutually supported encryption type.
• Client Connecting to DES-Only Service: A client running Windows 7 or Windows Server 2008 R2 attempts to connect to a service whose associated user or computer account is configured exclusively for DES encryption. The client will try to request a service ticket using its preferred, stronger encryption types, which the DES-only service cannot support.
• Inter-Domain Trust Relationships: A trust relationship between domains is configured to use only DES encryption, and this relationship involves domain controllers running Windows Server 2008 R2. Cross-domain authentication requests will fail as the newer KDCs refuse to use DES.
• Hardcoded Applications: An application or service has been hardcoded by its developers to use only DES encryption for its Kerberos authentication requests. Such applications cannot adapt to the stronger default encryption types offered by modern Windows systems, leading to consistent authentication failures.

In any of these scenarios, you are likely to observe specific events logged in the Application, Security, and System logs, with the Microsoft-Windows-Kerberos-Key-Distribution-Center source. These events serve as crucial indicators of DES-related authentication issues.

ID	Symbolic Name	Message	Description
27	KDCEVENT_UNSUPPORTED_ETYPE_REQUEST_TGS	While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5.	This event indicates that the KDC received a Ticket Granting Service (TGS) request specifying an encryption type (etype) that is not supported by the target service account or by the KDC itself. It highlights an incompatibility in encryption capabilities.
16	KDCEVENT_NO_KEY_INTERSECTION_TGS	While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5. Changing or resetting the password of %6 will generate a proper key.	This event signifies that there is no common encryption type between the KDC and the target service account. The KDC cannot find a “key intersection” – a shared encryption key that both parties can use. Resetting the password for the account can help generate new keys.

These event IDs directly point to a mismatch in encryption capabilities. Event ID 27 usually means the KDC was asked to use an encryption type it simply doesn’t support or isn’t configured for with that specific account. Event ID 16 indicates a more fundamental issue where no common ground (no shared “key”) for encryption could be found between the KDC and the service account for the requested ticket.

Root Cause of DES Encryption Failures¶

The fundamental cause of these Kerberos errors is the deliberate disabling of DES encryption as a default security setting in newer Windows operating systems. By default, Windows 7, Windows Server 2008 R2, and their domain controllers prioritize stronger cryptographic algorithms, thereby excluding DES from the commonly supported encryption types.

This default configuration directly impacts services that are still configured to use only DES encryption. Such services will invariably fail to authenticate unless one of the following corrective actions is taken:

• Service Reconfiguration: The service must be reconfigured to support more secure encryption types, such as RC4 or AES. This is the recommended long-term solution, as it aligns with current security best practices.
• Universal DES Enablement: All client computers, servers, and domain controllers involved in the authentication path for the service account’s domain must be explicitly configured to support DES encryption. This is generally considered a short-term workaround due to the inherent security risks associated with enabling a weak encryption standard.

By default, Windows 7 and Windows Server 2008 R2 support a range of robust cipher suites, including aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, and rc4-hmac. While DES-CBC-MD5 and DES-CBC-CRC cipher suites can be enabled in these operating systems when absolutely necessary for compatibility, this action should be carefully considered due to the reduced security posture it entails. The shift away from DES is primarily driven by its cryptographic vulnerabilities, making its re-enablement a security trade-off that requires thorough risk assessment.

Workaround and Resolution Strategies¶

Addressing DES-related Kerberos errors involves a two-pronged approach: first, identifying the source of the DES dependency, and second, implementing a solution, preferably by migrating away from DES, or, if absolutely necessary, by re-enabling it with full awareness of the security implications. It is strongly recommended to first determine if DES encryption is still genuinely required in your environment. Evaluate whether specific services can be reconfigured to use RC4 or AES encryption, or if a vendor offers an alternative authentication method with stronger cryptography.

Before proceeding with any changes, especially enabling DES, consider installing Hotfix 978055 on all Windows Server 2008 R2-based domain controllers. This hotfix is crucial for correctly handling encryption type information replicated from older domain controllers (Windows Server 2003 or 2000), preventing potential inconsistencies in mixed-mode environments.

Step 1: Identify DES Dependencies¶

To effectively troubleshoot, you must first pinpoint exactly where DES is being used or requested.

1. Check for Hardcoded Applications:
   Determine if an application is hard-coded to use only DES encryption, which is disabled by default on newer clients and Key Distribution Centers (KDCs). The most effective way to detect this is through network packet analysis.

   To check for this problem, collect network traces during an authentication attempt and look for specific Kerberos error messages. Tools like Wireshark or Microsoft Network Monitor can be invaluable. Focus on traces that resemble the following sample:

   Frame 1 {TCP:48, IPv4:47} <SRC IP> <DEST IP> KerberosV5 KerberosV5:TGS Request Realm: CONTOSO.COM Sname: HTTP/<hostname>.<FQDN>
   Frame 2 {TCP:48, IPv4:47} <DEST IP> <SRC IP> KerberosV5 KerberosV5:KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14)
   
   0.000000 {TCP:48, IPv4:47} <source IP> <destination IP> KerberosV5 KerberosV5:TGS Request Realm: <fqdn> Sname: HTTP/<hostname>.<fqdn>
   -Etype:
   +SequenceOfHeader:
   +EType: aes256-cts-hmac-sha1-96 (18)
   +EType: aes128-cts-hmac-sha1-96 (17)
   +EType: rc4-hmac (23)
   +EType: rc4-hmac-exp (24)
   +EType: rc4 hmac old exp (0xff79)
   +TagA:
   +EncAuthorizationData:
   

   
   The KRB_ERROR - KDC_ERR_ETYPE_NOSUPP (14) message in the KDC’s response is a direct indicator that the KDC could not satisfy the encryption type requested by the client. Examining the EType field in the client’s request reveals the encryption types it preferred. If DES is conspicuously absent from this list, but the target service only supports DES, this is the issue. Conversely, if the client is requesting DES and the KDC responds with ETYPE_NOSUPP, then the KDC is explicitly refusing DES.

2. Verify User or Computer Account Configuration:
   Determine if a specific user account or computer account is configured for only DES encryption within Active Directory. This is a common misconfiguration for legacy services.

   In the “Active Directory Users and Computers” snap-in:
   * Locate and open the properties of the affected user or computer account.
   * Navigate to the Account tab for user accounts or the Delegation tab (for specific computer accounts needing Kerberos delegation) to check for relevant settings.
   * Specifically, look for the “Use Kerberos DES encryption types for this account” option. If this checkbox is selected and no other stronger encryption types are enabled for the account, then this account is restricted to DES. Unchecking this box and ensuring the account supports RC4 or AES (often by simply resetting the password, which generates new keys) is the preferred solution.

Step 2: Enable DES Encryption via Group Policy (If Unavoidable)¶

If, after thorough investigation, you conclude that a critical system or application absolutely requires DES encryption and cannot be migrated to stronger standards, you can re-enable DES encryption types for Kerberos authentication using Group Policy. This should be considered a last resort due to the security implications.

Follow these steps to configure the Group Policy:

1. Open Group Policy Management Console (GPMC): Access GPMC on a domain controller or a management workstation with appropriate permissions.
2. Locate the Policy Setting:
   Navigate through the console tree to the following location:
   Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
3. Configure Kerberos Encryption Types:
   Scroll down and click to select the policy setting: “Network security: Configure encryption types allowed for Kerberos.”
4. Define Policy Settings:
   • Enable the policy by clicking to select “Define these policy settings.”
   • Crucially, you must select all six checkboxes for the encryption types to ensure DES is fully recognized:
     • DES_CBC_CRC
     • DES_CBC_MD5
     • RC4_HMAC_MD5
     • AES128_HMAC_SHA1
     • AES256_HMAC_SHA1
     • Future encryption types
   • While only DES types are strictly needed for this problem, enabling all recommended types ensures broader compatibility and future-proofing while also re-enabling DES.
5. Apply and Close:
   Click OK to apply the changes, then close the GPMC.

Depending on your environment, you may need to set this policy at the domain level to affect all Windows 7 or Windows Server 2008 R2 clients and servers. Alternatively, if the issue is isolated to specific domain controllers or groups of servers, apply the policy to the Organizational Unit (OU) containing those machines. Remember to perform a gpupdate /force on the affected machines to ensure the policy is applied immediately.

Understanding the Kerberos Authentication Flow and Encryption¶

To further clarify why these issues occur, it’s essential to grasp how encryption types are negotiated in Kerberos authentication. For successful Kerberos authentication, three critical encryption type criteria must be met:

1. Client and Domain Controller Authenticator: A common encryption type must exist and be supported between the client (the entity requesting a service ticket) and the Key Distribution Center (KDC) for encrypting the initial authenticator.
2. Domain Controller and Resource Server (Ticket Encryption): A common encryption type must be available and supported between the KDC and the target resource server for encrypting the service ticket itself. The KDC needs to encrypt the ticket using a key that the resource server can decrypt.
3. Client and Resource Server (Session Key): A common encryption type must be supported between the client and the resource server for encrypting the session key (which is embedded in the service ticket). The client needs to be able to decrypt the session key, and then use it to communicate securely with the resource server.

Consider a scenario to illustrate these criteria:

Role	OS	Supported Encryption Level for Kerberos
Domain Controller	Windows Server 2003	RC4 and DES
Client	Windows 7	AES and RC4
Resource Server	J2EE	DES

In this situation:

• Criterion 1: Satisfied by RC4 encryption. The Client (Windows 7) supports AES and RC4, and the Domain Controller (Windows Server 2003) supports RC4 and DES. RC4 is a common, mutually supported encryption type between the client and the DC.
• Criterion 2: Satisfied by DES encryption. The Domain Controller (Windows Server 2003) supports RC4 and DES. The Resource Server (J2EE) only supports DES. Therefore, DES is the common encryption type for the KDC to encrypt the service ticket for the resource server.
• Criterion 3: Fails. The Client (Windows 7) supports AES and RC4 for the session key. However, the Resource Server (J2EE) only supports DES. There is no common encryption type between the client and the resource server for the session key, meaning the client cannot decrypt the session key within the ticket, leading to authentication failure.

This example highlights that even if parts of the Kerberos flow can use different encryption types, all three criteria must ultimately find a common denominator for success. The client’s inability to decrypt the session key, even if the ticket was issued by the KDC, is a critical point of failure.

Embedding a Supporting Video¶

For a deeper dive into Kerberos encryption types and troubleshooting, watch this informative video:

This video explains the different Kerberos encryption types, their historical context, and common troubleshooting steps for authentication issues related to encryption mismatches.

Conclusion and Call to Action¶

The deprecation of DES encryption in modern Windows operating systems is a necessary step towards enhancing cybersecurity. While this change can introduce compatibility challenges with legacy systems, understanding the underlying causes and symptoms is paramount for effective troubleshooting. Prioritizing migration away from DES to stronger encryption standards like AES or RC4 is always the recommended approach. Re-enabling DES should only be considered as a temporary measure when absolutely critical, and always with a full understanding of the increased security risks involved.

By diligently identifying DES dependencies through network traces and Active Directory configurations, and by carefully implementing Group Policy changes when necessary, administrators can resolve these Kerberos errors. This ensures both secure authentication and continued operation of essential services within their environments.

Have you encountered similar DES-related Kerberos issues in your infrastructure? What troubleshooting steps proved most effective for you? Share your experiences and insights in the comments below to help others in the community navigate these complex challenges.