In the concerted effort to provide more secure methods of authentication we have added in product behind-the-scenes support for Advanced Encryption Standard (AES) and other security enhancements.
More info on that is here:
http://www.microsoft.com/brasil/technet/itsolutions/network/evaluate/new_network.mspx
and here:
Advanced Encryption Standard (AES) is a form of encryption that was adopted by the United States government in 2001. AES provides more secure encryption than its predecessor, Data Encryption Standard (DES). This version of Windows (Vista) uses AES.
http://windowshelp.microsoft.com/Windows/en-US/Help/9a07a27f-3406-4af5-856b-a412b3865e671033.mspx
With this added support is at least one thing to be aware of. AES must be supported by client and server when used to encrypt across the wire, and as such there must be a way to identify whether that should be used at all. The identification of whether the client will attempt to use AES is included as an attribute in Active Directory:
http://msdn2.microsoft.com/en-us/library/ms677827.aspx
It’s simple. If it’s a Vista client it will have the attribute, and if it is not that will not be a defined attribute at all.
For those people who have read my posts before you know that there’s usually a “but” or a “however” at some point. Here it is. In this case, if you have had a Vista client joined to your domain and then had for some reason decided to use a prior operating system client, like Windows XP, in that computers place then you could encounter a problem.
The machine account for that computer in the AD, originally created by the Windows Vista domain join, will have the attribute denoting the support for AES. The “but” comes into play when your downlevel client (like Windows XP or Server 2003) attempts to do certain actions which will automatically attempt to use the AES support (to oversimplify) like below:
x:>net view \piginadress
System error 2148074306 has occurred.
The encryption type requested is not supported by the KDC.
Which is a true enough error message. So if you see this sort of thing, check for the existence of that attribute using LDP.EXE. It’ll look similar to the one below:
>> Dn: CN=ComputerA,OU=Workstations,DC=letme,DC=outof,DC=here
5> objectClass: top; person; organizationalPerson; user; computer;
…
1> operatingSystem: Windows Server 2003;
1> operatingSystemVersion: 5.2 (3790);
1> operatingSystemServicePack: Service Pack 1;
1> dNSHostName: computera.letme.outof.here
…
1> msDS-SupportedEncryptionTypes: 31;
What do you do to fix this? Disjoin the computer from the domain, delete the computer object (after documenting any security groups or other proprietary data on that object) and then rejoin the domain. Alternatively, you can try clearing the attribute value (ADSIEDIT.MSC or LDP.EXE) on the object and see if that makes a difference.
Not too elegant a solution, but why makes things harder than they need to be?
Microsoft
