Por qué una VPN no arregla el reloj de un portátil unido al dominio

Un trabajador remoto conecta la VPN, el túnel se levanta y los inicios de sesión empiezan a fallar con un error de autenticación que menciona la hora. Nada del túnel está roto. Una VPN transporta paquetes entre redes; no da a dos máquinas un reloj común, y la autenticación de dominio, la validación de certificados y la correlación de auditoría dependen de relojes que coincidan lo bastante. De ahí se siguen tres decisiones: quién posee la hora en el dominio, qué usa realmente el dispositivo y qué ocurre mientras el dispositivo está en itinerancia.

Una ruta no es un reloj

La autenticación Kerberos incluye datos sensibles al tiempo y rechaza las peticiones que quedan fuera de una tolerancia configurada, que por defecto es de cinco minutos en los dominios de Windows. Los certificados llevan intervalos de validez, así que un dispositivo cuyo reloj va lo bastante adelantado trata un certificado válido como todavía no válido. Los registros de auditoría de varias máquinas solo se correlacionan si sus relojes están cerca, y eso importa la primera vez que una revisión de incidente pregunta qué ocurrió antes.

Esas tres dependencias son independientes del túnel. Levantar una VPN cambia la accesibilidad, y la accesibilidad es lo que permite a un dispositivo encontrar una fuente de tiempo; no es la fuente.

Mantenga la zona horaria mostrada separada del reloj en sí. Dos portátiles que muestran horas locales distintas pueden estar perfectamente sincronizados, y dos que muestran la misma hora pueden discrepar en minutos si sus ajustes de zona horaria difieren. Cambiar la zona horaria no es una reparación de un reloj incorrecto, y retrasar una fecha para que funcione un certificado caducado rompe todas las demás comprobaciones del equipo que dependen del tiempo.

Decida quién posee la hora en el dominio

Los miembros de Windows unidos al dominio suelen seguir la jerarquía de tiempo de Active Directory en lugar de consultar un servidor público cada vez. Esa cadena termina en el emulador PDC de la raíz del bosque, cuya referencia es la fuente autoritativa de la organización.

Dos condiciones deciden la referencia: si la directiva permite un servicio de hora externo y si la red puede alcanzar de forma fiable una fuente interna aprobada desde cada sitio. Si ambas son poco claras, la respuesta práctica es mantener la jerarquía intacta y arreglar la accesibilidad en lugar de apuntar a los clientes a un grupo público. Una tercera condición decide la ruta de fallo: qué debe hacer el dispositivo cuando no se alcanza ninguna de las dos fuentes. Resolverlo por adelantado evita la solución improvisada de fijar un servidor público en un solo portátil.

Esa elección corresponde a los administradores de dominio y de tiempo, no al diseño del acceso remoto. Un portátil que se configura como autoridad de tiempo fiable es otra arquitectura, y rara vez es la que aprobó la revisión de seguridad.

Lea qué está usando realmente el dispositivo

Dos comandos de solo lectura documentan el estado actual en un dispositivo Windows gestionado, y merece la pena capturarlos antes y después de un cambio:

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

Anote el origen seleccionado, la última sincronización correcta y el estrato o identificador de referencia junto a la directiva de gestión del dispositivo. Una sincronización manual correcta demuestra que el comando funciona, no que la directiva sobreviva a un reinicio o a un cambio de rol.

Si el origen muestra el reloj CMOS local, el dispositivo no está sincronizando en absoluto, lo que suele significar que el controlador de dominio no era accesible al arrancar o que el servicio de hora estaba deshabilitado por directiva. Si muestra un servidor público, algo fuera de la jerarquía del dominio está ganando, y eso es una cuestión de directiva, no de red.

Decida qué ocurre durante la itinerancia

Mientras está desconectado, un dispositivo depende de su reloj local y de los proveedores de tiempo que pueda alcanzar. Los portátiles derivan, y un dispositivo que ha estado semanas sin conexión puede desviarse lo suficiente como para fallar la primera petición Kerberos tras reconectarse.

Al reconectarse, el dispositivo necesita descubrimiento de dominio y la ruta prevista del servicio de hora, no solo una ruta a un recurso compartido. Compruébelo reiniciando fuera de la red, conectando la VPN y leyendo de nuevo el origen en lugar de suponer que la jerarquía se restableció sola.

Las máquinas virtuales añaden otro proveedor. La integración de tiempo del hipervisor es una fuente legítima en muchos diseños, pero su papel debe elegirse deliberadamente y coordinarse con la directiva del dominio. Dos proveedores que no coinciden producen un reloj que parece estable y es incorrecto.

Mantenga la directiva de miembros aparte de la autoridad

La configuración ordinaria de un miembro y la configuración del servidor autoritativo son problemas distintos con controles de cambio distintos. Mezclarlos es como un cambio rutinario de directiva en un portátil acaba alterando la referencia de todo el bosque.

Escriba el registro de decisión en cuatro líneas: la fuente autoritativa, la jerarquía que la transporta, el comportamiento en itinerancia y el comando que demuestra el estado en un dispositivo. Si las tres primeras están documentadas y la cuarta es repetible, un fallo de inicio de sesión relacionado con el tiempo se convierte en una comprobación de cinco minutos en lugar de una cacería por los registros de la VPN.