Erro “The trust relationship between this workstation and the primary domain failed” no logon do Windows: causas, correções e prevenção definitiva

Erro “The trust relationship between this workstation and the primary domain failed” ao entrar no Windows? Este guia prático explica a causa real, mostra correções rápidas (sem reingressar), validações de infraestrutura e como prevenir o problema de forma definitiva em ambientes com Active Directory.

Índice

Visão geral e por que esse erro acontece

Quando um computador ingressa no domínio, ele cria no Active Directory (AD) uma conta de computador e estabelece um canal seguro com os controladores de domínio (DCs). Esse canal é autenticado por uma senha que o próprio computador altera periodicamente (por padrão, a cada 30 dias). Se o canal seguro “quebra”, o Windows interrompe o logon com a mensagem: “The trust relationship between this workstation and the primary domain failed”.

Os motivos mais comuns para a quebra do canal seguro são:

Senha da conta de computador fora de sincronia entre o PC e o objeto no AD (ex.: restauração de snapshot, longos períodos offline, falha na última troca de senha).
Hora incorreta (Kerberos é sensível a desvio <≈5 minutos).
DNS mal configurado no cliente (apontando para DNS público em vez de DNS interno/AD).
Replicação do AD com erros (o PC fala com um DC “atrasado”).
Objetos de computador duplicados ou obsoletos, OU incorreta, ou objeto desabilitado.
Snapshots/restore de VMs (cliente ou DC) retornando a estados antigos.

Como reconhecer o problema

Mensagem de erro ao tentar logar no domínio, mas logon local funciona.
nltest /sc_verify:dominio.local retorna falha.
Eventos de Netlogon/Kerberos no Visualizador de Eventos (por exemplo, 5719, 5722, 5805; 40960/40961; 3210).
Cliente com DNS público configurado ou hora divergente do domínio.

Correções rápidas por máquina

Preferir estas ações antes de remover e reingressar a máquina ao domínio.

Passo a passo

Efetue logon com uma conta local do PC (por exemplo, .\Administrador ou outra com privilégios).
Conecte-se à rede corporativa (cabo ou Wi‑Fi do domínio) e certifique-se de que o DNS aponta para os DCs.
Repare o canal seguro usando credenciais de administrador do domínio por um dos métodos abaixo.
Reinicie e teste logon no domínio.

PowerShell (recomendado)

# Reparar canal seguro com credenciais do domínio
Test-ComputerSecureChannel -Repair -Credential DOMINIO\Admin

Alternativa: redefinir a senha da conta de computador falando com um DC específico

Reset-ComputerMachinePassword -Server DC01 -Credential DOMINIO\Admin

Dica: se houver vários DCs, indique um DC atualizado com -Server DC01 para evitar um controlador desatualizado.

Linha de comando (CMD)

nltest /sc_reset:dominio.local

netdom resetpwd /Server:DC01 /Domain:dominio.local /UserD:DOMINIO\Admin /PasswordD:*

Correção a partir do Active Directory

No Active Directory Users and Computers (ADUC), localize o objeto de computador e use Reset Account.
No cliente: retire do domínio para um WORKGROUP, reinicie e reingresse ao domínio com credenciais de administrador do domínio.
Se a falha persistir, verifique DNS, hora e replicação antes de novas tentativas.

Observação: somente “Reset Account” no AD não restaura o canal seguro por si só; é necessário reingressar ou reparar a partir do cliente.

Se o erro continuar: valide a infraestrutura

DNS correto nos clientes

Cada estação/servidor deve apontar exclusivamente para os DNS internos (os DCs). Evite DNS público (ex.: 8.8.8.8, 1.1.1.1) nas NICs.
No cliente, confirme com ipconfig /all e nslookup que o DNS preferencial é o DC.
Verifique se o domínio tem os registros SRV corretos e se o cliente resolve o DC certo.

Verificação	Comando/onde	Esperado	Ação se falhar
DNS do cliente	`ipconfig /all`	Somente IPs dos DCs nos campos DNS	Remover DNS público; definir DNS dos DCs via GPO/DHCP
Resolução do DC	`nslookup DC01` / `nltest /dsgetdc:dominio.local`	Retorna o DC correto com flags do domínio	Ajustar zonas DNS, checar registros SRV e replicação
Canal seguro	`nltest /sc_verify:dominio.local`	Trusted DC connection status Status = 0x0	Executar reparo (`Test-ComputerSecureChannel -Repair`)

Hora sincronizada (Kerberos)

O desvio máximo padrão tolerado é em torno de 5 minutos.
No PDC Emulator do domínio, configure pares NTP confiáveis e torne-o reliable.
Nos clientes, sincronize com o domínio e confirme o status do serviço de tempo.

# No PDC Emulator
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
w32tm /resync
w32tm /query /status

