1. Як підготуватися до роботи з груповими політиками Кожному, хто використовує групові політики для...
2. Політики установки обмежень на комп'ютери користувачів
3. політики безпеки
4. Виявлення ненадійних політик
5. Політики, переваги і загублені настройки
6. Програмні засоби та методики
7. Перевірка, перевірка і ще раз перевірка

Як підготуватися до роботи з груповими політиками

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

Зворотним боком багатих можливостей даної технології є складність поширення групових політик і управління ними, а в ряді випадків некоректна установка параметрів може привести до несподіваних наслідків для користувачів і додатків. Саме наслідки подібних ненавмисних дій ми будемо розглядати в даній статті. Оскільки найбільш складним етапом при вирішенні такого роду проблем найчастіше є ідентифікація їх причин, спочатку мова піде про те, як грамотно підходити до дослідження причин виникнення найбільш типових неполадок, пов'язаних із застосуванням групових політик, після чого я розповім про декілька методиках усунення цих проблем.

Найбільш характерні типи проблем

Неполадки, які виникають в процесі використання групових політик, можуть приймати різні форми. Найчастіше вони проявляються у вигляді порушень роботи додатків на комп'ютерах користувачів. Або це можуть бути проблеми адміністрування, що виникають у фахівців, які обслуговують ці комп'ютери. Якщо говорити більш виразно, то в більшості відомих мені випадків подібні проблеми були пов'язані з двома основними типами політик, а саме з політиками установки обмежень на комп'ютери користувачів (desktop lockdown policies) і з політиками безпеки (security policies).

Політики установки обмежень на комп'ютери користувачів

В одній з мереж, супроводом яких я займаюся, використання політики приховування дисків Administrative Templates Hide Drives (User ConfigurationAdministrative TemplatesWindows ComponentsWindows ExplorerHide these specified drives in My Computer) призвело до відмови «старих» додатків. В результаті почали з'являтися повідомлення про помилки, які не мають ніякого відношення до групових політикам. Тому навіть в тих випадках, коли налаштування групових політик не зачіпають безпосередньо ті і чи інші додатки, що вносяться ними обмеження можуть призвести до ряду помилок, які не мають належного опису, що може збити з пантелику як користувача, так і адміністратора. Наприклад, якщо для заборони запуску деяких додатків задіяти політику User ConfigurationAdministrative TemplatesSystemDon? T run specified Windows applications, при спробі запуску відповідної програми користувач отримає стандартне повідомлення про помилку, показане на екрані 1.

При використанні адміністративних шаблонів політик (Administrative Templates) в реєстрі встановлюються відповідні параметри, які стосуються користувачам або комп'ютерів, значення яких будуть потім застосовуватися різними компонентами Windows для внесення обмежень і їх використання (до подібних компонентів належать, наприклад, Windows Explorer, Microsoft Internet Explorer ( IE) і Windows Media Player (WMP)). Зазначу, що можливість управління роботою цих компонентів Windows через групові політики була закладена спочатку, оскільки в процесі їх розробки була передбачена можливість роботи даних програм з параметрами реєстру, що відносяться до групових політикам. Іншими словами, для того щоб можна було керувати роботою додатка через групові політики, його розробник повинен свідомо закласти в нього можливість роботи з параметрами реєстру, що відносяться до групових політикам. Якщо для блокування або приховування тих чи інших компонентів програмного середовища комп'ютера застосовуються адміністративні шаблони політик, то вносяться ними обмеження можуть вплинути на роботу користувальницьких додатків найнесподіванішим чином.

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

У деяких випадках може взагалі не виводитися ніяких повідомлень про помилки, особливо якщо мова йде про взаємодію додатків незалежних компаній з системою, на якій діють установки політики щодо обмеження використання тих чи інших компонентів. Подібного роду взаємодії, як правило, бувають недостатньо повними, оскільки розробники таких програм не перевіряють їх на предмет можливості застосування в середовищі з діючими в ній обмеженнями і не використовують функції прикладного інтерфейсу API, що дозволяють взаємодіяти з параметрами групових політик. Таким чином, важливо знати, чи дотримуються постачальники програмного забезпечення специфікацій для додатків від компанії Microsoft, в яких, крім усього іншого, детально описується, як слід розробляти програми, щоб вони коректно взаємодіяли з механізмами групових політик. Специфікацію по розробці додатків для Windows XP (Designed for Windows XP Application Specification) можна завантажити за адресою: http://www.microsoft.com/downloads/ details.aspx? FamilyID = 44aa70b3-99d9-4529-9117-82cc0845938b & displaylang = en .

політики безпеки

