Início / server / Perguntas / 960128
Accepted
Tim Brigham
Asked: 2019-03-27 13:33:24 +0800 CST

Falhas de pré-autenticação do Kerberos entre DCs

  • 772

Estou recebendo falhas de pré-autenticação kerberos - evento 4771 - entre meus DCs. Eu acho que é um comportamento normal (isso acontece há anos, desde que habilitei o registro adicional), mas não consigo encontrar nenhuma explicação do motivo pelo qual isso está acontecendo.

Algumas notas:

  • acontecendo de controlador de domínio para controlador WENDELde domínioSTEVE
  • nunca ocorre STEVEa WENDEL.
  • STEVEdetém as funções FSMO.
  • DCs ainda estão em 2012r2, incluindo nível operacional

Todos os eventos têm os mesmos detalhes de ingresso.

Ticket Options:     0x40810010
Failure Code:       0x18
Pre-Authentication Type:    2

Eu fiz o dcdiag usual como uma verificação de sanidade e nada parecia fora do comum.

active-directory

2 respostas

  1. Best Answer

    Este é realmente um comportamento normal, o que você está vendo são etapas de validação de credenciais de domínio para o detentor da função do emulador FSMO PDC. Todos os servidores DC que falham na autenticação de uma determinada conta do AD (usuário ou computador) executam uma etapa de verificação extra de tentar autenticar o DC emulador de PDC para verificar se as credenciais não foram alteradas nesse meio tempo. O emulador PDC detém a responsabilidade de administrar as atualizações de senha, portanto, sempre sabe a senha mais atualizada.

    • 2

  2. De acordo com a documentação da Microsoft, os eventos de falha de autenticação 4771 do Kerberos (Código de falha 0x18 e pré-autenticação tipo 2) significam que as informações de pré-autenticação do Kerberos eram inválidas. Isso pode acontecer quando o computador perdeu a confiança no domínio e está enviando uma senha incorreta. Já vi várias situações colocar um computador nesse estado: 1) Redefinir a senha do objeto do computador à força no ADU&C sem restabelecer a confiança do domínio. 2) Recriar o objeto de computador no AD. 3) O cliente esteve fora da rede por um período de tempo e não conseguiu sincronizar novamente sua senha de computador com um controlador de domínio. Essas situações são mais comuns do que a maioria das pessoas pensa e são difíceis de diagnosticar porque os usuários podem continuar fazendo logon nesses computadores usando credenciais armazenadas em cache.

    Você pode verificar a relação de confiança do domínio em um computador fazendo com que o evento seja acionado (Nome da conta no visualizador de eventos / TargetUserName no XML do evento) executando " nltest.exe /sc_query:[your_domain_name]" do cliente de domínio afetado.

    Os sistemas nesse estado são bastante falantes e também gerarão eventos de erro NETLOGON (como Event ID 5722 e 5805) no log do sistema dos controladores de domínio gerando os eventos 4771. Você pode consultar os logs do sistema DC para esses erros NETLOGON para determinar quais sistemas podem estar tendo problemas de confiança de domínio. Esses eventos podem ocorrer em circunstâncias normais, então eu focaria apenas em reincidentes gerando mais de 5 erros de NETLOGON por dia.

    Aqui está um one-liner do PowerShell que você pode executar como administrador de domínio para exportar um CSV contendo os erros NETLOGON dos dias anteriores de todos os seus controladores de domínio.

    Invoke-Command -ComputerName (Get-ADDomainController -Filter * | Sort-Object Name).Name -ScriptBlock {Get-WinEvent -FilterHashtable @{Logname="System";id=5722,5805;StartTime=(Get-Date).AddDays(-1)} | Select-Object TimeCreated,@{L='LoggedBy';E={$_.MachineName}},ProviderName,Id,Message,@{L='FailingComputer';E={($_.Message -split "\s+")[6]}}} | Export-Csv -Path "$(Get-Date -format "yyyy-MM-dd")_NETLOGON_Errors.csv" -NoTypeInformation

    Sugiro juntar novamente um dos sistemas afetados ao domínio e ver se isso resolve o problema.

    Nota: Na minha experiência, quando a falha de pré-autenticação é gerada em um controlador de domínio que não é o emulador de PDC, o emulador de PDC de domínio registrará um evento 4771 duplicado contendo o endereço IP do controlador de domínio de onde a falha se originou e o TargetUserName do cliente de domínio com a senha incorreta. Nesse caso, concentre-se no TargetUserName do evento, não no endereço IP.

    • 0

relate perguntas