Event ID: 4 The Kerberos client received a KRB_AP_ERR_MODIFIED Windows 2003 and Windows 2012 R2 DC Environment

Good timing for me, bad timing for those that already have 2012 R2 DCs in their domain.

Event ID: 4 The Kerberos client received a KRB_AP_ERR_MODIFIED

There is a bug in Kerberos

When a Windows 2012 R2 DC is promoted in an environment where Windows 2003 DCs are present, there is a mismatch in the encryption types that are supported on the KDCs and used for salting. Windows Server 2003 DCs do not support AES and Windows Server 2012 R2 DCs don’t support DES for salting.

There are 3 workarounds

Option 1: Query against Active Directory the list of computers which are about to change their machine account password and proactively reset their password against a Windows Server 2012 R2 DC and follow that by a reboot.

Option 2: Disable machine password change or increase duration to 120 days. (this buys you time until the hotfix is supposed to be out)

Option 3: Disable AES in the environment by modifying Supported Encryption Types for Kerberos using Group Policy. This tells your domain controllers to use RC4-HMAC as the encryption algorithm, which is supported in both Windows Server 2003 and Windows Server 2012 and Windows Server 2012 R2.

I am going for Option 2

Details here:

It turns out that weird things can happen when you mix Windows Server 2003 and Windows Server 2012 R2 domain controllers

The other thing worth noting for those of you that have recently removed your last Windows 2003 DC, from the comments section:

“For those of you who have decommissioned your last Windows Server 2003 domain controller after adding Windows Server 2012 R2 DC’s, all that you should need to do is force the password change one time with the 2012 R2 domain controllers. The issue can actually take up to two password changes to happen and clear up from talking with our Escalation Engineers.”