it-swarm.com.de

Windows 10: Gruppenrichtlinie wird nicht direkt nach dem Start angewendet und ist später erfolgreich

Mein Problem ist, dass Gruppenrichtlinien nicht angewendet werden, wenn ein Client neu gestartet wird. Direkt nach dem Start sendet der Client eine Fehlermeldung im Ereignisprotokoll mit der Quelle "GroupPolicy (Microsoft-Windows-GroupPolicy)" und der Ereignis-ID 1058: "Die Verarbeitung der Gruppenrichtlinie ist fehlgeschlagen. [...]". Auf der Registerkarte Details lautet der Fehlercode 50, was für ERROR_NOT_SUPPORTED steht. Es ist nicht nur ein kosmetisches Problem: Die Richtlinien werden wirklich nicht richtig angewendet: Die zugeordneten Netzwerklaufwerke sind beispielsweise nicht vorhanden. Nach einer Weile funktioniert die Ausführung von "gpupdate" und die Richtlinien werden normal angewendet: Die zugeordneten Netzlaufwerke werden angezeigt.

Das einfachste Szenario, in dem ich das Problem reproduzieren konnte: Neu erstellte Domäne auf frisch installiertem Windows Server 2012R2, Client ist ein frisch installierter Windows 10 64-Bit-Computer. Die Domäne besteht nur aus dem einen Domänencontroller und hat keine Beziehung zu anderen Domänen.

Da die Fehlermeldung besagt, dass Windows eine GPT-Datei nicht von der Sysvol-Freigabe der Domäne lesen kann, habe ich versucht, über eine Eingabeaufforderung auf dieselbe Datei zuzugreifen. Und tatsächlich, wenn ich direkt nach dem Booten eine Eingabeaufforderung öffne, erhalte ich Folgendes:

C:\Users\username>dir \\domain.example.com\sysvol
The request is not supported.

Nach ein oder zwei Minuten Wartezeit wird durch Ausführen des gleichen Befehls eine Verzeichnisliste angezeigt. Das Ausführen von gpupdate zu diesem Zeitpunkt funktioniert einwandfrei.

Ich habe die Gruppenrichtlinieneinstellung "Beim Starten und Anmelden des Computers immer auf das Netzwerk warten" auf "Aktiviert" gesetzt und weiß, dass diese Richtlinie angewendet wird: In demselben Richtlinienobjekt wird eine Registrierungseinstellung angegeben, und wenn ich die Registrierung überprüfe Auf dem Client ist die angegebene Einstellung vorhanden.

Andere Faktoren, die relevant sein könnten:

  • NTLM ist in der Domäne eingeschränkt, dies scheint jedoch keine Rolle zu spielen: Auch nach dem Aktivieren, Aktualisieren von Richtlinien und Neustarten aller Computer bleiben die Symptome gleich.
  • Es spielt keine Rolle, ob der Server über DHCP oder mit einer statischen Konfiguration konfiguriert ist.
  • Der DNS-Server für die Domäne unterstützt keine dynamischen Updates. Die erforderlichen Datensätze wurden manuell hinzugefügt (aus C:\Windows\System32\config\netlogon.dns).
  • Der Ruhezustand ist auf dem Client deaktiviert (mit powercfg /h off), Daher ist jeder Start ein vollständiger Start, kein schneller Start
  • Die Wartezeit für die Richtlinienstartverarbeitung ist auf 120 Sekunden festgelegt
  • Die Konnektivität zum DC funktioniert einwandfrei. Pings funktionieren. Wenn Sie den Client deaktivieren, mein Konto in AD deaktivieren und den Client aktivieren, meldet sich der Client nicht bei mir an. Er merkt sofort, dass der Konto ist deaktiviert.
  • Abgesehen von diesem Problem bemerke ich nichts Außergewöhnliches.

Dies scheint eher ein SMB -Problem als ein Gruppenrichtlinienproblem zu sein. Das Abhören der Verbindung auf der Serverseite zeigt etwas Interessantes: Wenn ich den Befehl dir \\domain.example.com\sysvol Zum ersten Mal ausführe, wird das Folgendes wird in Microsoft Message Analyzer auf dem DC angezeigt:

  1. Der Client richtet eine TCP -Verbindung zu Port 445 des DC ein, und eine ComNegotiation wird erfolgreich durchgeführt (DialectRevision: 0x02FF).
  2. Unmittelbar danach wird ein Verhandeln erfolgreich durchgeführt. Die DialectRevision ist 0x0302.
  3. Unmittelbar danach schließt der Client die Verbindung TCP mit einem TCP RST (??)

Jedes Mal, wenn ich den Befehl erteile und den Fehler erhalte, werden die Schritte 2 und 3 ausgeführt.

Wenn der Befehl zu arbeiten beginnt, werden die Schritte 1 und 2 ausgeführt, aber anstatt dass der Client ein TCP RST) sendet, wird ein SessionSetup ausgeführt, dann ein TreeConnect und dann eine ganze Reihe von (scheinbar normalen) SMB Chatter tritt auf.

Es sieht also so aus, als würde der Client bis ein oder zwei Minuten nach dem Start nicht richtig mit SMB mit dem DC) sprechen, was dazu führt, dass die Gruppenrichtlinienverarbeitung fehlschlägt .

Weiß jemand, wie ich dieses Problem debuggen und lösen kann?

8
Jurjen

