Продолжение «опытных мелочей». Предыдущие части: раз, два, три, четыре, пять, шесть.

Сегодня мы поговорим об одном интересном параметре в Group Policy. Да, именно так. Один единственный параметр, который может облегчить вам жизнь (ну или усложнить ее, такое тоже возможно)


Задача была поставлена очень просто:
Требуется, чтобы определенные пользователей, входя на терминальный сервер, имели СуперМинимальный набор прав. Не могли изменять ничего на рабочем столе, не видели диски, могли запускать только заранее определенные приложения (1С, Консультант+, Word, Excel) и т.д. В тоже время все остальные, заходя на тот же терминальный сервер, должны получать полный набор прав. Ну и касаться это должно только данного конкретного терминального сервера, на рабочих станциях все пользователи примерно равны.

Казалось бы чего проще — настраивай групповую политику и вперед, на танки. Однако, как в старом анекдоте, «Есть нюанс!». Если мы говорим про настройку пользовательского окружения (запрет на отображение дисков, настройку рабочего стола и т.п.), то эти параметры применяются к пользователям (логично!), и возникает вопрос: куда именно применять нашу политику.

Если применить на OU, в котором содержатся пользователи, то у них будут СуперМинимальный набор прав везде, в том числе и на их рабочих компьютерах, что в наши планы не входило.

Если применять эту политику на OU в котором содержится терминальный сервер, то пользовательские параметры просто не применятся, т.к. они перечислены в категории User Configuration, и на сервер никакого влияния не окажут.

И вот тут в бой вступает вышеупомянутый интересный параметр в Group Policy. Записывайте: Computer Configuration — Administrative Template — System -Group Policy — User Group Policy Loopback processing mode -Merge (или Replace)

Делаем примерно так:

• Создаем группу Pol_RestrictTerminalUsers и вносим в нее тех людей, которым нужно выставить заданные ограничения
• Создаем политику RestrictTerminalUsers
• Выставляем в политике все те пользовательские (!) ограничения, которые нам нужны
• Выставляем описанный выше параметр в значение Enable-Merge
• Применяем ее на OU, в котором содержится нужный нам терминальный сервер (логично, кстати, вынести его в отдельный OU, чтобы политика не влияла на соседние компьютеры)
• В Security Filter этой политики убираем Authenticated Users и добавляем группу Pol_RestrictTerminalUsers, а также (!!) сам терминальный сервер
• В результате, когда пользователь состоящий в группе Pol_RestrictTerminalUsers входит на данный терминальный сервер, к нему применяются не только обычные его пользовательские политики, но и наша новая политика RestrictTerminalUsers, причем ее пользовательские значения имеют приоритет над значениями из других политик.
• Для пользователей, которые НЕ входят в эту группу, срабатывает Security Filter, и им никакие дополнительные настройки не применяются. Таким образом мы получаем следующее: при входе на терминал одним пользователям сеанс сконфигурирован одним образом, другим — другим, и управляется это все очень просто через группы в AD.
• На своих рабочих станциях у пользователей остается все по прежнему.

Что и требовалось. Ну и напоследок пара замечаний:

1. Режим Merge «сливает» все пользовательские настройки, а режим Replace заменяет их. Мы обычно используем Merge, т.к. в предыдущих политиках могут быть параметры (например подключаемый диски, принтера и т.д.), которые не нужно менять. Подробнее про Replace и Merge можно почитать, например, вот тут
2. При использовании Loopback processing в режиме Merge политика фактически отрабатывает дважды, учитывайте это, если используете Logon-скрипты. У меня, например, долго крышу сносило. Четко видно, что скрипт отрабатывает дважды, с перерывом в 0,5 -1 сек, а причину — не мог понять, пока не прочитал более подробно про Loopback processing.

Продолжение следует