DCs do Exchange 2016 e Server 2016: tipo de criptografia KDC desconhecido

Equipe,

O ambiente do Exchange é todo de 2016, sem mistura. Existem domínios pai e filho, mas o nível funcional de cada domínio e floresta é 2012R2. Todos os controladores de domínio eram 2012R2 até recentemente. A equipe do AD (diferente de mim) introduziu os controladores de domínio do Server 2016 e acho que isso causou um problema. Aqui estão os sintomas:

Mail fica preso em servidores em um domínio pai com o destino para o domínio filho. O erro na fila é "454 4.7.0 Temporary Authentication error" e os eventos correlacionados no log de eventos são Event ID 2017, Source: MSExchangeTransport, a mensagem é:

"Falha na autenticação de saída com o erro KdcUnknownEncryptionType para o conector de envio Conector de envio SMTP dentro da organização. O mecanismo de autenticação é ExchangeAuth. O destino é SMTPSVC/servidor fqdn."

O e-mail fluirá do domínio filho para o domínio pai sem problemas. Como eu disse anteriormente, acho que a mudança mais significativa que aconteceu é simplesmente introduzir os DCs do Server 2016. Para corrigi-lo temporariamente, posso reiniciar o servidor em que as mensagens estão travadas e funcionará por um tempo. Isso realmente parece um problema do Kerberos.

EDIT: Também temos um ASA configurado, mas os tipos de criptografia suportados entre todos os meus servidores de troca, DCs e este ASA são todos "28".

As pesquisas do Google sugerem problemas de sincronização de tempo, mas verifiquei os servidores Exchange e os controladores de domínio e as coisas parecem estar exatamente sincronizadas. Também verifiquei a integridade da replicação e não parece haver nenhum problema com isso. Também verifiquei se há SPNs duplicados ou malformados e não encontrei nada. Há mais coisas que eu possa analisar sobre os SPNs? Como que tipo de criptografia eles estão solicitando/usando ou algo assim? Eu não sei muito sobre Kerberos.

EDIT: Como outra nota, usando um GPO, removi o RC4-HMAC do servidor de destino. Como resultado, o klist ticketscomando mostrou o "AES ..." correto, mas meu powershell foi quebrado ... "Possíveis causas" foram:

• "Usuário ou senha incorretos"
• "Kerberos usado quando nenhum método de autenticação e nenhum nome de usuário são especificados"
• "O Kerberos aceita nomes de usuários de domínio, mas não nomes de usuários locais."
• "SPN para nome de computador remoto e porta não existe"
• "computadores cliente e remotos estão em domínios diferentes e não há confiança."

Em seguida, sugere tentar adicionar o computador de destino na lista WinRM TrustedHosts.