Lösungen für GPO-Probleme nach Update MS 16-072 bzw. KB3163622

Das von Microsoft im Juni veröffent­lichte Sicher­heits-Update MS 16-072 (KB3163622) verur­sacht bei vielen Anwen­dern Pro­bleme bei der Ausfüh­rung von GPOs. Verant­wortlich dafür sind fehlende Zugriffs­rechte, wenn Admins die Standard­einstellungen geändert haben. Microsoft lieferte nun detail­liertere Informa­tionen zum Patch und dessen Auswir­kungen.

Nach der Installation von KB3163622 stellten viele Administratoren fest, dass bestimmte Gruppen­richtlinien nicht mehr angewandt werden. Betroffen waren jene GPOs, bei denen der Systemverwalter den Gültigkeits­bereich durch die Sicherheitsfilterung auf bestimmte Gruppen oder Objekte eingeschränkt und dabei das Leserecht für Authentifizierte Benutzer entfernt hat.

Computer-Konto ruft jetzt GPOs ab

Dies führt nun zu unerwünschten Effekten, weil nach Einspielen des Updates nicht mehr der angemeldete Benutzer die GPOs vom SYSVOL der DCs abruft, sondern dies unter der Kennung des Computers erfolgt. Durch diese Änderung erzwang Microsoft die Verwendung von Kerberos, was gegen Man-in-the-Middle-Angriffe schützen soll.

Ein Computer-Konto fällt ebenfalls unter Authentifizierte Benutzer, so dass MS 16-072 keine Probleme bereitet, wenn sie das standardmäßig erteilte Leserecht behalten haben. Fehlt ihnen diese Berechtigung, dann kann der Computer die GPOs nicht stell­vertretend für den Benutzer abrufen.

Leserecht für Authentifizierte Benutzer erteilen

Damit liegt eine Lösung auf der Hand, die Microsoft unmittelbar nach den ersten Fehlerberichten der Kunden empfahl. Sie besteht schlicht darin, Authentifizierte Benutzer für alle GPOs wieder mit dem Leserecht zu versehen.

Bei einer größeren Zahl von GPOs wäre das manuelle Update der Sicherheits­einstellungen zu umständlich. PowerShell kann diese Aufgabe jedoch in einem Durchgang erledigen. Dazu findet sich auf TechNet Gallery ein entsprechendes Script.

Berechtigung für Domain Computers

Allerdings stellt sich die Frage, ob man das Leserecht wirklich an Authentifizierte Benutzer vergeben möchte oder man nicht vielmehr die Gelegenheit nutzen will, um es auf jene Objekte einzuschränken, die es tatsächlich benötigen - also die jeweiligen Computer-Konten.

Um dieses Ziel zu erreichen, schlägt dieser Beitrag auf dem TechNet-Blog vor, das Leserecht nur an Domain Computers zu verleihen. Dazu liefert der Autor gleich ein paar Zeilen PowerShell-Code, die Domain Computers das Leserecht für sämtliche GPOs einräumt:

$gpos = get-gpo -all

foreach ($gpo in $gpos){
	Set-GPPermissions -Name $gpo.DisplayName -PermissionLevel GpoRead `
	-TargetName "Domain Computers" -TargetType Group
}

Ungünstig ist diese Lösung jedoch in Umgebungen, wo GPOs mit mehreren Domänen verknüpft sind. Dort haben dann nur die Computer-Konten aus der aktuellen Domäne den Zugriff auf GPOs, jene aus den anderen Domains müssten explizit eingetragen werden. Außerdem muss sichergestellt sein, dass tatsächlich alle Computer in Domain Computers vorhanden sind und keiner etwa manuell entfernt wurde.

Mit der nachträglichen Zuordnung des erforderlichen Leserechts an die Computer-Konten, sei es über Domain Computers oder Authentifizierte Benutzer, ist das durch MS 16-072 verursachte Problem vorerst beseitigt.

Konfiguration künftiger GPOs

Allerdings muss künftig darauf geachtet werden, dass die Sicherheits­einstellungen bei neuen GPOs passen. Erhalten die Computer-Konten ihr Leserecht als Mitglieder von Authentifizierte Benutzer, dann fügt die Gruppenricht­linienverwaltung diese beim Anlegen eines GPO ohnehin automatisch ein.

Entscheidet man sich jedoch für die Variante Domain Computers, dann muss man für sie die Leseberechtigung explizit eintragen. Das gilt umso mehr, wenn man GPOs mit mehreren Domänen verknüpft.