Porque uma VPN não corrige o relógio de um portátil associado ao domínio

Um trabalhador remoto liga a VPN, o túnel sobe e os inícios de sessão começam a falhar com um erro de autenticação que menciona a hora. Nada do túnel está avariado. Uma VPN transporta pacotes entre redes; não dá a duas máquinas um relógio comum, e a autenticação de domínio, a validação de certificados e a correlação de auditoria dependem todas de relógios que concordem o suficiente. Daí decorrem três decisões: quem é dono da hora no domínio, o que o dispositivo usa realmente e o que acontece enquanto o dispositivo está em roaming.

Um caminho não é um relógio

A autenticação Kerberos inclui dados sensíveis ao tempo e rejeita pedidos fora de uma tolerância configurada, que por predefinição é de cinco minutos nos domínios Windows. Os certificados têm intervalos de validade, pelo que um dispositivo cujo relógio esteja suficientemente adiantado trata um certificado válido como ainda não válido. Os registos de auditoria de várias máquinas só se correlacionam se os relógios estiverem próximos, e isso conta a primeira vez que uma revisão de incidente pergunta o que aconteceu primeiro.

Essas três dependências são independentes do túnel. Levantar uma VPN altera a acessibilidade, e a acessibilidade é o que permite a um dispositivo encontrar uma origem de tempo; não é a origem.

Mantenha o fuso horário apresentado separado do relógio em si. Dois portáteis que mostram horas locais diferentes podem estar perfeitamente sincronizados, e dois que mostram a mesma hora podem divergir em minutos se as definições de fuso horário forem diferentes. Mudar o fuso horário não é uma reparação de um relógio errado, e recuar uma data para que um certificado expirado funcione quebra todas as outras verificações da máquina que dependem do tempo.

Decida quem é dono da hora no domínio

Os membros Windows associados ao domínio seguem normalmente a hierarquia de tempo do Active Directory em vez de consultar um servidor público de cada vez. Essa cadeia termina no emulador PDC da raiz da floresta, cuja referência é a origem autoritativa da organização.

Duas condições decidem a referência: se a política permite um serviço de tempo externo e se a rede consegue alcançar de forma fiável uma origem interna aprovada a partir de cada local. Se ambas forem pouco claras, a resposta prática é manter a hierarquia intacta e corrigir a acessibilidade em vez de apontar os clientes para um conjunto público. Uma terceira condição decide o caminho de falha: o que o dispositivo deve fazer quando nenhuma das origens está acessível. Resolver isso antecipadamente evita a correção improvisada de fixar um servidor público num único portátil.

Essa escolha pertence aos administradores de domínio e de tempo, não ao desenho do acesso remoto. Um portátil que se configura como autoridade de tempo fiável é outra arquitetura, e raramente é a que a revisão de segurança aprovou.

Leia o que o dispositivo está realmente a usar

Dois comandos só de leitura documentam o estado atual num dispositivo Windows gerido, e vale a pena registá-los antes e depois de uma alteração:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

Anote a origem selecionada, a última sincronização bem-sucedida e o estrato ou identificador de referência junto à política de gestão do dispositivo. Uma sincronização manual bem-sucedida prova que o comando funciona, não que a política sobrevive a um reinício ou a uma mudança de função.

Se a origem mostrar o relógio CMOS local, o dispositivo não está a sincronizar de todo, o que normalmente significa que o controlador de domínio não estava acessível no arranque ou que o serviço de tempo foi desativado por política. Se mostrar um servidor público, algo fora da hierarquia do domínio está a ganhar, e isso é uma questão de política, não de rede.

Decida o que acontece em roaming

Enquanto está desligado, um dispositivo depende do seu relógio local e dos fornecedores de tempo que consegue alcançar. Os portáteis derivam, e um dispositivo que esteve semanas offline pode desviar-se o suficiente para falhar o primeiro pedido Kerberos após a reconexão.

Ao reconectar, o dispositivo precisa de descoberta do domínio e do caminho previsto para o serviço de tempo, não apenas de uma rota para uma partilha de ficheiros. Teste isso reiniciando fora da rede, ligando a VPN e lendo novamente a origem, em vez de assumir que a hierarquia se restabeleceu sozinha.

As máquinas virtuais acrescentam outro fornecedor. A integração de tempo do hipervisor é uma origem legítima em muitos desenhos, mas o seu papel deve ser escolhido deliberadamente e coordenado com a política do domínio. Dois fornecedores em desacordo produzem um relógio que parece estável e está errado.

Mantenha a política dos membros separada da autoridade

A configuração comum de um membro e a configuração do servidor autoritativo são problemas diferentes com controlos de alteração diferentes. Misturá-los é a forma como uma alteração de rotina à política de um portátil acaba por alterar a referência de toda a floresta.

Escreva o registo da decisão em quatro linhas: a origem autoritativa, a hierarquia que a transporta, o comportamento em roaming e o comando que prova o estado num dispositivo. Se as três primeiras estiverem documentadas e a quarta for repetível, uma falha de início de sessão relacionada com o tempo passa a ser uma verificação de cinco minutos em vez de uma caça nos registos da VPN.