GPO - Loobbackverarbeitung. Funktioniert es nicht oder raff ichs nicht?

[toasti 11]

Hallo zusammen,

 

ich spiele grad in meiner Testumgebung mit GPOs und em Loobackverarbeitungsmodus.

 

Leider will das nicht so richtig hinhauen, hier mal die Situation:

 

Eine GPO "Firmen Standards" in der festgelegt ist, dass der Bildschirmschoner nach 10 min rein geht und nur durch Eingabe des Passworts wieder beendet wird. Diese ist auf die Domäne verlinkt.

 

Nun habe ich eine OU mit Schulungscomputern. Hier möchte ich, dass wenn man sich an Schulungsrechnern die sich in dieser OU befinden anmeldet, dass diese Bildschirmschoner Einstellungen zurückgesetzt werden auf "nicht konfiguriert".

 

Habe eine GPO erstellt und auf die OU Schulungsrechner verlinkt in der der Loopbackmodus aktiviert ist - bei den Benutzereinstellungen sind die Richtlinien für Bildschirmschoner alle auf "nicht konfiguriert".

 

D.h. wenn ich jetzt mit dem GPO-Modellierungstool simuliere müssten die Einstellungen nicht gesetzt sein für diese computer. Das sind sie aber immer noch - durch die GPO "Firmen Standards".

 

 

Kann es sein, dass die Einstellungen nur ersetzt werden, wenn ich in der GPO für die Schulungsrechner auch die Bildschirmschoner Richtlinien einstelle, z.B. deaktiviere??

 

 

Helft mir mal bitte auf die Sprünge.

 

Besten Dank schon mal.

 

Grüße

toasti

[XP-Fan 215]

Hallo toasti,

 

stell dir vor du hast eine Kolonne Maler und ein Haus.

Der ganzen Gruppe sagt du das Haus wird weiß gestrichen.

Nun trennst du 2 Maler heraus, und sagst ihnen diese Seite machen wir anders in der Farbe.

 

Mit welcher Farbe wird die eine Wand gestrichen ?

 

Mal so als Denkanstoß verstehen :)

 

Warum definierst du diese Richtlinie in der obersten Ebene ?

 

Mach dir das Leben doch leichter, erstelle 2 OU / Gruppen, füge entsprechende Mitglieder

hinzu und definiere dort deine Einstellungen.

[toasti 11]

hmmm, weiß? ;-)

 

Du hast schon Recht, aber ist nicht genau dafür der Loobbackmodus da?

 

Ich mein, nehmen wir an es gibt eine Unternehmens-Sicherheitsrichtlinie die eben besagt JEDER Rechner in der Domäne wird nach 10 min gesperrt und nur mit Passwort kann man sich wieder anmelden. Plus weitere Sicherheitseinstellungen die Domänenweit einfach gelten sollen.

 

Und jetzt aber habe ich eine OU voller Schulungscomputer die z.B. nicht diese Einstellungen des Bildschirmschoners bekommen sollen, egal welcher User sich anmeldet.

 

Anhand der Loopbackverarbeitung sollten dann doch die Benutzereinstellungen der "Sicherheitsrichtlinie" die auf die Domäne verlinkt ist verworfen werden (im Ersetzen-Modus) und die Benutzerkonfigs angewendet werden, die in der GPO drin stehen die auf die OU der Schulungsrechner verlinkt ist.

 

Man kanns bestimmt einfacher gestalten, aber es geht mir einfach um die Loopback-Geschichte.

 

Der Gedankenweg ist doch richtig, oder?

 

 

 

 

Besten Dank nochmal!!

[olc 18]

Hi,

 

ist die Einstellung eine "Computer Configuration" oder "User Configuration"? Gib bitte einmal den kompletten "Pfad" zur Gruppenrichtlinie.

 

