Пара статей как это работает.

ОБЪЯСНЕНИЕ 1

Режим обработки замыкания групповой политики (Loopback Policy Processing)
Если управлять пользовательскими профилями через групповые политики, то можно заметить, что некоторые настройки, например, перенаправление папок, располагаются в разделе User configuration (Конфигурация пользователя) политики.
А это значит, что если пользовательская учетная запись находится в организационном подразделении (Organization Unit, OU), на которое распространяется действие такой политики, то применяться эти настройки будут при входе пользователя в систему независимо от того, локальный это компьютер или сервер RDS. Такое поведение может быть нежелательным, вполне разумно иметь одни пользовательские настройки для сервера, другие – для локального компьютера.
Но если поместить политику с настроенными разделами User Configuration в раздел OU с серверами, то она не будет обрабатываться, так как учетные записи пользователей не находятся в этом OU.
Чтобы это произошло, существует специальная политика Loopback Policy Processing (Режим обработки замыкания пользовательской групповой политики), располагающаяся в разделе Computer Configuration (Конфигурация компьютера) -» Policies (Политики) -> Administrative Templates (Административные шаблоны) -> System (Система) -> Group Policy (Групповая политика).
У нее два режима работы – Replace (Замена) и Merge (Слияние). В первом случае происходит замещение пользовательских политик из OU пользователя, во втором – объединение с ними.

Например, на рис. 5 изображен домен с двумя организационными подразделениями – OU1 и OU2.
В первом находятся объекты учетных записей пользователей и их локальные компьютеры, во втором – объекты серверов RDS.
Если пользователь осуществляет вход в систему на локальном компьютере, то он оказывается под действием доменной групповой политики (Default domain policy), затем политики GP1 локального компьютера (которая была применена при его включении) и политики GP2 пользователя (примененной при входе в систему).
Если пользователь осуществляет вход на сервер RDS, то будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2.
Если же включить Loopback Policy Processing, то при входе на сервер RDS будут действовать доменная политика, политика сервера GP3 и политика пользователя GP2+GP4 (в режиме Merge) или только GP4 (в режиме Replace).
При возникновении любых конфликтов настроек между политиками OU пользователя и OU сервера в режиме Merge политика в OU сервера будет иметь более высокий приоритет.

Используя несколько серверов RDS в кластере, просто необходимо управлять пользовательскими профилями. К счастью, для этого есть достаточно много возможностей со своими сильными и слабыми сторонами. Остается только выбрать то сочетание, которое лучше всего будет подходить для каждого конкретного случая.

( взято тут: http://www.xnets.ru/plugins/content/content.php?content.240.4  )

ОБЪЯСНЕНИЕ 2

Когда GPO линкуется к какому-то OU, то по умолчанию политики из раздела Computer Configuration данной GPO применяются ко всем компьютерным объектам внутри этого OU (и его подконтейнеров), а политики из раздела User Configuration применяются ко всем пользовательским объектам внутри этого OU (и его подконтейнеров).

Если вы прилинкуете GPO к OU, в котором лежат только компьютерные объекты, и в этом GPO укажете какие-то настройки в разделе User Configuration, то по умолчанию эти пользовательские настройки будут проигнорированы и никем не будут использоваться (т.к. я уже указал выше, что по умолчанию к компьютерным объектам применяются только настройки из Computer Configuration).

Так вот, чтобы к пользователям, которые логинятся на какие-то машины, применялись пользовательские настройки (раздел User Configuration) из GPO, которая прилинкована к компьютерному объекту, и включается «User Group Policy Loopback processing mode».

При этом в режиме Replace пользовательские настройки (User Configuration) из других GPO, назначенных на пользовательский объект, будут отменены и будут действовать только пользовательские настройки (User Configuration) из GPO, назначенного на компьютерный объект, куда логинится пользователь.
А в режиме Merge эти настройки совместятся (ранее назначенные сохранятся, новые добавятся, конфликтующие перезапишутся). Т.е. частично у пользователя останутся настройки, назначенные на самого пользователя через другие GPO, плюс добавятся пользовательские настройки (User Configuration) из GPO, назначенного на компьбютер.

Но нужно понимать, что хоть в этом случае меняются пользовательские настройки, но сам GPO назначается всё же на компьютерный объект. И при настройке линковки Security Filtering про это не нужно забывать.

Если вы для GPO, прилинкованному к OU, настраиваете Security Filtering, тогда политики из этого GPO применяются не ко всем объектам внутри данного OU, а только к тем, которые указаны в фильтре безопасности прямо или косвенно (через группы).
Чтобы данный GPO применился к какому-то объекту, этот объект:
а) должен быть внутри OU, к которому прилинкован GPO;
б) должен подпадать под указанный фильтр безопасности (с правами: read group policy + apply group policy).
В Security Filter нет смысла включать объекты, которые не содержатся внутри OU, к которому вы линкуете GPO, — политики к таким объектам всё равно не применятся.

