4
Softwareeinschränkungen (White List) per GPO unter Win 2003 und MS Net Frame Work Update
Wie bekomme ich Windows Updates (z. B. Net Frame Work), die zur Installation kurz auf C: zugreifen, dazu, sich trotz Softwareeinschränkungen auszuführen, ohne jedes Update per Hand in den GPO zuzulassen?
Hallo,
ich arbeite mit einem Windows 2003 Server und 40 WS, überwiegend Win XP. Ich habe per Gruppenrichtlinien (Softwareeinschränkung) den Usern die Ausführung aller Programme auf den PCs untersagt. Ausnahme die Standartfreigaben ( %Programme% und %Windows%). Auf diese Ordner haben die User aber nur Leserechte. Programmausnahmen habe ich natürlich auch konfiguriert. Soweit läuft das alles prima. Nur wenn ein Windows Update kommt, welches sich temporär auf C: breitmacht, wie z. B. bei dem aktuellen NetframeWork 2 / 3 Update, was gestern rauskam, blockt der PC natürlich diese Ausführung und die Installation des Updates scheitert.
Ich habe jetzt die Möglichkeit, über die GPOs Ausnahmen für die jeweiligen Programme / Dateien zu erstellen, oder ich verschiebe die Clients für 1-2 Tage in eine andere Gruppe ohne Softwareeinschränkung. Beide Möglichkeiten gefallen mir nicht so gut, da ich bei jedem Net Frame Work Update, per Hand eingreifen muss.
Gibt es eine Programm/Pfadfreigabe unter Win 2003, wo ich sagen kann, dass z. B. generell alles, was von Microsoft bzw. von meinem lokalen WSUS-Update-Server kommt zur Ausführung freigegeben ist? Vielleicht über Zertifikate?
Wie handhabt ihr das?
Hallo,
ich arbeite mit einem Windows 2003 Server und 40 WS, überwiegend Win XP. Ich habe per Gruppenrichtlinien (Softwareeinschränkung) den Usern die Ausführung aller Programme auf den PCs untersagt. Ausnahme die Standartfreigaben ( %Programme% und %Windows%). Auf diese Ordner haben die User aber nur Leserechte. Programmausnahmen habe ich natürlich auch konfiguriert. Soweit läuft das alles prima. Nur wenn ein Windows Update kommt, welches sich temporär auf C: breitmacht, wie z. B. bei dem aktuellen NetframeWork 2 / 3 Update, was gestern rauskam, blockt der PC natürlich diese Ausführung und die Installation des Updates scheitert.
Ich habe jetzt die Möglichkeit, über die GPOs Ausnahmen für die jeweiligen Programme / Dateien zu erstellen, oder ich verschiebe die Clients für 1-2 Tage in eine andere Gruppe ohne Softwareeinschränkung. Beide Möglichkeiten gefallen mir nicht so gut, da ich bei jedem Net Frame Work Update, per Hand eingreifen muss.
Gibt es eine Programm/Pfadfreigabe unter Win 2003, wo ich sagen kann, dass z. B. generell alles, was von Microsoft bzw. von meinem lokalen WSUS-Update-Server kommt zur Ausführung freigegeben ist? Vielleicht über Zertifikate?
Wie handhabt ihr das?
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 164490
Url: https://administrator.de/forum/softwareeinschraenkungen-white-list-per-gpo-unter-win-2003-und-ms-net-frame-work-update-164490.html
Ausgedruckt am: 15.04.2025 um 17:04 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
eingentlich sollte es reichen, in der Softwareeinschränkungsrichtlinie es so einzustellen, dass sie nicht für "Alle Benutzer" gilt, sondern für "Alle benutzer außer den lokalen Administratoren".
Solange deine Benutzer nur Benutzer sind, ändert es sich für die nichts, aber der Update-Dienst müsste wieder arbeiten können.
Alternativ könntest du eine neue Zertifikatsregel erstellen mit der Signatur von Microsoft. Dazu bei Zusätzliche Regel eine "neue Zertifikatsregel" erstellen und eine signierte Updatedatei auswählen. Deren Zertifikat sollte dann importiert werden. Das ganze dann erlauben. Allerdings dauern Zertifikatsprüfungen deutlich länger als die anderen Prüfungen, daher sind diese zunächst deaktiviert. Du musst also diese also erstmal im Register "Erzwingen" überhaupt einschalten.
Ich würde dir aber zur Option 1 raten.
Gruß
Schorsch
eingentlich sollte es reichen, in der Softwareeinschränkungsrichtlinie es so einzustellen, dass sie nicht für "Alle Benutzer" gilt, sondern für "Alle benutzer außer den lokalen Administratoren".
Solange deine Benutzer nur Benutzer sind, ändert es sich für die nichts, aber der Update-Dienst müsste wieder arbeiten können.
Alternativ könntest du eine neue Zertifikatsregel erstellen mit der Signatur von Microsoft. Dazu bei Zusätzliche Regel eine "neue Zertifikatsregel" erstellen und eine signierte Updatedatei auswählen. Deren Zertifikat sollte dann importiert werden. Das ganze dann erlauben. Allerdings dauern Zertifikatsprüfungen deutlich länger als die anderen Prüfungen, daher sind diese zunächst deaktiviert. Du musst also diese also erstmal im Register "Erzwingen" überhaupt einschalten.
Ich würde dir aber zur Option 1 raten.
Gruß
Schorsch
Ich hab die Richtlinie unter den Computerconfigurationen eingerichtet, damit ich bei Neuanlage von Usern nicht immer drauf achten muss, dass dieser mit bestimmten Gruppenrichtlinen verknüpft werden muss.
Auf welchen lokalen Administrator sollte das Update dann zurückgreifen? Ich dachte immer, das wird mit den Rechten ausgeführt, die der angemeldete User gerade hat, da ich ja beim Anmelden am Netz gerade die aktuelle GPO vom AD mitgeteilt habe.
Gut ich könnte das was ich unter der Computerconfiguration eingetragen habe unter die Benutzerkonfiguration schreiben und das dann nur gültig für die Gruppe Benutzer machen. Aber woher soll das Update dann wissen, wenn der Benutzer "ohne Rechte" angemeldet ist, "hey ich installier mich jetzt mal als lokaler Admin"?
Der Update-Dienst arbeitet wunderbar, weil Windows so schlau ist und alles temporäre in den Ordner Windows entpackt. Dieser ist ja dafür freigegeben. Nur Net Frame Work oder z. B. auch Adobe Flash will bei der Installation mal kurz was auf C: machen und da werden sie natürlich geblockt.
Auf welchen lokalen Administrator sollte das Update dann zurückgreifen? Ich dachte immer, das wird mit den Rechten ausgeführt, die der angemeldete User gerade hat, da ich ja beim Anmelden am Netz gerade die aktuelle GPO vom AD mitgeteilt habe.
Gut ich könnte das was ich unter der Computerconfiguration eingetragen habe unter die Benutzerkonfiguration schreiben und das dann nur gültig für die Gruppe Benutzer machen. Aber woher soll das Update dann wissen, wenn der Benutzer "ohne Rechte" angemeldet ist, "hey ich installier mich jetzt mal als lokaler Admin"?
Der Update-Dienst arbeitet wunderbar, weil Windows so schlau ist und alles temporäre in den Ordner Windows entpackt. Dieser ist ja dafür freigegeben. Nur Net Frame Work oder z. B. auch Adobe Flash will bei der Installation mal kurz was auf C: machen und da werden sie natürlich geblockt.
Zitat von @Reiner.Zufall:
Ich hab die Richtlinie unter den Computerconfigurationen eingerichtet, damit ich bei Neuanlage von Usern nicht immer drauf achten
muss, dass dieser mit bestimmten Gruppenrichtlinen verknüpft werden muss.
Ich hab die Richtlinie unter den Computerconfigurationen eingerichtet, damit ich bei Neuanlage von Usern nicht immer drauf achten
muss, dass dieser mit bestimmten Gruppenrichtlinen verknüpft werden muss.
ist ok.
Denk aber daran, dass die Computerkonfiguration vom Computer selbst verarbeitet wird und mit den Benutzern rein gar nichts zu tun hat (für den gilt die Benutzerkonfiguration). U.a. dafür wird bei der Aufnahme des Computers in die Domäne ja auch Computerkonto angelegt.
Auf welchen lokalen Administrator sollte das Update dann zurückgreifen?
Na, dann schau mal, unter welchem Konto die Dienste "Automatische Updates" sowie "Windows Installer" laufen?
Diese laufen als "Systemkonto". Und ja, dieses ist lokaler Administrator.
Ich dachte immer, das wird mit den Rechten
ausgeführt, die der angemeldete User gerade hat, da ich ja beim Anmelden am Netz gerade die aktuelle GPO vom AD mitgeteilt
habe.
ausgeführt, die der angemeldete User gerade hat, da ich ja beim Anmelden am Netz gerade die aktuelle GPO vom AD mitgeteilt
habe.
Richtig, aber wenn das Update nicht von einem Benutzer, sondern einem der genannten Dienste gestartet wird, gelten dessen Rechte.
Es kommt also darauf an, wer das Update startet: Versucht ein Benutzer es manuell zu startet, wird er zu Recht geblockt, hast du aber den Updatedienst so konfiguriert, dass er es automatisch vom WSUS lädt und unabhängig vom Benutzer installiert, wird das eben mit dem Systemkonto durchgeführt.
Muss ja auch, man braucht schließlich Adminrechte für die Installation von Windowsupdates.
[...]
Der Update-Dienst arbeitet wunderbar, weil Windows so schlau ist und alles temporäre in den Ordner Windows entpackt. Dieser
ist ja dafür freigegeben. Nur Net Frame Work oder z. B. auch Adobe Flash will bei der Installation mal kurz was auf C: machen
und da werden sie natürlich geblockt.
Der Update-Dienst arbeitet wunderbar, weil Windows so schlau ist und alles temporäre in den Ordner Windows entpackt. Dieser
ist ja dafür freigegeben. Nur Net Frame Work oder z. B. auch Adobe Flash will bei der Installation mal kurz was auf C: machen
und da werden sie natürlich geblockt.
Klar, da deine Richtlinie auch auf Admins wirkt.
Der Updatedienst beginnt mit dem Update, entpackt die Dateien in einen Temp-Ordner und starten von hier die eigentliche Setup-Datei. Schränkt deine Richtlinie den Temp-Pfad ein, fällt er auf die Nase.
Daher die Empfehlung, die Richtlinie so einzustellen, dass Admins nicht betroffen sind. Oder aber die (langsame) Zertifikatsregel.
Gruß,
Schorsch
Schorsch du hast ja soo Recht.
Manchmal hab ich in meiner Denke einen Knoten im Kopf. Danke fürs entknoten! Schönes WE
Für alle die hier mal mit dem gleichen Problem an der Stelle stehen eine kurze Zusammenfassung:
Ich habe mich für Schorschs Version 1 entschieden.
Ich habe alle Einstellungen, die generell für alle PCs im AD gelten in der Gruppenrichtline unter Computerkonfiguration eingetragen. (In meinem Fall sind das die WSUS-Einstellungen, die Firewall-Config und dass die Benutzergruppe "WS-Admin" (normaler Benutzer) Admin-Rechte auf den lokalen PCs bekommt.
Und die Software-White-List (Richtlinien für Softwareeinschränkung) unter Benutzerkonfiguration eingetragen. (Standart=nichts zulassen, Ausnahmen = die Standart-Win-Ausnahmen und unsere individuellen Programme)
Dann habe ich eine neue OU im AD angelegt "Anwender", die Software-White-List aktiviert und meine ganzen Anwendungsuser dorthin geschoben. Alle Administratoren und Gruppen hab ich in der Standart OU User gelassen.
Nun können die Anwender nix installieren, aber jeder Administrator kann das. Und das Windows-Update (welches tatsächlich unter dem "builtin-Admin" läuft
) funktioniert auch.
Wenn ich einen neuen Anwender im AD anlegen muss, mache ich es gleich in dem "Anwender" Ordner und die Gruppenrichtlinie wirkt.
Manchmal hab ich in meiner Denke einen Knoten im Kopf. Danke fürs entknoten! Schönes WE
Für alle die hier mal mit dem gleichen Problem an der Stelle stehen eine kurze Zusammenfassung:
Ich habe mich für Schorschs Version 1 entschieden.
Ich habe alle Einstellungen, die generell für alle PCs im AD gelten in der Gruppenrichtline unter Computerkonfiguration eingetragen. (In meinem Fall sind das die WSUS-Einstellungen, die Firewall-Config und dass die Benutzergruppe "WS-Admin" (normaler Benutzer) Admin-Rechte auf den lokalen PCs bekommt.
Und die Software-White-List (Richtlinien für Softwareeinschränkung) unter Benutzerkonfiguration eingetragen. (Standart=nichts zulassen, Ausnahmen = die Standart-Win-Ausnahmen und unsere individuellen Programme)
Dann habe ich eine neue OU im AD angelegt "Anwender", die Software-White-List aktiviert und meine ganzen Anwendungsuser dorthin geschoben. Alle Administratoren und Gruppen hab ich in der Standart OU User gelassen.
Nun können die Anwender nix installieren, aber jeder Administrator kann das. Und das Windows-Update (welches tatsächlich unter dem "builtin-Admin" läuft
) funktioniert auch.Wenn ich einen neuen Anwender im AD anlegen muss, mache ich es gleich in dem "Anwender" Ordner und die Gruppenrichtlinie wirkt.
