De ce un laptop cu Protected Users are nevoie de VPN înainte de autentificare
Protected Users împiedică Windows să memoreze în cache un verificator de autentificare, așa că tunelul trebuie să existe înainte de desktop. Demonstrați granița, apoi testați calea de rezervă.
Un laptop, un cont funcțional și o rețea de hotel formează împreună o buclă de autentificare pe care nicio reîncercare nu o rupe. Contul este în Protected Users, ceea ce împiedică Windows să stocheze verificatorul de care ar avea nevoie pentru a autentifica utilizatorul offline. Orice plan de forma „autentifică-te mai întâi, conectează tunelul după aceea” are ordinea inversată, iar protecția face exact ceea ce promite. Cele ce urmează presupun un cont Active Directory tradițional pe un host Windows acceptat.
Ce elimină de fapt protecția
De obicei Windows memorează un verificator în cache pentru ca un cont de domeniu să se poată autentifica atunci când un controler de domeniu este inaccesibil. Protected Users blochează acest lucru pentru cont, ceea ce elimină autentificarea în domeniu offline ca posibilitate în loc să o facă nesigură.
Aceasta nu este problema obișnuită a unui cache învechit, iar remediile obișnuite nu se aplică. Autentificarea online repetată, o altă schimbare de parolă sau creșterea numărului de autentificări memorate nu vor restabili capacitatea, pentru că niciuna dintre aceste acțiuni nu creează verificatorul pe care politica refuză să îl stocheze. Contul se comportă conform proiectării, iar proiectarea presupune că rețeaua este prezentă atunci când Windows o cere. Tratarea simptomului ca o defecțiune a cache-ului este modul în care echipele ajung să reconstruiască un profil care nu a fost niciodată stricat.
De ce tunelul trebuie să existe înainte de desktop
Dispozitivul trebuie să ajungă la autentificarea de domeniu în momentul în care Windows o cere, adică înainte să existe orice sesiune de utilizator. Un client VPN care pornește doar după ce apare desktopul lasă o autentificare nouă așteptând o cale care nu sosește niciodată. Dependența aparține mașinii, nu unui utilizator care nu s-a autentificat încă.
Folosiți o soluție compatibilă de autentificare prealabilă, convenită cu proprietarii punctelor finale și ai identității. Un tunel de dispozitiv Always On VPN autentificat cu un certificat de computer este potrivit atunci când dispozitivul administrat îndeplinește condițiile prealabile ale acelei implementări. Integrarea compatibilă a unui ecran de autentificare oferită de un furnizor este o altă opțiune. Un profil obișnuit de utilizator cu un declanșator automat nu este niciuna dintre ele, oricât de asemănător ar arăta în interfața clientului.
Această cale are nevoie de rezolvarea numelor pentru domeniu, de un controler de domeniu accesibil și de protocoalele de autentificare pe care contul le poate folosi, iar niciun indicator „conectat” nu oferă aceste lucruri. Rutele și filtrele sale ar trebui să transporte serviciile de identitate și nimic altceva ce nu este necesar, pentru că acea listă de prefixe este suprafața pe care o obține un laptop furat înainte ca cineva să se autentifice. Deciziile de tunel divizat luate pentru tunelul de utilizator nu se transferă la tunelul de dispozitiv, așa că examinați-le separat.
Accesibilitatea nu este compatibilitate de autentificare
Un tunel poate transporta pachetele perfect în timp ce autentificarea de domeniu eșuează, pentru că mecanismul încercat este unul pe care contul nu îl poate folosi. Într-un domeniu care aplică restricțiile grupului, NTLM nu este disponibil membrilor, iar Kerberos necesită un cont și o configurație compatibile cu AES. O cale de pachete nu poate repara niciuna dintre ele. De aceea un ping curat către un controler de domeniu nu este dovada că autentificarea va funcționa.
Pot fi implicate și două sisteme de acreditări. VPN-ul se poate autentifica la un furnizor de identitate în timp ce Windows are nevoie separat de o autentificare în domeniu, iar acceptarea primului nu spune nimic despre al doilea. „VPN-ul s-a conectat” și „utilizatorul s-a autentificat” sunt observații separate, iar repararea uneia nu o implică pe cealaltă.
Citiți dovezile autentificării
Colectați evenimente de la client și de la un controler de domeniu pentru aceeași încercare, nu doar de pe o singură parte. Jurnalele Protected Users se află sub Applications and Services Logs\Microsoft\Windows\Authentication, iar un administrator poate trebui să activeze un jurnal înainte ca acesta să înregistreze ceva. Corelați marcajele de timp cu jurnalul de conectare al tunelului însuși, pentru că o eroare de ordine arată ca o defecțiune de acreditări din ambele părți.
Prima comandă de mai jos listează fiecare jurnal de autentificare expus de dispozitiv, astfel încât citiți ce există, nu ce a numit o postare de blog. A doua citește intrările recente după ce știți numele. Căutați pachetul de autentificare, contul și condiția de eșec, pentru că o cale de rețea lipsă și un mecanism respins lasă dovezi diferite și doar una dintre ele este o problemă de VPN. Dacă tunelul a urcat după încercare, ordinea a fost greșită orice ar spune acele intrări.
Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20Demonstrați granița dintr-o pornire la rece
Rulați testul dintr-o stare deconectată sau proaspăt pornită cu un cont limitat și țineți deschisă o cale de recuperare aprobată înainte de a schimba ceva pentru utilizatorii privilegiați. Un test pe un desktop deja în funcțiune nu exersează nicio parte a căii de cod care contează, iar asta explică majoritatea rapoartelor despre o corectare care a rezistat până la următoarea repornire. Apoi parcurgeți cei patru pași în această ordine.
- Confirmați că dispozitivul poate găsi un controler de domeniu înainte ca cineva să se autentifice, cu
nltest /dsgetdc:corp.example.com. - Încercați autentificarea în domeniu, apoi întrebați dacă s-a obținut măcar un bilet, cu
klist. - Citiți jurnalul de autentificare pe care îl înregistrează dispozitivul, cu cele două comenzi de mai sus, și notați pachetul și condiția de eșec.
- Confirmați că acreditarea de recuperare aprobată încă funcționează de pe ecranul de autentificare, pentru că este singura cale de întoarcere dacă testul graniței eșuează.
Deschiderea unei partajări de fișiere cu acreditări furnizate nu creează nici ea o autentificare interactivă offline, așa că nu înlocuiește niciun pas de mai sus. Dacă organizația are într-adevăr nevoie de autentificare fără conexiune, răspunsul este un design compatibil de cont și punct final ales deliberat. Scoaterea contului din grup, sau păstrarea unei autentificări de urgență nerestricționate pe fiecare laptop, este o decizie de politică de identitate pe care o schimbare de VPN nu o poate lua pentru dumneavoastră.
Documentația Protected Users descrie atât comportamentul verificatorului, cât și restricțiile de domeniu de care depinde acest design. Planificați procesul de recuperare înainte ca cineva să călătorească, pentru că testul de pornire la rece este singurul loc unde este exersat.