Видаляємо розширення схеми AD

1. невелике вступ
2. Навіщо видаляти розширення схеми
3. Запобіжні заходи
4. Видалення об'єктів схеми
5. Як це робиться

Наша взаимовыгодная связь https://banwar.org/

У багатьох книгах і статтях, присвячених схемою Active Directory, - навіть в тих, що підготовлені фахівцями Microsoft, - стверджується, ніби видалення класів або атрибутів зі схеми AD неприпустимо. Це створює проблеми для адміністраторів AD, оскільки в подібних умовах тестувати нові розширення схеми складно, а видалення непотрібних розширень і зовсім виявляється неможливим. Припустимо, потрібно перевірити процес розширення схеми в тестовому лісі. Зрозуміло, що в разі виникнення помилки в ході випробувань процедуру потрібно повторити. Але видалення розширень не допускається, і залишається тільки знову формувати ліс. Або інша ситуація: додається розширення в наявний ліс, але воно виявляється неправильним. Взяти б і просто видалити це розширення - але ні, така можливість не передбачена.

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

невелике вступ

Схема AD визначає порядок, відповідно до якого служба каталогу AD представляє і структурує дані. Знати основи функціонування схеми повинен кожен адміністратор. Більш повне уявлення про схему можна отримати, прочитавши статті «Diving into the AD Schema» September 2001, http://www.winnetmag.com , InstantDoc ID 21839, і «Extending the AD Schema» November 2001, http://www.winnetmag.com , InstantDoc ID 22540.

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

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

Але якщо розширення схеми представляється настільки важливим завданням у справі адміністрування служби AD, можливість видалення розширень схеми може бути виключно корисною. Багато з них були розчаровані тим обставиною, що розробники Microsoft не вважали за потрібне реалізувати в Windows 2000 кошти для видалення розширень схеми. Правда, в їх захист можна привести один суттєвий аргумент. Справа в тому, що видалення з схеми атрибутів і класів - операція вельми делікатна, і, якщо при її виконанні допускаються помилки, це може обернутися воістину катастрофічними наслідками для всієї інфраструктури AD.

Так, видалення класу при збереженні його об'єктів може привести до неузгодженості даних або до виникнення ситуації, коли існують об'єкти класу, що не має визначення. Звичайно, реалізована в службі AD розподілена архітектура реплікації - річ корисна, але вона ускладнює здійснення надійного процесу видалення розширень схеми. Адміністратор не може гарантувати, що даний об'єкт не використовує той чи інший клас або атрибут, до тих пір поки об'єкт не буде видалений. А адже після видалення класу або атрибуту з контролера домену (domain controller, DC) якийсь час йде на те, щоб сповіщення про видалення надійшло на інші контролери доменів. І за цей час один з додатків цілком може створити на не повідомлених про видалення контролері домену об'єкт на основі даного класу або з використанням даного атрибута.

Хоча розробники Microsoft не передбачили процедури видалення класів або атрибутів, їх можна зробити недоступними подібно до того, як ми відключаємо обліковий запис користувача. Після відключення об'єкт продовжує існувати в середовищі AD, але його вже не можна використовувати ні для створення інших об'єктів, ні для формування визначень інших класів. В інфраструктурі Microsoft .NET функція відключення доступу до об'єкта отримує подальший розвиток. Адміністратор може при необхідності перевизначити (т. Е. Відтворювати, але не знову активізувати) недоступні класи або атрибути.

Навіщо видаляти розширення схеми

Може виникнути питання: а навіщо тоді взагалі ставити питання про видалення елементів схеми - адже їх можна просто зробити недоступними? Назвемо дві основні причини. Видалення елементів схеми може знадобитися, по-перше, для тестування нових розширень схеми, а по-друге, для видалення зайвих класів і атрибутів.

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

Є й третя причина, яка спонукає ставити питання про видалення елементів схеми AD: так можна позбавлятися від розширень, створених додатками, які вже виведені з експлуатації. На дуже багатьох підприємствах з різних причин одні додатки встановлюються, а інші ліквідуються. Майже напевно прикладна програма, для якої раніше розширили схему, коли-небудь буде виведена з експлуатації. Видалення елементів схеми дозволяє усунути всі сліди існування цієї програми, збережені в середовищі AD. Згодом число «осиротілих» класів і атрибутів буде тільки зростати, так що необхідність позбавлення схеми від баласту стане ще більш очевидною.

Запобіжні заходи

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