# Nos clientes
w32tm /query /status
w32tm /resync

Item	Comando	Validação
Status do tempo	`w32tm /query /status`	Origem aponta para DC ou NTP válido; sem grandes desvios
Fonte de tempo	`w32tm /query /source`	Em clientes, DC; no PDCe, pares NTP confiáveis

Replicação do AD saudável

No DC, rode repadmin /replsummary para um panorama geral e dcdiag para testes adicionais.
Corrija erros antes de tentar novas reintegrações.

repadmin /replsummary
dcdiag /v

Snapshots e restaurações

Evite restaurar clientes ou DCs para snapshots antigos. Isso “volta” a senha da conta e quebra o canal seguro.
Para DCs, snapshots podem causar problemas graves de replicação; use sempre backup consistente e procedimentos suportados.

Objeto de computador no AD

Verifique se o objeto é único, está habilitado e na OU correta.
Remova resíduos/duplicatas; confirme permissões herdadas e políticas aplicáveis.

Automação em escala

Para dezenas/centenas de máquinas, padronize o reparo com PowerShell e GPO.

PowerShell Remoting habilitado

$cred = Get-Credential DOMINIO\Admin
$pcs  = Get-ADComputer -SearchBase "OU=Workstations,DC=dominio,DC=local" -Filter * | Select -ExpandProperty Name

Invoke-Command -ComputerName \$pcs -ScriptBlock {
if (-not (Test-ComputerSecureChannel)) {
Test-ComputerSecureChannel -Repair -Credential \$using\:cred | Out-Null
}
} -ErrorAction SilentlyContinue

Script de inicialização via GPO

nltest /scverify:dominio.local || nltest /screset:dominio.local

Relatórios e auditoria

# Gera um CSV de status do canal seguro
$pcs = Get-ADComputer -Filter * | Select -Expand Name
$result = foreach($pc in $pcs){
  try {
    $ok = Invoke-Command -ComputerName $pc -ScriptBlock { Test-ComputerSecureChannel } -ErrorAction Stop
    [pscustomobject]@{ Computer=$pc; SecureChannel=$ok; Timestamp=Get-Date }
  } catch {
    [pscustomobject]@{ Computer=$pc; SecureChannel=$false; Timestamp=Get-Date }
  }
}
$result | Export-Csv .\SecureChannelStatus.csv -NoTypeInformation -Encoding UTF8

Prevenção definitiva

Não desativar a troca de senha de conta de computador

Assegure que DisablePasswordChange = 0 em HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters nos membros de domínio.
Política: Membro de Domínio: Idade máxima da senha da conta de máquina (padrão 30 dias). Ajuste para 60–90 dias apenas para portáteis que ficam muito tempo fora. Evite 0 (desativa a troca).
Evite RefusePasswordChange em DCs (não recomendado).

Hora e DNS por GPO

Defina tempo no PDC Emulator e deixe a hierarquia do domínio cuidar da distribuição. Em clientes, não aponte NTP externo diretamente.
Force DNS internos via GPO/DHCP; evite configurações manuais em estações.

Monitorar eventos críticos

Netlogon/Sistema: 5719, 5722, 5805.
Kerberos/LSASRV: 40960, 40961.
Time-Service: eventos de desvio e falha de sincronização.

# Exemplo: alertar quando o canal seguro falhar
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=5719,5722,5805} -MaxEvents 200

Higiene de AD/infra

Rodar periodicamente repadmin /replsummary e dcdiag e atuar nos erros.
Evitar snapshots em DCs; usar backups consistentes com AD.
Remover objetos de computador obsoletos e manter OU/Policies coerentes.

Guia rápido de diagnóstico

No cliente: confirme DNS interno (ipconfig /all). Ajuste se necessário.
Cheque hora: w32tm /query /status. Se houver desvio, sincronize.
Valide canal: nltest /sc_verify:dominio.local.
Se falhar, repare: Test-ComputerSecureChannel -Repair -Credential DOMINIO\Admin.
Reinicie. Se persistir, valide replicação no AD (repadmin /replsummary / dcdiag).

Fluxo de decisão prático

Erro de confiança →
  DNS aponta para DCs internos? → NÃO → Corrija DNS → Teste
                              → SIM →
  Hora dentro de &lt;=5 min?        → NÃO → Corrija tempo → Teste
                              → SIM →
  Replicação AD ok?             → NÃO → Corrija replicação → Teste
                              → SIM →
  Reparar canal seguro (PS/CMD) → OK → Reinicie e valide
                              → FALHA →
  Reset Account no AD + reingressar → OK

Boas práticas adicionais

