Conectarea la VPN nu reia scriptul de autentificare

Utilizatorul dumneavoastră se autentifică acasă, conectează VPN-ul și așteaptă maparea unității care înainte apărea de la sine la birou. Tunelul urcă, domeniul răspunde și nimic nu se mapează. Nimic nu este stricat: un script de autentificare rulează la autentificare, iar un tunel deschis douăzeci de minute după începerea sesiunii nu este o autentificare. Citirea celor două ca același eveniment trimite oamenii să caute o defecțiune VPN care nu există.

Patru decizii transformă surpriza într-un flux de lucru care se comportă corect, iar prima este pur și simplu să știți pe ce evenimente se sprijină un script.

Scripturile se sprijină pe evenimente din ciclul de viață pe care nu le puteți relua

Politica din partea computerului se aplică la pornirea mașinii, iar politica din partea utilizatorului la autentificare, în timp ce o reîmprospătare din fundal parcurge aceleași setări fără a reporni nimic. Acea reîmprospătare procesează extensia de scripturi, dar nu rulează din nou scripturile individuale, care se declanșează doar la pornire, oprire, autentificare sau deconectare. De aceea gpupdate /force poate raporta succes în timp ce maparea lipsește încă, iar o reîmprospătare curată nu este dovada că scriptul a făcut ceva.

Referința Microsoft despre procesarea politicilor trasează exact acea linie între procesarea extensiei și executarea a ceea ce conține, și este pagina de citat atunci când cineva insistă că o reîmprospătare ar fi trebuit să reia scriptul.

Nu orice script eșuează și offline. Unul care citește doar material local sau din cache poate fi reușit parțial, în timp ce unul care atinge o partajare eșuează în tăcere și nu lasă o urmă evidentă. Verificați calea reală a scriptului și până unde ajunge înainte de a da vina pe rețea. Aceeași verificare se cuvine oricărei afirmații că un script nu rulează la autentificare, pentru că o sarcină programată sau o acțiune a clientului poate face lucrul acolo unde nimeni nu se uită.

Legați lucrul de conexiune, nu de autentificare

Trei lucruri diferite se ascund în spatele sintagmei script de autentificare: maparea unei unități după ce utilizatorul se conectează, aplicarea configurației mașinii înainte ca cineva să se autentifice și aducerea politicii actualizate. Au termene diferite, și doar al doilea are într-adevăr nevoie de conectivitate înainte de autentificare. Scrieți cerința ca o propoziție cu termen, de exemplu: această mapare trebuie să existe în termen de un minut după ridicarea tunelului.

Pentru lucrul care trebuie să se întâmple după conectare, folosiți o sarcină declanșată de conexiune sau acțiunea de conectare pe care clientul o acceptă. Verificați ce eveniment emite clientul cu adevărat, pentru că un eveniment ridicat de clientul VPN nativ Windows nu este ridicat de un client terț. Pentru configurația mașinii care trebuie să preceadă autentificarea, răspunsul acceptat este un tunel de dispozitiv sau altă concepție dinaintea autentificării, nu o sarcină care se declanșează când apare desktopul. Executați lucrul cu identitatea și în sesiunea care au nevoie de el, pentru că o mapare creată ca SYSTEM ajunge într-o sesiune pe care utilizatorul nu o vede niciodată.

Testați pregătirea înainte de a acționa și eșuați zgomotos

Un eveniment de conexiune poate ajunge înainte ca DNS-ul sau serverul de fișiere să fie utilizabile, așa că sarcina ar trebui să testeze ce are nevoie în loc să presupună. Rezolvați numele concret, încercați conexiunea concretă și reîncercați cu o limită și o întârziere: Resolve-DnsName files.corp.example într-o buclă scurtă separă încă-nu de niciodată. Raportați o eșuare concretă după ultima încercare, cu numele și eroarea în ea.

O buclă fără sfârșit și fără jurnal este indistingibilă de o sarcină care nu a început niciodată, și ascunde diferența dintre o acreditare expirată și o regulă de firewall.

Verificați patru lucruri, apoi faceți-l repetabil

În timpul pilotului, înregistrați patru observații în loc de una: evenimentul de conexiune s-a declanșat, sarcina a pornit, resursa a răspuns și modificarea cerută s-a aplicat cu adevărat. Dacă jurnalul se oprește la sarcina a pornit, eșuarea reală rămâne invizibilă oricât ați aștepta. Apoi rulați gpresult /scope user /v pentru a vedea ce politică crede sesiunea că are, și comparați cu setarea așteptată. Un raport care listează GPO ca aplicat tot nu spune nimic despre o mapare.

Faceți lucrul sigur de repetat înainte de a-l extinde, pentru că clientul se reconectează și sarcina se declanșează din nou. Verificați dacă maparea sau configurația există deja înainte de a o crea, și notați ce ați găsit. Lucrul duplicat după fiecare reconectare trecătoare este felul în care o sarcină utilă devine un incident.

Acolo unde un declanșator automat nu se potrivește, o acțiune de utilizator aprobată care rulează același script semnat este o concepție legitimă. Face momentul explicit în loc să pretindă că a avut loc un eveniment de autentificare.