Статьи

Групові політики в доменах AD :: Журнал СА 7.2007

Олександр Ємельянов   Групові політики в доменах AD   Адміністратору локальної мережі сподіватися на свідомість користувачів при роботі в мережі підприємства не доводиться, тому роботи зі створення ефективної і безпечної робочого середовища, як правило, справа непроста Олександр Ємельянов

Групові політики в доменах AD

Адміністратору локальної мережі сподіватися на свідомість користувачів при роботі в мережі підприємства не доводиться, тому роботи зі створення ефективної і безпечної робочого середовища, як правило, справа непроста. На допомогу в цьому випадку приходять групові політики, використання яких як не можна краще підходить для виконання адміністративних завдань.

Постараємося узагальнити інформацію по технології розгортання і застосування групових політик (ДП) в службі каталогів. Зокрема:

  • в чому вигода для адміністратора при використанні ДП;
  • сутність об'єктів ДП ​​і їх місце в каталозі AD;
  • відміну ДП домену від локальних політик робочих станцій;
  • як створюються, призначаються і застосовуються ДП в домені;
  • успадкування та пріоритети для ДП;
  • утиліти gpupdate, gpresult і RSoP;
  • багато інших програм для керування і діагностики несправностей в застосуванні ДП;
  • майбутнє ДП - що нового в плані групових політик в Windows Vista.

Для чого потрібні групові політики в домені

У попередній статті [1] я говорив про управління користувачами в середовищі Active Directory. Cлужба каталогів полегшує роботу IT-підрозділу з адміністрування інформаційних ресурсів підприємства. Технології Intellimirror і CCM (Change and Configuration Management - управління змінами та конфігураціями) дозволяють управляти робочими місцями, використовуючи переміщувані профілі і перенаправлення каталогів, автономні папки та поширення програм. Багато з цих завдань легко виконуються за допомогою групових політик, забезпечуючи при цьому централізоване управління, а також гнучкий механізм настройки і налагодження. Групові політики дозволяють:

  • призначати сценарії запуску, входу і виходу;
  • поширювати програмне забезпечення в мережі за допомогою публікації або призначення;
  • однозначно визначати набір налаштувань безпеки для віддалених машин;
  • визначати політики паролів для користувачів домену;
  • конфігурувати параметри Internet Explorer (навіть незважаючи на всю його «діряві», за різними джерелами від 60 до 80% користувачів у всьому світі використовують для перегляду веб-сторінок саме цей браузер);
  • налаштовувати перенаправлення певних папок з профілю користувача;
  • накладати обмеження на робочий стіл;
  • визначати настройки таких категорій, як автономні папки, дискові квоти та ін., не виключенням є налаштування самих групових політик.

Всі настройки адміністратор може зробити за допомогою редактора реєстру, але інтуїтивно зрозумілий інтерфейс редактора об'єктів групової політики багато в чому спрощує це завдання.

Структура об'єктів групової політики і їх місце в службі каталогів

Об'єкт групової політики (GPO, Group Policy Object) складається з двох частин: конфігурація комп'ютера (Computer Configuration) і конфігурація користувача (User Configuration) (див. Рис. 1). Він є контейнером для груп політик, що застосовуються відповідно до машин і користувачам мережі.

Малюнок 1. Редактор групових політик gpedit.msc

У «Зміни комп'ютера» адміністратор може налаштувати параметри безпеки, політики паролів користувачів, параметри аудиту, використання груп з обмеженим доступом (Restricted Groups), параметри реєстру і так далі.

У розділі «Конфігурація користувача» налаштовуються параметри робочого оточення користувача (настройки робочого столу, вид і обмеження для панелі задач і меню «Пуск»), перенаправлення папок, а також параметри Internet Explorer. Кожен об'єкт GPO створюється за допомогою редактора групових політик (Group Policy Object Editor). Запустити його можна з вкладки Group Policy властивостей контейнера.

Як вже говорилося, GPO містить в собі два вузла, в яких визначаються специфічні для комп'ютерів і користувачів налаштування. Однак буває, що існують ідентичні налаштування для комп'ютерів і користувачів. Як система «розрулює» їх застосування, буде розказано далі.

Кожна політика в об'єкті GPO може бути налаштована і немає. У першому випадку вона впливає на об'єкт і може бути в змозі включено / вимкнено, а також приймати значення із зазначенням додаткових параметрів. У другому - політика на об'єкт не впливає.