Wenn es eine Computerkonfiguration ist, dann brauchst Du keine Loopback verarbeitung - dann konfigurierst Du einfach die Einstellung auf der Schulungsrechner OU in einer eigenen GPO.

 

Oder ist die Domänen Policy (Standard Settings) "erzwungen / enforced"?

 

Viele Grüße

olc

[deniii 10]

Hallo,

 

ich beschäftige mich momentan auch mit der Loopback-Geschichte.

Und ich bin da auf eine Seite gestoßen, die allgemeine Klarheit schaffen sollte was den Loopbackmodus und Gruppenrichtlinien an sich angeht.

 

Hier erstmal der Link -> MSXFAQ.DE - Gruppenrichtlinien

 

Ich habe allerdings auch eine Frage dazu.

 

Zunächst einmal wie ich das Ganze verstanden habe - und ich bin absoluter Anfänger (Azubi) :

 

Also zunächst einmal besteht eine Richtlinie aus einem Computeranteil und einem Benutzeranteil - im Folgenden CA und BA abgekürzt.

 

Es gibt Richtlinien für User sowohl als auch für die Rechner selbst - was sicherlich bekannt sein sollte.

 

Wird nun ein Rechner gestartet, verbindet sich dieser mit der AD und list die für 'Ihn' zutreffenden Richtlinien ein. Allerdings nur den Computeranteil (CA) seiner Richtlinie. Der Benutzeranteil (BA) wird praktisch nicht vom Rechner beachtet.

 

Loggt sich ein User dann auf diesem Rechner ein, so durchläuft er die selbe Prozedur, allerdings wird hier nicht der CA sondern der BA der User-Richtlinie "geladen".

 

Das ist der Normalfall, so habe ich es auf jedem Fall verstanden.

 

Nun zu meiner Situation/Frage:

 

Ich melde mich als User an einem lokalen Rechner oder ThinClient an - dort soll keine spezielle Richtlinie, außer die der Domain-Policy und evtl. anderen zugewiesenen, greifen. Doch melde ich mich doch am Terminal-Server via RDP- oder ICA-Session an, soll z.B. die Systemsteuerung ausgeblendet werden.

 

Nur ich frage mich, was ist wenn ich direkt vor dem TS sitze, ohne RDP, ICA oder sonstwas anmelde, wie verhält sich dann das Ganze? Welche Richtlinie greift?

 

Was ich auch noch nicht ganz verstanden habe, was der Unterschied zwischen ersetzen und verbinden ist. Hier hänge ich auch noch ein wenig.

 

Brauche ich dazu 2 neue/eigene Policys oder kann ich es in einer Zusammenfassen und es wird sich nur der CA bzw. BA Anteil gezogen? Normal ist es ja so, dass ich die Policy auf einer OU anwende, in der User- oder Gruppen- oder Computerkonten vorhanden sind. Im Loopbackmodus stellt sich für mich nur die Frage, auf welche OU wende ich denn die Policy an? Auf der, in der der Terminal-Server ist oder auf der sich der/die User/Gruppen befinden.

 

Habe in der Testumgebung eine OU angelegt, die eine Gruppe beinhaltet, an die ich einige Benutzer hinzugefügt habe.

 

Stelle es mir eigentlich so vor, wenn sich ein Benutzer, der Mitglied dieser TerminalUser Gruppe ist und wenn sich genau ein User aus dieser Gruppe an dem Terminal-Server anmeldet, dass dann Systemsteuerung etc. ausgeblendet wird. Wenn ein Benutzer nicht Mitglied dieser Gruppe ist, dann soll genauso wenig passieren, als wenn er sich lokal an seinem Rechner anmeldet.

 

Hoffe ich sorge nicht für soviel Verwirrung und jemand von euch hat noch den zündenden Hinweis für mich.

 

Gruß

Denii

[Fraenky 10]

@deniii:

 

Nur ich frage mich, was ist wenn ich direkt vor dem TS sitze, ohne RDP, ICA oder sonstwas anmelde, wie verhält sich dann das Ganze? Welche Richtlinie greift?

 

