*** Update siehe Ende des Artikels ***
Dieses mal einen außerplanmäßigen Post (nicht in der Reihe "The lies of GPOs!").
Einige benutzen den Loopbackmodus.
Im Normalfall wird für den Benutzer, der Benutzeranteil der Richtlinie angewandt, die auf der OU des Users bzw. einer darübergelegenen OU verlinkt ist. Der angewandte Computeranteil wird anhand der Position des Computerobjektes im AD gelesen.
In einigen Situationen ist dies jedoch nicht erwünscht.
Stellen wird uns beispielsweise vor, ein Benutzer meldet sich an einem Terminalserver an. Es wirken also die Computereinstellungen, die durch das Computerobjekt des Terminalservers gelesen werden.
Die Benutzereinstellungen werden allerdings anhand des Benutzerobjektes angewandt. Ein Admin eines Terminalserver möchte jedoch meistens ebenfalls Benutzereinstellungen definieren, die nur für die Anmeldung an dem Terminalserver gelten. Oftmals ist es sogar gewünscht, dass die "normalen" Benutzereinstellungen, also diejenigen die über die Position des Benutzerobjektes gefunden werden, ignoriert werden.
Dieses Verhalten lässt sich mit Loopback beeinflussen.
Das genaue Verfahren möchte ich an dieser Stelle nicht erklären,
eine übersichtliche Auflistung findet sich hier:
http://www.msxfaq.de/verschiedenes/gpo.htm
Ist Loopback aktiv, so reichte es bis einschließlich Windows XP und Server 2003 aus, wenn der User Leserechte und Rechte zum Übernehmen der Policy hatte.
Haben wir z.B. eine OU, in der 5 Terminalserver vorhanden sind und es ist eine GPO mit Usereinstellungen verlinkt, so werden diese Settings für alle Benutzer angewandt, die sich an den Terminalservern anmelden (vorausgesetzt Loopback ist aktiv).
Es besteht also keine direkte Möglichkeit, an dieser Stelle eine Beziehung zum Computeraccount herzustellen.
Möchte ich die Policy nur an 2 von den 5 Terminalservern anwenden, so ist dies nur per WMI-Filter möglich.
Ab Windows Vista wurde deshalb ein zusätzlicher Filtermechanismus eingebaut.
Damit die Benutzereinstellungen mittels Loopback angewandt werden, muss zusätzlich das Computerobjekt mindestens Leserechte auf die Policy haben.
Andernfalls werden die Benutzereinstellungen dieser Policy trotz Loopback nicht angewandt. Zu unserem Beispiel also, wird in der Policy nur Terminalserver1 und Terminalserver2 mit Leserechten eingefügt, so wird diese auch nur an diesen 2 Terminalservern übernommen und nicht an allen 5.
Wie oben im Link beschrieben, gibt es zwei Modi für Loopback.
Merge und Replace.
Nun zum Problem.
Was bisher nirgends dokumentiert ist:
Die neue Sicherheitsfilterung gilt nur für Loopback-Merge.
Nicht für Loopback-Replace.
Der offizielle KB-Artikel ist dieser hier:
http://support.microsoft.com/kb/953768/en-us
Ich habe offiziell eine Korrektur für diesen Artikel eingereicht.
Bisher ist der Artikel allerdings noch auf dem alten Stand.
Unter Loopback-Replace wird dieser neue Mechanismus nicht verwendet.
Update 07.03.2013:
Der Artikel wurde nun aktualisiert und ist deutlich präziser.
