Unknown KDC Encryption Type in Exchange 2016 and Server 2016 DCs – Fix

exchangeexchange-2016kerberoswindows-server-2016

Team,

Exchange environment is all 2016, no mix. Parent and child domains exist, but the functional level of each domain and forest is 2012R2. All domain controllers have been 2012R2 until recently. The AD team (different from me) have introduced Server 2016 domain controllers and I think it has caused a problem. Here are the symptoms:

Mail gets stuck on servers in a parent domain with the destination to the child domain. Error on the queue is "454 4.7.0 Temporary Authentication error" and the correlating events in the event log are Event ID 2017, Source: MSExchangeTransport, the message is:

"Outbound authentication failed with error KdcUnknownEncryptionType for Send connector Intra-Organization SMTP Send Connector. The authentication mechanism is ExchangeAuth. The target is SMTPSVC/server fqdn."

Mail will flow from child domain to parent domain with no problem. Like I said earlier, I think the most significant change that has happened is simply introducting Server 2016 DCs. To fix it temporarily, I can reboot the server that the messages are stuck on and it will work for a while. This really seems like a Kerberos issue.

EDIT: We also have an ASA set up, but the supported encryption types between all my exchange servers, DCs, and this ASA are all "28".

Google searches suggest time sync issues, but I've checked both the Exchange servers and the domain controllers and things seem to be exactly on sync. I've also checked replication health and there doesn't appear to be any issues with that. I've also checked for duplicate or malformed SPNs and didn't find anything. Is there more that I can look into about the SPNs though? Like what kind of encryption they are requesting/using or something? I don't know much about Kerberos.

EDIT: As another note, using a GPO, I did remove the RC4-HMAC from the destination server. As a result, the klist tickets command did show the correct "AES…", but then my powershell was broken… "Possible causes" were:

  • "Username or password invalid"
  • "Kerberos used when no authentication method and no user name are specified"
  • "Kerberos accepts domain usernames, but not local user names."
  • "SPN for remote computer name and port doesn't exist"
  • "client and remote computers are in different domains and there is no trust."

Then it suggests to try adding destination computer in the WinRM TrustedHosts list.

Best Answer

It sounds like RC4 was an allowed Kerberos encryption type on the 2012 DCs, and your AD team introduced 2016 DCs with RC4 disabled. I say this with some confidence, because it is the recommended security setting on Server 2016. The goal is to remove RC4 from the environment, but not without first updating your mission critical applications to support AES. My suggestion would be to ensure the allowed Kerberos encryption types are configured the same on all DCs and then enable Kerberos service ticket success auditing on all Domain Controllers to see which applications are still trying to use RC4. It will show up in EventId 4769 with an encryption type of 0x17. If you see this, then RC4 is being used. You need to make sure all involved user accounts, computer accounts, and the Kerberos policy on each server (including the DCs) is configured properly for AES to work.

Related Topic