Gruppenrichtlinie fehlt über VPN? Geltungsbereich vor dem Tunnel prüfen

Etwas, das im Büronetz gegriffen hat, greift in der Woche nicht mehr, in der ein Benutzer über VPN zu arbeiten beginnt, und der Tunnel bekommt die Schuld, bevor irgendjemand einen Bericht öffnet. Die Gruppenrichtlinie verwaltet, welche Einstellungen beim Windows-Benutzer und -Computer ankommen, holt das Material aus der Domäne und führt die clientseitige Verarbeitung aus, und diese drei Schritte scheitern auf drei verschiedene Arten. Der Tunnel ändert nur, welchen Pfad der Client hat. Wer die Prüfungen der Reihe nach durchgeht, verhindert, dass ein Dateiberechtigungsproblem als Routingproblem verfolgt wird.

Mit der Einstellung beginnen, nicht mit dem Tunnel

Notieren Sie eine erwartete GPO und eine konkrete Einstellung darin und entscheiden Sie dann, ob diese Einstellung unter Benutzerkonfiguration oder Computerkonfiguration liegt. Das setzt einen autorisierten, domänenbeigetretenen Windows-Client in einem genehmigten VPN voraus, nicht ein nicht verwaltetes oder reines Cloud-Gerät, das zum Domänenmitglied gemacht werden soll. Die Antwort zum Geltungsbereich entscheidet, wer das Ergebnis lesen darf und ob eine Rechteerhöhung nötig ist, also klären Sie das, bevor Sie irgendetwas ausführen.

Fragen Sie den Domänenadministrator, welche Verknüpfung, welcher Objektstandort, welche Sicherheitsfilter und welche WMI-Filter im Spiel sein sollen. Diese Steuerelemente zu ändern, damit ein Test besteht, ist ein anderes Projekt mit einem anderen Verantwortlichen.

Den Bericht mit dem Konto lesen, dem die Einstellung gehört

Führen Sie in der eigenen Sitzung des betroffenen Benutzers whoami /user und dann gpresult /scope user /r aus. Das Konto, das das VPN authentifiziert hat, ist nicht automatisch das Windows-Konto, dessen Richtlinie Sie lesen, und eine Prüfung aus einem Administratorkonto beantwortet eine andere Frage. Speichern Sie die Ausgangslage unter einem frischen Dateinamen wie %TEMP%\vpn-policy-user-before.html. Die gpresult-Referenz dokumentiert die Schalter für Geltungsbereich und Ausgabe, und es lohnt zu wissen, dass das Erzeugen eines Berichts nichts aktualisiert.

Die Computerrichtlinie hat ihren eigenen Geltungsbereich und Berechtigungskontext, prüfen Sie sie also getrennt mit der nötigen Rechteerhöhung. Beide Geltungsbereiche in einen Bericht zu falten, ist der Weg, auf dem eine Benutzereinstellung als fehlend erklärt wird, obwohl sie nie in diesem Geltungsbereich lag.

Erkennung ist kein Zugriff: erst SRV-Einträge, dann SMB

Bestätigen Sie bei verbundenem genehmigtem VPN, dass der Client Domänencontroller über den vorgesehenen DNS-Pfad auflöst; eine öffentliche Website, die lädt, sagt nichts über die Controller-Erkennung aus. Für die beispielhafte Domäne corp.example beantwortet nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example die Frage, die Sie tatsächlich haben. Ein zurückgegebener Diensteintrag ist nur ein Erkennungsnachweis, denn die Adresse des ausgewählten Controllers muss weiterhin mit der erforderlichen Authentifizierung und erlaubten Verzeichnisdiensten erreichbar sein. Richtlinienmaterial kommt dann aus SYSVOL, was ein SMB-Lesezugriff auf genau diesen Controller ist und kein ICMP-Test.

Schwächere Belege werden leicht für einen Beweis gehalten. Eine ICMP-Antwort eines Controllers neben einem verweigerten Lesezugriff auf eine Richtlinienvorlage erzeugt einen Bericht, der aus einem Grund leer aussieht, den noch niemand verbunden hat.

Halten Sie die AD-Dienstberechtigungen, Rückwege und den Zeitabgleich der Bereitstellung stimmig, statt sie durch eine pauschale Firewall-Öffnung oder einen öffentlichen DNS-Server zu ersetzen. Richtliniendaten, die sich zwischen Controllern unterscheiden, sind eine Replikationsfrage für den Verzeichniseigentümer.

Eine Aktualisierung, zwei Berichte, ein Vergleich

Lösen Sie mit bewiesenem Pfad die relevante Aktualisierung mit gpupdate /target:user aus und lesen Sie das Ergebnis, statt es anzunehmen. Die Standardaktualisierung wendet geänderte Richtlinien an, während /force eine erneute Anwendung anfordert; keines von beiden repariert DNS, Dateiberechtigungen oder Filterung. Manche Erweiterungen schließen erst bei einer späteren Anmeldung oder einem weiteren Vordergrundereignis ab, ein einzelner Lauf ist also kein Urteil. Abmelde- oder Neustartschalter routinemäßig zur Sitzung eines entfernten Benutzers hinzuzufügen, wirft weg, was er offen hatte.

Erzeugen Sie einen zweiten Bericht unter einem anderen Dateinamen und vergleichen Sie die Verarbeitungszeit, die erwartete GPO, ihren angewendeten oder verweigerten Status und die Einstellung selbst. Ein Bericht aus einer früheren erfolgreichen Sitzung beweist nichts für diese Aktualisierung. Eine herausgefilterte Richtlinie deutet auf Anwendbarkeit statt auf Transport hin, was ändert, wer den nächsten Schritt verantwortet.

Den Fehler an eine einzelne Aktivität binden

Beginnen Sie in der Ereignisanzeige mit der Warnung oder dem Fehler zur Gruppenrichtlinie im Systemprotokoll und wechseln Sie dann zum operationalen Protokoll GroupPolicy unter Anwendungs- und Dienstprotokolle. Filtern Sie dieses operationale Protokoll nach der Aktivitätskennung der gerade ausgeführten Aktualisierung, denn eine neue Aktualisierung bekommt eine neue Kennung, und sie mit den Ereignissen von gestern zu mischen, erzeugt eine sichere, falsche Schlussfolgerung. Notieren Sie die Zeit, den Benutzer- oder Computerkontext, den ausgewählten Controller, die GPO, den Fehlercode und die fehlgeschlagene Abhängigkeit.

Dieser Eintrag ist es, auf den der Netzwerk- oder Verzeichniseigentümer reagieren kann. Mit dem VPN verbunden zu sein und gpupdate mehrmals ausgeführt zu haben, sind keine Belege, und beides übersteht keine Übergabe.

Halten Sie die HTML-Berichte privat, denn sie legen interne Namen, Gruppenmitgliedschaften und Sicherheitskonfiguration offen. Sobald die Einstellung bestätigt ist, entfernen Sie die vorübergehend hinzugefügten Berechtigungen, statt sie stehen zu lassen.