[English]Update KB3159398, welches zum Juni 2016-Patchday ausgerollt wurde, führt offenbar zu Problemen mit der Verarbeitung von Gruppenrichtlinien unter Windows. Nachtrag: Microsoft hat reagiert und den KB-Artikel aktualisiert (siehe Ergänzung inside). Und es gibt ein PowerShell-Script zum Fixen, sowie einen Artikel meines MVP-Kollegen Marc Heitbrink, warum es das Problem gibt.
Anzeige
Hintergrundinformationen zu KB3159398
Im Artikel Update-Details zum Microsoft Patchday 14. Juni 2016 habe ich über das Sicherheitsupdate für Gruppenrichtlinien (3163622) berichtet, welches im Microsoft Sicherheits-Bulletin MS16-072 adressiert wird. Dieses Sicherheitsupdate behebt eine Sicherheitsanfälligkeit in Microsoft Windows. Diese könnte die Erhöhung von Berechtigungen zulassen, wenn ein Angreifer einen Man-in-the-Middle (MiTM)-Angriff auf den Datenverkehr zwischen einem Domänencontroller und dem Zielcomputer ausführt. Betroffen sind eigentlich alle Windows-Versionen.
– Windows Vista Service Pack 2
– Windows Vista x64 Edition Service Pack 2
– Windows Server 2008 for 32-bit Systems Service Pack 2
(Windows Server 2008 Server Core installation affected)
– Windows Server 2008 for x64-based Systems Service Pack 2
(Windows Server 2008 Server Core installation affected)
– Windows Server 2008 for Itanium-based Systems Service Pack 2
– Windows 7 for 32-bit Systems Service Pack 1
– Windows 7 for x64-based Systems Service Pack 1
– Windows Server 2008 R2 for x64-based Systems Service Pack 1
(Windows Server 2008 R2 Server Core installation affected)
– Windows Server 2008 R2 for Itanium-based Systems Service Pack 1
– Windows 8.1 for 32-bit Systems
– Windows 8.1 for x64-based Systems
– Windows Server 2012
(Windows Server 2012 Server Core installation affected)
– Windows Server 2012 R2
(Windows Server 2012 R2 Server Core installation affected)
– Windows RT 8.1
– Windows 10 for 32-bit Systems
– Windows 10 for x64-based Systems
– Windows 10 Version 1511 for 32-bit Systems
– Windows 10 Version 1511 for x64-based Systems
Der Fix erfolgt über das Update KB3159398.
KB3159398 macht Ärger
Bereits in den Kommentaren zum Blog-Beitrag Update-Details zum Microsoft Patchday 14. Juni 2016 kam der Hinweis von Blog-Leser Geronimo1.0, dass es Probleme mit dem Update gibt.
Anzeige
Leider hängt die Installation jetzt schon eine Weile bei KB3159398. Irgendwas mit Group Police. Gibt auch schon was im Internet dazu zu lesen. Habe aber noch keine passende Lösung gefunden.
Hattet Ihr Probleme mit diesem Update?
Nun hat mich Hanspeter H. in einem Google+-Beitrag auf ein Problem mit KB3159398 hingewiesen. Es gibt diesen Technet-Foreneintrag, wo ein Nutzer unter Windows Server 2008 R2 das Problem anreißt. Nach dem Update können z.B. folgende Fehler auftreten:
- Desktop-Symbole für Verknüpfungen werden nicht mehr sauber angezeigt.
- Laufwerke A:, B:, C: und D: sind vor dem Benutzer versteckt – das Drive-Mapping funktioniert nicht mehr (siehe auch).
- Diverse Gruppenrichtlinien (z.B. Drucker GPOs, siehe) funktionieren nicht mehr.
Es gibt eine ganze Anzahl an Benutzern im Forenthread, die den Fehler auf diversen Windows-Versionen bestätigen.
Workarounds zum Fixen der Problematik
Als Workaround kann man Update KB3159398 deinstallieren – was aber aus Sicherheitsgründen eine schlechte Idee ist. Einzelne Nutzer berichten im Technet-Foreneintrag, dass man der GPO das Leserecht zuteilen kann, damit die Gruppenrichtlinien wieder funktionieren.
I can confirm that our broken GPO's were missing the Read permission for Authenticated Users on the delegation tab. Once that was added back the GPO's processed as expected, but clearly this is a change from the patch. It would be nice to know if the patch will be fixed, or do we need to start "fixing" GPO permissions.
Dieser Ansatz funktioniert aber nur auf Windows Server, wenn die Gruppenrichtlinien-Verwaltungskonsole gpmc.msc als entsprechende Rolle installiert ist (siehe oder hier, bzw. hier für Windows 7 SP1).
- Hierzu ruft man die Gruppenrichtlinien-Verwaltungskonsole gpmc.msc auf (siehe).
- Dann geht man zur Gruppenrichtlinie, die Probleme macht, und ruft die Delegation Registerkarte Delegation (Delegierung) auf.
- Anschließen lässt sich "Authenticated Users" als Gruppe mit Read-Permission zuweisen (siehe auch).
Ich habe keinen Windows Server lauffähig, kann also keine Screenshots zeigen. Vielleicht hilft es aber trotzdem weiter.
Nachtrag: Bestätigung des Workarounds durch Microsoft
Zwischenzeitlich wurde von Microsoft der KB-Beitrag KB3163622 (MS16-072: Security update for Group Policy: June 14, 2016) erweitert. Beim Schreiben des Blog-Beitrags habe ich noch nichts davon gesehen. Danke an Hanspeter Holzer für den Hinweis. Hier die Ergänzung durch Microsoft.
Known issues
MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers' computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user's security context. After MS16-072 is installed, user group policies are retrieved by using the machines security context. This issue is applicable for the following KB articles:
- 3159398 MS16-072: Description of the security update for Group Policy: June 14, 2016
- 3163017 Cumulative update for Windows 10: June 14, 2016
- 3163018 Cumulative update for Windows 10 Version 1511 and Windows Server 2016 Technical Preview 4: June 14, 2016
- 3163016 Cumulative Update for Windows Server 2016 Technical Preview 5: June 14 2016
Symptoms
All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.
Cause
This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.
Resolution
To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
- Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
- If you are using security filtering, add the Domain Computers group with read permission.
Nachtrag #1: PowerShell-Script zum Fixen
Mein MVP-Kollege Mark Heitbrink hat mich auf den Artikel New Group Policy Patch MS16-072– "Breaks" GP Processing Behavior hingewiesen. Dort hat Benutzer Darren ein kleines Powershell-Script bereitgestellt, mit dem man die Read Permission der GPOs automatisch hinzufügen lassen kann. Details im englischsprachigen Artikel.
Nachtrag #2: Warum streiken Richtlinien
Es klang bereits in den Kommentaren weiter unten an. Mit dem Update ändert Microsoft die Art, wie die Sicherheitsfilterung bei Gruppenrichtlinien funktioniert. Ich selbst bin in der Thematik nicht drin, da Server-Umgebungen nicht so mein Baustelle sind. Daher verweise ich auf den Artikel Sicherheitsfilterung neu erfunden – MS16-072 – Patchday 14.06.2016 meines MVP-Kollegen Marc Heitbrink von gruppenrichtlinien.de. Dort wird erklärt, was sich mit MS16-072 geändert hat und wie man sauber darauf reagieren sollte. Ich hoffe, es hilft weiter.
Anzeige
Was sagt Microsoft denn dazu? Die bringen ja inzwischen wirklich einen fehlerhaften Patch nach dem anderen heraus. Das macht keinen Spaß mehr. Wäre es nicht besser, das Update dann erstmal nicht zu installieren, bevor man hinterher nur Probleme hat? Ich mag nicht gern selbst an den Gruppensichtlinien herumfummeln. Haben denn hier alle User das Problem? Bin ratlos. Lieben Dank aber für den Hinweis!
Ich verstehe auch nicht, warum die das Update nicht längst zurückgezogen haben. Die müssen doch inzwischen mitbekommen haben, welch graviende Fehler es verursacht!
Für Privatanwender ist das imho nicht wirklich relevant.
Danke für die Ergänzung! :-) Wie lange hat die Updatesuche eigentlich bei Ihnen gedauert, wenn ich fragen darf?
Ich habe es nicht genau gestoppt – bei mehreren Systemen im Haus habe ich diese einfach gestartet und nach einer halben Stunde nachgeschaut – dann waren die Updates da.
Bei meinem Produktivsystem (Windows 7 SP1) kamen die Updates während des Schreibens des Blogbeitrags zum Patchday (könnten 30 Minuten gewesen sein), was wohl ca. 1 Stunde braucht. Länger als eine Stunde hat es wohl bei keinem System gedauert.
Ich danke Ihnen und hoffe, das problematische Update hat auch langfristig keine negativen Auswirkungen für Privatanwender. Interessieren würde mich auch, welche Nutzer insbesondere davon betroffen sind und warum. So ganz habe ich es nämlich noch nicht verstanden.
Beim Lonovo-Notebook (2012) mit Intel-CPU lief unter Win 7 Ultimate SP1 64-bit die Update-Suche bestern recht zügig.
Die selbst zusammengeschraubten HTPC (2008) und Miditower (2010) , beide ebenfalls mit Win 7 Ultimate SP1 64-bit, aber mit AMD-Prozessoren, suchen noch immer. Gestern habe ich nach ca. 2 Stunden entnervt das Ganze abgebrochen und soeben wieder gestartet. Hoffentlich finden bei Rechner die Updates noch bis zum Abend bevor die Gewitter-Cluster über meinen Wohnort hinwegziehen.
Der Miditower hat nach 2 Stunden 11 Updates gefunden und installiert, während der HTPC seit ca. 6 Stunden immer noch sucht. Was soll ich nun tun? Ich weiß nicht mehr weiter; danke im voraus!
@Georg,
das was bei http://sm.krelay.de/wu/ steht probiert? Funktioniert (hier) gut.
Die Aussage im Titel ist schlicht falsch – wenn man von vornherein seine GPOs _korrekt!_ konfiguriert und sich an Best Practives hält (anders gesagt: Wenn man weiß, was man tut!), kommt es erst gar nicht zu solchen "Problemen".
@Jörg: Das mag sein – da ich nix mit Servern am Hut habe, kann ich das nicht bestätigen oder widerlegen. Auffällig ist aber, dass da mehr als Einer in den Internetforen aufschlägt. Die administrieren Server und wissen alle nicht, was sie tun? Falls diese Prämisse zuträfe, hat MS imho was falsch gemacht (Stichwort: Schwächstes Glied der Kette bricht – also muss ich das foolproof machen). Aber ich mag mich täuschen.
Nachtrag: Es wurde im KB-Artikel zum Patch (nachträglich) kommuniziert, dass die Problematik auf eine Design-Änderung zurückzuführen ist – Jörg hat wohl Recht. Auch bei reddit.com gibt es einen Eintrag. Beim Querlesen komme ich aber zum Schluss, dass das ganze Thema irgendwie von Microsoft wohl nie wirklich sauber kommuniziert wurde bzw. es sogar widersprüchliche Aussagen gab.
@ Jörg: Wir hatten hier eine GPO auf eine Sicherheitsgruppe gefiltert. Diese GPO war ebenfalls betroffen. Somit ist Deine Aussage falsch, da wir die normale Techniken genutzt haben, die uns von MS zur Verfügung gestellt werden. Das hat nix mit "von Hinten durchs Knie zu tun", sondern ist Standard. Und der funktioniert nach dem Update nicht mehr.
Ganz genau so sieht es nämlich aus. Wir haben fast auf jeder GPO eine Sicherheitsfilterung.
Ebenso. Da muss ich Jörg deutlich widersprechen.
Naja. Ich glaube nicht, dass die Nutzer selbst daran schuld sind oder von sich aus irgendwas an den Gruppenrichtlinien verändert haben. Das kann ich mir einfach nicht vorstellen. Der Fehler muss schon bei MS liegen. Sonst hätten nicht so viele User das Problem. Ist aber auch nur meine Meinung, und die muss ja nicht zwangsläufig stimmen.
Wem das händische hinzufügen der "Authenticated Users" zu viel ist, kann hier ein Script herunterladen: https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior/
Das ist schlicht keine Lösung. Entweder sind die Authentifizierten Benutzer schon berechtigt, weil die GPO z.B. auf eine gesamte OU wirken soll, oder es ist eine Sicherheitsfilterung drauf, die man damit dann aushebeln würde.
genau lesen hilft: Man gibt "Authenticated Users" nur Lese-Berechtigung ohne "APPLY GROUP POLICY"-Berchtigung sodass die Sicherheitsfilterung weiterhin funktioniert.
Ja, ist richtig. Was trotzdem bleibt, ist die Erkenntnis, die ich unten geschildert habe. Selbst wenn man jetzt alle GPOs anpassen würde – mit Skript oder ohne – so wirkt das nur auf schon vorhandene GPOs und nicht auf zukünftige. Ich finde das schon ziemlich heftig von Microsoft, ohne Vorankündigung eine derartig große Änderung vorzunehmen.
"To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
If you are using security filtering, add the Domain Computers group with read permission."
Das kann aber nicht deren Ernst sein? Man könnte nun künftig jede neue GPO derart bearbeiten, nachdem man die schon vorhandenen alle angefasst hat. Oder man muss das Schema ändern, damit die Computerkonten künftig standardmäßig berechtigt werden. Sowas können die doch nicht einfach so einführen?
Hi, können Sie die Quelle dazu posten?
Danke & Gruß
Sicherheitsfilterung neu erfunden – MS16-072 – Patchday 14.06.2016
http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/
Danke für den Link – Marc Heitbrink ist mit gruppenrichtlinien.de da die eindeutig bessere Quelle für GPO-Trallala.
So so. Microsoft hat also erkannt, daß mit dem Update etwas nicht in Ordnung ist. Und warum fixen die dann nicht das Ding? Ziehen es also zurück und rollen ein bug-gefixtes aus?
Dieser Workaround ist ja wohl nichts für den Otto-Normal-User, sondern eher was für Profis, studierte Informatiker oder so ähnlich.
Ich werde das Ding erstmal ignorieren, bis es mir mit anderen Datum als dem 14.06.2016 angezeigt werden sollte.
Normal-User sind (nach aktuellem Wissen) auch nicht betroffen – es geht hier um Domänen in Windows Server-Umgebungen, die dann die Probleme mit Gruppenrichtlinien auf den Clients verursachen.
Lasst das Sicherheits-Update installieren. Da die Home-Editionen nie in eine Domäne eingebunden werden, bleiben die beschriebenen Sachen imho folgenlos. Bei einer Professional-Version von Windows ist es ähnlich, solange diese nicht in eine Domäne eingebunden wird. Und in einem Szenario Pro-Version von Windows in Kombination mit einem Windows Server samt Domänen-Controller sollte dessen Administrator wissen, wie er den Fall handhabt.
Besten Dank für den Hinweis, lieber Herr Born! Für mich ist Ihre Seite inzwischen unverzichtbar geworden. :-)
Danke für den Hinweis. Da hatte ich wohl was falsch verstanden.
Das heißt also, ich kann (und sollte auch?) dieses Update auf unseren normalen W7-Heimrechnern installieren?
Ja, lasse das Update installieren. Mir sind noch keine Fundstellen untergekommen, dass das Update auf reinen Clients – die nicht mit einem Server kommunizieren – Probleme verursacht.
Ok, werde ich nun tun. Nochmals Dank.
Ich hatte einfach überlesen, daß die ganze hier beschriebene Problematik für Privatanwender irrrelevant ist.
Hm, stehe gerade auf dem Schlauch. Also, ich hab das noch rechtzeitig mitbekommen, und die DC haben noch gar keine dahingehenden Patches. Die Abhilfe ist ok, dass ich kein unfundiertes MS-Bashing betreibe, merkt man vielleicht. Der Umstand ist nämlich gewollt und sinnvoll. Eine Ankündigung wäre natürlich hilfreich gewesen.
Aber, neue W10-Clients mit diesen Patches, ziehen sich nicht mehr die Laufwerkszuordnung, obwohl der zuständige DC ja noch gar nicht gepatcht ist. ? Sonst noch jemand mit dem Symptom? Danke.
Seit dem KB3149135 ist auch kein zugriff mehr auf die Samba Freigaben auf einem aktuellen QNAP System mehr möglich.
Soll heissen das auch "normale" Clients betroffen sind.
Da sich das KB3149135 nicht deinstallieren lässt ist das natürlich ärgerlich :-(
@Holger: Danke für den Hinweis.
Nur mal ein Schrotschuss – ich kann daneben liegen. Schau dir mal den Kommentar hier an. Würde mich interessieren, ob der server max protocol = SMB3 Schalter in der Samba-Konfig was bewirkt. Ich habe z.B. keinen Samba-Server in einer VM laufen.
Wie gesagt ein QNAP NAS mit samba 4
Mit patch keinen zugriff (Das NAS wird dann nicht mal in der Netwerkumgebung angezeigt)
Ohne Patch keine Probleme!
@Holger
Das Problem ist der Patch auf dem Client, dem Domain Controller ist das ziemlich Wurscht. Außer natürlich bei Richtlinien, die ihn selbst betreffen.
Danke, genau, der Patch auf dem Client ist das Problem. Inzwischen ist der DC gepatcht, bisherige Clients, noch ohne den Patch, haben die Mappings. Die neuen W10-Maschinen mit Patch, ziehen sich keine Laufwerke mehr. Ich hatte und habe vor und nach dem Patch am DC die Domänenbenutzer lesend in der Delegierung. Da ist also nun nichts zu troubleshooten? Ich hoffte, daran könnte ich nacharbeiten.
Steht eigentlich alles schon oben, aber nochmal: Die GPOs werden unter dem Computeraccount abgefragt. Also brauchst du mindestens die Domänencomputer oder eben die Authentifizierten Benutzer leseberechtigt.
Das Problem ist nicht Clientseitig sondern Serverseitig in der Gruppenrichtlinienverwaltung zu lösen!
Richtig. Aber was machen, wenn die Benutzer bereits mit Leserechten in der Delegierung sind?
Sorry! Bin nicht mehr der jüngste, aber jetzt ist der Groschen gefallen ;-). Hatte zwar alle Benutzer lesend drin, aber erst durch explizites Hinzufügen von Auhentifizierten, sowie Domänencomputer, jeweils lesend, funktioniert es. Reproduzierbar getestet. Alles schick, puh! Wochenende gerettet.
Eins von beiden reicht aber, sinnvollerweise die kleinere, also die Domänencomputer. ;-)
Danke, riedenthied. Genau, natürlich richtig. Panik ist ein schlechter Ratgeber, und das von 10:55 hatte ich übersehen. Dann freuen wir uns jetzt, dass die Kuh vom Eis ist, und auf den nächsten Patchday ;-).
off topic – @ frands oos:
Danke für den Link! Z.Z. findet mein HTPC wieder Windows Updates!
Sorry für die späte Rückmeldung, aber ich konnte mich erst letzten Samstag um das Problem kümmern.
Ich wollte jetzt die Vorlage für neue GPOs anpassen, damit standardmäßig die Domänencomputer unter Deligierung hinzugefügt werden.
Quelle: http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/
ADSI-Editor öffnen und zum Schema verbinden dann das Objekt "CN=Group-Policy-Container" suchen.Attribut: defaultSecurityDiscriptor öffnen und diesen Eintrag am Ende(!) hinzufügen: (A;CI;LCRP;;;DC)
Doch jetzt bekomme ich beim Übernehmen die Meldung:
"Fehler bei Vorgang. Fehldercode: 0x202b
Eine Referenzsauswertung wurde vom Server zurückgesendet."
Kann mir einer sagen wo das Problem liegt?
Und auf einmal hat man dann doch eine Lösung gefunden. :-)
Siehe unten in roter Schrift: http://clintboessen.blogspot.de/2011/08/ad-delegation-how-to-set-default.html
Sehr geehrter Herr Born !
Beim letzten Patchday war auch ein kumulatives Sicherheitsupdate für Internet
Explorer 11 mit dabei. ( KB3170106 ) Das Update wird nur zu 45 % heruntergeladen.
Dementsprechend wird die Installation abgebrochen, und zwar immer wieder seit
dem 12. Juli 2016. Ist über dieses Problem schon Etwas bekannt ?
Muß dieses Update überhaupt installiert werden, oder ist das Update KB3170106
nicht unbedingt nötig ?
Mit freundlichen Grüßen
Hans Thölen aus Don Mueang / Bangkok / Thailand
Mal probiert, das Update KB3170106 direkt von Microsoft herunterzuladen und manuell zu installieren?
KB3170106
Dieser Vorschlag war wie immer bei Ihnen ein voller Erfolg.
KB3170106 wurde in wenigen Minuten erfolgreich von der
Downloadseite von Microsoft heruntergeladen und installiert.
Ich danke vielmals für diese Hilfe
Liebe Community,
ich habe immer noch ein Problem mit meinen benutzerdefinierten GPOs. Authentifizierte Benutzer haben ein Lese-Recht (durch Sicherheitsfilterung) unter Delegation. Trotzdem funktioniert die GPO nicht (Meldung: Zugriff verweigert). Erstelle ich aber dieselbe GPO neu (unter einen anderen Namen), so wird sie übernommen. Die Einstellungen sind identisch zur alten GPO (sowohl inhaltlich als auch der Delegierung und der Sicherheitsfilterung. Hat jemand eine Ahnung, wie ich es umgehen kann, alle Benutzer GPOs neu anzulegen?
Im Einsatz ist ein Win 2012 R2 – Server, der die benutzerdefinierten GPOs an Win2012 R2 Terminalserver verteilt.
Herzlichen Dank.