Об'єкти групових політик зберігаються двома частинами: контейнер групової політики (GPC, Group Policy Container) і шаблон групової політики (GPT, Group Policy Template). Контейнер зберігається безпосередньо в службі каталогів і містить інформацію про властивості, версії, статус і список компонентів. Шаблони GPT знаходяться в каталозі WindowsSYSVOLsysvolDomain_NamePoliciesGUID (див. Рис. 2), де GUID - глобальний унікальний ідентифікатор об'єкта GPO. У цій папці містяться адміністративні шаблони (ADM - файли), настройки безпеки, інформація про доступні додатках і імена сценаріїв з командними рядками.

У цій папці містяться адміністративні шаблони (ADM - файли), настройки безпеки, інформація про доступні додатках і імена сценаріїв з командними рядками

Малюнок 2. Папка, що містить шаблони групових політик на контролері домену

Локальні політики робочої станції

Кожна робоча станція під управлінням операційних систем сімейства Windows 2000 має свої локальні політики, і адміністратор домену має можливість редагувати їх. Вони схожі з груповими політиками домену, але застосовуються для всіх локальних користувачів комп'ютера без винятку. Також неможливо налаштувати ряд установок, таких, наприклад, як перенаправлення каталогів і установка додатків. Незважаючи на це, структура об'єкта локальних групових політик така ж, як і GPO домену. Розміщується він в папці \ Windows \ system32 \ GroupPolicy.

За допомогою команди gpedit.msc ви можете редагувати локальні політики робочої станції. Синтаксис рядка для запуску gpedit.msc для перегляду локальної політики віддаленої машини буде виглядати наступним чином:

Gpedit.msc / gpcomputer: ім'я комп'ютера

Однак варто відмітити, що ви не зможете подивитися локальні настройки безпеки віддаленої машини (мабуть, Microsoft зробила це з міркувань безпеки).

Групові політики за замовчуванням

Після створення першого контролера домену формуються політики за замовчуванням: Default Domain Controller Policy (прив'язується до контейнера Domain Controllers, застосовується виключно для контролерів домену та містить настройки безпеки) і Default Domain Policy (політика безпеки для домену, прив'язується до контейнера домену і поширюється на весь домен ). Ви легко їх можете замінити своїми політиками, або використовувати в поєднанні з іншими. Ще один нюанс, який варто відзначити - якщо ви спробуєте відкрити Default Domain Controller Policy з меню «Адміністрування», вам будуть доступні тільки настройки безпеки. Повністю побачити і змінити всі налаштування цього GPO можна з оснащення Active Directory - Users and Computers (DSA.MSC) у властивостях контейнера Domain Controllers.

Створення об'єктів GPO

Незважаючи на назву, GPO не мають нічого спільного з групами. Об'єкти групових політик можуть бути пов'язані з контейнерами сайту, домену та OU (організаційної одиниці). Таким чином, для створення об'єкта GPO ми можемо скористатися консолями Active Directory - Users and Computers або Active Directory Sites and Services, все залежить від того, для якого контейнера ми створюємо GPO. Отже, запускаємо DSA.MSC або DSSITE.MSC. Далі заходимо в властивості контейнера і відкриваємо вкладку «Групова політика» (Group Policy), як це показано на рис. 3. Тут ми можемо створити або змінити GPO, а також додати і прив'язати до об'єкта вже існуючий GPO. У цих настройках можна видалити як посилання на GPO, і тоді пропаде всього лише прив'язка GPO до контейнера, так і сам об'єкт групової політики.

Малюнок 3. Відкриття редактора групових політик в DSA.MSC

В параметрах (Options) встановлюється, чи дозволено перекриття для цього об'єкта. Коли меню «Чи не перекривати» (No Override) інші політики не можуть накласти свої настройки на установки даної. Якщо включена опція "Відключити" (Disabled), це означає, що GPO не застосовуватиметься на цьому рівні (до цього контейнеру). При встановленому прапорці «Блокувати спадкування політики» (Block Inheritance) політики верхніх рівнів ієрархії служби каталогів застосовуватися не будуть. Однак, якщо для політики вищого рівня включена опція «No Override», блокувати спадкування не вдасться.

