Windows Server 2019 “cai do domínio” no VMware: diagnóstico e correção definitiva (Netlogon, Kerberos e DNS)

Se o seu Windows Server 2019 em ambiente VMware às vezes “cai do domínio” e mostra “We can’t sign you in with this credential because your domain isn’t available …”, este guia prático apresenta um playbook completo de diagnóstico e correção, priorizando Rede → DNS → Hora → Canal seguro, com comandos e checklists.

Índice

Visão geral do problema

O sintoma típico é a impossibilidade de autenticar no domínio de forma intermitente. Após uma reinicialização, o servidor volta a ingressar no domínio sem intervenção — o que complica a análise por mascarar a causa raiz. Em geral, a origem está em um destes pontos: conectividade momentânea com os Controladores de Domínio (DCs), resolução DNS inconsistente, desalinhamento de horário (Kerberos), ou quebra do canal seguro (secure channel) entre a conta de computador e o DC.

“We can’t sign you in with this credential because your domain isn’t available …”

Este artigo entrega um roteiro objetivo e reproduzível para fechar o diagnóstico e aplicar correções duradouras.

Sintomas e impacto

Erro de logon de domínio no console/RDP, enquanto outras VMs na mesma rede funcionam normalmente.
Serviços que dependem de Kerberos/LDAP (por exemplo, serviços IIS com Windows Authentication) falham intermitentemente.
Eventos de Netlogon, Kerberos e LSA próximos ao horário da falha (por exemplo, Netlogon 5719/5805 e LSASRV 40960/40961).
Após reiniciar a VM, o logon volta ao normal por algum tempo.

Causas prováveis e o que verificar

Área	O que verificar	Ferramentas / comandos úteis
Rede	Quedas de conectividade entre a VM e os DCs, falha de switch/porta, NIC virtual instável ou drivers desatualizados.	`ping <DC> -t`, monitor SNMP/ICMP, métricas vSphere, logs de host ESXi.
DNS	Resolução intermitente do FQDN dos DCs, uso de DNS externo/errado na NIC, ou ordem de DNS incorreta.	`nslookup <domínio>`, validação de servidores DNS na NIC, `ipconfig /all`.
Sincronismo de hora	Desvio (> 5 min) entre a VM e os DCs invalida tickets Kerberos.	`w32tm /query /status`, comparação com o DC, `w32tm /resync`.
Canal seguro	Corrupção do secure channel máquina⇄DC, às vezes causada por snapshot revertido ou replicação AD lenta.	`nltest /scverify`, `nltest /screset`, `Test-ComputerSecureChannel`.
Credenciais em cache	Falha ao usar credenciais em cache quando o DC não está acessível, especialmente para contas recém-criadas.	Tentar login local com outra conta de domínio já usada na VM.
Saúde dos DCs	Replicação, sobrecarga, reinícios ou indisponibilidade momentânea de sites remotos.	`dcdiag`, `repadmin /replsummary`, Event Viewer dos DCs.
Eventos locais	Mensagens de Netlogon, Kerberos e LSA nos minutos que antecedem o erro.	Event Viewer → System & Security (IDs 5719, 5805, 40960, 40961, 4, 5, 7).

Checklist rápido para estabilizar

Fixe somente os IPs dos DCs como DNS preferencial/alternativo na NIC da VM (evite DNS público).
Valide conectividade contínua com pings prolongados aos DCs e monitore perda/latência.
Garanta hora correta e fonte única de tempo (desabilite sincronismo do VMware Tools, se aplicável, e use o domínio).
Verifique e repare o secure channel da máquina.
Correlacione eventos no Windows com métricas do ESXi (flapping de link, perda de pacotes, vMotion).

Procedimento de diagnóstico detalhado

Rede: conectividade e estabilidade

Execute ping <DC> -t por alguns minutos; registre perdas e variação de latência. Faça o mesmo para o FQDN do domínio.
No vSphere, observe quedas no port group, falhas de NIC virtual (link state changes) e eventos de vMotion próximos aos horários do erro.
Se estiver usando NIC E1000, considere migrar para VMXNET3 e atualizar o driver VMware Tools/VMXNET.
Valide VLAN e port group corretos; teste mover a VM para outro host ESXi ou outro port group (desvio controlado).
Se houver NIC Teaming no vSwitch distribuído, confirme políticas LACP/Port‑Channel e hashing consistentes nos switches físicos.

DNS: apenas interno e previsível

No adaptador da VM, configure como DNS apenas DCs ou servidores DNS internos que hospedem a zona do AD.
Confirme sufixo DNS primário e registro do host:

ipconfig /all
ipconfig /flushdns
ipconfig /registerdns
nslookup ldap.tcp.dc._msdcs.<dominio>

Evite múltiplas NICs registrando no DNS; se necessário, desabilite “Registrar este endereço no DNS” na NIC secundária.
Verifique se o site/sub-rede do AD está mapeado corretamente (Active Directory Sites and Services), evitando busca de DC remoto.

