Grupprincip saknas på VPN? Kontrollera omfånget före tunneln

Något som gällde på kontorsnätet slutar gälla i veckan då en användare börjar arbeta över VPN, och tunneln får skulden innan någon öppnar en rapport. Grupprincip avgör vilka inställningar som landar hos Windows-användaren och -datorn, hämtar materialet från domänen och kör bearbetningen på klientsidan, och de tre stegen misslyckas på tre olika sätt. Tunneln ändrar bara vilken väg klienten har. Att gå igenom kontrollerna i ordning hindrar att ett filrättighetsproblem jags som ett routingproblem.

Börja med inställningen, inte med tunneln

Skriv ned en förväntad GPO och en konkret inställning i den och avgör sedan om inställningen hör till användarkonfiguration eller datorkonfiguration. Detta förutsätter en auktoriserad Windows-klient som är domänansluten på ett godkänt VPN, inte en ohanterad eller enbart molnbaserad enhet som görs till domänmedlem. Svaret om omfånget avgör vem som får läsa resultatet och om förhöjda rättigheter krävs, så klargör det innan du kör något.

Fråga domänadministratören vilken länk, objektplacering, säkerhetsfilter och WMI-filter som ska vara i spel. Att ändra dessa kontroller för att ett test ska gå igenom är ett annat projekt med en annan ägare.

Läs rapporten med det konto som äger inställningen

Kör i den berörda användarens egen session whoami /user och sedan gpresult /scope user /r. Kontot som autentiserade VPN:et är inte automatiskt det Windows-konto vars princip du läser, och en kontroll från ett administratörskonto svarar på en annan fråga. Spara baslinjen under ett nytt filnamn, till exempel %TEMP%\vpn-policy-user-before.html. Den gpresult-referens dokumenterar switcharna för omfång och utdata, och det är värt att veta att det inte uppdaterar något att skapa en rapport.

Datorprincip har sitt eget omfång och sin egen rättighetskontext, så undersök den separat med den förhöjning som behövs. Att fälla in båda omfången i en rapport är sättet på vilket en användarinställning förklaras saknad trots att den aldrig var i det omfånget.

Upptäckt är inte åtkomst: först SRV-poster, sedan SMB

Med det godkända VPN:et anslutet, bekräfta att klienten löser domänkontrollanter via den avsedda DNS-vägen; en offentlig webbplats som laddas säger ingenting om upptäckt av kontrollanter. För exempeldomänen corp.example svarar nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example på frågan du faktiskt har. En returnerad tjänstpost är bara upptäcktsbevis, eftersom adressen till den valda kontrollanten fortfarande måste vara nåbar med den autentisering som krävs och tillåtna katalogtjänster. Principmaterialet kommer sedan från SYSVOL, vilket är en SMB-läsning mot just den kontrollanten och inte ett ICMP-test.

Svagare bevis förväxlas lätt med bevis. Ett ICMP-svar från en kontrollant bredvid en nekad läsning av en principmall ger en rapport som ser tom ut av en anledning som ingen ännu har kopplat.

Håll distributionens AD-tjänstetillstånd, returvägar och tidssynkronisering sammanhängande i stället för att ersätta dem med en generell brandväggsöppning eller en offentlig DNS-server. Principdata som skiljer sig mellan kontrollanter är en replikeringsfråga för katalogägaren.

En uppdatering, två rapporter, en jämförelse

När vägen är bevisad, begär den relevanta uppdateringen med gpupdate /target:user och läs resultatet i stället för att anta det. Standarduppdateringen tillämpar ändrad princip medan /force begär ny tillämpning; ingen av dem reparerar DNS, filrättigheter eller filtrering. Vissa tillägg slutförs först vid en senare inloggning eller en annan händelse i förgrunden, så en enda körning är ingen dom. Att lägga till utloggnings- eller omstartsswitchar i en fjärranvändares session som rutindiagnostik kastar bort det användaren hade öppet.

Skapa en andra rapport under ett annat filnamn och jämför bearbetningstiden, den förväntade GPO:n, dess tillämpade eller nekade status och själva inställningen. En rapport från en tidigare lyckad session bevisar ingenting om den här uppdateringen. En princip som filtrerades bort pekar på tillämplighet snarare än transport, vilket ändrar vem som äger nästa steg.

Bind felet till en enda aktivitet

I Loggboken börjar du med grupprincipvarningen eller -felet i systemloggen och går sedan till den operativa loggen GroupPolicy under Loggar för program och tjänster. Filtrera den operativa loggen på aktivitetsidentifieraren för den uppdatering du just körde, eftersom en ny uppdatering får en ny identifierare och att blanda den med gårdagens händelser ger en självsäker och felaktig slutsats. Anteckna tiden, användar- eller datorkontexten, den valda kontrollanten, GPO:n, felkoden och det misslyckade beroendet.

Den anteckningen är det som nätverks- eller katalogägaren kan agera på. Att vara ansluten till VPN:et och ha kört gpupdate flera gånger är inte bevis, och ingen av dem överlever en överlämning.

Håll HTML-rapporterna privata, eftersom de avslöjar interna namn, gruppmedlemskap och säkerhetskonfiguration. När inställningen är bekräftad, ta bort de tillfälliga behörigheter du lade till i stället för att låta dem ligga kvar.