Досвідчені дрібниці-7, або «Злиття і поглинання в Group Policy»

Продовження «досвідчених дрібниць». Попередні частини: разів, два, три, чотири, п'ять, шість.


Сьогодні ми поговоримо про один цікавий параметр в 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.

Продовжити