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.