Per què una VPN no arregla el rellotge d’un portàtil unit al domini

Un treballador remot connecta la VPN, el túnel s’aixeca i els inicis de sessió comencen a fallar amb un error d’autenticació que esmenta l’hora. No hi ha res trencat al túnel. Una VPN transporta paquets entre xarxes; no dona a dues màquines un rellotge comú, i l’autenticació de domini, la validació de certificats i la correlació d’auditoria depenen de rellotges que coincideixin prou. Se’n deriven tres decisions: qui posseeix l’hora al domini, què fa servir realment el dispositiu i què passa mentre el dispositiu és en itinerància.

Un camí no és un rellotge

L’autenticació Kerberos inclou dades sensibles al temps i rebutja les peticions que queden fora d’una tolerància configurada, que per defecte és de cinc minuts als dominis de Windows. Els certificats porten intervals de validesa, així que un dispositiu amb el rellotge prou avançat tracta un certificat vàlid com a encara no vàlid. Els registres d’auditoria de diverses màquines només es correlacionen si els seus rellotges són propers, i això importa el primer cop que una revisió d’incident pregunta què va passar abans.

Aquestes tres dependències són independents del túnel. Aixecar una VPN canvia la connectivitat, i la connectivitat és el que permet a un dispositiu trobar una font de temps; no és la font.

Manteniu la zona horària mostrada separada del rellotge mateix. Dos portàtils que mostren hores locals diferents poden estar perfectament sincronitzats, i dos que mostren la mateixa hora poden discrepar en minuts si la configuració de zona horària difereix. Canviar la zona horària no és una reparació d’un rellotge incorrecte, i fer retrocedir una data perquè funcioni un certificat caducat trenca tota la resta de comprovacions del dispositiu que depenen del temps.

Decidiu qui posseeix l’hora al domini

Els membres de Windows units al domini normalment segueixen la jerarquia de temps d’Active Directory en lloc de consultar un servidor públic cada cop. Aquesta cadena acaba a l’emulador PDC de l’arrel del bosc, la referència del qual és la font autoritzada de l’organització.

Dues condicions decideixen la referència: si la política permet un servei de temps extern i si la xarxa pot arribar de manera fiable a una font interna aprovada des de cada lloc. Si totes dues són poc clares, la resposta pràctica és mantenir la jerarquia intacta i arreglar la connectivitat en lloc d’apuntar els clients a un pool públic. Una tercera condició decideix el camí de fallada: què ha de fer el dispositiu quan no és abastable cap de les dues fonts. Resoldre-ho per endavant evita la solució improvisada de fixar un servidor públic en un sol portàtil.

Aquesta tria pertany als administradors del domini i del temps, no al disseny de l’accés remot. Un portàtil que es configura com a autoritat de temps fiable és una altra arquitectura, i poques vegades és la que va aprovar la revisió de seguretat.

Llegiu què fa servir realment el dispositiu

Dues ordres de només lectura documenten l’estat actual en un dispositiu Windows gestionat, i val la pena capturar-les abans i després d’un canvi:

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

Anoteu la font seleccionada, l’última sincronització correcta i l’estrat o l’identificador de referència al costat de la política de gestió del dispositiu. Una sincronització manual correcta demostra que l’ordre funciona, no que la política sobrevisqui a un reinici o a un canvi de rol.

Si la font mostra el rellotge CMOS local, el dispositiu no se sincronitza gens, cosa que normalment vol dir que el controlador de domini no era abastable en arrencar o que el servei de temps estava desactivat per política. Si mostra un servidor públic, hi ha alguna cosa fora de la jerarquia del domini que guanya, i això és una qüestió de política, no de xarxa.

Decidiu què passa durant la itinerància

Mentre està desconnectat, el dispositiu depèn del seu rellotge local i dels proveïdors de temps que pugui abastar. Els portàtils es desvien, i un dispositiu que ha estat setmanes fora de línia pot desviar-se prou per fallar la primera petició Kerberos després de reconnectar-se.

En reconnectar-se, el dispositiu necessita descobriment de domini i el camí previst del servei de temps, no només una ruta a un recurs compartit. Comproveu-ho reiniciant fora de la xarxa, connectant la VPN i tornant a llegir la font, en lloc de suposar que la jerarquia s’ha restablert sola.

Les màquines virtuals afegeixen un altre proveïdor. La integració de temps de l’hipervisor és una font legítima en molts dissenys, però el seu paper s’ha de triar deliberadament i coordinar amb la política del domini. Dos proveïdors que no coincideixen produeixen un rellotge que sembla estable i és incorrecte.

Manteniu la política dels membres a part de l’autoritat

La configuració ordinària d’un membre i la configuració del servidor autoritzat són problemes diferents amb controls de canvi diferents. Barrejar-los és com un canvi rutinari de política en un portàtil acaba alterant la referència de tot el bosc.

Escriviu el registre de decisió en quatre línies: la font autoritzada, la jerarquia que la transporta, el comportament en itinerància i l’ordre que demostra l’estat en un dispositiu. Si les tres primeres estan documentades i la quarta és repetible, una fallada d’inici de sessió relacionada amb el temps es converteix en una comprovació de cinc minuts en lloc d’una cacera pels registres de la VPN.