schau mal hier:

 

Gruppenrichtlinien - Übersicht, FAQ und Tutorials

 

unter Howto -> Terminalserver

 

gibt es eine schöne Anleitung dafür ;)

 

Gruß

[NorbertFe 1.809]

Was ich auch noch nicht ganz verstanden habe, was der Unterschied zwischen ersetzen und verbinden ist. Hier hänge ich auch noch ein wenig.

 

Zusammenführen nimmt sowohl den Benutzeranteil des GPOs des Users sowie den Benutzeranteil des GPOs des Computers. Letzterer hat bei gleicher Policy immer Vorrang.

Ersetzen bedeutet: Der Benutzeranteil des GPOs des Users wird nicht angewandt, sondern nur der des GPOs des Computerobjekts.

 

Bye

Norbert

[toasti 11]

Zusammenführen nimmt sowohl den Benutzeranteil des GPOs des Users sowie den Benutzeranteil des GPOs des Computers. Letzterer hat bei gleicher Policy immer Vorrang.

Ersetzen bedeutet: Der Benutzeranteil des GPOs des Users wird nicht angewandt, sondern nur der des GPOs des Computerobjekts.

 

Bye

Norbert

 

und genau da will ich nochmal einsteigen - ich glaube wir reden aneinander vorbei :D

 

Was passiert, wenn ich in der GPO des Computers den Benutzeranteil nicht konfiguriere, in der GPO des Benutzers aber der Benutzeranteil konfiguriert ist?

 

Werden die Einstellungen durch die GPO des Computers auf "nicht konfiguriert" zurückgesetzt oder bleiben die Einstellungen der Benutzer-GPO?

 

Wie ich das laut MS-Press Buch 70-640 verstanden habe, sollte bei einer Loopbackverarbeitung im Ersetzen-Modus der Benutzeranteil der Benutzer-GPO komplett verworfen werden.

[olc 18]

Hi,

 

mal abgesehen davon, daß Du meine Fragen oben nicht beantwortet hast ;), sollte im "Replace Mode" die Benutzer Policy komplett ersetzt werden, in Deinem beschriebenen Szenario also durch "leere" Einstellungen. Beim "Merge Mode" wäre in Deiner Beschreibung das Benutzer Setting auf Benutzer OU GPO Basis weiterhin aktiv.

 

Aber wie oben angesprochen: Wenn es sich um Computer Einstellungen handelt, ist diese Diskussion nicht fruchtbar. Sag uns erst noch einmal konkret, was genau Du konfiguriert hast.

 

Viele Grüße

olc

[toasti 11]

Abend,

 

wie schon in meinem Eröffnungspost geschrieben handelt es sich um Bildschirmschoner Einstellungen, also User Settings.

 

So, hier mal die Screens von den beiden GPOs. Zu erst mal die Contoso Standard, diese ist direkt auf die Domain verlinkt.

 

 

 

Dann haben wir hier noch die Schulungsraum GPO, hier ist der Loopbackmodus aktiviert, die GPO ist auf die OU Schulungsraum gelinkt.

 

 

 

Nach meinem und deinem Verständnis müssten nun also die Benutzereinstellungen der Contoso Standard durch die, der GPO Schulungsraum ersetzt werden, d.h. die Einstellungen werden zurückgesetzt.

[NorbertFe 1.809]

Nach meinem und deinem Verständnis müssten nun also die Benutzereinstellungen der Contoso Standard durch die, der GPO Schulungsraum ersetzt werden, d.h. die Einstellungen werden zurückgesetzt.

 

Setz doch einfach mal die Screensaversetting auf explizit deaktiv. ;)

So wie du das definiert hast, kann das nicht funktionieren. Das Prinzip hast du zwar korrekt verstanden, aber nicht berücksichtigt, dass du Contose Standard auf Dom-Ebene definiert hast. und das bedeutet, auch der TS zieht diese Settings. ;)

 