Припустимо, адміністратору потрібно позбавити користувачів, які не мають адміністративних прав, можливості реєстрації на деяких серверах. У цьому випадку він повинен контролювати склад груп, які мають право локальної реєстрації (Logon locally) на відповідних серверах. І ось наш адміністратор, через неуважність, посилається на об'єкт GPO, який відповідає за політику домену, без установки фільтрів безпеки, розпорядчих застосовувати дану політику тільки до тих серверів, на які необхідно обмежити доступ. В результаті після того, як комп'ютери компанії опрацюють доменну політику, жоден з користувачів не зможе локально зареєструватися на своєму комп'ютері до тих пір, поки адміністратор не розбереться в тому, що сталося, і все ще виникають проблеми.

Це тільки один із прикладів проблем, які можуть виникнути під час налаштування політик безпеки. Слід розуміти, що багато з розглянутих вище установок обмежень за допомогою адміністративних шаблонів не є справжніми політиками безпеки. Вони просто не дають користувачам можливості порушувати роботу систем. Справжня безпека - в розділі групової політики Computer ConfigurationWindows SettingsSecurity Settings, де можуть встановлюватися обмеження на права користувачів, визначається політика паролів, дозволу на доступ до файлів, реєстру, службам і т. Д.

Налаштування політики безпеки можуть породжувати проблеми з різних причин. Припустимо, політика безпеки була випадково налаштована таким чином, що це спричинило за собою відмову ряду базових операцій. Наприклад, якщо на сервері або робочої станції були змінені настройки рівня аутентифікації NTLM (що може бути зроблено за допомогою установки Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options Network Security: LAN Manager authentication-level). В результаті буде отримано показане на екрані 2 повідомлення про помилку, а також буде заборонений доступ до мережевих ресурсів для клієнтів з більш ранніми версіями операційних систем (до них відносяться системи Windows 9x без встановленого на них клієнта служби каталогів, а також системи Windows NT 4.0 з встановленим пакетом оновлень Service Pack 3 або більш раннім). Отримувані при цьому повідомлення про помилки ніяк не відображають суть проблеми, але в той же час відрізняються від звичних повідомлень, що вказують, наприклад, на невірне ім'я користувача або пароль. У статті Microsoft «Client, Service, and Program Incompatibilities That May Occur When You Modify Security Settings and User Rights Assignments» (http://support.microsoft.com/default.aspx?scid=kb;en-us;823659) наведено прекрасний огляд налаштувань параметрів політики безпеки, здатних привести до проблем для різних версій Windows, а також даються рекомендації щодо виконання коректних налаштувань.

У ряді випадків виконання деяких налаштувань політики може привести до того, що буде заблокований вхід в систему для самого адміністратора. Розглянемо приклад, коли адміністратор здійснює управління локальними групами на робочих станціях і серверах домена за допомогою політики безпеки Restricted Groups. Дана політика часто використовується для роботи зі списками локальної групи «Адміністратори» на комп'ютерах з Windows. Застосування політики Restricted Groups може здійснюватися двома способами. У першому випадку при виборі варіанту Members of this group можна забезпечити членство в локальній групі "Адміністратори" тільки для заданих користувачів і груп, при цьому кожен раз, коли комп'ютер обробляє установки групової політики, всі інші облікові записи з цієї групи будуть автоматично видалятися. Інший варіант є менш жорстким: якщо використовується This group is a member of, це дозволяє адміністратору вказати для обраної групи, членом яких інших груп вона повинна бути. Цей варіант може використовуватися, наприклад, в тому випадку, коли в мережі потрібно включити в локальну групу «Адміністратори» кожної робочої станції з операційною системою Windows глобальну групу Desktop Admins. Одна з типових проблем виникає в тому випадку, коли адміністратори використовують варіант Members of this group для управління локальними групами «Адміністратори», забувши при цьому включити в даний список обліковий запис локального адміністратора або групу Domain Admins і, відповідно, блокуючи доступ до робочих станцій для самих себе. Оскільки в результаті використання даного параметра відбувається повна заміна списків членів відповідних груп, а не доповнення їх новими обліковими записами, допустити цю помилку дуже легко.

Зрозуміло, існує багато інших політик, які можуть привести до порушень роботи користувачів, але виходячи з особистого досвіду можу сказати, що причини більшості проблем (а особливо неочевидних) пов'язані з використанням об'єктів GPO, що відповідають за політики установки обмежень на комп'ютери користувачів і політику безпеки . Тому далі ми розглянемо деякі інструментальні засоби і методики, призначені для аналізу причин порушень роботи користувачів, пов'язаних з GPO.

Виявлення ненадійних політик

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