• Видаляйте тільки ті об'єкти схеми, які створеними об'єктами не використовуються. У середовищі AD, особливо в мережах з великою кількістю контролерів доменів, немає можливості гарантувати, що той чи інший клас або атрибут не застосовується. Для формування запитів до одного або кількох контролерів доменів адміністратор може скористатися таким засобом, як Ldp (воно входить в набір Windows 2000 Support Tools kit). У більшості випадків Ldp дозволяє визначити, чи використовують об'єкти даний клас або атрибут. Програма не зможе виконати це завдання лише в тому випадку, якщо якесь додаток створило об'єкт, який використовує даний клас або атрибут, але сам об'єкт ще не був реплицироваться на контролер домену, до якого направлено відповідний запит Ldp. У даній ситуації рекомендується організувати форсоване тиражування за допомогою засобів Replmon або Repadmin (вони теж входять в комплект Support Tools).
• Не знімайте об'єкти схеми з базової схеми AD. В принципі це можливо, однак треба мати на увазі, що видалення стандартних класів або атрибутів може обернутися порушеннями у функціонуванні служби AD. При цьому не виключено, що додатки (наприклад, Microsoft Exchange 2000 Server) будуть вести себе несподіваним чином. Розробники Microsoft і багато постачальників програмного забезпечення виходять з того, що стандартні елементи схеми AD будуть завжди присутні в системі, і програмні засоби часто намагаються організувати як зберігання даних, так і запити на їх отримання з використанням існуючих об'єктів схеми.
• Операції з видалення проводите тільки в тестових лісах, а також в лісах, виділених для групи розробки. Процедура видалення об'єктів схеми поки що досліджена мало. Крім того, з огляду на, що Microsoft не дає санкції на цю операцію, не варто робити спроби видалення в наявному лісі, не провівши попередньо всебічні випробування і не отримавши чіткого уявлення про наслідки можливого порушення цілісності схеми.
• Після видалення непотрібних об'єктів схеми зробіть недоступною функцію видалення елементів схеми. Завжди корисно відключати функцію модернізації, коли немає необхідності в зміні схеми. Точно так же слід визнати вдалою ідею блокувати можливість видалення елементів схеми, коли не потрібно видаляти з неї об'єкти. Це дозволить виключити можливість випадкових змін.
• Необхідно пам'ятати про те, що, якщо внаслідок видалення класу або атрибуту виникне якась проблема, фахівці Microsoft, можливо, не стануть надавати допомогу, бо видалення елементів схеми не документовано, і в програмному забезпеченні відповідна можливість не передбачена. Мало того, представники Microsoft майже напевно будуть стверджувати, що видалення елементів схеми попросту неможливо.

Видалення об'єктів схеми

