Joseph's questions

Ambiente: Windows Server 2019, Nível Funcional de Floresta/Domínio - 2016, ~40 controladores de domínio com ~17 sites

Estrutura da PKI: Recebemos certificados emitidos por terceiros. Enviamos CSRs a eles e recebemos um certificado deles. Historicamente e atualmente, a cadeia de certificados segue: Raiz > Intermediário > Certificado de Máquina/Usuário.

Tenho o servidor1 e os servidores2-4 em um site, cada um com certificados. Se eu verificar (usando a interface do Windows) a cadeia de certificados de ambos os servidores no servidor2, a cadeia de certificados parece estar como esperado. Se eu verificar no servidor1, há outro certificado misteriosamente aparecendo no topo da cadeia para AMBOS os servidores.

Parece que meu certificado de CA raiz foi emitido por outro certificado, mas não é.

Gostaria de saber por que esses certificados mostram certificados diferentes na raiz quando visualizados em servidores diferentes.

O Servidor 1 aparece nos relatórios de vulnerabilidade como tendo sido emitido por um certificado não confiável. O Servidor 2 não aparece nesta lista. O servidor que produz esses relatórios é um servidor Linux e parece estar usando OpenSSL para realizar essas verificações.

Outra etapa de solução de problemas que fizemos foi criar um novo certificado. Antes de importar o certificado, ele mostrava uma cadeia de certificados esperada. Depois que o importei, o certificado misterioso apareceu novamente, acima do certificado raiz.

Então, antes de importá-lo, a cadeia de certificados parecia com Raiz > Intermediário > Máquina. Depois de importá-lo, parecia com isso: Nova Raiz Misteriosa > Raiz Anterior > Intermediário > Máquina.

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.