У властивостях групових політик можна побачити дату створення, останньої зміни об'єкта GPO, його версію, GUID (Globally Unique Identifier, глобальний унікальний ідентифікатор) і домен, в якому розташовується об'єкт GPO. Тут же є можливість відключити налаштування конфігурації комп'ютера або користувача. На вкладці «Зв'язки» (Links) можна подивитися, з якими об'єктами служби каталогів GPO має зв'язок. В налаштуваннях безпеки вказується, яким групам користувачів надаються права на читання політики, зміна, застосування і т. Д. Нагадаю, що зв'язування і спадкування об'єктів GPO відбувається на рівні контейнерів. Але адміністратор може явно вказати, чи буде тієї чи іншої групи користувачів, що належать якомусь контейнеру, дозволено читання і застосування групових політик з об'єкта GPO, пов'язаного з цим контейнером. Таким чином, при використанні ACL (Access Control List, список контролю доступу), визначаються області дії політики на основі груп. На вкладці «Фільтр WMI» (WMI Filter) ви можете вибрати, чи буде застосовуватися до об'єкта політик фільтр WMI (Windows Management Instrumentation), і якщо так, то який.

При створенні об'єкт групової політики прив'язується до контейнера, для якого ви його створили. Цей GPO буде зберігатися в Active Directory і може бути застосований до інших контейнерів - сайтам, доменах і організаційних одиниць. Одночасно з цим ви можете видалити прив'язку GPO до контейнера, не видаляючи сам об'єкт GPO. Групові політики даного GPO до цього контейнеру застосовуватися не будуть, але сам об'єкт все ще буде існувати в службі каталогів. Таким чином, може виникнути ситуація, коли який-небудь об'єкт групової політики не буде пов'язаний ні з одним контейнером, але він все ще буде існувати в службі каталогів, і ви в будь-який момент зможете прив'язати його до сайту, домену або OU.

Кожен контейнер може мати зв'язок з декількома GPO, які будуть відображені в списку на вкладці «Групова політики». І, чим вище політика, тим вище її пріоритетність. Виграє є сама верхня в списку політика. Змінити пріоритетність ви можете, пересуваючи об'єкти вгору-вниз і змінюючи тим самим черговість. Важливо розуміти, що застосування параметрів при впливі багатьох політик відбувається знизу вгору, і, якщо політика в об'єкті GPO НЕ налаштована, вона не буде впливати на параметр. Таким чином, для параметра буде встановлено значення, визначене самим верхнім в списку об'єктом GPO, в якому політика налаштована.

Порядок застосування групових політик

При завантаженні комп'ютер отримує від контролера домену свого сайту список групових політик в тому порядку, в якому він повинен їх застосувати. Аналогічно при вході користувача в систему відбувається запит групових політик, визначених для контейнера, яким цей користувач належить, і подальше їх застосування. Далі в процесі роботи групові політики оновлюються у фоновому режимі кожні X хвилин, де X - величина, що лежить в інтервалі 60-120 хвилин. Цю величину можна змінити за допомогою групових політик, але не рекомендується робити її дуже маленькою, тому що це спричинить за собою витрати системних ресурсів через постійне звернення до контролера домену. Для контролерів домену групові політики оновлюються кожні 5 хвилин.

За обробку групових політик на комп'ютерах клієнтів відповідає набір динамічних бібліотек - клієнтських розширень групових політик. І, до речі кажучи, якщо на локальній машині не буде файлу scecli.dll (на комп'ютерах часто можна бачити подію з джерелом SceCli і описом «Політика безпеки в об'єктах групової політики успішно застосована»), то групові політики на ньому і зовсім не виконуватимуться .

Застосування групових політик користувача і комп'ютера в системах Windows NT 5 відбувається по-різному. У таблиці показано, як це відбувається в різних системах за замовчуванням. Попросту кажучи, в системі Windows XP політики застосовуються після того, як користувач вже бачить екран входу в систему. При вході в систему він відразу ж бачить робочий стіл, не чекаючи застосування всіх політик. Для підвищення безпеки таку поведінку можна змінити за допомогою параметра Computer Configuration / Administrative Templates / System / Logon / Always wait for the network at computer startup and logon.

Застосування групових політик користувача і комп'ютера в системах Windows NT 5

Операційна система

Завантаження

Вхід в систему

оновити регламент

Windows 2000

синхронно

синхронно

асинхронно

Windows XP

асинхронно

асинхронно

асинхронно

Windows 2003 Server

синхронно

синхронно

асинхронно