Hora: fundamento do Kerberos

Em membros do domínio, prefira sincronizar com o domínio (via cadeia do PDC Emulator). Desative o sincronismo do host/hypervisor:

# vSphere (GUI da VM): desmarque "Synchronize guest time with host".
No Windows:
w32tm /query /status
w32tm /resync
Opcional: apontar manualmente (se autorizado pela política)
w32tm /config /syncfromflags:DOMHIER /update
net stop w32time && net start w32time

Confirme que a diferença de hora é menor que 5 minutos entre VM e DC. Se for maior, investigue a fonte de tempo do domínio.

Canal seguro com o domínio

O secure channel é o “túnel” de confiança entre a conta de computador e o DC. Snapshots antigos ou replicação AD atrasada podem quebrá‑lo.

# Validar e reparar com PowerShell (execute como Administrador)
Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Verbose

Alternativa com NLTEST (cmd)

nltest /sc_verify:
nltest /sc_reset:

Se o problema reaparece após reinícios, automatize a verificação (ver seção “Scripts úteis”).

Saúde dos DCs e da replicação

dcdiag /v
repadmin /replsummary
repadmin /showrepl * /csv

Procure por atrasos de replicação, falhas intermitentes de RPC e sobrecarga no PDC Emulator.

Eventos locais e correlação temporal

Crie uma Custom View para filtrar IDs relevantes próximos ao erro:

# System e Security (Netlogon, Kerberos, LSA)
Exemplos comuns:
Netlogon: 5719 (sem DC), 5805 (falha autenticação), 5722 (senha da conta de computador incorreta)
LSASRV: 40960/40961 (falhas credenciais/segurança)
Kerberos: 4 (KRBAPERR_MODIFIED), 5 (clock skew), 7 (falhas diversas)

Correlacione o minuto da falha com vMotion, queda de NIC ou switch, reinício de DC, manutenção de rede ou backup que sature I/O.

Notas específicas para VMware

Prefira VMXNET3. Avalie desativar/ativar offloads (TSO/LRO/Checksum) apenas se evidenciada perda de pacotes.
Evite snapshots antigos: reverter a snapshots rompem o secure channel (senha de máquina expira periodicamente).
Verifique se a VM não está em host isolation ou com HA failover recente durante as ocorrências.

Correções duradouras e boas práticas

DNS interno consistente

Use exclusivamente DNS interno nos membros do domínio. Nunca mescle DNS interno com público na mesma NIC.
Mantenha as zonas do AD integradas e replicando; habilite scavenging adequado para registros antigos de VMs movidas.

Hora em uma única hierarquia

Defina a hierarquia de tempo: PDC Emulator ⇄ fonte de tempo confiável; demais DCs e membros sincronizam da hierarquia (evite múltiplas origens).
Desabilite a sincronização do VMware Tools nos membros do domínio (exceto em cenários específicos e bem documentados).

Atraso de logon até a rede estar pronta

Para evitar que o Windows tente autenticar antes de a rede estar disponível após o boot, habilite a política:

Computer Configuration → Policies → Administrative Templates → System → Logon
"Always wait for the network at computer startup and logon" = Enabled

Canal seguro resiliente

Se suspeitar de quebra recorrente, crie tarefa agendada para validar/recuperar o secure channel fora do horário de pico.
Evite “remover e reingressar” do domínio como solução de rotina; isso esconde a causa.

Atualizações e drivers

Mantenha o Windows Server 2019 atualizado, especialmente patches que tocam Netlogon/Kerberos.
Atualize VMware Tools e drivers de NIC. Avalie trocar E1000 por VMXNET3.

Roteiro de testes reproduzível

Ping contínuo: rode contra dois DCs simultaneamente e capture perdas.
Consulta DNS: nslookup <dominio> e nslookup kerberos.tcp.dc._msdcs.<dominio>; valide respostas consistentes.
Hora: compare w32tm /query /status da VM e do DC (offset baixo).
Secure channel: Test-ComputerSecureChannel e repare se necessário.
Event Viewer: filtre IDs citados e correlacione com vSphere.

Matriz de sintomas e causa provável

Sintoma observado	Suspeita principal	Ação imediata
Erro de logon logo após boot	Rede não pronta; DHCP lento; dependências de serviço	Habilitar “Always wait…”, validar ordem de serviços e NIC
Falha durante janelas de backup	Saturação de I/O/rede; perda momentânea	Testar sem backup; revisar QoS e janelas
Falha pós‑snapshot/vMotion	Secure channel quebrado; latência temporária	Reparar secure channel; evitar snapshots antigos
Falha isolada em uma VM	NIC/driver/port‑group específico	Mover para outro host/port‑group; atualizar driver
Falhas aleatórias em horários diversos	DNS externo/ordem incorreta na NIC	Fixar apenas DNS interno; limpar/registar DNS

Lista de portas essenciais a verificar

