Lipsește politica de grup pe VPN? Verificați domeniul de aplicare înainte de tunel

Ceva ce se aplica în rețeaua biroului încetează să se aplice în săptămâna în care un utilizator începe să lucreze prin VPN, iar tunelul este învinuit înainte ca cineva să deschidă un raport. Politica de grup decide ce setări ajung la utilizatorul și computerul Windows, aduce materialul din domeniu și execută procesarea pe partea de client, iar aceste trei etape eșuează în trei moduri diferite. Tunelul schimbă doar ce cale are clientul. Parcurgerea verificărilor în ordine împiedică urmărirea unei probleme de permisiuni de fișiere ca problemă de rutare.

Începeți cu setarea, nu cu tunelul

Notați o GPO așteptată și o setare concretă în ea, apoi decideți dacă setarea se află în Configurarea utilizatorului sau în Configurarea computerului. Aceasta presupune un client Windows autorizat, înrolat în domeniu, pe un VPN aprobat, nu un dispozitiv neadministrat sau doar în cloud care este transformat în membru al domeniului. Răspunsul privind domeniul de aplicare decide cine poate citi rezultatul și dacă este nevoie de elevare, așa că lămuriți asta înainte de a rula ceva.

Întrebați administratorul domeniului ce legătură, locație de obiect, filtre de securitate și filtre WMI ar trebui să fie în joc. Modificarea acelor controale pentru ca un test să treacă este alt proiect, cu alt proprietar.

Citiți raportul cu contul căruia îi aparține setarea

În sesiunea proprie a utilizatorului afectat, rulați whoami /user și apoi gpresult /scope user /r. Contul care a autentificat VPN-ul nu este automat contul Windows a cărui politică o citiți, iar o verificare dintr-un cont de administrator răspunde la altă întrebare. Salvați linia de bază sub un nume de fișier nou, de exemplu %TEMP%\vpn-policy-user-before.html. referința gpresult documentează comutatoarele de domeniu de aplicare și de ieșire, și merită să știți că generarea unui raport nu reîmprospătează nimic.

Politica de computer are propriul domeniu de aplicare și propriul context de permisiuni, așa că inspectați-o separat cu elevarea necesară. Unirea ambelor domenii într-un singur raport este modul în care o setare de utilizator este declarată lipsă deși nu a fost niciodată în acel domeniu.

Descoperirea nu este acces: mai întâi înregistrările SRV, apoi SMB

Cu VPN-ul aprobat conectat, confirmați că clientul rezolvă controlerele de domeniu prin calea DNS prevăzută; un site web public care se încarcă nu spune nimic despre descoperirea controlerelor. Pentru domeniul ilustrativ corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example răspunde la întrebarea pe care o aveți cu adevărat. O înregistrare de serviciu returnată este doar dovadă de descoperire, deoarece adresa controlerului selectat trebuie să fie în continuare accesibilă cu autentificarea cerută și cu serviciile de director permise. Materialul politicii vine apoi din SYSVOL, ceea ce este o citire SMB către exact acel controler și nu un test ICMP.

O dovadă mai slabă este ușor de confundat cu o dovadă. Un răspuns ICMP de la un controler, lângă o citire refuzată a unui șablon de politică, produce un raport care pare gol dintr-un motiv pe care nimeni nu l-a conectat încă.

Mențineți coerente permisiunile serviciului AD, căile de retur și sincronizarea orei din implementare, în loc să le înlocuiți cu o deschidere generală a paravanului de protecție sau cu un server DNS public. Datele de politică ce diferă între controlere sunt o chestiune de replicare pentru proprietarul directorului.

O reîmprospătare, două rapoarte, o comparație

Odată calea dovedită, cereți reîmprospătarea relevantă cu gpupdate /target:user și citiți rezultatul în loc să îl presupuneți. Reîmprospătarea implicită aplică politica modificată, în timp ce /force cere o reaplicare; niciuna nu repară DNS, permisiunile fișierelor sau filtrarea. Unele extensii se finalizează doar la o autentificare ulterioară sau la un alt eveniment din prim-plan, așa că o singură rulare nu este un verdict. Adăugarea comutatoarelor de deconectare sau repornire în sesiunea unui utilizator la distanță ca diagnostic de rutină aruncă ceea ce avea deschis.

Generați un al doilea raport sub un alt nume de fișier și comparați timpul de procesare, GPO așteptată, starea ei aplicată sau refuzată și setarea în sine. Un raport dintr-o sesiune anterioară reușită nu dovedește nimic despre această reîmprospătare. O politică filtrată indică aplicabilitatea, nu transportul, ceea ce schimbă cine deține pasul următor.

Legați eșecul de o singură activitate

În Vizualizatorul de evenimente, începeți cu avertismentul sau eroarea politicii de grup din jurnalul de sistem, apoi treceți la jurnalul operațional GroupPolicy din Jurnalele de aplicații și servicii. Filtrați acel jurnal operațional după identificatorul de activitate al reîmprospătării pe care tocmai ați rulat-o, deoarece o reîmprospătare nouă primește un identificator nou, iar amestecarea cu evenimentele de ieri produce o concluzie sigură și greșită. Notați ora, contextul utilizatorului sau al computerului, controlerul selectat, GPO, codul de eroare și dependența eșuată.

Acea notă este ceea pe baza căreia poate acționa proprietarul rețelei sau al directorului. Faptul că sunteți conectat la VPN și ați rulat gpupdate de mai multe ori nu sunt dovezi, și niciuna nu supraviețuiește unei predări.

Păstrați rapoartele HTML private, deoarece expun nume interne, apartenența la grupuri și configurația de securitate. După ce setarea este confirmată, eliminați permisiunile temporare pe care le-ați adăugat în loc să le lăsați pe loc.