Tread Lightly – Kerberos Encryption Types

Or better yet, make sure you know what you are doing before you make any changes.  Otherwise, you could be in for a world of hurt.

Why all the fuss?

One of the major changes with Windows 7 and Windows Server 2008 R2 is disabling DES encryption support by default.  While DES encryption of Kerberos tickets is still supported, these encryption types  have been disabled by default.   

Repeat after me, DES encryption is disabled by default for Windows 7 and Windows 2008 R2.  This knowledge is critical as changing the encryption types without consideration for the rest of the infrastructure (domain controller operating system versions) could cause massive outage to your environment.

Based on a table provided by Ned Pyle‘s from his post titled, Hunting down DES in order to securely deploy Kerberos, in the Ask the Directory Services Team, I have listed the supported encryption types for each operating system.

Operating System Version
Enabled Encryption Types
Supported Encryption Types
Windows 7, Windows Server 2008 R2
Windows Vista, Windows Server 2008
Windows 2000, Windows 2003, Windows XP

Why is this information critical?

If your environment  runs on 100%  newer versions of Microsoft operating systems  (Windows 7, Windows 2008 Server and newer) with no third-paty software or user accounts that use DES encryption, then you can ignore this warning.  Anyone have that pristine environment?  I thought so.  So, read the rest of the article.

Changing the supported encrytion types may be a consideration when you have Windows 7 or Server 2008 R2 machines in your environment and there are third-party applications  that have not been updated to use newer and more secure encryption types for Kerberos.  These application would require DES encryption to be enabled on Windows 7 and Server 2008 R2 machines.

As a quick background, DES encryption is a legacy encryption type which is very insecure in this day and age.  While older versions of the Windows operating systems still have DES support, these operating systems negotiate the most secure encryption level supported, RC4-HMAC or AES for newer versions, before falling back to DES.

If you have any applications that still use DES encryption, raise hell and bug the vendor to update it to start using RC4-HMAC encryption at the very least.

Ok, but can you provide a doomsday scenario?

Yes, I can.

Environment background

Domain Controllers:  all running Server 2003

Member Machines: Windows XP, Server 2003, Windows 2008, Windows 2008 R2

Existing GPO to enable all supported encryption types on Windows 7 and Server 2008 R2 machines.

Policy Change

Policy change made to disable support for RC4-HMAC encryption on Windows 7, Windows 2008 & Windows 2008 R2 machines. 

Once the change is in place, Windows 7, Server 2008, Server 2008 R2 machine would only have DES-CBC-CRC, DES-CBC-MD5, AES256-HMAC-SHA1-96 & AES128-HMAC-SHA1-96 encryption types enabled.

After group policy refresh and LSASS reload intervals, you will start seeing the following issues:

  • Users getting kicked out of Outlook client, unable to reload and repeatedly being prompted for credentials
  • Users unable to logon (remote desktop or local logon)  to Windows 7, Windows Server 2008, Windows Server 2008 R2 machines using their domain accounts.  Repeatedly getting prompted for credentials. Local account log on still working.
  • If your Exchange servers are running on Server 2008 or R2, you will get error messages in the event log about failure to communicate with domain controllers/global catalogs.
  • Server 2008, Windows 7, Server 2008 R2 unable to access SYSVOL share
  • Group policy refresh failures
  • Kerberos errors being logged on Windows 7, Server 2008, Server 2008 R2 machines

Why does it break?

If you look at the table listing supported encryption types, disabling RC4-HMAC support on the targeted machines should not break the communication channels between the domain controllers running on Server 2003 & the affected member machines running win7, server 2008, server 2008 R2.  That’s because DES encryption is still supported by the domain controllers and the affected member machines.

There is a twist to this however.  The answer can be found by reading MS KB article 833708.  In the symptoms section, it states:

The Microsoft Windows Server 2003 Key Distribution Center (KDC) uses the strongest encryption type (etype) available to encrypt service tickets. If a client requests etype DES-CBC-CRC, the KDC encrypts tickets with RC4_HMAC_NT. If the client does not understand this etype, the service ticket is unusable.

Well, doh!  Yes, affected machines will be able to request for a Kerberos ticket from the domain controllers.  However, the default behavior on the Server 2003 domain controllers is to encrypt the DES-CBC-CRC ticket using the most secure encryption type supported which is RC4_HMAC.  In short, the ticket given to the affected machine is now unusable since we disabled support for RC4_HMAC.

And from this point forward, communication between the affected machines and the domain controllers is not possible.

How can we fix this?

Some of the actions you can try:

Reverting the change and re-enabling the RC4-HMAC encryption using  group policy will not resolve the issue.  Since the affected machines are still not able to communicate with the domain controllers, the group policy update will  not apply to the affected machines.

Adding the registry value on domain controllers as specified in MS KB article 833708 forces the domain controller to use the requested encryption type for tickets instead of using the most secure encryption type.

  • This change will restore the ability to log on to affected machines using domain accounts but still does resolve the issue of communicating with the domain controllers.

Manually changing the registry value for affected machines to the value specified in MS KB 977321 allowed the affected machine to communicate with the domain controllers.

  • After the reboot, group policy update successfully completed and reverted the encryption type support.
  • Further testing showed that a reboot is not required for the change to take effect. However, you will have to wait for the LSASS reload interval.

Lessons Learned

  • Test and test before making these kinds of changes
  • Scope your testing to limit possible impact
  • Learn and understand what kerberos encryption types are.


The security principals and the services that use only DES encryption for Kerberos authentication are incompatible with the default settings on a computer that is running Windows 7 or Windows Server 2008 R2

KDC does not allow clients to specify an etype in Windows Server 2003

Hunting down DES in order to securely deploy Kerberos

This entry was posted in Active Directory. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s