Якщо ви приступаєте до аналізу проблем, пов'язаних з груповими політиками, то перше, що треба зробити, - це запустити на проблемному клієнта звіт Resultant Set of Policy (RSoP). Даний звіт містить інформацію про те, які саме налаштування політики були передані даному клієнту, що дозволить звузити коло розглянутих причин виниклої проблеми. Набір використовуваних програмних засобів визначається версією операційної системи. Якщо, наприклад, на клієнтському комп'ютері встановлена ​​Windows 2000, слід використовувати утиліту командного рядка gpresult.exe з комплекту Microsoft Windows 2000, Resource Kit. Тут необхідно зазначити, що система Windows 2000 підтримує обмежений набір можливостей RSoP, внаслідок чого утиліта gpresult.exe не зможе видати повні результати за такими категоріями, як політики безпеки. Якщо ж ми маємо справу з Windows XP, то в цьому випадку в нашому розпорядженні є різні програмні засоби. Перший і найпростіший шлях - запустити оснастку rsop.msc, яка є в кожній системі Windows XP Professional. За допомогою даного засобу можна швидко отримати звіт RSoP по поточному користувачеві у форматі, подібному до форматом редактора групових політик (GPE), як показано на екрані 3.

Для того щоб віддалено створити звіт RSoP по клієнту з Windows XP, можна скористатися консоллю GPMS (Group Policy Management Console). Наявний в GPMS майстер Group Policy Results Wizard генерує звіт в форматі HTML, в якому міститься інформація по діючих політиків для користувача і комп'ютера, а також вказані об'єкти GPO, які ініціювали поширення даних політик. Крім того, до складу систем Windows Server 2003 і Windows XP включена більш повна версія утиліти gpresult.exe, за допомогою якої можна створювати звіт RSoP з командного рядка.

Після того як по установкам політик був отриманий звіт RSoP і стало ясно, з якими об'єктами GPO вони пов'язані, наступний крок буде полягати в тому, щоб звузити перелік можливих джерел проблем. Але перед цим важливо розібратися в механізмах застосування політик, особливо тих, які пов'язані з використанням адміністративних шаблонів.

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

Як зазначалося вище, компоненти системи Windows зчитують встановлені адміністративними шаблонами значення параметрів реєстру, які відповідають за управління функціонуванням або блокування компонентів. Всі діючі установки політик зберігаються в чотирьох розділах реєстру, два з яких відносяться до комп'ютера і два - до користувача. Параметри політики, що застосовуються до комп'ютера, зберігаються в таких розділах реєстру:

HKEY_LOCAL_MACHINESoftwarePolicies

HKEY_LOCAL_MACHINESoftwareMicrosoftWindows CurrentVersionPolicies

Власні параметри політики знаходяться в підрозділах:

HKEY_CURRENT_USERSoftwarePolicies

HKEY_CURRENT_USERSoftwareMicrsoftWindows CurrentVersionPolicies

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