Evite múltiplos DNS diferentes nas NICs (ex.: primário interno e secundário público). Use apenas DNS do AD.
Defina “Perfil de Rede” como Domínio quando conectado internamente; perfis incorretos podem afetar firewall e descoberta de DC.
Em filiais com RODC: faça reparos apontando para um DC gravável (ex.: -Server DC-EscritorioCentral).
Notebook fora por meses: aumente a idade máxima da senha da conta de máquina (60–90 dias) e forneça VPN sempre que possível para permitir trocas periódicas.

FAQ

Trocar a senha do usuário pode causar esse erro?
Não. O logon do usuário é independente do canal seguro do computador. A coincidência temporal geralmente revela problemas de tempo/DNS ou um canal já quebrado.

Reingressar ao domínio sempre resolve?
Frequentemente, sim — mas é trabalho desnecessário na maioria dos casos. Reparar o canal seguro é mais rápido, menos intrusivo, preserva perfil local e evita reprocessar GPOs extensivamente.

Quanto tempo o computador pode ficar desligado sem romper a confiança?
Depende da política de idade da senha de máquina. Padrão é 30 dias; para portáteis, considere 60–90 dias. Evite desativar a troca.

Posso desabilitar a troca de senha de máquina para “nunca mais ter problema”?
Não é recomendado: reduz segurança e não elimina outras causas (DNS/hora/replicação). O correto é manter troca habilitada e a infraestrutura saudável.

Reset Account no AD é suficiente?
Sozinho, não. É preciso reingressar o computador ao domínio ou executar um reparo do canal a partir do cliente.

Exemplos úteis de comandos

# Ver o DC que atendeu o logon
echo %LOGONSERVER%

Listar DCs do domínio

nltest /dclist\:dominio.local

Forçar atualização de registros dinâmicos de DNS do cliente

ipconfig /registerdns

Limpar tickets Kerberos (em caso de credenciais antigas em cache)

klist purge

Modelo de runbook para a equipe de suporte

Coletar: hostname, usuário, IP, VLAN, resultados de ipconfig /all e w32tm /query /status.
Checar eventos 5719/5722/5805 e 40960/40961 no cliente.
Validar DNS/hora; corrigir.
Rodar Test-ComputerSecureChannel -Repair (ou nltest /sc_reset).
Se falhar: apontar para DC específico (-Server DC01), repetir.
Persistindo: Reset Account no AD + reingresso.
Abrir incidente para equipe de AD se houver erros de replicação (repadmin/dcdiag).

Políticas e registro relevantes

Política (pt‑BR)	Equivalente (en‑US)	Local	Registro
Membro de Domínio: Idade máxima da senha da conta de máquina	Domain member: Maximum machine account password age	Configuração do Computador > Configurações do Windows > Configurações de Segurança > Políticas Locais > Opções de Segurança	`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge` (dias)
Membro de Domínio: Desabilitar alterações de senha de contas de máquina	Domain member: Disable machine account password changes	Mesmo caminho	`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange` (0 = permitir)

Script de diagnóstico tudo‑em‑um (cliente)

# Executar como administrador local
$dom = (Get-WmiObject Win32_ComputerSystem).Domain
Write-Host "Dominio detectado: $dom"

Write-Host "\`n-- DNS --"
ipconfig /all
nltest /dsgetdc:\$dom

Write-Host "\`n-- Tempo --"
w32tm /query /status

Write-Host "\`n-- Canal seguro --"
nltest /sc\_verify:\$dom

Write-Host "\`n-- Tentando reparo (se necessario) --"
if (-not (Test-ComputerSecureChannel)) {
\$cred = Get-Credential "\$dom\Admin"
Test-ComputerSecureChannel -Repair -Credential \$cred
}

Observações úteis

Altera-se a senha do computador, não a do usuário. Perfis e dados locais permanecem.
Se o PC falar com DC “antigo”, use -Server DCAtual para forçar o reparo contra um DC saudável.
Depois do reparo, reinicie a máquina para garantir sessão limpa e aplicação de políticas.

Checklist rápido

☐ Cliente aponta somente para DNS interno (DCs).
☐ Hora correta no cliente e nos DCs (w32tm /query /status sem desvios).
☐ Replicação do AD sem erros (repadmin /replsummary / dcdiag ok).
☐ Reparar canal seguro (Test-ComputerSecureChannel / nltest / netdom).
☐ Reiniciar e testar logon no domínio.

Resumo executivo

O erro de “relação de confiança” é quase sempre um problema de canal seguro quebrado — consequência de senha de máquina fora de sincronia, hora incorreta, DNS externo em clientes ou replicação inconfiável. A correção eficaz e menos intrusiva é reparar o canal pelo próprio cliente (PowerShell/CMD), validando e corrigindo previamente DNS e tempo. Para acabar com reincidências, mantenha políticas de senha de máquina ativas, tempo e DNS gerenciados por GPO, e monitoramento de eventos de Netlogon/Kerberos e replicação do AD.