Por que unha VPN non arranxa o reloxo dun portátil unido ao dominio

Un traballador remoto conecta a VPN, o túnel sobe e os inicios de sesión comezan a fallar cun erro de autenticación que menciona a hora. Nada do túnel está roto. Unha VPN transporta paquetes entre redes; non dá a dúas máquinas un reloxo común, e a autenticación de dominio, a validación de certificados e a correlación de auditoría dependen de reloxos que coincidan o suficiente. De aí derivan tres decisións: quen posúe a hora no dominio, que usa realmente o dispositivo e que ocorre mentres o dispositivo está en itinerancia.

Unha ruta non é un reloxo

A autenticación Kerberos inclúe datos sensibles ao tempo e rexeita as peticións que quedan fóra dunha tolerancia configurada, que por defecto é de cinco minutos nos dominios de Windows. Os certificados levan intervalos de validez, así que un dispositivo cuxo reloxo vai o suficiente adiantado trata un certificado válido como aínda non válido. Os rexistros de auditoría de varias máquinas só se correlacionan se os seus reloxos están preto, e iso importa a primeira vez que unha revisión de incidente pregunta que ocorreu antes.

Eses tres dependencias son independentes do túnel. Levantar unha VPN cambia a accesibilidade, e a accesibilidade é o que permite a un dispositivo atopar unha orixe de tempo; non é a orixe.

Manteña a zona horaria mostrada separada do reloxo en si. Dous portátiles que mostran horas locais distintas poden estar perfectamente sincronizados, e dous que mostran a mesma hora poden discrepar en minutos se os seus axustes de zona horaria difiren. Cambiar a zona horaria non é unha reparación dun reloxo incorrecto, e atrasar unha data para que funcione un certificado caducado rompe todas as demais comprobacións do equipo que dependen do tempo.

Decida quen posúe a hora no dominio

Os membros de Windows unidos ao dominio adoitan seguir a xerarquía de tempo de Active Directory en lugar de consultar un servidor público cada vez. Esa cadea remata no emulador PDC da raíz do bosque, cuxa referencia é a orixe autoritativa da organización.

Dúas condicións deciden a referencia: se a directiva permite un servizo de hora externo e se a rede pode alcanzar de forma fiable unha orixe interna aprobada desde cada sitio. Se ambas son pouco claras, a resposta práctica é manter a xerarquía intacta e arranxar a accesibilidade en lugar de apuntar os clientes a un grupo público. Unha terceira condición decide a ruta de fallo: que debe facer o dispositivo cando non se alcanza ningunha das dúas orixes. Resolvelo por adiantado evita a solución improvisada de fixar un servidor público nun só portátil.

Esa elección corresponde aos administradores de dominio e de tempo, non ao deseño do acceso remoto. Un portátil que se configura como autoridade de tempo fiable é outra arquitectura, e raramente é a que aprobou a revisión de seguridade.

Lea que está a usar realmente o dispositivo

Dous comandos de só lectura documentan o estado actual nun dispositivo Windows xestionado, e paga a pena capturalos antes e despois dun cambio:

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

Anote a orixe seleccionada, a última sincronización correcta e o estrato ou identificador de referencia xunto á directiva de xestión do dispositivo. Unha sincronización manual correcta demostra que o comando funciona, non que a directiva sobreviva a un reinicio ou a un cambio de rol.

Se a orixe mostra o reloxo CMOS local, o dispositivo non está sincronizando en absoluto, o que adoita significar que o controlador de dominio non era accesible ao arrincar ou que o servizo de hora estaba desactivado por directiva. Se mostra un servidor público, algo fóra da xerarquía do dominio está gañando, e iso é unha cuestión de directiva, non de rede.

Decida que ocorre durante a itinerancia

Mentres está desconectado, un dispositivo depende do seu reloxo local e dos provedores de tempo que poida alcanzar. Os portátiles derivan, e un dispositivo que estivo semanas sen conexión pode desviarse o suficiente como para fallar a primeira petición Kerberos tras reconectarse.

Ao reconectarse, o dispositivo necesita descubrimento de dominio e a ruta prevista do servizo de hora, non só unha ruta a un recurso compartido. Compruébeo reiniciando fóra da rede, conectando a VPN e lendo de novo a orixe en lugar de supor que a xerarquía se restableceu soa.

As máquinas virtuais engaden outro provedor. A integración de tempo do hipervisor é unha orixe lexítima en moitos deseños, pero o seu papel debe elixirse deliberadamente e coordinarse coa directiva do dominio. Dous provedores que non coinciden producen un reloxo que parece estable e é incorrecto.

Manteña a directiva de membros aparte da autoridade

A configuración ordinaria dun membro e a configuración do servidor autoritativo son problemas distintos con controis de cambio distintos. Mesturalos é como un cambio rutineiro de directiva nun portátil acaba alterando a referencia de todo o bosque.

Escriba o rexistro de decisión en catro liñas: a orixe autoritativa, a xerarquía que a transporta, o comportamento en itinerancia e o comando que demostra o estado nun dispositivo. Se as tres primeiras están documentadas e a cuarta é repetible, un fallo de inicio de sesión relacionado co tempo convértese nunha comprobación de cinco minutos en lugar dunha caza polos rexistros da VPN.