Підготовка схеми до видалення не викликає ускладнень. Процес складається з двох етапів. Спочатку потрібно модифікувати список управління доступом (access control list, ACL) контейнера Schema (cn = Schema, cn = Configuration, ForestDN, де ForestDN - це складене ім'я - distinguished name, DN - ліси). Таким чином, буде отримано дозвіл на видалення об'єктів-нащадків. Далі потрібно включити функцію модифікації схеми.

Модифікація списку управління доступом. Для внесення змін до списку керування доступом члени групи Schema Admins можуть скористатися оснащенням ADSI Edit консолі Microsoft Management Console (MMC). За замовчуванням члени груп Enterprise Admins і Domain Admins необхідними правами на внесення змін в контейнер Schema не наділяє.

У вікні оснащення ADSI Edit слід додати запис для контейнера Schema, який потрібно редагувати в даному лісі (якщо, звичайно, такого запису поки немає). Необхідно розкрити запис для контейнера Schema і натиснути правою кнопкою миші на папці з складовим ім'ям контейнера Schema, як показано на Екрані 1. Потім слід клацнути на елементі Properties і на закладці Security і вибрати групу, членам якої потрібно надати право видаляти елементи схеми (наприклад, Schema Admins). Після цього в розділі Permissions потрібно встановити прапорець Allow для пункту Delete All Child Objects, як показано на Екрані 2.

Тепер при натисканні на кнопці OK членам відповідної групи буде надано право на видалення елементів схеми. Для виконання цієї процедури можна також використовувати оснастку Schema консолі MMC. При необхідності процедуру можна навіть автоматизувати за допомогою утиліти Dsacl (поставляється в комплекті Support Tools kit).

Включення функції оновлення схеми. Будь-які модифікації схеми, в тому числі видалення її об'єктів, можуть здійснюватися лише на контролерах доменів, наділених роллю майстра схеми, і тільки після того, як в реєстр контролер домену будуть внесені зміни, що забезпечують функцію модифікації схеми. Значення параметра Schema Update Allowed (типу REG_DWORD) з підрозділу реєстру HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesNTDSParameters має бути встановлено рівним 1. Щоб змінити цю установку можна скористатися редактором реєстру або встановити прапорець Allow Schema Updates в оснащенні Schema.

Видаляти об'єкти схеми можна декількома способами. Наприклад, є можливість робити це безпосередньо, за допомогою інструментів ADSI Edit або Ldp, як видаляються об'єкти будь-якого іншого типу. Однак потрібно мати на увазі, що існують обмеження, як по об'єктах, дозволеним до видалення, так і по порядку видалення. Наприклад, не допускається видалення атрибута, якщо він визначений як частина належить класу атрибута mayContain або mustContain; крім того, не можна видалити клас, якщо він визначений як частини належного іншого класу атрибута subClassOf.

Як це робиться

Можливо, гідності функції видалення елементів схеми найяскравіше проявляються в процесі тестування або розробки розширень схеми в тестовому лісі. Буває, що для тестування розширень адміністратору доводиться розширювати схему знову і знову. Для створення розширень схеми я рекомендую використовувати файли формату LDAP Data Interchange Format (LDIF). Формат описаний в документі Request for Comments (RFC) 2849, який був підготовлений комітетом IETF (Internet Engineering Task Force). Файли LDIF зручні для читання і мають оптимальний формат. Застосовуючи файли LDIF для модифікації схеми, можна отримати простий засіб відстеження змін в схемі, яке зручно зберігати і архівувати. У лістингу 1 представлений простий LDIF-файл з ім'ям add.ldf. Файл створює новий допоміжний клас (xyz-ITUser) і два атрибути (xyz-ITDeptName і xyz-ITBldg-Name). За допомогою класу xyz-ITUser можна розширити клас user так, щоб він містив два нових атрибута. Цей підхід широко використовується для розширення існуючих класів об'єктів, таких, як user.

Код в мітках A і B лістингу 1 створює атрибути xyz-ITBldgName і xyz-ITDeptName, відповідно. Рядки в мітці C лістингу 1 модифікують кеш схеми. Подібна модифікація кеша необхідна для того, щоб атрибути xyz-ITBldgName і xyz-ITDeptName могли бути описані в мітці D лістингу 1 як частина класу xyz-ITUser. У решти файлу модифікується кеш схеми; таким чином, внесені в новий клас зміни фіксуються негайно.

Для імпорту та експорту файлів LDIF можна використовувати утиліту Ldifde, яка встановлюється на будь-якій машині Windows 2000. Для імпорту розширень схеми, виконаних в лістингу 1, потрібно ввести наступну команду:

Ключ -i включає режим імпорту, ключ -v (verbose) забезпечує розширений висновок, а ключ -f вказує ім'я LDIF-файлу, який належить імпортувати. Щоб провести аналогічний тест в умовах конкретної мережі, слід замінити всі вирази DC = xyz, DC = com в лістингу 1 складовим ім'ям лісу, де буде проводитися випробування. Якщо утиліта Ldifde виконується в мережі на не наділена роллю майстра схеми контролері домену, потрібно буде використовувати ключ -s для вказівки імені такого контролера.

Тепер, коли є файл LDIF, що забезпечує додавання розширень схеми, можна приступати до створення ще одного файлу LDIF - delete.ldf, - містить команди на видалення даних розширень. В лістингу 2 міститься код у форматі LDIF, який би видалення класу і атрибутів, створених за допомогою коду, представленого в лістингу 1. Внаслідок обмежень на видалення, про які говорилося раніше, перш за все, слід видаляти клас xyz-ITUser, описаний в мітці A лістингу 2, і тільки після цього - атрибути, описані в мітках B і C лістингу 2. Знову-таки можна використовувати утиліту Ldifde для виконання файлу LDIF на контролері домену і видалити зазначені розширення схеми:

Так само, як і в уже розглянутому випадку з Листингом 1, буде потрібно замінити всі зустрічаються в лістингу 2 вирази DC = xyz, DC = com складовим ім'ям лісу, в якому проводиться тестування.

Зрозуміло, операції по додаванню, модифікації або видалення розширень схеми виробляються не тільки за допомогою файлів LDIF. Всі ці дії можна виконувати вручну, використовуючи утиліту ADSI Edit, або програмним шляхом, за допомогою Perl, VBScript і інших мов.

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

Роббі Ален - системний архітектор і програміст в ІТ департаменті Cisco Systems. Співавтор книги «Managing Enterprise Active Directory Services» (Addison-Wesley). З ним можна зв'язатися за адресою: [email protected] .