Bye

Norbert

[deniii 10]

Hier noch mal mein Feedback bzw. Situation.

 

Zunächst wurde eine OU erstellt, die den Namen „Terminalserver Objects“ trägt. In dieser OU habe ich eine globale Sicherheitsgruppe angelegt, welche wiederum „Terminalserver-Benutzergruppe“ heißt und die betroffenen TS-User beinhaltet.

Folgende Schritte bin ich durchgegangen:

 

- OU (Terminalserver Objects) erstellt > globale Sicherheitsgruppe (Terminalserver-Benutzergruppe) erstellt > TS User in die Gruppe

- Eigenschaften der OU > Sicherheitseinstellungen der „Terminalserver-Benutzergruppe“ > „Authentifizierte Benutzer“ aus den Sicherheitseinstellungen der Gruppe entfernt > dem Terminalserver als Computerkonto und die Gruppe hinzugefügt > Lese-Berechtigung erteilt

 

Anmerkung: Dort sind noch viele andere Gruppen (Domänencontroller, Exchange Enterprise Servers etc.) hinterlegt, müssen diese gelöscht werden? Oder müssen die Sicherheitseinstellungen nicht auf der Gruppe selbst, sondern auf der OU angepasst werden? Habe es eigentlich so verstanden, dass man dies auf der Gruppe selbst machen muss.

 

Die Berechtigung „Gruppenrichtlinien übernehmen“, wie sie auf folgendem Link beschrieben ist (Gruppenrichtlinien - Übersicht, FAQ und Tutorials) konnte ich dort nicht finden und somit auch nicht vergeben.

 

Zwischenfrage:

Gibt es diese Berechtigung unter W2k3 SP2? Wo finde ich sie?

 

- Register Gruppenrichtlinien der OU > Neu > Name „Terminalserver_Loopback“ > Optionen keine ausgewählt

- Bearbeiten > Aktivierung folgender Richtlinien

Computerkonfiguration\Administrative Vorlagen\System\Gruppenrichtlinien > Loopbackverarbeitungsmodus für Benutzergruppenrichtlinie > Aktiviert > Ersetzen

 

Des Weiteren habe ich dort einige zusätzliche Einstellungen vorgenommen, wie sie auch in dem o.g. Link zu finden sind und habe es anschließend übernommen.

 

- Testanmeldung via RDP am TS > kein „Loopbackeffekt“

- TS-User, welcher auch in der Terminalserver-Benutzergruppe als Mitglied hinterlegt ist, direkt von Users in die OU (Terminalserver Objects) verschoben

- Testanmeldung via RDP am TS > Richtlinie greift

 

- Testanmeldung an einer Workstation > die selbe Richtlinie greift, was aber nicht sein soll/darf.

 

Was ich auch nicht verstehe, warum greift die Gruppenrichtlinie nicht bei der Gruppe, sondern nur, wenn ich den User direkt in die OU verschiebe Muss es eine lokale Sicherheitsgruppe sein? Und warum tritt der Loopbackeffekt nicht ein?

 

Wo könnte das Problem liegen?

 

 

Und übrigens: Danke für eure Rückmeldungen :)

[NorbertFe 1.809]

Zunächst wurde eine OU erstellt, die den Namen „Terminalserver Objects“ trägt.

 

OK.

 

In dieser OU habe ich eine globale Sicherheitsgruppe angelegt, welche wiederum „Terminalserver-Benutzergruppe“ heißt und die betroffenen TS-User beinhaltet.

 

OK, aber wozu?

 

- OU (Terminalserver Objects) erstellt > globale Sicherheitsgruppe (Terminalserver-Benutzergruppe) erstellt > TS User in die Gruppe

 

sagtest du bereits. ;)

 