Serviço	Porta	Protocolo	Uso
Kerberos	88	TCP/UDP	Autenticação
LDAP	389	TCP/UDP	Consulta AD
LDAP Global Catalog	3268	TCP	GC
SMB	445	TCP	Netlogon, scripts de logon
RPC Endpoint Mapper	135	TCP	RPC
RPC dinâmico	49152–65535	TCP	Vários serviços AD
DNS	53	TCP/UDP	Resolução de nomes

Verifique políticas de firewall locais e de perímetro garantindo tráfego bidirecional com os DCs.

Scripts úteis para agilizar

Verificação e autorreparo do secure channel

param([switch]$Repair)

$ok = Test-ComputerSecureChannel -Verbose -ErrorAction SilentlyContinue
if (-not $ok -and $Repair) {
Write-Host "Tentando reparar o secure channel..."
$ok = Test-ComputerSecureChannel -Repair -Verbose
}
if ($ok) {
Write-Output "Secure channel OK"
exit 0
} else {
Write-Output "Secure channel com problemas"
exit 1
}

Dica: crie uma Tarefa Agendada que rode a cada 30–60 minutos fora do horário crítico, apenas com -Repair em caso de falha.

Coleta rápida de sinais vitais

# Salva diagnóstico em C:\Temp\diag-dominio.txt
$dc = (Get-ADDomain).PDCEmulator
$report = @()
$report += "Hora local: $(Get-Date)"
$report += ("w32tm: " + (w32tm /query /status 2>&1))
$report += ("DNS NIC: " + (Get-DnsClientServerAddress -AddressFamily IPv4 | 
    Select-Object -ExpandProperty ServerAddresses) -join ", ")
$report += ("SecureChannel: " + (Test-ComputerSecureChannel))
$report += ("Ping DC: " + (Test-Connection -Count 5 -ComputerName $dc | 
    Measure-Object -Property ResponseTime -Average).Average + " ms")
$report | Out-File C:\Temp\diag-dominio.txt -Encoding UTF8

Erros comuns a evitar

Usar DNS público na NIC da VM: isso quebra a localização de DCs e o Kerberos.
Reingressar no domínio como atalho: resolve o efeito, não a causa; investigue o secure channel e a rede.
Sincronizar hora de várias fontes: escolha uma cadeia e siga‑a (domínio ou host — não ambos).
Ignorar o mapeamento de sites/sub‑redes do AD: pode forçar DC remoto e aumentar a intermitência.

Perguntas frequentes

Por que reiniciar “resolve” temporariamente?

O boot restabelece rotas, renova registros DNS, reabre o secure channel e pode recarregar drivers — mascarando a causa real (rede/DNS/hora).

Devo desativar IPv6?

Não por padrão. O AD usa IPv6 quando disponível. O importante é consistência de DNS e conectividade; desativar IPv6 pode introduzir novos problemas.

Snapshots antigos podem quebrar o domínio?

Sim. Reverter a um estado em que a senha da conta de computador não coincide com o AD quebra o secure channel. Evite snapshots longos ou reverte‑os com plano de recuperação do secure channel.

Plano de monitoramento e alerta

Eventos: crie alertas para Netlogon 5719/5805 e LSASRV 40960/40961.
Rede: monitore perda de pacotes e latência para os DCs; habilite notificações quando > 1% por 5 min.
Tempo: alerte se w32tm /query /status reportar offset > 120 s.
DNS: valide periodicamente registros SRV e health da zona _msdcs.

Playbook final de correção

Fixe apenas DNS interno na NIC e limpe/registre o DNS.
Desabilite sincronismo de hora do hypervisor; confirme w32tm alinhado ao domínio.
Atualize VMware Tools/driver da NIC; prefira VMXNET3.
Habilite “Always wait for the network…” na GPO.
Valide e repare o secure channel; considere tarefa agendada de autorreparo.
Correlacione com vSphere: se persistir, mova a VM para outro host/port‑group para isolar hardware/stack.

Seguindo a sequência Rede → DNS → Hora → Canal seguro → Logs, a maioria dos casos é resolvida rapidamente e sem depender de reinicializações manuais.

Apêndice de comandos

# Rede
ping <DC> -t
tracert <DC>

DNS

ipconfig /flushdns
ipconfig /registerdns
nslookup 

Hora

w32tm /query /status
w32tm /resync

Secure channel

Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Verbose
nltest /sc_verify:
nltest /sc_reset:

AD/DC

dcdiag /v
repadmin /replsummary

Conclusão

“Queda de domínio” em Windows Server 2019 quase sempre resulta de um dos quatro pilares: rede, DNS, hora ou secure channel. Com um roteiro disciplinado, correções de configuração (DNS interno, hora única, GPO de espera pela rede) e uma pitada de observabilidade (eventos + métricas do hypervisor), você estabiliza de vez a autenticação, elimina reinicializações desnecessárias e aumenta a confiabilidade do ambiente.