Kerberos Failure Audit Event Id 4769 on Domain Controller

Question

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:   [email protected] 
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?

Answer 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

Answer 2

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.