- Eigenschaften der OU > Sicherheitseinstellungen der „Terminalserver-Benutzergruppe“ > „Authentifizierte Benutzer“ aus den Sicherheitseinstellungen der Gruppe entfernt > dem Terminalserver als Computerkonto und die Gruppe hinzugefügt > Lese-Berechtigung erteilt

 

Weißt du, was du da tust? Bzw. erklär mal, warum du das getan hast.

 

Anmerkung: Dort sind noch viele andere Gruppen (Domänencontroller, Exchange Enterprise Servers etc.) hinterlegt, müssen diese gelöscht werden? Oder müssen die Sicherheitseinstellungen nicht auf der Gruppe selbst, sondern auf der OU angepasst werden? Habe es eigentlich so verstanden, dass man dies auf der Gruppe selbst machen muss.

 

Ich würde behaupten, du hast irgendwas falsch verstanden. ;) Deine beiden obigen Vermutungen sind jedenfalls falsch.

 

Die Berechtigung „Gruppenrichtlinien übernehmen“, wie sie auf folgendem Link beschrieben ist (Gruppenrichtlinien - Übersicht, FAQ und Tutorials) konnte ich dort nicht finden und somit auch nicht vergeben.

 

Ich würde sagen, dass das dein Fehler ist. ;) Wie wärs nochmal mit genauem Lesen?

"· In den Sicherheitseinstellungen der Richtlinie entfernt "

 

Gibt es diese Berechtigung unter W2k3 SP2? Wo finde ich sie?

 

Ja klar gibts die. ;)

 

Was ich auch nicht verstehe, warum greift die Gruppenrichtlinie nicht bei der Gruppe, sondern nur, wenn ich den User direkt in die OU verschiebe

 

FAQ-GPO

 

Muss es eine lokale Sicherheitsgruppe sein?

 

Nein.

 

Und warum tritt der Loopbackeffekt nicht ein?

 

Weil du so ziemlich nichts von dem umgesetzt hast, was Mark im How To beschrieben hat.

 

Wo könnte das Problem liegen?

 

Lies dir mal Gruppenrichtlinien - Übersicht, FAQ und Tutorials in der Breite durch und versuch zu verstehen wie das alles zusammenhängt, dann sollte dein Problem bald gelöst sein.

 

Bye

Norbert

[deniii 10]

Hallo,

 

okay okay – ich habe mir das Ganze noch mal in Ruhe angesehen und habe noch mal ein wenig verändert, nämlich folgendes:

- Die Sicherheitsgruppe in der von mir erstellten OU habe ich verschoben. In der OU befindet sich jetzt nur noch unser Terminal-Server.

 

- Dann wurde die Gruppe „Authentifizierte Benutzer“ aus der Sicherheitseinstellung der Richtlinie entfernt. Weitergehend wurde die Gruppe „Terminalserver-Benutzergruppe“ und der Terminalserver selbst dort hinzugefügt. Lese-Berechtigungen sowohl als auch die Berechtigung „Gruppenrichtlinien übernehmen“ wurden vergeben. (Habs’ nun entdeckt)

 

- Der Terminal Server wurde genau nach Anleitung aus dem „HowTo von Mark“ konfiguriert.

 

Bei einer Testanmeldung via RDP auf den TS greift die erstellte Richtlinie, die ich an sich unverändert gelassen habe, leider nicht.

 

Die DNS-Konfiguration am Client wurde überprüft und ist korrekt.

 

 

Habt Ihr nochmal einen Tipp für mich?

 

Besten Dank.

[NorbertFe 1.809]

Rede ich chinesisch? ;)

https://www.mcseboard.de/post11-952045.html

So wie du das definiert hast, kann das nicht funktionieren. Das Prinzip hast du zwar korrekt verstanden, aber nicht berücksichtigt, dass du Contose Standard auf Dom-Ebene definiert hast. und das bedeutet, auch der TS zieht diese Settings.