De ce un VPN nu repară ceasul unui laptop înscris în domeniu

Un angajat la distanță conectează VPN-ul, tunelul urcă și autentificările încep să eșueze cu o eroare de autentificare care menționează timpul. Nimic din tunel nu este stricat. Un VPN transportă pachete între rețele; nu le dă două mașini un ceas comun, iar autentificarea de domeniu, validarea certificatelor și corelarea auditului depind toate de ceasuri care coincid suficient de bine. De aici decurg trei decizii: cine deține timpul în domeniu, ce folosește de fapt dispozitivul și ce se întâmplă în timp ce dispozitivul este în roaming.

O cale nu este un ceas

Autentificarea Kerberos include date sensibile la timp și respinge cererile din afara unei toleranțe configurate, care în domeniile Windows este de cinci minute implicit. Certificatele au intervale de valabilitate, așa că un dispozitiv al cărui ceas este suficient de avansat tratează un certificat valid ca încă nevalid. Înregistrările de audit de la mai multe mașini se corelează doar dacă ceasurile lor sunt apropiate, iar acest lucru contează prima dată când o analiză de incident întreabă ce s-a întâmplat mai întâi.

Acele trei dependențe sunt independente de tunel. Ridicarea unui VPN schimbă accesibilitatea, iar accesibilitatea este ceea ce permite unui dispozitiv să găsească o sursă de timp; nu este sursa.

Țineți fusul orar afișat separat de ceasul propriu-zis. Două laptopuri care afișează ore locale diferite pot fi perfect sincronizate, iar două care afișează aceeași oră pot diferi cu minute dacă setările de fus orar diferă. Schimbarea fusului orar nu este o reparație a unui ceas greșit, iar retrogradarea unei date pentru ca un certificat expirat să funcționeze strică orice altă verificare a mașinii care depinde de timp.

Decideți cine deține timpul în domeniu

Membrii Windows înscriși în domeniu urmează de obicei ierarhia de timp a Active Directory în loc să întrebe un server public de fiecare dată. Lanțul se termină la emulatorul PDC al rădăcinii pădurii, a cărui referință este sursa autoritară a organizației.

Două condiții decid referința: dacă politica permite un serviciu de timp extern și dacă rețeaua poate ajunge în mod fiabil la o sursă internă aprobată din fiecare locație. Dacă ambele sunt neclare, răspunsul practic este să păstrați ierarhia intactă și să reparați accesibilitatea în loc să îndreptați clienții către un pool public. O a treia condiție decide calea de eșec: ce trebuie să facă dispozitivul când niciuna dintre surse nu este accesibilă. Stabilirea acestui lucru în avans evită soluția improvizată de a fixa un server public pe un singur laptop.

Alegerea aparține administratorilor de domeniu și de timp, nu proiectării accesului la distanță. Un laptop care se configurează ca autoritate de timp de încredere este altă arhitectură și rareori cea aprobată de revizuirea de securitate.

Citiți ce folosește de fapt dispozitivul

Două comenzi doar pentru citire documentează starea curentă pe un dispozitiv Windows administrat, iar acestea merită înregistrate înainte și după o modificare:

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

Notați sursa selectată, ultima sincronizare reușită și stratul sau identificatorul de referință lângă politica de administrare a dispozitivului. O singură sincronizare manuală reușită dovedește că comanda funcționează, nu că politica supraviețuiește unei reporniri sau unei schimbări de rol.

Dacă sursa arată ceasul CMOS local, dispozitivul nu se sincronizează deloc, ceea ce înseamnă de obicei că controlerul de domeniu nu era accesibil la pornire sau că serviciul de timp a fost dezactivat prin politică. Dacă arată un server public, câștigă ceva din afara ierarhiei domeniului, iar aceasta este o problemă de politică, nu de rețea.

Decideți ce se întâmplă în roaming

Cât timp este deconectat, un dispozitiv se bazează pe ceasul său local și pe orice furnizori de timp pe care îi poate accesa. Laptopurile derivează, iar un dispozitiv care a fost offline săptămâni poate deriva suficient încât prima cerere Kerberos după reconectare să eșueze.

La reconectare, dispozitivul are nevoie de descoperirea domeniului și de calea prevăzută către serviciul de timp, nu doar de o rută către o partajare de fișiere. Testați acest lucru repornind în afara rețelei, conectând VPN-ul și citind din nou sursa, în loc să presupuneți că ierarhia s-a restabilit singură.

Mașinile virtuale adaugă un alt furnizor. Integrarea timpului de la hipervizor este o sursă legitimă în multe proiecte, dar rolul ei trebuie ales deliberat și coordonat cu politica domeniului. Doi furnizori în dezacord produc un ceas care pare stabil și este greșit.

Țineți politica membrilor separată de autoritate

Configurația obișnuită a unui membru și configurația serverului autoritar sunt probleme diferite cu control al modificărilor diferit. Amestecarea lor este modul în care o modificare de rutină a politicii unui laptop ajunge să modifice referința pentru întreaga pădure.

Scrieți decizia în patru linii: sursa autoritară, ierarhia care o transportă, comportamentul în roaming și comanda care dovedește starea pe un dispozitiv. Dacă primele trei sunt documentate, iar a patra este repetabilă, o eroare de autentificare legată de timp devine o verificare de cinci minute în loc de o vânătoare prin jurnalele VPN.