91863
10.02.2014, aktualisiert am 11.02.2014
5652
21
0
Frage zu GPO . GPO hat Gruppen , wird aber nur im Userteil und nicht im Computerteil aktiv
Hallo,
das Problem ist, wir haben eine Domäne und eine Childdomäne.
Die User sind in der childdomäne und Computerobjekte in der Domäne.
Die Verlinkte GPO ist in der Domäne OU Notebook.
Computerobjekte befinden sich auch dort
Die verlinkte GPO hat 2 Gruppen. 1 Gruppe aus Domäne und 1 Gruppe aus Childdomäne.
Ich trage mich nun in eine der Gruppen ein. Nun kommt aber wenn ich Gpresult mache in den Computersettings
Security Filtering not Applied.
Der Userteil wird aber ausgeführt.
Zuerst dache ich : (Auszug aus einer alten Frage hier
Ein Satz heisst : That's not how GPO filtering works. GPO's don't process against security groups, they process against users and computers. Security Filtering allows you to "scope" the GPO so that it applies only to users who are members of the security group in your filter. You need to link the GPO to the OU where the user objects are and then the security filter applies the GPO to only members of that security Group
Nun habe ich mal die GPO auf die Root gesetzt, das im ganzen AD Sie aktiv ist. Den User Administrator in eine ganz andere OU getan "Pflege" und die Gruppe Verwaltung in die "Verwaltung" und es geht !
Es muss in dem Fall nicht immer der User genau in der OU sein , wo auch die Gruppe ist. Wichtig ist, das die GPO die wohl findet ! Sonst müsste ich immer die User genau im jeweiligen Bereich erstellen.
Kurz gesagt heisst das:
Die GPO muss in dem Bereich aktiv sein, das User auch gefunden werden, um dann die Gruppe als Filter nutzen zu können.
Da aber nun der Userteil ausgeührt wird. Trifft das ja nicht ganz zu, und das Filtering ist aktiv ! Die Frage ist nun, warum wird der Computerteil verweigert ?
Hat wer ne Idee , warum der Computerteil nicht ausgeführt wird ?
Zum testen ob der Teil tut habe ich mal einen PC in die Policy direct getan:
Die geht, weil ja Policy direct auf OU geht.
Aber das ist ja falsch , nur die Leute der Gruppe den Computerteil bekommen sollen.
Was kann getan werden, das der Computerteil der Policy auch ausgeführt wird ?
Für mich heisst das, das der Computerteil Ignoriert wird, da die GPO Richtlinie keine Hardware als Filter hat !
http://www.gruppenrichtlinien.de/artikel/loopbackverarbeitungsmodus-loo ...
Auszug auf Gruppenrichtlinien.de:
Ich muss die Richtlinie irgendwie auf das Computerkonto anwenden? Aber der Computer ignoriert den Anteil der Benutzerkonfiguration einer Richtlinie, da er ja schliesslich ein Computerobjekt ist und kein Benutzer. Ebenfalls, ist dem anmeldenden Benutzer die Benutzerkonfiguration einer Richtlinien auf dem Computerobjekt egal, da der Benutzer die Computerkonfiguration garnicht liest, und damit am Ende die Richtlinie, nicht übernehmen kann. Es kommt noch hinzu, daß der Benutzer meistens nicht in der OU des Computers steht...
Das heisst, da der User zwar Authorisiert und gefiltert wird, aber kein Hardwareobject zur Verfügung steht, wird der Computerteil ignoriert. Es gibt zwar nun den Loopbackverarbeitungsmodus in der GPO unter der Computerkonfiguration wo ich nun "Merge" einstellen könnte aber dieser Teil wird ja ignoriert.
Die GPO ist zwar mit der OU verknüpft wo die Hardware ist, aber durch das , das die GPO 2 Gruppen hat, sollen auch nur die Laptops mit den Usern der GPO aktiv sein.
Das gibt es in den Usersettings ja nicht ?
Ziel ist nun , das der Computerteil wie oben beschrieben auch ausgeführt wird.
Gruss
Ralf
das Problem ist, wir haben eine Domäne und eine Childdomäne.
Die User sind in der childdomäne und Computerobjekte in der Domäne.
Die Verlinkte GPO ist in der Domäne OU Notebook.
Computerobjekte befinden sich auch dort
Die verlinkte GPO hat 2 Gruppen. 1 Gruppe aus Domäne und 1 Gruppe aus Childdomäne.
Ich trage mich nun in eine der Gruppen ein. Nun kommt aber wenn ich Gpresult mache in den Computersettings
Security Filtering not Applied.
Der Userteil wird aber ausgeführt.
Zuerst dache ich : (Auszug aus einer alten Frage hier
Ein Satz heisst : That's not how GPO filtering works. GPO's don't process against security groups, they process against users and computers. Security Filtering allows you to "scope" the GPO so that it applies only to users who are members of the security group in your filter. You need to link the GPO to the OU where the user objects are and then the security filter applies the GPO to only members of that security Group
Nun habe ich mal die GPO auf die Root gesetzt, das im ganzen AD Sie aktiv ist. Den User Administrator in eine ganz andere OU getan "Pflege" und die Gruppe Verwaltung in die "Verwaltung" und es geht !
Es muss in dem Fall nicht immer der User genau in der OU sein , wo auch die Gruppe ist. Wichtig ist, das die GPO die wohl findet ! Sonst müsste ich immer die User genau im jeweiligen Bereich erstellen.
Kurz gesagt heisst das:
Die GPO muss in dem Bereich aktiv sein, das User auch gefunden werden, um dann die Gruppe als Filter nutzen zu können.
Da aber nun der Userteil ausgeührt wird. Trifft das ja nicht ganz zu, und das Filtering ist aktiv ! Die Frage ist nun, warum wird der Computerteil verweigert ?
Hat wer ne Idee , warum der Computerteil nicht ausgeführt wird ?
Zum testen ob der Teil tut habe ich mal einen PC in die Policy direct getan:
Die geht, weil ja Policy direct auf OU geht.
Aber das ist ja falsch , nur die Leute der Gruppe den Computerteil bekommen sollen.
Was kann getan werden, das der Computerteil der Policy auch ausgeführt wird ?
Für mich heisst das, das der Computerteil Ignoriert wird, da die GPO Richtlinie keine Hardware als Filter hat !
http://www.gruppenrichtlinien.de/artikel/loopbackverarbeitungsmodus-loo ...
Auszug auf Gruppenrichtlinien.de:
Ich muss die Richtlinie irgendwie auf das Computerkonto anwenden? Aber der Computer ignoriert den Anteil der Benutzerkonfiguration einer Richtlinie, da er ja schliesslich ein Computerobjekt ist und kein Benutzer. Ebenfalls, ist dem anmeldenden Benutzer die Benutzerkonfiguration einer Richtlinien auf dem Computerobjekt egal, da der Benutzer die Computerkonfiguration garnicht liest, und damit am Ende die Richtlinie, nicht übernehmen kann. Es kommt noch hinzu, daß der Benutzer meistens nicht in der OU des Computers steht...
Das heisst, da der User zwar Authorisiert und gefiltert wird, aber kein Hardwareobject zur Verfügung steht, wird der Computerteil ignoriert. Es gibt zwar nun den Loopbackverarbeitungsmodus in der GPO unter der Computerkonfiguration wo ich nun "Merge" einstellen könnte aber dieser Teil wird ja ignoriert.
Die GPO ist zwar mit der OU verknüpft wo die Hardware ist, aber durch das , das die GPO 2 Gruppen hat, sollen auch nur die Laptops mit den Usern der GPO aktiv sein.
Das gibt es in den Usersettings ja nicht ?
Ziel ist nun , das der Computerteil wie oben beschrieben auch ausgeführt wird.
Gruss
Ralf
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 229278
Url: https://administrator.de/contentid/229278
Ausgedruckt am: 22.11.2024 um 17:11 Uhr
21 Kommentare
Neuester Kommentar
Hi,
also wenn Du das meinst, was ich denke, dass Du es meinst, dann bist Du auf dem Holzweg.
Erstmal: Was ist für Dich "Computerteil"? Der Teil einer GPO, der für Computer gilt oder etwa der Benutzer-Teil einer GPO, die der Benutzer nicht direkt über das Benutzer-Objekt sondern über das Computer-Objekt "erbt" (Loopback)?
Falls ersteres: Eine GPO-Einstellung für Computer kann niemals(!) abhängig vom Benutzer und dessen Gruppenmitgliedschaften angewendet werden.
Falls letzteres: Schau Dir mal das Prinzip der Loopback-Verarbeitung von GPO's an.
E.
also wenn Du das meinst, was ich denke, dass Du es meinst, dann bist Du auf dem Holzweg.
Erstmal: Was ist für Dich "Computerteil"? Der Teil einer GPO, der für Computer gilt oder etwa der Benutzer-Teil einer GPO, die der Benutzer nicht direkt über das Benutzer-Objekt sondern über das Computer-Objekt "erbt" (Loopback)?
Falls ersteres: Eine GPO-Einstellung für Computer kann niemals(!) abhängig vom Benutzer und dessen Gruppenmitgliedschaften angewendet werden.
Falls letzteres: Schau Dir mal das Prinzip der Loopback-Verarbeitung von GPO's an.
E.
Hi Ralf,
bitte nichts für ungut, aber schon allein Dein erster Text liest sich ziemlich wirr, sorry. Und lässt mich echt daran zweifeln, ob Du das mit den GPO's überhaupt überblickst.
Ich versuche es mal trotzdem.
1. Ich hoffe, Du machst beim Testen nicht den üblichen Fehler: Schnell mal in eine Gruppe packen (oder raus nehmen) und gleich wieder testen - uups geht nicht. - Natürlich nicht: Mitgliedschaften in Sicherheitsgruppen werden erst bei Neuanmeldung neu eingelesen. Also wenn Du sowas testest, dann nach dem Ändern der Gruppenmitgliedschaft den Benutzer neu anmelden. Gpupdate allein reicht da nicht.
2. Richtig: Das Wort "Gruppe" in "Gruppenrichtlinie" hat nichts mit Gruppen im ADS zu tun. Hier ist eher gemeint: "eine Gruppe von Richtlinien".
3. Es ist vollkommen irrelevant, aus welcher Domäne eine GPO kommt. Damit eine GPO überhaupt für einen Benutzer wirken kann, muss der Benutzer zwei Rechte auf diese GPO haben: "Lesen" und "GPO anwenden". Gleiches gilt für Computer. Eine GPO "hat" keine Gruppen. Es stehen nur Benutzer-, Computer- und/oder Gruppen-Objekte mit bestimmten Rechten in der ACL des GPO-Objekts.
4. Der GPO-Ergebnissatz wird berechnet, indem ausgehend vom Computer- oder Benutzer-Objekt im ADS-Verzeichnisbaum die OU's aufwärts bis zur Domäne abgefragt werden, welche GPO's dort verlinkt sind, die der Benutzer/Computer anwenden darf. Natürlich auch die an der Donmäne verlinkten GPO's. Zuletzt dann noch die am Standort verlinkten. Ist "auf dem Weg nach oben" eine OU dabei, bei welcher die GPO-Vererbung ausgeschaltet ist, dann hört die Abfrage dort auf. Aber die Standort-GPO's werden dann trotzdem noch angewendet.
5. Loopback: Eine Einstellung für Computer. Sie ändert das Verhalten des Gruppenrichtlinien-Clients auf diesem Computer, wenn er GPO's für den Benutzer abfragt. Standardmäßig fragt dieser die GPO's wie unter 4. beschrieben ab. Wenn Loopback aktiviert ist, dann gibt es zwei Möglichkeiten:
"Ersetzen" - Hier fragt der GPO-Client die GPO's für den Benutzer ab, geht dabei aber nicht den Pfad vom Benutzer-Objekt "nach oben" sondern den des Computers.
"Zusammenführen" - Hier fragt der GPO-Client die GPO's für den Benutzer sowohl über den Pfad des Benutzers als auch über den Pfad des Computers ab und wendet beide Ergebnisse an.
Damit ist auch klar: Eine der grössten Enten, die ich immer wieder zu hören bekomme, ist, dass man das Loopback in jeder betreffenden GPO festlegen muss. --> FALSCH!
6. Die abgefragten GPO (egal ob mit oder ohne Loopback) werden alle solange "gleichberechtigt" angewendet, wie sich einzelne Einstellungen in diesen GPO's nicht widersprechen. Sollten sich einzelne Einstellungen widersprechen, dann gilt jene aus der höchstpriorisierten GPO. Die Priorität einer GPO ergibt sich aus der Verlinkung im Verzeichnisbaum. Die abgefragten GPO (egal ob mit oder ohne Loopback) werden "von oben nach unten", also Standort->Domäne (falls nicht Vererbung blockiert)->OU (falls nicht Vererbung blockiert)->OU->OU, ausgelesen und in den Richtlinien-Ergebnissatz geschrieben. Wenn mehrere Richtlinien dieselbe Einstellung reinschreiben, dann gewinnt jene, welche zuletzt schreibt. Ausnahme: Man kann eine GPO erzwingen ("no override"). Eine Einstellung, welche aus einer erzwungenen GPO in den Richtlinien-Ergebnissatz geschrieben wird, kann von höherpriorisierten GPO nicht wieder überschrieben werden, auch nicht wenn die höherpriorisierten ebenfalls erzwungen werden sollten. Andere Einstellungen einer höherpriosisierten GPO, welche nicht mit erzwungenen GPO kollidieren, werden dann aber trotzdem übernommen. Mal abgesehen von der Erzwingung könnte man also pauschal sagen: Je "weiter unten" eine GPO verlinkt ist, desto größer ihre Priorität. Wenn Du also eine GPO an die Root hängst, und in keiner OU die Vererbung deaktiviert ist, dann wird sie also immer angewendet, egal ob mit oder ohne Loopback und auch egal ob einzelne Einstellungen von höherpriorisierten GPOs überschrieben werden. (und Benutzer wie Computer sind in der selben Domäne)
Wenn Du erreichen willst, dass eine GPO für einen Benutzer immer gilt, egal an welchem Computer im Forest er sich anmeldet, dann muss die GPO irgendwo an einer OU im Pfad des Benutzer-Objekts, an der Domäne des Benutzers oder am Standort, wo sich der Benutzer anmeldet, verlinkt sein. Und an den Computern darf nicht Loopback mit "ersetzen" aktiviert sein. Und der Benutzer muss über die oben genannten Berechtigungen für diese GPO verfügen, egal ob direkt erteilt, oder über eine Sicherheitsgruppe oder einer der berechneten Gruppen, wie "Jeder", "Interaktiv" oder ähnlich. Und es ist egal, in welcher Domäne die GPO gespeichert ist. Der GPO-Client muss nur Zugriff auf einen DC jener Domäne haben um von dort die GPO einlesen zu könnnen.
Wenn Du erreichen willst, dass eine GPO für einen Benutzer nur an bestimmten Computern gilt, dann muss die GPO irgendwo an einer OU im Pfad des Computer-Objekts, an der Domäne des Computers oder am Standort, wo sich der Benutzer anmeldet, verlinkt sein. Und an den Computern muss Loopback aktiviert sein, egal welcher Modus. Und die Berechtigungen.
Wenn Du erreichen willst, dass bei Anmeldung an einem bestimmten Computer nur die Richtlinien gelten sollen, welche explizit für diesen Computer (oder einer Gruppe von solchen) gedacht sind, und nicht jene, welche für den Benutzer sonst gedacht sind, dann muss die GPO irgendwo an einer OU im Pfad des Computer-Objekts, an der Domäne des Computers oder am Standort, wo sich der Benutzer anmeldet, verlinkt sein. Und an den Computern muss Loopback mit "ersetzen" aktiviert sein.
Ein Hinweis noch: Falls Du mit Loopback arbeiten willst, und die Benutzer servergespeicherte Benutzerprofile haben, dann musst Du beachten, dass Einstellungen, welche über GPOs verteilt werden, im Benutzerprofil gespeichert werden und deshalb auch dann noch gelten, wenn das Profil geladen wird und die GPO garade nicht gilt.
Beispiel: Benutzer darf generell nicht ins Internet, bekommt per GPO keinen Proxy eingetragen und auch keinen Zugriff auf die IE-Einstellungen. Nur wenn er an einem bestimmten PC arbeitet bekommt er einen Proxy eingetragen. Wenn er jetzt ein Roaming-Profile hat und sich wieder an einem "anderen" PC anmeldet, dann hat er immer noch den Proxy eingetragen! Lösen kannst Du das nur, wenn Du entweder dafür sorgst, dann an dem Internet-PC kein oder ein anderes Roaming-Profile gilt oder am "anderen" PC eine explizite "Gegenrichtlinie" wirkt.
Hilft Dir das weiter?
E.
bitte nichts für ungut, aber schon allein Dein erster Text liest sich ziemlich wirr, sorry. Und lässt mich echt daran zweifeln, ob Du das mit den GPO's überhaupt überblickst.
Ich versuche es mal trotzdem.
1. Ich hoffe, Du machst beim Testen nicht den üblichen Fehler: Schnell mal in eine Gruppe packen (oder raus nehmen) und gleich wieder testen - uups geht nicht. - Natürlich nicht: Mitgliedschaften in Sicherheitsgruppen werden erst bei Neuanmeldung neu eingelesen. Also wenn Du sowas testest, dann nach dem Ändern der Gruppenmitgliedschaft den Benutzer neu anmelden. Gpupdate allein reicht da nicht.
2. Richtig: Das Wort "Gruppe" in "Gruppenrichtlinie" hat nichts mit Gruppen im ADS zu tun. Hier ist eher gemeint: "eine Gruppe von Richtlinien".
3. Es ist vollkommen irrelevant, aus welcher Domäne eine GPO kommt. Damit eine GPO überhaupt für einen Benutzer wirken kann, muss der Benutzer zwei Rechte auf diese GPO haben: "Lesen" und "GPO anwenden". Gleiches gilt für Computer. Eine GPO "hat" keine Gruppen. Es stehen nur Benutzer-, Computer- und/oder Gruppen-Objekte mit bestimmten Rechten in der ACL des GPO-Objekts.
4. Der GPO-Ergebnissatz wird berechnet, indem ausgehend vom Computer- oder Benutzer-Objekt im ADS-Verzeichnisbaum die OU's aufwärts bis zur Domäne abgefragt werden, welche GPO's dort verlinkt sind, die der Benutzer/Computer anwenden darf. Natürlich auch die an der Donmäne verlinkten GPO's. Zuletzt dann noch die am Standort verlinkten. Ist "auf dem Weg nach oben" eine OU dabei, bei welcher die GPO-Vererbung ausgeschaltet ist, dann hört die Abfrage dort auf. Aber die Standort-GPO's werden dann trotzdem noch angewendet.
5. Loopback: Eine Einstellung für Computer. Sie ändert das Verhalten des Gruppenrichtlinien-Clients auf diesem Computer, wenn er GPO's für den Benutzer abfragt. Standardmäßig fragt dieser die GPO's wie unter 4. beschrieben ab. Wenn Loopback aktiviert ist, dann gibt es zwei Möglichkeiten:
"Ersetzen" - Hier fragt der GPO-Client die GPO's für den Benutzer ab, geht dabei aber nicht den Pfad vom Benutzer-Objekt "nach oben" sondern den des Computers.
"Zusammenführen" - Hier fragt der GPO-Client die GPO's für den Benutzer sowohl über den Pfad des Benutzers als auch über den Pfad des Computers ab und wendet beide Ergebnisse an.
Damit ist auch klar: Eine der grössten Enten, die ich immer wieder zu hören bekomme, ist, dass man das Loopback in jeder betreffenden GPO festlegen muss. --> FALSCH!
6. Die abgefragten GPO (egal ob mit oder ohne Loopback) werden alle solange "gleichberechtigt" angewendet, wie sich einzelne Einstellungen in diesen GPO's nicht widersprechen. Sollten sich einzelne Einstellungen widersprechen, dann gilt jene aus der höchstpriorisierten GPO. Die Priorität einer GPO ergibt sich aus der Verlinkung im Verzeichnisbaum. Die abgefragten GPO (egal ob mit oder ohne Loopback) werden "von oben nach unten", also Standort->Domäne (falls nicht Vererbung blockiert)->OU (falls nicht Vererbung blockiert)->OU->OU, ausgelesen und in den Richtlinien-Ergebnissatz geschrieben. Wenn mehrere Richtlinien dieselbe Einstellung reinschreiben, dann gewinnt jene, welche zuletzt schreibt. Ausnahme: Man kann eine GPO erzwingen ("no override"). Eine Einstellung, welche aus einer erzwungenen GPO in den Richtlinien-Ergebnissatz geschrieben wird, kann von höherpriorisierten GPO nicht wieder überschrieben werden, auch nicht wenn die höherpriorisierten ebenfalls erzwungen werden sollten. Andere Einstellungen einer höherpriosisierten GPO, welche nicht mit erzwungenen GPO kollidieren, werden dann aber trotzdem übernommen. Mal abgesehen von der Erzwingung könnte man also pauschal sagen: Je "weiter unten" eine GPO verlinkt ist, desto größer ihre Priorität. Wenn Du also eine GPO an die Root hängst, und in keiner OU die Vererbung deaktiviert ist, dann wird sie also immer angewendet, egal ob mit oder ohne Loopback und auch egal ob einzelne Einstellungen von höherpriorisierten GPOs überschrieben werden. (und Benutzer wie Computer sind in der selben Domäne)
Wenn Du erreichen willst, dass eine GPO für einen Benutzer immer gilt, egal an welchem Computer im Forest er sich anmeldet, dann muss die GPO irgendwo an einer OU im Pfad des Benutzer-Objekts, an der Domäne des Benutzers oder am Standort, wo sich der Benutzer anmeldet, verlinkt sein. Und an den Computern darf nicht Loopback mit "ersetzen" aktiviert sein. Und der Benutzer muss über die oben genannten Berechtigungen für diese GPO verfügen, egal ob direkt erteilt, oder über eine Sicherheitsgruppe oder einer der berechneten Gruppen, wie "Jeder", "Interaktiv" oder ähnlich. Und es ist egal, in welcher Domäne die GPO gespeichert ist. Der GPO-Client muss nur Zugriff auf einen DC jener Domäne haben um von dort die GPO einlesen zu könnnen.
Wenn Du erreichen willst, dass eine GPO für einen Benutzer nur an bestimmten Computern gilt, dann muss die GPO irgendwo an einer OU im Pfad des Computer-Objekts, an der Domäne des Computers oder am Standort, wo sich der Benutzer anmeldet, verlinkt sein. Und an den Computern muss Loopback aktiviert sein, egal welcher Modus. Und die Berechtigungen.
Wenn Du erreichen willst, dass bei Anmeldung an einem bestimmten Computer nur die Richtlinien gelten sollen, welche explizit für diesen Computer (oder einer Gruppe von solchen) gedacht sind, und nicht jene, welche für den Benutzer sonst gedacht sind, dann muss die GPO irgendwo an einer OU im Pfad des Computer-Objekts, an der Domäne des Computers oder am Standort, wo sich der Benutzer anmeldet, verlinkt sein. Und an den Computern muss Loopback mit "ersetzen" aktiviert sein.
Ein Hinweis noch: Falls Du mit Loopback arbeiten willst, und die Benutzer servergespeicherte Benutzerprofile haben, dann musst Du beachten, dass Einstellungen, welche über GPOs verteilt werden, im Benutzerprofil gespeichert werden und deshalb auch dann noch gelten, wenn das Profil geladen wird und die GPO garade nicht gilt.
Beispiel: Benutzer darf generell nicht ins Internet, bekommt per GPO keinen Proxy eingetragen und auch keinen Zugriff auf die IE-Einstellungen. Nur wenn er an einem bestimmten PC arbeitet bekommt er einen Proxy eingetragen. Wenn er jetzt ein Roaming-Profile hat und sich wieder an einem "anderen" PC anmeldet, dann hat er immer noch den Proxy eingetragen! Lösen kannst Du das nur, wenn Du entweder dafür sorgst, dann an dem Internet-PC kein oder ein anderes Roaming-Profile gilt oder am "anderen" PC eine explizite "Gegenrichtlinie" wirkt.
Hilft Dir das weiter?
E.
Also der Computer wendet die für ihn gedachten Richtlinien nicht an?
Betrachte das bitte so: Auch wenn in nur einer GPO immer beide Bereiche existieren ("Computerkonfiguration" und "Benutzerkonfiguration") so bekommen doch beide Konten (der Computer selbst sowie der/die Benutzer des Computers) unabhängig voneinander vom GPO-Client den Ergebnissatz berechnet. Das bedeutet also, dass Du das Computerkonto unabhängig vom Benutzerkonto für die GPO berechtigen musst.
Wenn Du also eine GPO hast, bei der Du in der Sicherheitsfilterung die "Authentifizierten Benutzer" rausgenommen und statt dessen zwei Gruppen eingetragen hast, dann muss das Computerkonto selbst in mindestens einer dieser Gruppen sein, um die GPO anwenden zu können.
Ich kann es sowieso nur jedem empfehlen, Richtlinien für Computer und Benutzer klar zu trennen und in jeweils getrennte GPO zu legen. Optimalerweise dann zusätzlich jeweils den nicht benötigten Bereich deaktivieren. Und im Namen der CPO einen klaren Hinweis, ob es eine GPO für Computer oder für Benutzer ist. Ich habe die Erfahrung gemacht, dass damit unsere Admins auch bei beim Troubleshooting besser zurecht kommen.
Noch mal der Hinweis: Du kannst mit GPO nicht erreichen, dass bestimmte Einstellungen aus der "Computerkonfiguration" einer GPO nur abhängig vom sich anmeldenden Benutzer angewendet werden. Umgekehrt geht das, entweder mit Loopback oder mit WMI-Filter.
E.
Betrachte das bitte so: Auch wenn in nur einer GPO immer beide Bereiche existieren ("Computerkonfiguration" und "Benutzerkonfiguration") so bekommen doch beide Konten (der Computer selbst sowie der/die Benutzer des Computers) unabhängig voneinander vom GPO-Client den Ergebnissatz berechnet. Das bedeutet also, dass Du das Computerkonto unabhängig vom Benutzerkonto für die GPO berechtigen musst.
Wenn Du also eine GPO hast, bei der Du in der Sicherheitsfilterung die "Authentifizierten Benutzer" rausgenommen und statt dessen zwei Gruppen eingetragen hast, dann muss das Computerkonto selbst in mindestens einer dieser Gruppen sein, um die GPO anwenden zu können.
Ich kann es sowieso nur jedem empfehlen, Richtlinien für Computer und Benutzer klar zu trennen und in jeweils getrennte GPO zu legen. Optimalerweise dann zusätzlich jeweils den nicht benötigten Bereich deaktivieren. Und im Namen der CPO einen klaren Hinweis, ob es eine GPO für Computer oder für Benutzer ist. Ich habe die Erfahrung gemacht, dass damit unsere Admins auch bei beim Troubleshooting besser zurecht kommen.
Noch mal der Hinweis: Du kannst mit GPO nicht erreichen, dass bestimmte Einstellungen aus der "Computerkonfiguration" einer GPO nur abhängig vom sich anmeldenden Benutzer angewendet werden. Umgekehrt geht das, entweder mit Loopback oder mit WMI-Filter.
E.
Hi Ralf,
ich verstehe immer noch nicht ganz! Was meinst Du mit "Computerteil"? Den Bereich "Computerkonfiguration"?
Du schreibst: "Aber das ist ja falsch , nur die Leute der Gruppe den Computerteil bekommen sollen."
Hier habe ich schon geschrieben, dass das nicht geht, dass Einstellungen aus der "Computerkonfiguration" abhängig vom Benutzer angewendet werden.
Aber ja, Du hast recht: Wenn der Computer direkt für die GPO berechtigt ist, und die GPO sonst nicht gefiltert wird (nicht im AD-Pfad des Computers, Vererbung blockiert, WMI-Filter, Computerkonfiguration in der GPO deaktiviert), dann muss der Client sie anwenden.
Um was für Einstellungen aus der "Computerkonfiguration" geht es denn genau? Manche wirken nur beim Booten.
E.
ich verstehe immer noch nicht ganz! Was meinst Du mit "Computerteil"? Den Bereich "Computerkonfiguration"?
Du schreibst: "Aber das ist ja falsch , nur die Leute der Gruppe den Computerteil bekommen sollen."
Hier habe ich schon geschrieben, dass das nicht geht, dass Einstellungen aus der "Computerkonfiguration" abhängig vom Benutzer angewendet werden.
Aber ja, Du hast recht: Wenn der Computer direkt für die GPO berechtigt ist, und die GPO sonst nicht gefiltert wird (nicht im AD-Pfad des Computers, Vererbung blockiert, WMI-Filter, Computerkonfiguration in der GPO deaktiviert), dann muss der Client sie anwenden.
Um was für Einstellungen aus der "Computerkonfiguration" geht es denn genau? Manche wirken nur beim Booten.
E.
Ich grab das hier mal aus
Hab so etwa die gleichen Noob-Probs.
Hier ist ein 2012R2 im Einsatz mit einigen Win8.1x64 Clients.
GPOs sehen so aus:
User-GPO's:
Schüler
Lehrer
Verwaltung
Client-GPOs:
Clients-Bibliothek
Clients-Surfstations
Clients-Lehrer
Clients-Verwaltung
Soo ich habe bei den User-GPOs ganz einfache Regeln.
Nehmen wir z.B. die Schüler-GPO welche im gleichen Ordner wie die Schüler Accounts liegt. Hier habe ich unter "User Configuration" fixe Netzlaufwerke oder Einschränkungen in den Rechten.
Wenn nun ein Schüler sich an einem Client in der Bibliothek anmeldet, soll zusätzlich die GPO "Clients-Bibliothek" greifen und den Drucker in der Bibliothek zuweisen. Bei Login an "Clients-Surfstations" soll natürlich ein anderer geladen werden.
Habe jeweils in jeder GPO Loopback mit merge aktiviert aber die Client-GPO's greifen einfach nicht.
An was kann das liegen? Soll ich das ganze am besten mit Scripts lösen?
Danke schonmal
Hab so etwa die gleichen Noob-Probs.
Hier ist ein 2012R2 im Einsatz mit einigen Win8.1x64 Clients.
GPOs sehen so aus:
User-GPO's:
Schüler
Lehrer
Verwaltung
Client-GPOs:
Clients-Bibliothek
Clients-Surfstations
Clients-Lehrer
Clients-Verwaltung
Soo ich habe bei den User-GPOs ganz einfache Regeln.
Nehmen wir z.B. die Schüler-GPO welche im gleichen Ordner wie die Schüler Accounts liegt. Hier habe ich unter "User Configuration" fixe Netzlaufwerke oder Einschränkungen in den Rechten.
Wenn nun ein Schüler sich an einem Client in der Bibliothek anmeldet, soll zusätzlich die GPO "Clients-Bibliothek" greifen und den Drucker in der Bibliothek zuweisen. Bei Login an "Clients-Surfstations" soll natürlich ein anderer geladen werden.
Habe jeweils in jeder GPO Loopback mit merge aktiviert aber die Client-GPO's greifen einfach nicht.
An was kann das liegen? Soll ich das ganze am besten mit Scripts lösen?
Danke schonmal
@br00tal
Für Deinen Fall brauchst Du kein Loopback. Also in allen GPO's zunächst das Loopback wieder deaktivieren. Nicht einfach rausnehmen (nicht konfiguriert)! Damit würde es aktiviert bleiben. Sondern explizit auf "deaktiviert" setzen und die GPO auf allen Computern anwenden lassen.
Dann in der "Schüler" GPO mit den Gruppenrichtlinien-Erweiterungen die Drucker verbinden und dort jeweils über die "Zielgruppenaddressierung" die Wirksamkeit dieser einen Einstellungen auf bestimmte Clients einschränken.
E.
Habe jeweils in jeder GPO Loopback mit merge aktiviert aber die Client-GPO's greifen einfach nicht.
Wenn Du meinen Text gelesen hättest, dann wüsstest Du bereits, dass es Unsinn ist, in jeder GPO "Loopback" zu konfigurieren. "Loopback" ist keine Einstellung einer GPO sondern die eines Computer, welche man diesem per GPO verpassen kann.Für Deinen Fall brauchst Du kein Loopback. Also in allen GPO's zunächst das Loopback wieder deaktivieren. Nicht einfach rausnehmen (nicht konfiguriert)! Damit würde es aktiviert bleiben. Sondern explizit auf "deaktiviert" setzen und die GPO auf allen Computern anwenden lassen.
Dann in der "Schüler" GPO mit den Gruppenrichtlinien-Erweiterungen die Drucker verbinden und dort jeweils über die "Zielgruppenaddressierung" die Wirksamkeit dieser einen Einstellungen auf bestimmte Clients einschränken.
E.
Oke danke für die schnelle Antwort
In dem Fall benötige ich die Client-GPO's eigentlich garnicht mehr oder? Richte jetzt einfach zb in jeder User-GPO jeden Drucker ein und gebe dann jedem Drucker per Item-Level-Targeting die Computer an auf die der Drucker angewendet werden soll. Hoffe das stimmt so halbwegs
In dem Fall benötige ich die Client-GPO's eigentlich garnicht mehr oder? Richte jetzt einfach zb in jeder User-GPO jeden Drucker ein und gebe dann jedem Drucker per Item-Level-Targeting die Computer an auf die der Drucker angewendet werden soll. Hoffe das stimmt so halbwegs
Aber wenn die Client-GPO eh garnicht mehr da ist, wird doch eh nicht versucht noch was zu mergen oder?
Ich stehe aber allgemein an:
Ich habe jetzt nur noch die User-GPO's Schüler, Lehrer und Verwaltung.
Wenn ich jetzt in der GPO Schüler alle Drucker angebe die verbunden werden sollen und in jedem Drucker in der Eigenschaft Item-level-Targeting die bestimmten Clients angebe auf denen diese verbunden werden sollen, werden trotzdem überall alle verbunden.
Ich stehe aber allgemein an:
Ich habe jetzt nur noch die User-GPO's Schüler, Lehrer und Verwaltung.
Wenn ich jetzt in der GPO Schüler alle Drucker angebe die verbunden werden sollen und in jedem Drucker in der Eigenschaft Item-level-Targeting die bestimmten Clients angebe auf denen diese verbunden werden sollen, werden trotzdem überall alle verbunden.
Aber wenn die Client-GPO eh garnicht mehr da ist, wird doch eh nicht versucht noch was zu mergen oder?
Ja heute vielleicht nicht mehr. Aber in einem halben Jahr, wenn man sich nicht mehr daran erinnert, dann fällt einem wohlmöglich auf die Füße, dass die Clients noch im Loopback-Modus sind. Mach was du willst, mehr als warnen kann ich nicht.Ich stehe aber allgemein an:
Ich nehme an, Du meinst "stebe" ?Wenn ich jetzt in der GPO Schüler alle Drucker angebe die verbunden werden sollen und in jedem Drucker in der Eigenschaft Item-level-Targeting die bestimmten Clients angebe auf denen diese verbunden werden sollen, werden trotzdem überall alle verbunden.
Na dann haste wohl was falsch gemacht. Ohne jetzt genau zu wissen, was Du das wo und wie konkret konfiguriert hast, kann ich da nichts weiter zu sagen.
Ja da habe ich wohl ein bisschen wenig Infos mitgeliefert sorry.
Also ich hab jetzt alle Policies rausgehauen um mal einfach sauber die Drucker-GPO's reinzu bekommen.
Ausgangspunkt: Jeder Schüler hat einen Acc in der OU "Schueler". Wenn sich einer dieser Schüler im EDV-Raum einloggt, soll er den Drucker EDV-Raum bekommen. Wenn er sich in der Bibliothek einloggt soll nur der Drucker-Bibliothek gemappt werden.
Jetzt hab ichs so eingerichtet:
Ich hab jetzt nur noch die GPO "Schüler" im User-Ordner Schüler gelinkt in dem alle Schüler-Accounts liegen. Hier habe ich unter User-Configuration einfach alle Drucker eingerichtet also "Drucker EDV-Raum" und "Drucker Bibliothek" .
Dann beim Item-Level-Targeting beim "Drucker EDV-Raum" die Computer im EDV-Raum angegeben und beim "Drucker Bibliothek" die Computer in der Bibliothek angegeben.
Jetzt habe ich im Fenster "Security Filtering" dieser GPO noch zusätzlich zu den Gruppen die ich schon drin habe, jeden einzelnen Computer im EDV-Raum sowie der Bibliothek angegeben. (Sonst zieht die GPO bei diesen CLients nicht oder?)
Zusätzlich habe ich auf dem Print-Server im Printer-Management bei beiden Druckern per "Deploy to GPO" die GPO "Schueler" angegeben.
Müsste so passen oder? Danke übrigens für die schnelle Hilfe ;)
Also ich hab jetzt alle Policies rausgehauen um mal einfach sauber die Drucker-GPO's reinzu bekommen.
Ausgangspunkt: Jeder Schüler hat einen Acc in der OU "Schueler". Wenn sich einer dieser Schüler im EDV-Raum einloggt, soll er den Drucker EDV-Raum bekommen. Wenn er sich in der Bibliothek einloggt soll nur der Drucker-Bibliothek gemappt werden.
Jetzt hab ichs so eingerichtet:
Ich hab jetzt nur noch die GPO "Schüler" im User-Ordner Schüler gelinkt in dem alle Schüler-Accounts liegen. Hier habe ich unter User-Configuration einfach alle Drucker eingerichtet also "Drucker EDV-Raum" und "Drucker Bibliothek" .
Dann beim Item-Level-Targeting beim "Drucker EDV-Raum" die Computer im EDV-Raum angegeben und beim "Drucker Bibliothek" die Computer in der Bibliothek angegeben.
Jetzt habe ich im Fenster "Security Filtering" dieser GPO noch zusätzlich zu den Gruppen die ich schon drin habe, jeden einzelnen Computer im EDV-Raum sowie der Bibliothek angegeben. (Sonst zieht die GPO bei diesen CLients nicht oder?)
Zusätzlich habe ich auf dem Print-Server im Printer-Management bei beiden Druckern per "Deploy to GPO" die GPO "Schueler" angegeben.
Müsste so passen oder? Danke übrigens für die schnelle Hilfe ;)
Hallo nochmal.. Also ich glaub ich hab das Problem. Vorher war ein 2003er als DC im Einsatz welcher von einem 2012R2 abgelöst wurde. Jedoch laufen noch beide auf Sync und wenn ich jetzt GPO's am 2012er angebe, werden die meisten davon vom 2003er nicht richtig übernommen bzw garnicht weil viele dieser GPO's zu neu sind für den. Werde mich darum kümmern dass der alte komplett abgeschaltet wird und melde mich dann nochmal.
Hallo nochmal.. Also ich glaub ich hab das Problem. Vorher war ein 2003er als DC im Einsatz welcher von einem 2012R2 abgelöst
wurde. Jedoch laufen noch beide auf Sync und wenn ich jetzt GPO's am 2012er angebe, werden die meisten davon vom 2003er nicht
richtig übernommen bzw garnicht weil viele dieser GPO's zu neu sind für den. Werde mich darum kümmern dass der
alte komplett abgeschaltet wird und melde mich dann nochmal.
Nee, der Zusammanhang so ist falsch.wurde. Jedoch laufen noch beide auf Sync und wenn ich jetzt GPO's am 2012er angebe, werden die meisten davon vom 2003er nicht
richtig übernommen bzw garnicht weil viele dieser GPO's zu neu sind für den. Werde mich darum kümmern dass der
alte komplett abgeschaltet wird und melde mich dann nochmal.
Also erstens wiederhole ich meine Empfehlung, das Loopback auf allen Clients, wo Du es nicht wirklich brauchst, explizit wieder zu deaktivieren. Das Löschen der GPO, welche es aktiviert hat, allein reicht nicht!
Zweitens: Wie Du selbst schreibst, hast Du die Drucker unter "User-Configuration" konfiguriert. So eine Richtlinine wird gar nicht von Clients angewendet sondern von Benutzern. Der Client (genauer: Der Dienst "Gruppenrichtlinienclient") ist maximal dafür zuständig, die GPO für den Benutzer einzusammeln.
Ob und welche GPO's angewendet werden, siehst Du am einfachsten, wenn Du unter der Anmeldung des Benutzers in der Eingabeaufforderung (CMD) den Befehl
gpresult /R
Natürlich kann auch eine gestörte Replikation zwischen den DC's zu Problemen bei derAnwendung von GPO's führen. z.B.
- neue erstellte GPO's werden nicht angewendet
- geänderte Einstellungen in vorhandenen GPO's werden nicht übernommen
- gelöschte oder deaktivierte GPO werden weiterhin angewendet
Das kan man mit relativ einfachen Mitteln überprüfen:
- Eventlogs "Verzeichnisdienst" und ggf. "DFS-Replikation" der DC's prüfen
- die MMC zur Gruppenrichtlinienverwaltung explizit mit einem bestimmten DC verbinden und prüfen, ob er bei den GPO's die gewünschten Einstellungen aufweist. Wenn da verschiedene DC's verschiedene GPO-Einstellungen liefern, dann hat man da ein Problem in der Replikation
E.
Ok inzwischen läuft das meiste.
Ich habe aber noch ein, zwei Punkte.
Und zwar habe ich eine Computer-GPO die auf alle Clients greift.
Hierbei geht es um das Startscreen-Layout des Metro.
Alle sollen eine bestimmte .xml kriegen die sie auch bekommen.
Jetzt hab ich aber darunter nochmal einen Ordner mit VDI-Clients bei denen die gleiche GPO gesetzt werden soll aber mit einer anderen xml File.
Gesagt getan aber die bekommen immer noch die xml die sie nicht bekommen sollten
Wie du ja bereits erwähnt hast, ist Loopback nicht so intelligent. Wie löse ich das am besten? Muss ich die GPO unter VDI als Erzwungen setzen?
Und wie entferne ich den Windows Store? Bzw wie kann ich komplett deaktivieren dass Apps gestartet werden sollen?
Mit freundlichen Grüßen und danke schonmal
Ich habe aber noch ein, zwei Punkte.
Und zwar habe ich eine Computer-GPO die auf alle Clients greift.
Hierbei geht es um das Startscreen-Layout des Metro.
Alle sollen eine bestimmte .xml kriegen die sie auch bekommen.
Jetzt hab ich aber darunter nochmal einen Ordner mit VDI-Clients bei denen die gleiche GPO gesetzt werden soll aber mit einer anderen xml File.
Gesagt getan aber die bekommen immer noch die xml die sie nicht bekommen sollten
Wie du ja bereits erwähnt hast, ist Loopback nicht so intelligent. Wie löse ich das am besten? Muss ich die GPO unter VDI als Erzwungen setzen?
Und wie entferne ich den Windows Store? Bzw wie kann ich komplett deaktivieren dass Apps gestartet werden sollen?
Mit freundlichen Grüßen und danke schonmal
Wie du ja bereits erwähnt hast, ist Loopback nicht so intelligent.
das habe so nie geschrieben! und du meinst sicher nur für deinen fall.Wie löse ich das am besten? Muss ich die GPO unter VDI als Erzwungen setzen?
ich weiss ja jetzt nicht, wie du dieses xml verteilst. falls mit gpp, dann sollte eine gpo reichen, bei der du über die zielgruppenadressierung selektierst.e.
Hab einfach nur zu viel rumgepfuscht.
Hab eine GPO rein für Clients und jeweils noch eine für jede User-GPO angelegt und läuft nun so halbwegs wie ich es will.
Ohne loopback
Jedoch würde ich nie wieder eine Domäne auf Win8 updaten. Microsoft versuchts wohl komplizierter zu machen wie es ist.
Danke für die Hilfe!
Hab eine GPO rein für Clients und jeweils noch eine für jede User-GPO angelegt und läuft nun so halbwegs wie ich es will.
Ohne loopback
Jedoch würde ich nie wieder eine Domäne auf Win8 updaten. Microsoft versuchts wohl komplizierter zu machen wie es ist.
Danke für die Hilfe!