А вы же в своём описании:
1) Создаёте OU, переносите в него компьютерные объекты терминальных серверов.
2) Создаёте GPO и линкуете его к этому OU.
3) Для GPO указываете Security Filter, в который включаете не только терминальные серверы (которые находятся в этом OU), но ещё зачем-то и пользователей (которые находятся за пределами данного OU).

Во-первых, нет смысла вообще делать Security Filtering, если вы и так терминальные серверы вынесли в отдельный OU. Просто линкуете GPO к этому OU с терминальными серверами (например: ou=terminal servers,ou=servers,dc=example,dc=org) без всякой фильтрации и всё.

Во-вторых, если и не выносить терминальные серверы в отдельный OU, а оставить их, например, в контейнере со всеми прочими серверами (ou=servers,dc=example,dc=org), то тогда можно использовать Security Filtering, но только в этот фильтр нужно добавлять никак не пользователей, а только терминальные серверы, которые содержатся в прилинкованном OU. Например создать domain local security-группу с именем TerminalServers, в неё включить компьютерныеобъекты всех терминальных серверов, находящихся в контейнере Setrvers. И уже эту группу добавлять в Security Filtering, убирая оттуда Authenticated Users.

Итого, как было правильно реализовать задуманное вами:

Вариант 1 (с созданием отдельного OU для терминальных серверов).
1. Создаёте отдельный подконтейнер для ТС: ou=terminal servers,ou=servers,dc=example,dc=org
2. В этот контейнер перемещаете компьютерные объекты всех терминальных серверов.
3. Создаёте GPO, например, TermSrv_Minimal_UserConf.
4. В настройках GPO TermSrv_Minimal_UserConf:
— в разделе User Configuration: задаёте нужные вам разрешения для пользователя.
— в разделе Computer Configuration включаете «User Group Policy Loopback processing mode» в режим Merge (или Replace).
5. Линкуете GPO TermSrv_Minimal_UserConf к OU, в котором находятся терм.серверы, т.е. к ou=terminal servers,ou=servers,dc=example,dc=org
6. Настройки безопасности GPO оставляете по умолчанию, т.е. Authenticated Users: Read+apply group policy.

Вариант 2 (без создания отдельного OU для терминальных серверов).
1. Терминальные серверы лежат в одном OU с прочими компьюьерными объектами (например, в ou=servers,dc=example,dc=org).
2. Создаёте доменную группу, например, TermServers (domain local, security), включаете в неё все терминальные серверы (комп. объекты).
3. Создаёте GPO, например, TermSrv_Minimal_UserConf.
4. В настройках GPO TermSrv_Minimal_UserConf:
— в разделе User Configuration: задаёте нужные вам разрешения для пользователя.
— в разделе Computer Configuration включаете «User Group Policy Loopback processing mode» в режим Merge (или Replace).
5. Линкуете GPO TermSrv_Minimal_UserConf к OU, в котором находятся терм.серверы (и не только), т.е. к ou=servers,dc=example,dc=org
6. Настраиваете для этого GPO Security Filtering: удаляете Authenticated User, добавляете созданную вами ранее группу TermServers (с правами по умолчанию: Read+apply group policy).

Вот и всё. При этом:
а) Если юзеры будут логиниться на свою рабочцю станцию и на какие-то прочие нетерминальные серверы (куда им разрешено), то к ним будут применяться пользовательские настройки из GPO, назначенных на их пользовательскую учётку (в частности из Default Domain Policy И прочих, созданных вами).
б) Если юзеры будут логиниться на терминальные серверы, то к ним сначала, как обычно, будут применяться пользовательские настройки из GPO, назначенных на их пользовательскую учётку, а потом сразу же поверх них будут накатываться пользовательские настройки из GPO TermSrv_Minimal_UserConf, прилинкованного к контейнеру с терминальными серверами, путём полной замены (Replace) или дополнения с перезаписью конфликтных значений (Merge).

Лепить непонятный винегрет, когда и отдельный OU и Security Filtering, да ещё и в группу для фильтрации добавлены и пользователи и компьютеры — это явный бред, который происходит от непонимания того, как это всё работает.

взято тут:

http://habrahabr.ru/users/foxyovovich/favorites/comments/

и тут

http://gamelton.com/2011/06/27/gpo-loopback/#comments