Видно, что вы сами не до конца понимаете, как работает Loopback processing mode и Security Filtering.
Когда 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 для терминальных серверов).
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).
Gamelton's blog 
Необходимо оставить Authenticated Users право на чтение политики, но убрать примененеие. Тогда такой способ можно считать рабочим
Увы и ах. И этот способ работать не будет. Вернее, будет, но… В общем, к пользователю, залогинившемуся на машине, для которой включена перемычка правил, будут применены пользовательские правила из всех GPO, которые «встречаются» на пути к учетной записи машины — независимо от того, применяется это GPO к самой машине или нет. Т. е. безразлично, включена ли обработка машинной части правил в этом GPO и не отфильтровывается ли GPO по безопасности, — к пользователю правила будут применены.
В приведенной мною выше (вернее, ниже) схеме все ухищрения с группами Deny_GPOx окажут влияние только на машинные части GPO — к пользователю будут применены правила из всех GPO. Прискорбно, но факт.
Хм, как оказалось, и этот способ не работает. Тогда по-другому.
Создаем две группы — Deny_GPO1 и Deny_GPO2. Deny_GPO1 оставляем пустой, в Deny_GPO2 включаем компьютер A. Оба компьютера (а в общем случае — все компьютеры) помещаем в OU _Computers, привязываем к нему GPO1 и GPO2. В свойствах безопасности GPO1 добавляем группу Deny_GPO1 и запрещаем для этой группы применение групповой политики. Аналогично настраиваем безопасность для GPO2. Методологически такое решение выглядит некрасиво, но других вариантов не вижу.
Спасибо, GCRaistlin, за комментарии. Самому пока не было времени проверить, но приятно узнать, что кто-то читает этот бложек.
Вариант 2 нерабочий: к пользователям, вошедшим на терминальный сервер, настройки из GPO TermSrv_Minimal_UserConf применены не будут из-за фильтрации по безопасности — ведь у Authenticated Users мы право применять политику убрали. Без дополнительного OU здесь не обойтись. Тем не менее, неудобства этого можно нивелировать.
Рассмотрим такую ситуацию: есть две политики GPO1 и GPO2, каждая из которых предполагает использование перемычки правил. При этом на компьютере A должно применяться GPO1, а на компьютере B — GPO1 и GPO2. На первый взгляд, задача неразрешима: и в один OU оба компьютера помещать нельзя (т. к. GPO2 на компьютере A применяться не должна), и компьютер B в двух OU одновременно находиться не может. Но выход есть.
Создаем два OU — GPO1 и GPO2 — и две группы — тоже GPO1 и GPO2. Группы помещаем в соответствующие OU. В группу GPO1 включаем компьютеры A и B, в группу GPO2 — только B. И получим искомое.