Ĉu mankas Grupa Politiko ĉe VPN? Kontrolu la amplekson antaŭ la tunelo

Io, kio validis en la oficeja reto, ĉesas validi en la semajno, kiam uzanto ek laboras per VPN, kaj la tunelo ricevas la kulpon antaŭ ol iu malfermas raporton. La Grupa Politiko decidas, kiuj agordoj alvenas al la Windows-uzanto kaj -komputilo, elprenas la materialon el la domajno kaj plenumas la prilaboradon ĉe la kliento, kaj tiuj tri paŝoj malsukcesas laŭ tri malsamaj manieroj. La tunelo nur ŝanĝas, kiun vojon la kliento havas. Obe sekvadi la kontrolojn malhelpas, ke problemo pri dosierpermesoj estas ĉasata kiel kursproblemo.

Komencu per la agordo, ne per la tunelo

Notu unu atendatan GPO kaj unu konkretan agordon en ĝi, poste decidu, ĉu tiu agordo apartenas al Uzula agordo aŭ al Komputila agordo. Tio supozas rajtigitan Windows-klienton aliĝintan al la domajno en aprobita VPN, ne neadministratan aŭ nur-nuban aparaton, kiun oni faras domajna membro. La respondo pri la amplekso decidas, kiu rajtas legi la rezulton kaj ĉu necesas privilegia plialtigo, do solvu tion antaŭ ol lanĉi ion ajn.

Demandu la domajnan administranton, kiu ligilo, objekta loko, sekurecaj filtriloj kaj WMI-filtriloj devus esti en ludado. Ŝanĝi tiujn regilojn por ke testo sukcesu estas alia projekto kun alia posedanto.

Legu la raporton per la konto, al kiu apartenas la agordo

En la propra sesio de la tuŝita uzanto, lanĉu whoami /user kaj poste gpresult /scope user /r. La konto, kiu aŭtentikigis la VPN, ne aŭtomate estas la Windows-konto, kies politikon vi legas, kaj kontrolo el administranta konto respondas al alia demando. Konservu la bazan staton sub nova dosiernomo, ekzemple %TEMP%\vpn-policy-user-before.html. La referenco de gpresult dokumentas la ŝaltilojn pri amplekso kaj eligo, kaj indas scii, ke generi raporton nenion refreŝigas.

La komputila politiko havas propran amplekson kaj permesan kuntekston, do ekzamenu ĝin aparte kun la bezonata plialtigo. Kunfaldi ambaŭ ampleksojn en unu raporton estas la maniero, per kiu uzula agordo estas deklarata mankanta, kvankam ĝi neniam estis en tiu amplekso.

Malkovro ne estas aliro: unue SRV-rikordoj, poste SMB

Kun la aprobita VPN konektita, konfirmu, ke la kliento solvas domajnajn regilojn tra la celita DNS-vojo; publika retejo, kiu ŝarĝiĝas, diras nenion pri la malkovro de regiloj. Por la ilustra domajno corp.example, nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example respondas al la demando, kiun vi vere havas. Revenigita serva rikordo estas nur malkovra pruvo, ĉar la adreso de la elektita regilo ankoraŭ devas esti atingebla kun la postulata aŭtentikigo kaj permesitaj dosierujaj servoj. Politika materialo poste alvenas el SYSVOL, kio estas SMB-lego al tiu specifa regilo kaj ne ICMP-testo.

Pli malfortan pruvon oni facile konfuzas kun pruvo. ICMP-respondo de regilo, apud rifuzita lego de politika ŝablono, produktas raporton, kiu aspektas malplena pro kialo, kiun ankoraŭ neniu kunligis.

Tenu la AD-servajn permesojn, la revenajn vojojn kaj la horan sinkronigon de la enkonduko koheraj, anstataŭ anstataŭigi ilin per ĝenerala fajroŝirma malfermo aŭ publika DNS-servilo. Politikaj datumoj, kiuj malsamas inter regiloj, estas replika demando por la posedanto de la dosierujo.

Unu refreŝigo, du raportoj, unu komparo

Kiam la vojo estas pruvita, petu la koncernan refreŝigon per gpupdate /target:user kaj legu la rezulton anstataŭ supozi ĝin. La defaŭlta refreŝigo aplikas ŝanĝitan politikon, dum /force petas reaplikon; neniu el ili riparas DNS, dosierpermesojn aŭ filtradon. Iuj etendaĵoj finiĝas nur ĉe posta ensaluto aŭ alia fona evento, do unu lanĉo ne estas verdikto. Aldoni ŝaltilojn por elsaluto aŭ restarto al la sesio de fora uzanto kiel rutinan diagnozon forĵetas tion, kion li havis malfermita.

Generu duan raporton sub alia dosiernomo kaj komparu la prilaboran tempon, la atendatan GPO, ĝian aplikitan aŭ rifuzitan staton kaj la agordon mem. Raporto el antaŭa sukcesa sesio pruvas nenion pri ĉi tiu refreŝigo. Politiko, kiu estis filtrita, montras aplikeblecon anstataŭ transporton, kio ŝanĝas, kiu posedas la sekvan paŝon.

Ligu la malsukceson al unu sola agado

En la Eventa Vidigilo, komencu per la averto aŭ eraro de Grupa Politiko en la sistema protokolo, poste transiru al la operacia protokolo GroupPolicy sub Protokoloj de Aplikoj kaj Servoj. Filtru tiun operacian protokolon laŭ la agada identigilo de la refreŝigo, kiun vi ĵus lanĉis, ĉar nova refreŝigo ricevas novan identigilon, kaj miksi ĝin kun la hieraŭaj eventoj produktas memfidan kaj malĝustan konkludon. Notu la tempon, la uzulan aŭ komputilan kuntekston, la elektitan regilon, la GPO, la erarkodon kaj la malsukcesan dependon.

Tiu noto estas tio, sur kio la reta aŭ dosieruja posedanto povas agi. Esti konektita al la VPN kaj lanĉi gpupdate plurfoje ne estas pruvoj, kaj neniu el ili postvivas transdonon.

Tenu la HTML-raportojn privataj, ĉar ili malkaŝas internajn nomojn, grupajn membrecojn kaj sekurecan agordon. Post kiam la agordo konfirmiĝis, forigu la tempajn permesojn, kiujn vi aldonis, anstataŭ lasi ilin surloke.