ARUBA INSTANT WI-FI: ПРОСТІ, ПОТУЖНІ, ДОСТУПНІ
Налаштовуєте ви десять серверів Windows або настільних комп'ютерів або десять тисяч, знайте, що групова політика пропонує неоціненну допомогу у вирішенні цього завдання. Але багато, ймовірно, чули жахливі історії про складнощі групових політик, коли системний адміністратор вносив зміни, не розуміючи їх наслідків, і в результаті не спрощувала собі життя, а зовсім навпаки. Наприклад, змінивши дозволу Logon Locally в об'єкті групової політики Group Policy Object (GPO) для видалення непотрібних груп, ви можете виявити, що зробили це в GPO, який застосовується до всіх комп'ютерів в домені, і тепер ніхто не може зареєструватися. Я можу розповісти, як це сталося.
Подібні проблеми досить поширені. Але ви можете переконатися, що групова політика відповідає своїм потенціалом, оперуючи кількома основними концепціями: як застосовуються GPO, як працюють дозволу і фільтри, в чому різниця між політиками і уподобаннями і що в першу чергу слід зробити для виявлення проблем.
Розуміння роботи групової політики
Розібратися в тому, як клієнтська система працює з GPO, важливо для того, щоб гарантувати, що все відбувається згідно з планом. Давайте для початку зрозуміємо, що, незважаючи на присутність в назві функції слова «групові», політики застосовуються тільки для комп'ютера і користувача. Тому коли ви призначаєте Group Policy Object (GPO) об'єкту Active Directory (AD), комп'ютерна частина GPO застосовується тільки для об'єктів комп'ютера в AD, а призначена для користувача частина застосовується тільки для об'єктів. Можна використовувати групи безпеки, щоб виявити за допомогою фільтра, які користувачі і комп'ютери пов'язані з даними GPO, однак не можна націлити GPO на певні групи безпеки.
Слідуйте правилу: всякий раз, коли ви прив'язуєте GPO до об'єкта, домену або організаційного підрозділу (OU) в Active Directory, переконайтеся, що користувач або комп'ютер, з яким ви хочете, щоб він був пов'язаний, знаходиться в потрібному контейнері в ієрархічному дереві Active Directory .
Ви також можете повторно використовувати GPO, під'єднуючи його до кількох контейнерів AD, наприклад, можна з'єднати один накладає суворі обмеження на систему GPO з чотирма або п'ятьма OU. Сенс приєднання GPO до кількох контейнерів полягає в тому, що будь-яка зміна в GPO, яке буде внесено згодом, вплине на користувачів і комп'ютери в усіх з'єднаних з ним OU. Однак, оскільки можна під'єднати різні GPO до кількох контейнерів в AD, до конкретного користувача або комп'ютера можуть застосовуватися кілька GPO. Щоб дізнатися, яка політика реалізована в тому чи іншому випадку, потрібно відповісти на два питання:
Як Group Policy дізнається, який GPO слід обробляти в першу чергу?
Які настройки реалізуються, якщо різні GPO мають різні настройки?
Процес обробки Group Policy відбувається наступним чином. Локальний GPO на даному комп'ютері обробляється в першу чергу, потім GPO, під'єднані до сайту AD, далі GPO, під'єднані до домену AD, і, нарешті, ті, які під'єднані до OU. Оскільки GPO, під'єднані до OU, обробляються в останню чергу, вони в підсумку і визначають, які налаштування GPO застосовуються до комп'ютера або користувачеві. Наприклад, якщо призначений домену GPO видаляє команду меню Run з меню Start в Windows, а GPO, приєднаний до OU, додає цю команду назад в меню, настройки останнього будуть застосовні до комп'ютера або користувачеві, тому що система користувача обробляє цей об'єкт другим. Це призведе до того, що команда меню Run з'явиться в призначеному для користувача меню.
Дозволи Group Policy і фільтрація
Як показано на екрані 1. можна змінювати групи безпеки для даного GPO, просто додаючи або видаляючи групи з розділу Security Filtering в GPMC.
Припустимо, у вас є GPO, приєднаний до Marketing OU, який містить 200 облікових записів користувачів. Ви хочете додати деякі настройки в призначеній для користувача політиці частини цих користувачів, які є членами групи Marketing Special Projects. За допомогою GPMC це зробити дуже легко. Запустіть GPMC, ввівши gpmc.msc
Фільтрація за дозволами безпеки визначає, які комп'ютери і користувачі можуть обробляти GPO. Існують також дозволу, які вказують, хто може редагувати GPO. Ви можете побачити ці дозволи, виділяючи GPO в GPMC і вибираючи вкладку Delegation, як показано на екрані 2.
Ви можете пов'язати тільки один фільтр WMI з даними GPO. Якщо запит, зазначений у фільтрі, видасть результат True при читанні GPO, значить, цей об'єкт застосовується. Перевірка запиту WMI відбувається на клієнтському комп'ютері, який обробляє GPO. Запит досліджує власний місцевий репозиторій WMI, щоб отримати відповідь «вірно» або «невірно». Якщо запит повертає False, то GPO до користувача або комп'ютера не застосовується. Чи можна застосовувати фільтр WMI до комп'ютера або користувачеві, залежить від запиту. Наприклад, якщо запитується інформація про те, управляється чи комп'ютер за допомогою XP, це питання специфічне для кожного комп'ютера, і якщо комп'ютер управляється за допомогою XP, GPO застосує фільтр, незалежно від того, зареєструвався користувач на комп'ютері чи ні. Однак, якщо запитується інформація про те, чи зареєструвався користувач Джо Сміт на комп'ютері на даний момент, GPO застосує фільтр тільки тоді, коли Джо Сміт дійсно зареєструється в системі.
Політики або переваги
Ймовірно, найпопулярнішою частиною Group Policy є адміністративні шаблони, Administrative Templates, або політики реєстру. Ця область групових політик дозволяє контролювати багато аспектів системи Windows. Дуже зручно, що політика реєстру більше не прописується явно в реєстрі і відповідно не застосовується, коли не потрібна, як це було в NT 4.0. Відсутність явного прописування означає наступне: припустимо, ви включаєте (або відключаєте) елемент політики реєстру в GPO і застосовуєте його до користувача або комп'ютера, а потім видаляєте цей GPO або міняєте фільтр безпеки для користувача або комп'ютера. Під час наступного циклу оперативної або фонової обробки даний елемент політики буде автоматично видалений, а не «застрягне» в реєстрі, поки ви його примусово не видалите.
Процес видалення працює описаним способом, тому що Microsoft навмисно створила чотири спеціальні розділу реєстру, де записані всі політики, і вони видаляються, коли їх більше не застосовують. Двома розділами політик реєстру для комп'ютера є:
HKEY_LOCAL_MACHINESoftwarePolicies
HKEY_LOCAL_MACHINESoftware
MicrosoftWindowsCurrentVersionPolicies
Розділами політик реєстру для користувача є:
HKEY_CURRENT_USERSoftwarePolicies
HKEY_CURRENT_USERSoftware
MicrosoftWindowsCurrentVersionPolicies
Оскільки настройки політики реєстру пишуться в один з цих чотирьох ключів, вони не будуть залишатися в реєстрі, коли GPO видаляється. Звичайно, щоб записати політики в ці чотири розділи, додатки або компоненти в Windows повинні бути написані так, щоб вони опитували дані розділи на предмет налаштувань політик. Однак ви ще можете створювати файли шаблонів ADM (або ADMX в Vista), які можуть записувати в будь-які розділи реєстру (в HKEY_ LOCAL_MACHINE або HKEY_CURRENT_ USER). Політики, які це роблять, називаються «переваги» і будуть впроваджені в реєстр, навіть якщо GPO, що містить їх, був знищений. Таким чином, якщо вам потрібно скасувати перевагу, яке реалізовано, необхідно відключити його в інтерфейсі Group Policy Editor (GPE) або вручну видалити параметр реєстру.
Явна накладення налаштувань асоціюється з політиками реєстру, а й інші політики показують таку поведінку. Наприклад, політика безпеки примусово реалізує постійні зміни в системі, коли застосовується. Так, якщо ви задаєте призначені для користувача права в конкретній системі (використовуючи політику, знайдену по Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser rights assignment), і потім видаляєте GPO, який реалізував дані настройки звідти, звідки комп'ютер обробляв їх, ці призначення прав користувача залишаються до тих пір, поки ви їх явно не зміните. Це важливо зрозуміти, тому що кожна область політик поводиться по-різному, «залишаючи сліди» в системах. У деяких випадках, наприклад у випадку з політиками для Folder Redirection або Software Installation, необхідно вказати політиці, що робити, коли GPO більше не застосовується, як показано на екрані 3.
Діагностика несправностей в Group Policy
Групові політики - інструмент складний, і іноді вони працюють не так, як очікується. Через неуважність ви можете налаштувати щось не так або політика може не працювати просто через збій. Процес обробки Group Policy вимагає, щоб деякі компоненти працювали в згоді. Інфраструктура вашої AD і робочі станції повинні бути справні, а різні настройки, які ви задаєте, повинні бути сумісні з додатками, запущеними на комп'ютерах. Коли щось з перерахованого не так, ви можете побачити, що процес обробки Group Policy не виконано.
Вкладка Summary показує, які GPO були застосовані до комп'ютера і користувачеві, і, що найважливіше, які GPO були відхилені і чому. Розділ звіту Component Status може дати інформацію про те, чи всі частини процесу обробки Group Policy були виконані, і якщо ні, то чому. Елемент Group Policy Infrastructure, який ви побачите в цьому розділі, розповість про те, чи була базова частина процесу обробки Group Policy успішною. Якщо це не так, то зазвичай виявляються деякі проблеми в інфраструктурі, які заважають виконанню процесу обробки Group Policy. Якщо помилка з'являється в так званих розширеннях клієнта, які реалізують різні аспекти політики, можна усунути цю проблему, використовуючи представлені повідомлення про помилки. Якщо ви хочете подивитися, які налаштування індивідуальної політики були доставлені комп'ютера або користувачеві, ви можете відкрити вкладку Settings в підсумковому звіті по Group Policy, щоб побачити, які налаштування в результаті були застосовані. Однак повідомлення про застосування налаштувань в звіті RSoP ще не означає, що вони були виконані успішно. Краще іноді перевіряти базові настройки, щоб дізнатися, чи зроблена дана настройка в рамках застосування політики безпеки або існує значення параметра реєстру.
Group Policy складні і могутні. Зрозумівши, як вони обробляються, ви зможете в повній мірі використовувати їх силу. Пам'ятайте, що Group Policy обробляються в наступному порядку: локальний GPO, сайт AD, домен, потім OU (іноді для цієї послідовності застосовують скорочення LSDOU) і, в типовій ситуації, «що пише останнім виграє», якщо є конфліктуючі настройки. Політики і переваги можуть впливати на те, як політика «залишає сліди» в системах, коли GPO видаляється, що важливо при виборі на користь того чи іншого інструменту. Політики реєстру, поширювані Microsoft в стандартних файлах ADM і ADMX, зазвичай не змінюють реєстр, але створені самостійно файли ADMX можуть це робити. До того ж інші аспекти політики, такі як безпека, змінюють системи і повинні бути явно і примусово скасовані, тоді як деяким частинам політики потрібно вказати, що слід скасувати свої дії, коли вони більше не застосовуються. Нарешті, якщо політика все-таки працює не так, як очікувалося, зверніться до майстра Group Policy Results в GPMC.
Поділіться матеріалом з колегами і друзями