A while back I did a blog post about some problems that were seen with people testing Windows Vista and then “rolling back” to Windows XP and some problems that could be seen when using the same computer object (also known as account) in AD. If you didn’t get a chance to read it here’s the post.
What that scenario highlighted was the added level of encryption, by way of leaving behind a little of the supporting infrastructure in the msds-supported-encryptiontypes attribute value. In this post we’re going to talk about the Big Picture of the new authentication encryption available and a few things to keep in mind.
So here are a few details. There is a set of security protocols called the Suite B protocols and they were designed to provide a great deal more security when they are used. This is relevant here since we will use AES (one of the Suite B protocols) in Windows Vista and Server 2008 in every instance where we can in order to provide that better security to Windows users by default, quietly behind the scenes.
A little about the Suite B components is here: http://en.wikipedia.org/wiki/NSA_Suite_B . The components we’re discussing here are the availability of aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96.
A few other details concerning AES and one of the reasons it is an improvement. The new scheme calls for a looping encryption function which helps to generate a more complex key every time it runs. The minimum, and default, number of times it runs is 4096. Each time it runs through it makes the key ultimately more complex and much more difficult to decrypt. The iteration count, or number of loops through, can be increased to help provide an even more secure key, with the real caveat being that the more iterations then the more resources on the client and server computers needed to encrypt and decrypt the keys following the keys (in tickets) being exchanged during Kerberos authentication. So there could be delays or at least increased resource utilization from increasing the iteration count when you consider that these functions may be done quite frequently if you access resources across the network quite a bit in your daily routine. I suppose a lesson from this would be to use better hardware to reap better security. The iteration count may be altered for those increased values in the registry.
The iteration count used by Kerberos client is configured at:
And the iteration count used by KDC is configured at
So other than bragging about this better security, why talk about this again? The reason for a follow up post is that there has been discussion about related problems from the same cause and to give a more complete backgrounder on how this feature works under the hood.
We’ve also seen additional complications folks had seen with differing behaviors when trying to transfer files between computers. It seemed that from some Vista clients to XP clients there would sometimes be problems, appearing as access denied errors, and vice versa sometimes. The more obvious error that’s been seen with this is:
System error 2148074306 has occurred.
The encryption type requested is not supported by the KDC.
The issue has occurred between the full gamut of computers, and seemed quite random (though it wasn’t really) as far as cause. The extremely frustrating part of the whole deal was that you could see things work fine to one computer (or from one computer) but have a failure to another. It would consistently fail when it did fail, but there was no apparent consistency about which computers it would fail to.
To figure out why these things were happening we need to talk about the logic behind how Windows Vista and Server 2008 determine the encryption which the Kerberos tickets will use. This is important since we want to use the more secure AES methods we mentioned earlier in this post, preferably.
Active Directory account objects for user, computer and principals used for service accounts, which typically are created as users, need a way to show that they can support AES encryption for their Kerberos tickets. We use the msds-SupportedEncryptionTypes attribute for this. The MSDN explanation for this puts it we
The encryption algorithms supported by user, computer or trust accounts. The KDC uses this information while generating a service ticket for this account. Services/Computers may automatically update this attribute on their respective accounts in Active Directory, and therefore need write access to this attribute.
Note that the msds-SupportedEncryptionTypes attribute is not published to the global catalog, nor is it a system only attribute. The system only aspect is important since it tells you that it can be altered easily. This attribute will be looked at by the KDC for a quick check before encrypting tickets for user, service or computer requests. Also keep in mind that computers that support AES have the Netlogon service take care of making sure that the msds-SupportedEncryptionTypes value is present and correct in the Active Directory (Vista and Server 2008).
Server 2008 domain functional level can also come into play as a unified way to reveal that all domain controllers in a particular domain support AES. For a single domain running at Domain Functional Level 2008 the domain object will have the ms-DS-Behavior-Version value set to reveal that domain functional level show whether every computer in the domain should be able to rely on AES encrypted tickets alone. For obvious security reasons this is the most secure and recommended domain functional level to be at in an organization that is lucky enough to be using Server 2008 and Windows Vista.
To reveal this on domain trust objects and see whether tickets sent to a remote domain across a trust can be encrypted using AES the trusted domain object (also known as TDOs) for a trust will have this value as well.
So to recap the msds-SupportedEncryptionTypes attribute may be set for users, computers, and trusts to show that these entities support AES in the Kerberos tickets. For determining the encryption support for a domain the dependency is ms-DS-Behavior-Version.
When can you expect AES to be used generally? Here’s a quick matrix, but keep in mind that if you are having a problem then that inherently suggests your situation is not following the Yes! entries in this matrix. Client and server terms here are used in the traditional client-server interaction sense.
Client Server KDC (aka domain) AES?
Vista Vista Server 2008 Yes!
Server 2008 Server 2008 Server 2008 Yes!
Vista Server 2008 Server 2008 Yes!
Server 2008 Vista Server 2008 Yes!
Vista 2000/XP/2003 Server 2008 No
2000/XP/2003 Vista Server 2008 No
Any OS Any OS Server 2003, 2000 No
If you suspect you are seeing complications resulting from this behavior then there are some places you can see what is happening. First, take a network trace. The Kerberos ticket request and response (AS_REQ, AS_REP, TGS_REQ and TGS_REP) packets will include an E_Type field which is also included in the requests per the RFCs for Kerberos. This is an added mechanism for displaying the encryption types the client supports.
Another thing to do is to look in your Active Directory. For a Server 2003 or 2000 domain the most common place to look will be the computer or user account for the presence of a value in the msds-SupportedEncryptionTypes attribute. If a value is present and that computer does not support AES then you should clear the value.
If you are using Server 2008 domains and see surprising behavior then you should consider checking the domain functional level in DSA.MSC, or by checking the domain object for what value is present in ms-DS-Behavior-Version. If you are accessing resources across a domain trust to a Server 2008 domain then you would want to check the trusted domain object for that same msds-SupportedEncryptionTypes attribute having a value.
For folks who haven’t rolled out or had a chance to test Server 2008 yet (which, since it hasn’t released is most of you) you can see you have some better security to look forward to. Hey, that could be a selling point for you all right there, couldn’t it?
It would be for me.