1

I have an average of 17-18 failure audit events per hour recorded in the Security event log of a Windows 2012R2 domain controller, related to attempts of a Windows 2008R2 member server to obtain a Kerberos service ticket

A Kerberos service ticket was requested. 

Account Information: 
Account Name:   TORPDC01$@ACME.COM 
Account Domain: ACME.COM 
Logon GUID: {00000000-0000-0000-0000-000000000000} 

Service Information: 
Service Name:   krbtgt/ACME.COM 
Service ID: S-1-0-0 

Network Information: 
Client Address: ::ffff:192.168.1.15 
Client Port:    28904 

Additional Information: 
Ticket Options: 0x60810010 
Ticket Encryption Type: 0xFFFFFFFF 
Failure Code:   0xE 
Transited Services: - 

This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested. 

This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket. 

Ticket options, encryption types, and failure codes are defined in RFC 4120.

The failure code 0xE indicates an unsupported authentication type. I have monitored the traffic between the servers with Wireshark and I see that the Windows 2008R2 server is making a request towards the domain controller to start a session using the encryption type aes256-cts-hmac-sha1-96. This request is rejected with an "encryption type not supported" error code and the audit failure is recorded in the event log. The Windows 2008 server then sends a list of 5 encryption types and from it the domain controller responds with the selected type: ARCFOUR-HMAC-MD5. After that, the traffic continues normally, and I'm assuming that the 2 servers are using the encryption parameters they agreed upon. There is no other problem that I can see between the 2 servers. Any suggestions on how to get rid of those events? Is it just a matter of audit policy? Maybe I can force the Windows 2008R2 server to start its requests with a different set of encryption protocols parameters?

2
  • What is the domain functional level (DFL)?
    – Greg Askew
    Feb 26, 2017 at 18:25
  • The DFL is Windows Server 2003.
    – AdiGri
    Feb 26, 2017 at 19:08

2 Answers 2

1

You need to raise your DFL to use the 'newer' (circa 2008) AES encryption types. Note that when raising from 2003, the krbtgt account passwords will be changed (both of them), and this may result in impact, so you should be prepared to restart servers/services as necessary to recover.

Also, you should not enable DES encryption type if you don't need it, and even disabling the RC4 encryption types and only using AES would be preferred if it is compatible with your environment due RC4 security is suboptimal.

See the following for more information:

https://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels(v=ws.10).aspx

1
  • Great insight! I raised the DFL to Windows 2008R2 and the problem is gone (before that I restored the settings for encryption types in the group policies to "not enabled"). Thank you!
    – AdiGri
    Feb 26, 2017 at 19:34
0

What's odd here is the 2012 R2 DC rejecting the AES256 based encryption type because it's supported by default. Are there any group policies configured in your domain that would be purposefully limiting the default supported encryption types?

I'd run an RSOP report on your DC and review what's configured. In particular, check the Windows Settings - Security Settings - Local Policies - Security Options section. There's a setting in there called Network security: Configure encryption types allowed for Kerberos that could be configured to disallow one or more of the AES algorithms. Some organizations have this disabled to better support legacy clients that don't support the newer encryption types.

1
  • Actually I did verify that policy and it wasn't set for domain or for the domain controllers containers. I enabled all the encryption types and refreshed the group policy and the problem persists. Another thing that I did was to use ADSI Edit, and adjust on the domain controller container the msDS-SupportedEncryptionTypes property from 28 to 31 (to enable all) and still the DC rejects the first proposal for encryption type. The RSOP shows the 5 encryption types enabled + "future encryption types". Next I'll enforce the use of HMAC_MD5 only at the domain-level group policy to see if it helps.
    – AdiGri
    Feb 26, 2017 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.