Changes in default encryption type for Kerberos pre-authentication on Vista and Windows 7 clients cause security audit events 675 and 680 on Windows Server 2003 DC's
I had a case recently with the following case description:
We‘re auditing AD security events as per SOX requirements and we seem to be getting a lot of events 675 and 680 after we added Vista and Windows 7 clients to our domain. We don‘t see any account lockouts or logon issues, are these events something to be concerned about?
The default encryption type for Vista/Win7 clients is AES256, Windows XP and Windows Server 2003 clients default to RC4 on the other hand.
This means that a Vista/Win7 client will initially attempt to use AES when talking to a Domain Controller during the Kerberos pre-authentication stage, Windows Server 2003 DC‘s on the other hand don‘t support using AES with Kerberos which is why they log the event and ask the client to try again with one of algorithms the DC supports (which usually ends up as RC4).
In short; The 675 event is expected when you have clients that want to use AES and DC’s that can’t or won’t. This is in itself not a problem and the client simply retries later in the conversation and negotiates an encryption algorithm that both server and client support. It does however generate some audit chatter that may trigger false alarms for monitoring applications.
For W2k8/Vista/Win7<->XP/W2k3 communication the highest common encryption algorithm usable by Kerberos is RC4 and this is usually the negotiated algorithm (unless the DC’s have been configured to accept a less secure algorithm for legacy systems with the KdcUseRequestedEtypesForTickets registry entry).
It is possible (although not recommended from a security perspective) to change the default on the Vista/Win7 client side to start pre-authentication with RC4 by modifying the DefaultEncryptionType registry value to 0x17 hex (0x18 hex is AES).
From KB 837361:
Entry: DefaultEncryptionType
Type: REG_DWORD
Default Value: 23 (decimal) or 0x17 (hexadecimal)
This value indicates the default encryption type for pre-authentication.
i.e.
0x17 (hex) or 23 (decimal) is KERB_ETYPE_RC4_HMAC_NT
0x18 (hex) or 24 (decimal) is KERB_ETYPE_AES256_CTS_HMAC_SHA1_96
However, please be aware of the issues described in http://support.microsoft.com/kb/2566059 if lowering the default encryption type (post-SP1 Windows 7 hotfix).
See:
Kerberos protocol registry entries and KDC configuration keys in Windows Server 2003
http://support.microsoft.com/kb/837361
Kerberos Enhancements in Vista
http://technet.microsoft.com/en-us/library/cc749438(WS.10).aspx
Kerberos Authentication Tools and Settingshttp://technet.microsoft.com/ko-kr/library/cc738673(WS.10).aspx
KDC does not allow clients to specify an etype in Windows Server 2003http://support.microsoft.com/kb/833708
RC4 pre-authentication failure for the Network Service account in Windows Server
2008 R2 or in Windows 7
http://support.microsoft.com/kb/2566059
Vista and Windows Server 2008 clients are unable to access cluster names with AES-encrypted Kerberos ticketshttp://support.microsoft.com/kb/961302
a) The security entity running the service; if the msDS-SupportedEncryptionTypes attribute on the object is set to 31 it indicates that it supports AES encryption. This is normally only set on computer objects that run W2k8 and Vista, if the cluster service created the account or it’s a service account then it shouldn’t be present and AES should not be an option.
b) The registry key on the DC’s; HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\KdcUseRequestedEtypesForTickets (DWORD); if this is set to non-zero on the DC the DC will attempt to use the highest encryption method the client supports. This requires the hotfix from 833708 or later builds of kdcsvc.dll to be installed on all W2k3 DC’s, without it the DC defaults to the highest possible encryption method which will be AES for W2k8/Vista clients (W2k8 DC’s already have it).