За замовчуванням політики користувача застосовуються після політик комп'ютера. Але може виникнути ситуація, коли зустрічаються політики, що впливають на один і той же параметр. У разі такого конфлікту, політики користувача беруть верх. Однак така поведінка не завжди прийнятно. Включення Loopback Processing (режим зворотної обробки) дозволяє вийти з цієї ситуації:

  • при встановленій опції Merge (злиття) відбувається об'єднання двох однакових для конфігурації комп'ютера і користувача політик: в разі, якщо політика для комп'ютера не визначена, а для користувача задана, виграє призначена для користувача політика; в разі ж, якщо політики конфліктують - виграє політика комп'ютера;
  • при встановленій опції Replace (заміна) призначені для користувача політики не обробляються.

Спадкування і порядок застосування групових політик в ієрархії служби каталогів

Головна формула застосування об'єктів GPO в доменах Active Directory така - LSDOU, що означає наступний порядок застосування (останні мають найвищий пріоритет):

  • локальні політики комп'ютера (Local Policies);
  • групові політики рівня сайту (Site);
  • групові політики рівня домену (Domain);
  • групові політики рівня організаційного підрозділу (Organizational Unit).

Однак, знаючи про те, що ієрархія служби каталогів може мати пристойну вкладеність OU один в одного, можна продовжити це правило: групові політики OU рівня 2, рівня 3 і т. Д.

Існує кілька способів, щоб перевизначити такий порядок застосування ГП (всі параметри можна задати у властивостях цільового контейнера на вкладці Group Policy або в системному реєстрі):

  • включити блокування успадкування групової політики з більш високого рівня (опція «Block Inheritance»);
  • заборонити перекриття політик більш високих рівнів політиками нижчих рівнів (опція «No Override»);
  • відключення застосування групової політики на заданому рівні ієрархії (опція «Disabled»);
  • використання списків контролю доступу (ACL) і інструментарію WMI.

Нагадаю, що при включеному перекритті групових політик блокування спадкування не обробляється.

Пошук і усунення несправностей при роботі з груповими політиками

Неважко зрозуміти, що групові політики в доменах Active Directory - інструмент наскільки гнучкий, настільки і складний. І, здавалося б, все вам зрозуміло і як на долоні весь домен. Ви створюєте групові політики, прив'язуєте їх до контейнерів, включаєте додаткові опції по перекриттю і спадкоємства, і чекаєте, коли налаштований вами механізм нарешті запрацює. Але щось йде не так, або взагалі нічого не відбувається. Ви в замішанні, але засмучуватися рано.

У складі Windows XP і Windows Server 2003 існує ряд утиліт, які допоможуть адміністратору в усуненні проблем з груповими політиками. Розглянемо їх докладніше.

Дуже часто на форумах доводиться бачити скарги про те, що у кого-то не застосовується групова політика, хоча всі параметри виставлені. Як вже говорилося, в процесі роботи політики застосовуються в фоновому режимі через заданий інтервал часу. А деякі з них взагалі вимагають перезавантаження комп'ютера. Однак існує можливість примусового застосування групових політик на конкретній машині. Її забезпечує утиліта командного рядка gpupdate. Вона має кілька параметрів, за допомогою яких можна визначити, як буде проведено оновлення політик. Наприклад, використовуючи параметр / Target, можна вказати, які політики повинні бути оновлені: користувача, комп'ютера або і ті й інші.

Для того щоб подивитися, які політики застосовуються на конкретній машині, використовується утиліта gpresult. Без заданих параметрів вона видає наступну інформацію для поточного користувача на даній машині:

  • контролер домену, з якого отримані об'єкти групової політики;
  • коли і які політики застосовувалися;
  • які політики не застосовувалися через фільтрацію;
  • членство в групах.

RSoP (Resultant Set of Policy, результуючі установки групових політик) - це графічний аналог утиліти gpresult з більш широкими можливостями. RSoP - це інструмент складання запитів, за допомогою якого адміністратор може отримувати інформацію про окремі системах, які політики на них були застосовані, в якому порядку і з яким старшинством.

