Verständnisfrage Gruppenrichtlinien mit Gruppen steuern
Hallo ans Forum
Ich konnte mich bisher beim Aufbau und der Konfiguration von GPO-Objekten immer so "durchmogeln", dass ich alle User- oder Computer-Objekte, für die eine bestimmte GPO greifen soll, in eine OU gepackt habe und das GPO-Objekt dort verknüpft habe oder ein GPO-Objekt auf mehrere OUs verknüpft habe.
Meine Idee ist nun, das Ganze per Gruppen zu steuern, als Beispiel: Das GPO-Objekt "GPO_001" wird nur angewendet, wenn der Benutzer in der Gruppe "Group_GPO_001" Mitglied ist. Zu jedem GPO-Objekt soll es eine eigene Gruppe geben. Nur wenn ein Benutzer oder ein Computer in dieser Gruppe ist, soll die Richtlinie angewandt werden.
Dafür gibt es ja die Sicherheitsfilterung bei jedem GPO Objekt, wo man die Authentifizierten Benutzer rausnehmen kann und eine eigene Gruppe einpflegen kann. Meine genaue Frage ist nun: Könnte ich theoretisch einfach alle GPO-Objekte auf der Domänen-Ebene verknüpfen (habe nur eine Domäne), für jedes GPO-Objekt eine Gruppe machen, diese mit Computer- oder User-Objekten abfüllen und in der Sicherheitsfilterung des GPO-Objekts eintragen? Damit wäre es dann ja komplett egal, in welcher Organisationseinheit ein Objekt ist. Die Entscheidung, ob ein GPO-Objekt greift oder nicht wird anhand der Gruppe gefällt und nicht, in welcher OU der betroffene User oder der betroffene Computer liegt.
Liege ich hier richtig oder denke ich komplett falsch? Wenn ich hier richtig liege, gibt es Gründe, die dagegen sprechen, sämtliche GPOs so zu handeln?
Was ich mir vorstellen könnte: Ich will für einige Benutzer den Proxy im IE eintragen. Ich mache also zwei GPO-Objekte (1x Proxy drin, 1x Proxy draussen). Für jedes der beiden GPO-Objekte mache ich eine Gruppe. Ich trage den User aus Versehen in beiden Gruppen ein und weiss dadurch nicht, welche Einstellung nun gilt......
Evt. könnte es bei einem User mit vielen Gruppen dann ein Weilchen dauern, bis der Login durch ist......
Was ist eure Meinung dazu? Ich verspreche mir davon, die GPOs viel feiner abstufen zu können, ohne dass ich gleich die sorgsam aufgebaute Struktur mit Abteilungen, etc. auseinander reissen muss.
Ach ja, das Ganze würde eine 2012er Domäne betreffen mit mehrheitlich XP-Clients (und einigen 7er-Rechnern). Wechsel auf 8.1 ist geplant.
Gruss
TuXHunT3R
Ich konnte mich bisher beim Aufbau und der Konfiguration von GPO-Objekten immer so "durchmogeln", dass ich alle User- oder Computer-Objekte, für die eine bestimmte GPO greifen soll, in eine OU gepackt habe und das GPO-Objekt dort verknüpft habe oder ein GPO-Objekt auf mehrere OUs verknüpft habe.
Meine Idee ist nun, das Ganze per Gruppen zu steuern, als Beispiel: Das GPO-Objekt "GPO_001" wird nur angewendet, wenn der Benutzer in der Gruppe "Group_GPO_001" Mitglied ist. Zu jedem GPO-Objekt soll es eine eigene Gruppe geben. Nur wenn ein Benutzer oder ein Computer in dieser Gruppe ist, soll die Richtlinie angewandt werden.
Dafür gibt es ja die Sicherheitsfilterung bei jedem GPO Objekt, wo man die Authentifizierten Benutzer rausnehmen kann und eine eigene Gruppe einpflegen kann. Meine genaue Frage ist nun: Könnte ich theoretisch einfach alle GPO-Objekte auf der Domänen-Ebene verknüpfen (habe nur eine Domäne), für jedes GPO-Objekt eine Gruppe machen, diese mit Computer- oder User-Objekten abfüllen und in der Sicherheitsfilterung des GPO-Objekts eintragen? Damit wäre es dann ja komplett egal, in welcher Organisationseinheit ein Objekt ist. Die Entscheidung, ob ein GPO-Objekt greift oder nicht wird anhand der Gruppe gefällt und nicht, in welcher OU der betroffene User oder der betroffene Computer liegt.
Liege ich hier richtig oder denke ich komplett falsch? Wenn ich hier richtig liege, gibt es Gründe, die dagegen sprechen, sämtliche GPOs so zu handeln?
Was ich mir vorstellen könnte: Ich will für einige Benutzer den Proxy im IE eintragen. Ich mache also zwei GPO-Objekte (1x Proxy drin, 1x Proxy draussen). Für jedes der beiden GPO-Objekte mache ich eine Gruppe. Ich trage den User aus Versehen in beiden Gruppen ein und weiss dadurch nicht, welche Einstellung nun gilt......
Evt. könnte es bei einem User mit vielen Gruppen dann ein Weilchen dauern, bis der Login durch ist......
Was ist eure Meinung dazu? Ich verspreche mir davon, die GPOs viel feiner abstufen zu können, ohne dass ich gleich die sorgsam aufgebaute Struktur mit Abteilungen, etc. auseinander reissen muss.
Ach ja, das Ganze würde eine 2012er Domäne betreffen mit mehrheitlich XP-Clients (und einigen 7er-Rechnern). Wechsel auf 8.1 ist geplant.
Gruss
TuXHunT3R
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 221813
Url: https://administrator.de/contentid/221813
Ausgedruckt am: 21.11.2024 um 17:11 Uhr
5 Kommentare
Neuester Kommentar
Guten Morgen @TuXHunt3R,
dein GPO-Design (mittels Gruppen) kannst du auf jeden Fall machen.
Ich würde es jedoch nicht machen (der MCSA spricht aus mir), weil:
Je nachdem wie viele GPO's du hast wird die Sache ein wenig unübersichtlich ...
... vor allem wenn man keine "richtige" Namenskonvention für GPO's hat
... da kann es schnell zu Problemen kommen
Daher würde ich immer die GPO's auf die jeweilige OU legen (und / oder trotzdem noch filtern) ...
... denn wenn man eine Übersicht aller GPO's haben will, kann man den Punkt Gruppenrichtlinienobjekte öffnen
Also wie du siehst, geht es hier eigentlich nur um Design-Technische und Best-Practice
Ach ja - der Login verzögert sich wahrscheinlich nicht merkbar ...
... anders sieht die Geschichte aus, wenn du viele WMI Filter für GPO's im Einsatz hast
Gruß
@kontext
dein GPO-Design (mittels Gruppen) kannst du auf jeden Fall machen.
Ich würde es jedoch nicht machen (der MCSA spricht aus mir), weil:
Je nachdem wie viele GPO's du hast wird die Sache ein wenig unübersichtlich ...
... vor allem wenn man keine "richtige" Namenskonvention für GPO's hat
... da kann es schnell zu Problemen kommen
Daher würde ich immer die GPO's auf die jeweilige OU legen (und / oder trotzdem noch filtern) ...
... denn wenn man eine Übersicht aller GPO's haben will, kann man den Punkt Gruppenrichtlinienobjekte öffnen
Also wie du siehst, geht es hier eigentlich nur um Design-Technische und Best-Practice
Ach ja - der Login verzögert sich wahrscheinlich nicht merkbar ...
... anders sieht die Geschichte aus, wenn du viele WMI Filter für GPO's im Einsatz hast
Gruß
@kontext
Guten Morgen @kontext,
natürlich kommt es auf die Namenskonventionen an. Wenn deine GPOs nur a1-z100 lauten kannst du von der Nachvollziehbarkeit her auch direkt auch gleich wieder User direkt einpflegen.
Gruß,
Christian
natürlich kommt es auf die Namenskonventionen an. Wenn deine GPOs nur a1-z100 lauten kannst du von der Nachvollziehbarkeit her auch direkt auch gleich wieder User direkt einpflegen.
Gruß,
Christian
Zitat von @certifiedit.net:
natürlich kommt es auf die Namenskonventionen an. Wenn deine GPOs nur a1-z100 lauten kannst du von der Nachvollziehbarkeit
her auch direkt auch gleich wieder User direkt einpflegen.
Daher je auch mein Hinweis bzgl. Namenskonvention und bzgl. Best-Practice natürlich kommt es auf die Namenskonventionen an. Wenn deine GPOs nur a1-z100 lauten kannst du von der Nachvollziehbarkeit
her auch direkt auch gleich wieder User direkt einpflegen.
Ich selbst verwalte um die 100 GPO's und das sogar Microsoft Best-Practice empfohlen (weiß ich auch erst seit kurzem )
Jedoch muss man den TO auch dahingehend informieren, da es ja möglich sein könnte, dass er dies nicht weiß bzw. vergessen hat
Gruß
@kontext