Ich habe es geschafft, dieses Problem selbst zu lösen. Für Referenz hier ist, was mein Problem gelöst hat:

Erstens habe ich mich geirrt, dass das Deaktivieren aller Blockierungen von NTLM zu denselben Symptomen führte. Es ergab sich ein anders Symptom, das zufällig den gleichen Effekt hatte. Ohne gültige NTLM-Blockierungsrichtlinien führte der Befehl dir jetzt zu einem Fehler, dem der Zugriff verweigert wurde. Gruppenrichtlinien gelten immer noch nicht, was sinnvoll ist: Auf SYSVOL war immer noch nicht zugegriffen.

Ein bisschen Websuche hat mir gesagt, dass ich weiß, dass ich ein häufigeres Problem habe. obwohl. Anscheinend können Windows 10-Clients Probleme beim Zugriff auf die SYSVOL-Freigabe von Domänencontrollern (und möglicherweise auch auf die NETLOGON-Freigabe) haben. Angeblich hat Windows 10 den Zugriff auf diese Freigaben geändert, was zu Problemen führen kann. Die Problemumgehung besteht darin, die UNC-Pfad-Härtung auf dem Client für diese Freigaben zu deaktivieren, indem Sie die Gruppenrichtlinie "Gehärtete UNC-Pfade" für die Windows 10-Clients wie folgt festlegen:

\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=1,RequireIntegrity=1

(Wenn Sie Probleme beim Zugriff auf die Netlogon-Freigabe von Windows 10-Clients aus haben, kann es hilfreich sein, alle drei Parameter auch für diese Freigabe auf Null zu setzen.)

Weitere Informationen finden Sie im Artikel von Microsoft über MS15-011 . Es enthält eine gute Beschreibung der Sicherheitsauswirkungen einer Änderung dieser Einstellung sowie detaillierte Schritte zum Ändern der Richtlinie.

Warnung: Beachten Sie, dass die obigen Einstellungen deaktivieren einige oder alle Schutzmaßnahmen gegen das Sicherheitsproblem MS15-011 für erstellt wurden! Nicht ​​einfach blind kopieren/einfügen, sondern eine fundierte Entscheidung treffen, die auf den damit verbundenen Risiken basiert. Außerdem wird dieses Problem wahrscheinlich irgendwann in der Zukunft behoben. Vergessen Sie in diesem Fall nicht, diese Richtlinie auf die empfohlenen Werte festzulegen, wie in MS15-011 beschrieben.

7
Jurjen

Ab Windows 8 führte Microsoft diesen Begriff des "Schnellstarts" ein, bei dem beim Herunterfahren des Betriebssystems der Speicherbedarf des Betriebssystems genau wie im Ruhezustand in normalen Ruhezustandszenarien in den Ruhezustand versetzt wird. Dies führt dazu, dass das Betriebssystem schneller gestartet wird, hat aber auch den Nebeneffekt, dass die GP-Verarbeitung pro Computer beim Start deaktiviert wird. Dies ist wahrscheinlich das, was Sie sehen, und dies kann deaktiviert werden, indem Sie die Richtlinie unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Herunterfahren\Schnellstart erfordern

Wenn dies das Problem nicht löst, handelt es sich höchstwahrscheinlich um ein Problem mit dem Netzwerkstapel-Timing, bei dem die GP-Verarbeitung für den Computer gestartet wird, bevor der Netzwerkstapel vollständig initialisiert ist. Dies gibt es seit XP und ab Windows 7 hat Microsoft unter Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Gruppenrichtlinie\Wartezeit für die Verarbeitung von Startrichtlinien eine Richtlinie hinzugefügt, in der Sie die Wartezeit verlängern können Dieser Hausarzt wartet vor dem Start. Versuchen Sie, ihn auf 60 Sekunden einzustellen, und prüfen Sie, ob dies hilfreich ist.

Darren

8
Darren Mar-Elia

Ich habe verschiedene Vorschläge ausprobiert, einschließlich Änderungen an der Registrierung und Änderungen an lokalen Gruppenrichtlinien, von denen keiner das Problem löste. Zugeordnete Laufwerke wurden beim Booten immer noch nicht ausgeführt. Ein gpupdate würde es jedes Mal beheben, aber das war ein zusätzlicher Schritt für den Benutzer.

Am Ende wurde das Problem behoben, indem die Netzwerklaufwerke manuell zugeordnet und die Einträge GPO) auf jedem von ihnen ersetzt wurden. Sie müssen nicht getrennt und ersetzt werden, sondern haben sie genauso zugeordnet, wie sie zugeordnet wurden, nur manuell.

0
Cory

Nur zu Ihrer Information für alle anderen, die diesen Thread finden. Wenn Sie die UNC-Härtung deaktivieren, indem Sie die gegenseitige Authentifizierung auf 0 setzen, wird ein Teil Ihrer Sicherheit deaktiviert. Wir haben das gleiche Problem mit Win7-Clients, und ich habe versucht, mit Microsoft daran zu arbeiten. Sie sagten mir, dass es sich um einen Fehler handelt, haben mir aber bisher keine Möglichkeit gegeben, zu verfolgen, wann der Fehler behoben wird.

Weitere Informationen finden Sie in diesem anderen Thread https://social.technet.Microsoft.com/Forums/en-US/6a20e3f6-728a-4aa9-831a-6133f446ea08/gpos-do-not-apply-on-windows -10-Enterprise-x64

0
sally5432