RSoP працює в двох режимах: режимі реєстрації та режимі моделювання. У першому випадку вона бере інформацію з бази CIMOM (Common Information Management Object Model, об'єктна модель управління загальною інформацією), використовуючи WMI запити. Це можливо, тому що при вході комп'ютера в мережу і застосування до нього групових політик всі налаштування і зміни записуються в CIMOM.

У режімі моделювання ви можете побудуваті запит и отріматі інформацію про гіпотетічній результате! Застосування групових політик. Режими реєстрації та моделювання могут застосовуватіся для окрема Користувачів и комп'ютерів. Для сайтів, доменів і OU можливо виконати тільки моделюють запити. Для груп безпеки запити RSoP не можуть бути виконані. Хоча членство в певній групі може вплинути на кінцевий результат застосування політик. Запустити виконання запиту ви можете на контролері домену з оснащення Active Directory Users and Computers (див. Рис. 4).

Малюнок 4. Відкриття інструменту RSoP в DSA.MSC

Утиліта GPOTOOL перевіряє цілісність об'єктів GPO. Як ви пам'ятаєте, кожен такий об'єкт складається з двох частин: GPT - шаблон групової політики, і GPC - контейнер групової політики. Якщо однією з частин немає, політика працювати не буде. Одна з неприємних особливостей даної утиліти (хоча ця особливість властива багатьом утилітам для роботи з груповими політиками) - вона не показує дружні імена політик. Замість цього вона виводить їх GUID. У статті Q216359 можна подивитися спосіб, як зіставити GUID імені політики. Аналогічно для перегляду зрозумілого імені політик можна скористатися інструментом ADSI Edit.

Утиліта Dcgpofix допоможе відновити початкові настройки для групових політик за замовчуванням домену та контролера домену.

консоль GPMC.MSC

Ми розглянули більшість коштів по створенню, настройці і відладці групових політик. Але через їх розрізненості існують певні незручності для адміністратора. Тому компанія Microsoft випустила єдиний інструмент управління груповими політиками - консоль GPMC.MSC (див. Рис. 5), який дозволяє виконувати всі основні операції з адміністрування ДП. Він не входить до складу жодної з операційних систем, але доступний для вільного скачування на офіційному сайті Microsoft.

Малюнок 5. Консоль управління груповими політиками GPMC.MSC

GPMC.MSC є незамінним інструментом адміністратора з управління груповими політиками в рамках домену, який інтегрує в собі функціонал вищеописаних утиліт. На додаток до цього ви можете:

  • створювати резервні копії об'єктів GPO і здійснювати їх відновлення;
  • складати звіти у форматі HTML;
  • дивитися сконфігуровані настройки політик;
  • копіювати політики та імпортувати настройки політик;
  • використовувати функцію Drug'n'Drop для призначення прив'язки об'єктів GPO до контейнерів.

За допомогою GPMC.MSC не можна виконати оновлення групових політик, для цього вам доведеться вдатися до gpupdate.

Майбутнє групових політик

Ну і наостанок не можна не сказати кілька слів про реалізацію механізму групових політик в вийшла порівняно недавно Windows Vista. Почну з того, що в попередніх версіях операційних систем за обробку групових політик відповідав процес Winlogon, тоді як в Vista вони представляють собою цілу службу, яку з міркувань безпеки не можна зупинити. Консоль GPMC.MSC тепер є вбудованим компонентом операційної системи.

Vista має декілька локальних об'єктів GPO, що дозволяє по-різному налаштувати параметри локальних робочих станцій для адміністраторів і звичайних користувачів. Однак в рамках домену групові політики Active Directory мають більш високий пріоритет над локальними. Крім цього, адміністратори домену можуть вимкнути локальні політики.

Сам факт того, що в Vista додалося близько 800 нових параметрів політик, говорить про те, наскільки підвищиться керованість призначеним для користувача оточенням. Але запрацює цей механізм на повну тільки після виходу нової серверної версії операційної системи від Microsoft, так як поточні серверні ОС не підтримують управління новими параметрами групових політик в рамках домену.

На закінчення хотілося б дати кілька порад по роботі з груповими політиками:

  • не будуйте занадто складних стратегій по розгортанню ДП в домені; чим складніше схема, тим важче потім буде знайти і усунути причину неполадки;
  • уникайте застосування великої кількості GPO з конфліктуючими параметрами;
  • намагайтеся не захоплюватися використанням потрібну опцію заборони перекриття і блокування успадкування;
  • по можливості документуйте зміни, це дозволить швидше відстежити причину виникнення конфлікту або неполадки;
  • не експериментуйте на функціонуючому домені, краще використовуйте моделювання.

Багато тонкощі роботи з груповими політиками залишилися за рамками статті. Використовуйте статті бази знань Microsoft і спеціальну літературу в якості теоретичної бази для оволодіння кращими навичками управління мережевою інфраструктурою за допомогою групових політик.

  1. Олександр Ємельянов. Адміністрування користувачів в домені Active Directory. // «Системний адміністратор», №4, 2007 р

Новости