Hiányzik a csoportházirend a VPN-en? A hatókört ellenőrizze az alagút előtt

Valami, ami az irodai hálózaton érvényesült, abban a héten megszűnik érvényesülni, amikor egy felhasználó VPN-en kezd dolgozni, és az alagút kapja a hibát, mielőtt bárki jelentést nyitna. A csoportházirend dönti el, mely beállítások jutnak el a Windows-felhasználóhoz és -számítógéphez, a tartományból szerzi be az anyagot, és kliensoldalon futtatja a feldolgozást, és ez a három lépés három különböző módon hiúsul meg. Az alagút csak azt változtatja meg, milyen útvonala van a kliensnek. Az ellenőrzések sorrendben történő végigvitele megakadályozza, hogy egy fájljogosultsági problémát útválasztási problémaként üldözzenek.

Kezdje a beállítással, ne az alagúttal

Írjon fel egy várt GPO-t és egy konkrét beállítást benne, majd döntse el, hogy a beállítás a felhasználói vagy a számítógép-konfigurációban van-e. Ez feltételezi egy jogosult, tartományhoz csatlakoztatott Windows-klienst jóváhagyott VPN-en, nem egy nem kezelt vagy csak felhőben létező eszközt, amelyet tartománytaggá tesznek. A hatókörre adott válasz dönti el, ki olvashatja az eredményt, és hogy kell-e jogosultságnövelés, ezért ezt még bármi futtatása előtt tisztázza.

Kérdezze meg a tartományi rendszergazdát, melyik kapcsolat, objektumhely, biztonsági szűrő és WMI-szűrő legyen játékban. E vezérlők megváltoztatása egy teszt sikeréért más projekt, más gazdával.

A jelentést azzal a fiókkal olvassa, amelyiké a beállítás

Az érintett felhasználó saját munkamenetében futtassa a whoami /user, majd a gpresult /scope user /r parancsot. A VPN-t hitelesítő fiók nem automatikusan az a Windows-fiók, amelynek házirendjét olvassa, és egy rendszergazdai fiókból indított ellenőrzés más kérdésre válaszol. Mentse az alapállapotot új fájlnév alá, például %TEMP%\vpn-policy-user-before.html. A gpresult-referencia dokumentálja a hatókör- és kimeneti kapcsolókat, és érdemes tudni, hogy egy jelentés létrehozása semmit nem frissít.

A számítógép-házirendnek saját hatóköre és engedélykörnyezete van, ezért külön vizsgálja meg a szükséges jogosultságnöveléssel. A két hatókör egy jelentésbe vonása az az út, amelyen egy felhasználói beállítás hiányzónak minősül, holott soha nem volt ebben a hatókörben.

A felderítés nem hozzáférés: először az SRV-rekordok, aztán az SMB

A jóváhagyott VPN csatlakoztatása mellett erősítse meg, hogy a kliens a szándékolt DNS-útvonalon oldja fel a tartományvezérlőket; egy betöltődő nyilvános webhely semmit nem mond a vezérlőfelderítésről. A példaértékű corp.example tartomány esetében a nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example válaszol arra a kérdésre, amely valóban felmerül. A visszakapott szolgáltatásrekord csak felderítési bizonyíték, mert a kiválasztott vezérlő címének továbbra is elérhetőnek kell lennie a szükséges hitelesítéssel és engedélyezett címtárszolgáltatásokkal. A házirend-anyag ezután a SYSVOL-ból érkezik, ami SMB-olvasás az adott vezérlő felé, és nem ICMP-teszt.

A gyengébb bizonyítékot könnyű bizonyítéknak nézni. Egy vezérlőtől kapott ICMP-válasz, egy házirend-sablon megtagadott olvasása mellett olyan jelentést ad, amely ok nélkül tűnik üresnek, mert még senki nem kapcsolta össze.

Tartsa összhangban a telepítés AD-szolgáltatási engedélyeit, a visszaútvonalakat és az időszinkronizálást, ahelyett hogy átfogó tűzfalnyitással vagy nyilvános DNS-kiszolgálóval helyettesítené őket. A vezérlők között eltérő házirend-adatok replikációs kérdés a címtár gazdája számára.

Egy frissítés, két jelentés, egy összehasonlítás

Miután az útvonal bizonyított, kérje a megfelelő frissítést a gpupdate /target:user paranccsal, és olvassa el az eredményt ahelyett hogy feltételezné. Az alapértelmezett frissítés a megváltozott házirendet alkalmazza, míg a /force újraalkalmazást kér; egyik sem javítja a DNS-t, a fájljogosultságokat vagy a szűrést. Egyes bővítmények csak egy későbbi bejelentkezéskor vagy más előtér-eseményben fejeződnek be, így egyetlen futás nem ítélet. A kijelentkezési vagy újraindítási kapcsolók hozzáadása egy távoli felhasználó munkamenetéhez rutindiagnosztikaként eldobja azt, ami nyitva volt nála.

Készítsen egy második jelentést más fájlnév alatt, és hasonlítsa össze a feldolgozási időt, a várt GPO-t, annak alkalmazott vagy megtagadott állapotát és magát a beállítást. Egy korábbi sikeres munkamenet jelentése semmit nem bizonyít erről a frissítésről. A kiszűrt házirend alkalmazhatóságra utal, nem átvitelre, ami megváltoztatja, hogy kié a következő lépés.

Kösse a hibát egyetlen tevékenységhez

Az Eseménynaplóban kezdje a rendszernaplóban lévő csoportházirend-figyelmeztetéssel vagy -hibával, majd lépjen át az Alkalmazások és szolgáltatások naplói alatti GroupPolicy műveleti naplóra. Szűrje ezt a műveleti naplót az imént futtatott frissítés tevékenység-azonosítójára, mert egy új frissítés új azonosítót kap, és a tegnapi eseményekkel keverve magabiztos és téves következtetést ad. Jegyezze fel az időt, a felhasználói vagy számítógép-környezetet, a kiválasztott vezérlőt, a GPO-t, a hibakódot és a meghiúsult függőséget.

Ez a feljegyzés az, amire a hálózat vagy a címtár gazdája támaszkodhat. Az, hogy valaki csatlakozik a VPN-hez és többször lefuttatja a gpupdate parancsot, nem bizonyíték, és egyik sem éli túl az átadást.

Tartsa privátan a HTML-jelentéseket, mert belső neveket, csoporttagságokat és biztonsági konfigurációt tárnak fel. Amint a beállítás megerősítést nyert, távolítsa el a hozzáadott ideiglenes engedélyeket, ahelyett hogy a helyén hagyná őket.