Microsoft підтримує можливість створення адміністратором своїх шаблонів (файлів з розширенням .adm), що дозволяє визначати для запису параметрів політик підрозділи реєстру, відмінні від перерахованих вище. Шаблони, розроблені додатково, називаються уподобаннями (preferences), і з їх допомогою можна записувати дані в будь-які розділи реєстру. Шаблони переваг можуть стати в нагоді в тих випадках, коли потрібно записати в реєстр будь-якої параметр, а в стандартному постачанні від Microsoft немає необхідного файлу .adm (наприклад, в тих випадках, коли необхідно записати дані, не пов'язані з політиками, або задати налаштування Windows , які потрібно розмістити в інших розділах реєстру). Зокрема, можна створити файл .adm, який активізує ведення журналу подій по груповій політиці на комп'ютерах з Windows, при цьому всі параметри реєстру, що запускають цей процес, будуть уподобаннями. Зворотний бік використання переваг полягає в тому, що ці параметри не будуть видалені автоматично при відключенні застосування GPO для даного користувача або комп'ютера. Якщо це відбувається, то виникає ситуація, при якій зберігаються старі настройки, що було однією з типових проблем при роботі з системними політиками на Windows NT 4.0 і Win9x.

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

Файли .adm Використовують об'єкти GPO з тих політик, Які відображаються в GPE в Розділах Administrative Templates. Пріпустімо, ви модіфікувалі будь-який стандартний .adm файл від Microsoft, для того щоб з его помощью Додати до реєстру необхідні настройки перевага. У наступному випущеному пакеті оновлень для Windows розробники Microsoft оновили цей .adm файл, таким чином, установка пакета привела до втрати всіх внесених змін. А оскільки до цього моменту політика вже була активована, всі ці настройки були збережені в GPO. Однак ви більше не зможете побачити ці налаштування переваг в GPE, так само як і скасувати їх. Налаштування подібного типу називаються загубленими. Для того щоб відновити можливість керування цими налаштуваннями, потрібно повторно внести аналогічні зміни до відповідного .adm-файл. Більш кращим підходом в даній ситуації є створення окремого .adm-файлу, що описує необхідні настройки політики, а не редагування стандартного файлу від Microsoft.

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

Програмні засоби та методики

Якщо за даними звіту RSoP неможливо відразу ж визначити, яка настройка політики послужила причиною виниклої проблеми, слід спробувати звузити коло пошуку можливих її причин. У тих випадках коли незрозуміло, з якої саме категорією політик (політики на базі адміністративних шаблонів або політики безпеки) пов'язана виникла проблемна ситуація, можна спробувати кілька варіантів подальших дій. Слід мати на увазі, що, оскільки помилки, пов'язані із застосуванням політик на базі адміністративних шаблонів, більшою мірою збивають з пантелику, ніж помилки, пов'язані із застосуванням політик безпеки, першим покажчиком на можливу причину проблеми може служити характер повідомлення про помилку. Наприклад, якщо повідомлення містить текст типу Access Denied або Permission Denied, то це досить явно вказує на зв'язок проблеми із застосуванням політики безпеки, але не політики установки обмежень на комп'ютери користувачів, в той час як повідомлення про помилки, подібні до наведеного на екрані 1, швидше за за все, пов'язані із застосуванням політик на базі адміністративних шаблонів.

Якщо характер отриманого повідомлення недостатньо зрозумілий, існує кілька програмних засобів, здатних допомогти встановити причину неполадок. При дослідженні проблем, імовірно пов'язаних з адміністративними шаблонами, моїм улюбленим засобом є вільно розповсюджується утиліта regmon.exe від Sysinternals ( http://www.sysinternals.com ). У даній утиліті можна встановлювати фільтрацію звернень до реєстру за його розділами. Таким чином, якщо при виконанні дій, що призводять до проблемної ситуації, запустити regmon.exe, то можна відстежити всі звернення до чотирьох описаним розділах реєстру, що відповідає за політики, в результаті чого можна виявити параметр політики, який породжує цю проблему. На екрані 4 показано, як утиліта regmon.exe допомогла мені відстежити заданий політикою обмеження, що забороняє запуск програми PowerPoint. Наведений випадок, зрозуміло, є досить спрощеним (оскільки дану політику можна було б побачити і через звіт RSoP, не вдаючись до сортування за допомогою regmon.exe), проте на цьому прикладі можна зрозуміти ідею використання утиліти regmon.exe для відстеження проблем, пов'язаних з політиками адміністративних шаблонів, в тих випадках, коли звіт RSoP не містить достатньо інформації для ідентифікації причин проблеми.

Якщо є підозра, що виникла проблема пов'язана з політикою безпеки, потрібно спробувати ідентифікувати і відключити дану політику. Як зазначалося вище, застосування політики безпеки особливо часто призводить до переходу системи в стан збереження старих параметрів в тих випадках, коли не було скасовано відповідні налаштування перед відключенням чинного GPO. Тому для виключення подібного роду проблем слід з особливою ретельністю виявляти і скасовувати всі специфічні настройки безпеки. Якщо вимоги норм безпеки, прийнятих у вашій організації, забороняють скасовувати політики безпеки в масштабах всього підприємства, слід виділити для тестування групу з кількох робочих станцій і спробувати вирішити проблему на них. Для того щоб почати аналіз проблеми «з чистого аркуша» (з точки зору налаштування параметрів безпеки), найкраще задіяти файл шаблону безпеки setup security.inf, що дозволить привести настройки системи безпеки Windows у відповідність з параметрами за замовчуванням, які має операційна система відразу після завершення установки. У всіх системах Windows файл setup security.inf зазвичай зберігається в каталозі% windir% security emplates. Для того щоб застосувати даний шаблон, можна використовувати утиліту secedit.exe або імпортувати його в локальний об'єкт GPO на комп'ютері, для чого слід запустити GPE, натиснути правою кнопкою на розділі Computer ConfigurationWindowsSettingsSecurity Settings, після чого вибрати пункт Import Policy.

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

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

Перевірка, перевірка і ще раз перевірка

Групові політики мають досить багатими можливостями. Але якщо перед застосуванням GPO не виконуватимуться тестові заходи, це може привести до щоденних порушень роботи.

Слід завжди пам'ятати про те, що перед застосуванням нових налаштувань групової політики всі внесені зміни повинні бути ретельно протестовані. Якщо проблеми все ж виникли, то такі інструменти, як RSoP від ​​Microsoft і утиліта regmon.exe від SysInternals, допоможуть полегшити процес усунення неполадок.

Редактор журналу Windows IT Pro ( [email protected] )