Як відомо, нічого вічного немає, все змінюється, особливо в такій галузі як IT. Розгорнута один раз інфраструктура постійно розвивається, розширюється, удосконалюється і настає момент коли у вашу Active Directoryпотрібно ввести контролер домену під керуванням більше пізньої версіїопераційна система.

Здавалося б, у чому проблема? Але, як показує практика, проблеми виникають багато в чому від того, що системні адміністратори слабо володіють теорією і відверто плутаються в даному питанні. Тому саме час розібратися в тому, що таке схема ADі яке відношення вона має до нашої нагоди.

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

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

Начебто зрозуміло, але не зовсім, тому перейдемо до поширених помилок та помилок.

• Оновлення схеми необхідне для включення до домену ПК під керуванням новіших версій Windows. Це не так, навіть самі останні версії Windows можуть успішно працювати в домені рівня Windows 2000 року без оновлення схеми. Хоча, якщо ви таки оновите схему, то нічого страшного не станеться.

• Для включення в домен контролера під управлінням новітньої ОС потрібно підвищити рівень роботи домену (лісу). Це теж не так, але на відміну від попереднього випадку, дана операція унеможливить використання контролерів домену під управлінням ОС нижче, ніж режим його роботи. Тому в разі помилки вам доведеться відновлювати структуру AD з резервної копії.

Також загостримо вашу увагу на режимі роботи лісу та домену. Домени, що входять до лісу, можуть мати різні режимироботи, наприклад один з доменів може працювати в режимі Windows 2008, а інші в режимі Windows 2003. Схема роботи лісу не може бути вищою, ніж схема роботи найстарішого домену. У нашому прикладі режим роботи лісу не може бути вищим, ніж Windows 2003.

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

Ознайомившись із теорією, перейдемо до практичному прикладу. Допустимо у нас є домен рівня Windows 2000 (змішаний режим) низький рівень AD - в якому є контролер під керуванням Windows 2003, а наша мета - створити новий контролер замість того, що вийшов з ладу.

Новий сервер працює під керуванням Windows 2008 R2. Зауважте, у нас не виникло жодних складнощів щодо включення даного серверау існуючий домен.

Однак при спробі додати новий контролер домену ми отримаємо помилку:

Для успішного включення контролера під управлінням новітньої версії ОС нам потрібно буде оновити схему лісу та схему домену. Виняток становить Windows Server 2012, який при додаванні нового контролера домену здійснить оновлення схеми самостійно.

Для оновлення схеми використовується утиліта Adprep, яка знаходиться в папці \support\adprepна настановному диску Windows Server. Починаючи з Windows Server 2008 R2, ця утиліта за замовчуванням 64-розрядна, за необхідності використовувати 32-розрядну версію слід запускати adprep32.exe.

Для відновлення схеми лісу дана утилітамає бути запушена на Господарі схеми, а для оновлення схеми домену на Господарі інфраструктури. Щоб дізнатися, які з контролерів мають необхідні нам ролі FSMO, скористаємося командою:

Netdom query FSMO

У Windows 2008 і новіше цю утиліту встановлено за замовчуванням, а в Windows 2003 її потрібно встановити з диска з директорії \support\tools

Результатом виведення цієї команди буде перерахування всіх ролей FSMOта контролерів мають дані ролі:

У нашому випадку всі ролі знаходяться на одному контролері, тому копіюємо папку \support\adprepна жорсткий диск(У нашому випадку в корінь диска C:) і приступаємо до оновлення схеми лісу. Для успішного виконання операції ваш обліковий запис повинен входити до груп:

• Адміністратори схеми
• Адміністратори підприємства
• Адміністратори домену, в якому знаходиться господар схеми

Щоб оновити схему лісу, виконайте команду:

C:\adprep\adprep /forestprep

Ознайомтеся зі стандартним попередженням та продовжіть натиснути C, потім Enter.

Розпочнеться процес оновлення схеми. Як бачимо, її версія зміниться з 30 (Windows 2003) до 47 (Windows 2008 R2).

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

Для успішного оновлення схеми домену цю операцію слід проводити на Господарі інфраструктурита мати права Адміністратора домену. Виконуємо команду:

C:\adprep\adprep /domainprep

І уважно читаємо інформацію, що виводиться. Оновлюючи схему домену з рівня Windows 2000 або Windows 2003, необхідно виконати зміну дозволів файлової системидля групових політик. Дана операція проводиться один раз і в подальшому, наприклад, оновлюючи схему з рівня 2008 на 2008 R2, виконувати її потрібно. Щоб оновити роздільну здатність об'єктів GPO, введіть команду:

З: \ adprep \ adprep / domainprep / gpprep

У версіях AD з Windows 2008 з'явився новий типконтролерів домену: контролер домену тільки для читання (RODC), якщо ви плануєте розгорнути такий контролер, то вам потрібно підготувати схему. Взагалі ми рекомендуємо виконати цю операціюнезалежно від того, чи збираєтеся ви найближчим часом встановлювати RODC чи ні.

Цю операцію можна виконати на будь-якому контролері домену, однак ви повинні входити до групи Адміністратори підприємстваі Господар іменуваньі Господар інфраструктуримають бути доступні.

C:\adprep\adprep /rodcprep

Як бачимо, оновлення схеми домену, будучи правильно сплановано, не викликає будь-яких труднощів, однак у будь-якому випадку слід пам'ятати, що це незворотня операція і мати під рукою необхідні резервні копії.
Джерело http://interface31.ru/tech_it/2013/05/obnovlenie-shemy-active-directory.html

Важко недооцінити важливість Схеми Active Directory для мереж, побудованих на базі доменного середовища Active Directory. Це основа технології AD і дуже важливо правильно розуміти принципи її функціонування. Більшість системних адміністраторівне приділяють схеми належної уваги через те, що мати справу з нею доводиться досить рідко. У цій статті я розповім, що таке версія схеми, для чого нам необхідно її знати і найголовніше поточну версію. Перш за все, кілька слів про саму схему, кожен об'єкт, створений в Active Directory, будь то користувач або комп'ютер, має певні параметри, які називаються атрибутами. Самим простим прикладомможе бути атрибут «Прізвище» у об'єкта користувач. Схема визначає, які об'єкти ми можемо створювати в Active Directory, і які атрибути вони будуть мати. різних версій Windows. А саме – на базі Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Оскільки дані версії випускалися в різні роки, і кожна Нова версіянесе більший функціонал, ніж попередня, розуміння схеми кожної операційної системи своє. Тому при додаванні нового контролера на базі Windows Server 2008 до організації, де існуючі контролерипобудовані на Windows Server 2003, вам доводилося запускати утиліту “ Adprep“. Тим самим ви оновлювали схему вашої організації до рівня, з яким працює Windows Server 2008

Процес оновлення схеми виконувався до встановлення першого контролера Windows Server 2008 і власне сама процедура встановлення нового контролера могла і не виконуватися. Якщо ви тільки починаєте працювати з якоюсь організацією Active Directory і не знаєте, які дії здійснювалися до вашого приходу, вам для розуміння повноти структури потрібно знати, на якому рівні працює Схема поточної організації.

Спонсор посту

Усі новинки прокату, найкращі фільми минулих років. Найкращі улюблене кіно на 5ic.ru

Можливі версії схеми:

13 - Windows 2000 Server
30 - Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 - Windows Server 2003 R2
44 - Windows Server 2008 RTM

Навіть якщо всі контролери у вашій організації працюють на Windows Server 2003 R2, а версія схеми показує "44" не варто дивуватися, це говорить про те, що вже було здійснено оновлення схеми до рівня Windows Server 2008 RTM, але сам контролер за якоюсь причину встановлювати не стали.

Подивитися версію схеми можна кількома способами. Найпростішим є спосіб використання утиліти «DSQuery». Для цього в командному рядку необхідно ввести команду з наступними параметрами:

"dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion"

Звичайно в частині « dc= domainname, dc= local» ви повинні підставити ім'я власного домену. (Приклад: dc= microsoft, dc= com )

Результатом введення команди є отримання атрибуту “ ObjectVersion“, який і буде номером версії схеми:

Мал. 1Отримання версії схеми через утиліту "DSQuery".

Другий спосіб більш довгий і передбачає використання оснастки “ ADSIEdit. msc“ . Щоб переглянути версію схеми вам доведеться підключитися до розділу Active Directory схема.

“CN=Schema,CN=Configuration,DC=domain,DC=local“

І знайти значення атрибуту “ objectVersion“.

Рис.2Отримання версії схеми через оснастку “ ADSIEdit. msc“.

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

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

Схема Active Directory Exchange сервером можна за атрибутом « rangeUpper», який приймає такі значення:

4397 - Exchange Server 2000 RTM
4406 - Exchange Server 2000 With Service Pack 3
6870 - Exchange Server 2003 RTM
6936 - Exchange Server 2003 With Service Pack 3
10628 - Exchange Server 2007
11116 - Exchange 2007 With Service Pack 1

Як можна помітити, оновлення схеми відбувається і при установці набору оновлень SP3 для Exchange Server 2000/2003 і SP1 для Exchange 2007.

Переглянути значення атрибута « rangeUpper» можна через утиліту DSQuery:

"dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

Мал. 3Отримання атрибуту « rangeUpper» через утиліту DSQuery.

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

Процес оновлення схеми є дуже важливим моментомдля кожного організації Active Directory, тому слід уникати зайвих, невиправданих дій. Розуміючи суті атрибутів “ objectVersion” та « rangeUpper» дає фахівцю перевагу при роботі з Active Directory у незнайомій організації, а також є допоміжним інструментом у вирішенні проблем.

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

Active Directory допускає використання у межах однієї організації кілька контролерів домену, побудованих з урахуванням різних версій ОС Windows. А саме – на базі Windows Server 2000, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008. Оскільки дані версії випускалися в різні роки, і кожна нова версія несе більший функціонал, ніж попередня, розуміння схеми кожної операційної системи своє. Тому при додаванні нового контролера на базі Windows Server 2008 в організацію, де існуючі контролери побудовані на Windows Server 2003, вам доводилося запускати утиліту. Adprep». Тим самим ви оновлювали схему вашої організації до рівня, з яким працює Windows Server 2008

Процес оновлення схеми виконувався до встановлення першого контролера Windows Server 2008 і власне сама процедура встановлення нового контролера могла і не виконуватися. Якщо ви тільки починаєте працювати з якоюсь організацією Active Directory і не знаєте, які дії здійснювалися до вашого приходу, вам для розуміння повноти структури потрібно знати, на якому рівні працює Схема поточної організації.

Можливі версії схеми:

13 – Windows 2000 Server
30 – Windows Server 2003 RTM, Windows 2003 With Service Pack 1, Windows 2003 With Service Pack 2
31 – Windows Server 2003 R2
44 – Windows Server 2008 RTM

Навіть якщо всі контролери у вашій організації працюють на Windows Server 2003 R2, а версія схеми показує "44" не варто дивуватися, це говорить про те, що вже було здійснено оновлення схеми до рівня Windows Server 2008 RTM, але сам контролер за якоюсь причину встановлювати не стали.

Подивитися версію схеми можна кількома способами. Найпростішим є спосіб використання утиліти «DSQuery». Для цього в командному рядку необхідно ввести команду з наступними параметрами:

"dsquery * cn=schema,cn=configuration,dc=domainname,dc=local -scope base -attr objectVersion"

Звичайно в частині « dc= domainname, dc= local» ви повинні підставити ім'я власного домену. (Приклад: dc= microsoft, dc= com )

Результатом введення команди є отримання атрибуту ObjectVersion», який і буде номером версії схеми:

Мал. 1Отримання версії схеми через утиліту "DSQuery".

Другий спосіб більш довгий і передбачає використання оснастки. ADSIEdit. msc» . Щоб переглянути версію схеми вам доведеться підключитися до розділу Active Directory схема.

"CN=Schema,CN=Configuration,DC=domain,DC=local"

І знайти значення атрибута objectVersion".

Рис.2Отримання версії схеми через оснастку ADSIEdit. msc».

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

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

Чи зрозуміти була зміна
нена Схема Active Directory Exchange сервером можна за атрибутом « rangeUpper», який приймає такі значення:

4397 – Exchange Server 2000 RTM
4406 – Exchange Server 2000 With Service Pack 3
6870 – Exchange Server 2003 RTM
6936 – Exchange Server 2003 With Service Pack 3
10628 – Exchange Server 2007
11116 – Exchange 2007 With Service Pack 1

Як можна помітити, оновлення схеми відбувається і при установці набору оновлень SP3 для Exchange Server 2000/2003 і SP1 для Exchange 2007.

Переглянути значення атрибута « rangeUpper» можна через утиліту DSQuery:

"dsquery * CN=ms-Exch-Schema-Version-Pt, cn=schema, cn=configuration, dc=domainname, dc=local -scope base -attr rangeUpper"

Мал. 3Отримання атрибуту « rangeUpper» через утиліту DSQuery.

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

Процес оновлення схеми є дуже важливим моментом для кожної організації Active Directory, тому слід уникати зайвих невиправданих дій. Розуміючи суті атрибутів objectVersion» і« rangeUpper» дає фахівцю перевагу при роботі з Active Directory у незнайомій організації, а також є допоміжним інструментом у вирішенні проблем.

07.04.2011 Браян Десмонд

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

Схема AD визначає структуру даних, збережених у каталозі. Спочатку AD підтримує багато типів об'єктів (наприклад, користувачі) та атрибутів (наприклад, ім'я та прізвище). Якщо базова схема AD погано узгоджується з даними, які потрібно зберігати в каталозі, її можна доповнити об'єктами користувача та атрибутами.

Зазвичай схему AD розширюють з кількох причин, найпоширенішою з яких у багатьох організаціях є застосування, що вимагає розширення схеми. Наочний приклад - Microsoft Exchange. Іноді постачальники програмного забезпеченнявимагають розширити схему сумісності зі своїми додатками. Часто схему розширюють для додатків власної розробкиабо для зручності зберігання даних компанії AD.

Варіанти зберігання даних

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

Якщо дані не відповідають цим критеріям, але все ж таки повинні розміщуватися в каталозі LDAP, оптимальний другий варіант. Служби каталогів AD Lightweight Directory Services (AD LDS, в минулому ADAM) - автономна версія AD, яка може функціонувати як служба на сервері, члені домену (або контролері домену - DC), і, подібно до AD, обробляти запити, що направляються до LDAP. Необхідність розміщувати контролери домену AD для перевірки достовірності та підтримки додатків - не прикре обмеження, а можливість суворо контролювати коло осіб, які мають право читати дані, та направлення реплікації даних шляхом розміщення екземплярів AD LDS у відповідних місцях.

Примітиви зберігання даних

Ключову роль розуміння схеми AD грають два терміни: клас і атрибут. Всі елементи AD, у тому числі схема, визначаються в рамках класів та атрибутів. Класи – це типи даних, які потрібно зберігати. Наприклад, користувач (user) - клас AD, як і комп'ютер (computer). Атрибути – властивості класів. Клас «користувач» має атрибут «ім'я» (givenName) та атрибут «прізвище» (sn). Клас "комп'ютер" має атрибут "операційна система". Схема AD визначається у термінах двох класів: classSchema для класів і attributeSchema для атрибутів.

Проводячи аналогію з типовою базою даних, можна порівняти класи з таблицями у базі даних, а атрибути - зі стовпцями усередині таблиці. Але майте на увазі, що структура бази даних AD Directory Information Tree (DIT) насправді має суттєві відмінності.

Вирішуючи завдання збереження даних нового типу AD, необхідно продумати зіставлення даних класам і атрибутам. У найбільш типових випадкахдостатньо додати атрибут до існуючого класу (наприклад, користувача або групи). Якщо потрібно просто зберегти новий фрагмент даних про об'єкт існуючого типу(Таким, як користувач), спочатку постарайтеся знайти відповідні атрибути серед наявних в AD. Схема містить тисячі атрибутів, більшість із яких не задіяно. Тому, наприклад, щоб зберегти відомості про поштовою адресоюкористувача, можна застосувати атрибут physicalDeliveryOfficeName.

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

Але іноді можливий лише підхід на основі класів. У двох випадках зручніше додати до схеми новий клас, ніж використовувати атрибути Перший: необхідність відстежувати новий тип даних у каталозі. Якщо, наприклад, потрібно відстежувати AD компанії компанії, можна визначити в схемі новий клас «автомобіль». Інший випадок - зіставлення "один до багатьох".

Ідеальним прикладом може бути Microsoft Exchange Server 2010. Кожен мобільний пристрій, синхронізований з Exchange за допомогою ActiveSync, зберігається як екземпляр спеціального класу об'єктів msExchActiveSyncDevice у каталозі. Ці мобільні пристроїзберігаються як дочірні об'єкти користувача, власника пристрою. Така структура забезпечує зіставлення великої кількостіатрибутів (кожного пристрою) одному користувачеві.

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

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

Перш за все виберіть назву класу або атрибута. Найважливіша частина імені – префікс. Імена атрибутів та класів у схемі (і у схемі покупця стороннього додатку) мають бути унікальними, тому додавання префіксу забезпечить відсутність конфліктів між ідентифікаторами атрибутів.

Зазвичай як префікс застосовується скорочена назва компанії. Наприклад, я використовую bdcLLC як префікс для атрибутів нашої компанії Brian Desmond Consulting LLC. Для корпорації ABC можна використати префікс abcCorp. Обов'язково подбайте про унікальність префікса, оскільки не існує загального реєстру префіксів. Якщо у компанії типова чи скорочена назва, придумайте, як надати їй унікальних рис.

Після того, як ім'я вибрано, потрібно призначити атрибут або клас ідентифікатор об'єкта Object Identifier (OID). Ідентифікатори OID - додатковий компонент, який має бути глобально унікальним. AD (узагальненіше, LDAP) - не єдина структура, в якій OID використовується як ідентифікатор, тому організація Internet Assigned Numbers Authority (IANA) призначає унікальні дерева OID за запитами компаній. Запит номера Private Enterprise Number, який є частиною дерева OID, унікальною для компанії, безкоштовно обслуговується приблизно за 10 хвилин. Отримати його потрібно перш, ніж приступити до створення користувацьких розширень схеми. Запросити номер Private Enterprise Number можна на сайті за адресою www.iana.org/cgi-bin/assignments.pl.

Отримавши Private Enterprise Number, можна створити практично необмежену кількість унікальних ідентифікаторів OID і впорядкувати їх. На малюнку показано структуру дерева OID для номера Private Enterprise Number нашої компанії. Ідентифікатори OID будуються шляхом додавання гілок до дерева, тому багато компаній починають із створення гілки AD Schema (1.3.6.1.4.1.35686.1 на малюнку), а потім під нею формується гілка класів та гілка атрибутів. Під кожною з цих гілок призначаються ідентифікатори OID для кожного нового атрибута або класу. На малюнку показаний OID (1.3.6.1.4.1.35686.1.2.1), виділений атрибуту користувача myCorpImportantAttr. Дуже важливо підготувати внутрішній механізм відстеження (наприклад, електронну таблицю Excelабо список SharePoint), що забезпечує унікальність ідентифікаторів OID.

Малюнок. Ієрархія OID

Компанія Microsoft надає сценарій, за допомогою якого можна сформувати OID зі випадковим значеннямале немає гарантій, що він виявиться унікальним. Кращий спосіб- Запитати унікальну гілка в організації IANA і задіяти її для розширень схеми. Цей процес настільки простий, що використовувати сценарій формування OID компанії Microsoft не потрібно.

Решта два вхідних параметрівспецифічні для атрибутів і залежить від їх типу. Надзвичайно корисні пов'язані атрибути використовуються для зберігання посилань між об'єктами AD. Вони зберігаються як покажчики в базі даних AD, тому посилання своєчасно оновлюються відповідно до розташування об'єкта в лісі. Два Типові прикладипов'язаних атрибутів - членство у групах (member і memberOf) та ставлення менеджер/співробітник (manager/directReports). До пов'язаних атрибутів застосовуються концепції посилань уперед та зворотних посилань. Посилання вперед – редагована частина зв'язку між атрибутами. Наприклад, у разі членства групи атрибут member для групи є посилання вперед; атрибут memberOf для користувача – зворотне посилання. При редагуванні членства в групі зміни вносяться до атрибута member (посилання вперед), а не атрибут memberOf об'єкта-члена (зворотне посилання).

Щоб визначити пов'язані атрибути AD, необхідно визначити два атрибути (посилання вперед і зворотне посилання) і приєднати ідентифікатор посилання (linkID) до кожного з цих атрибутів. Ідентифікатори посилання мають бути унікальними всередині лісу, а оскільки ідентифікатори посилань необхідні й іншим додаткам, які потребують розширення схеми, їх потрібно зробити глобально унікальними. В минулому компанія Microsoftвидавала ідентифікатори посилань для сторонніх організацій, але починаючи з Windows Server 2003 замість цього AD з'явився спеціальний покажчик, що дозволяє формувати унікальні ідентифікатори посилань при доповненні схеми, пов'язаної парою атрибутів.

AD передбачається, що ідентифікатори посилань є послідовними числами. Зокрема, атрибут посилання вперед - парне число, а наступне число призначається атрибуту зворотного посилання. Наприклад, для member і memberOf (членство групи) ідентифікатор посилання для member дорівнює 4, а ідентифікатор посилання для memberOf - 5. Якщо розширена схема має бути сумісна з лісом Windows 2000, необхідно визначати ідентифікатори статичних посилань описаним способом. В іншому випадку слід використовувати процес автоматичного формування ідентифікаторів посилань, реалізований у Windows Server 2003. Для використання автоматичного процесустворення ідентифікаторів посилань дотримуйтесь наведених нижче рекомендацій, визначаючи розширення схеми. У процесі розширення схеми, як описано далі у статті, наведені кроки необхідні конструювання пов'язаних атрибутів (якщо вони є частиною розширення).

Спочатку підготуйте посилання вперед за допомогою ідентифікатора посилання 1.2.840.113556.1.2.50. Зверніть увагу, що, хоча дане значенняідентифікатор посилання є OID, компанія Microsoft просто резервує це значення OID для створення ідентифікатора автопосилання.

Потім перезавантажте кеш-схеми. Після цього створіть атрибут зворотного посилання за допомогою ідентифікатора посилання імені атрибута посилання вперед і перезавантажте кеш схеми.

Другий унікальний (і необов'язковий) елемент атрибутів - ідентифікатор MAPI. Ідентифікатори MAPI – особливість Exchange Server. За відсутності Exchange або необхідності показувати атрибут у списку глобальних адрес (Global Address List, GAL), цей розділ можна пропустити. Ідентифікатори MAPI використовуються для відображення атрибутів на одній зі сторінок властивостей адресної книги, такий як шаблон загальних деталей користувача (див. екран). Наприклад, якщо потрібно показати класифікацію співробітників (штатний співробітник або працівник за договором) у списку GAL, призначте відповідний атрибут як ідентифікатор MAPI. Після того, як ідентифікатор MAPI призначений атрибуту, можна використовувати редактор Exchange Details Templates Editor для введення даних атрибуту до представлення у списку GAL всередині Office Outlook.

Ідентифікатори MAPI повинні бути унікальними, так само як ідентифікатори OID та посилань. У минулому було неможливо формувати унікальні ідентифікатори MAPI, тому ці ідентифікатори завжди виявлялися слабким місцему разі розширення схеми. На щастя, Windows Server 2008 з'явився спосіб автоматичного формування унікальних ідентифікаторів MAPI в каталозі, щоб зменшити ризик дублювання ідентифікаторів MAPI. Щоб скористатися цією функцією, надайте значення 1.2.840.113556.1.2.49 атрибуту ідентифікатора MAPI під час створення атрибута. AD формує унікальний ідентифікатор MAPI для атрибута після перезавантаження схеми кешу. Зверніть увагу, що хоча це значення являє собою OID, воно зарезервовано в AD для вказівки автоматичного формування ідентифікаторів MAPI, подібно до автоматичного формування ідентифікаторів посилань, описаному вище.

Підведемо підсумок. При плануванні розширення схеми необхідно враховувати три найважливіші вхідні параметри. Перший - ім'я класу чи атрибута; другий - унікальний префікс, який призначається всім класам та атрибутам; третій – OID. Для формування OID необхідно запросити унікальну гілку OID у організації IANA. Якщо потрібно створити пов'язану пару атрибутів, потрібна унікальна пара ідентифікаторів посилань. Якщо потрібно показати атрибут у списку GAL Exchange, необхідно використовувати унікальний ідентифікатор MAPI. Як у випадку з ідентифікаторами посилань, так і у випадку з ідентифікаторами MAPI, використання процесу автоматичного формування всередині AD краще статичних значень.

Планування впровадження

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

Під час підготовки користувача розширення схеми використовуйте тимчасове середовище розробки. Службу AD Lightweight Directory Service (AD LDS) можна безкоштовно завантажити на робітники станції Windows XP та Windows 7. робочої станціїможна створити екземпляр AD LDS, побудувати розширення схеми ізольованому середовищі, а потім експортувати це розширення для подальшого імпорту до тестового лісу AD. Схема AD LDS сумісна з AD, тому можна використовувати LDIFDE для експорту. Готове розширення схеми можна імпортувати в тестовий ліс AD, а потім переконатися, що імпорт виконано успішно, і найважливіші програми не постраждали. Відносно AD слід запланувати перевірку успішності імпорту та правильності реплікації у тестовому середовищі.

Якщо потрібно перевірити розширення схеми в тестовому лісі AD, його схема має збігатися з виробничим лісом. І тут тестування буде повноцінним. Можна скористатися інструментом AD Schema Analyzer (зі складу AD LDS) виявлення відмінностей у схемі між двома лісами AD. У статті "Export, Compare, and Synchronize Active Directory Schemas" на сайті TechNet (http://technet.microsoft.com/en-us/magazine/2009.04.schema.aspx) описано порядок імпорту та експорту розширень схеми, а також способи використання інструмента AD Schema Analyzer Зверніть увагу, що при порівнянні схем можливі деякі відмінності, залежно від пакетів оновлення та версій Windows, зокрема в індексації атрибутів та зберігання відміток про видалення.

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

• що постачаються у файлі LDIF (кілька файлів LDIF);
• правильність префіксів атрибутів;
• зареєстровані OID;
• зареєстровані/автоматично формовані ідентифікатори посилань;
• ідентифікатори MAPI, що автоматично формуються.

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

• Атрибут має префікс на основі імені компанії-постачальника (Brian Desmond Consulting, LLC: bdcllc).
• Унікальний OID для атрибуту видано за допомогою номера Private Enterprise Number, зареєстрованого постачальником.
• Атрибут індексований (search Flags: 1) і доступний у глобальному каталозі (isMemberOfPartialAttributeSet: TRUE).

Також необхідно перевірити доступність атрибута у глобальному каталозі Partial Attribute Set (PAS) та правильність індексів, створених для атрибута, якщо атрибут буде використовуватись у фільтрах пошуку LDAP. Крім того, корисно переконатися, що дані, що зберігаються в атрибуті, прийнятні для AD у контексті розглянутих вище обмежень та рекомендацій.

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

Планомірний підхід

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

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

Лістинг. Приклад записів LDIF

Dn: CN=bdcllcShoeSize,CN=Schema,CN=Configuration,DC=X changetype: add objectClass: top objectClass: attributeSchema cn: sfsuLiveServiceEntitlements attributeID: 1.3.6.1.4.1.35686.10.1.5.1.5. Valued: FALSE showInAdvancedViewOnly: TRUE adminDisplayName: bdcllcShoeSize adminDescription: Stores users shoe size oMSyntax: 64 searchFlags: 1 lDAPDisplayName: bdcllcShoeSize name: bdcllcShoeSiz = isMemberOfPartialAttributeSet: TRUE

FSMO-роль господар схеми ( Schema master) є однією з двох ролей, що функціонують на рівні ліси Active Directory. Тобто у всьому лісі AD необхідно мати лише одного власника схеми.

Основна стаття з Active Directory - . Читайте також інші статті щодо ролей господарів операцій — .

Якщо вам цікава тематика Windows Server, рекомендую звернутися до рубрики на моєму блозі.

Schema master - Хазяїн схеми Active Directory

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

Теорія

Оскільки господар схеми — роль рівня лісу, то кожному конкретному лісі AD вона існує завжди в єдиному екземплярі. Іншими словами, існує тільки один контролер домену, який має право вносити зміни/оновлення в схему, проте репліка схеми присутня на кожному контролері домену і при необхідності роль може бути захоплена примусово будь-яким DC, але про це пізніше. Насправді зміни схеми відбуваються дуже рідко, наприклад при установці сервера Exchangeабо інших програм, які зберігають деякі свої дані (наприклад, об'єкти конфігурації) в AD.

Все-таки що таке схема AD? Це насамперед набір об'єктів та його атрибутів, що використовуються зберігання даних. Мало кому це визначення щось пояснює, спробую розповісти детальніше на прикладі. Що таке об'єкт? Наприклад, об'єктами є облікові записи користувачів або комп'ютерів. У даному випадкуу схемі AD знаходиться клас user, який визначає всі атрибути об'єкта облікового запису користувача:

Кожна обліковий запискористувача в домені буде мати всі ці атрибути. Але значення атрибутів можуть і не задані. Можна перевірити, які атрибути та їх значення має мій нещодавно створений обліковий запис адміністратора домену. Щоб це зробити, потрібно зайти в консоль adsiedit.mscта відкрити контекст іменування за умовчанням. В ієрархії знаходимо об'єкт користувача та відкриваємо його властивості:

Ви можете побачити, що об'єкт має всі атрибути, які визначені у класі user. Якщо ви самі вирішили переконатися у сказаному мною та інформація у вас різниться, то зверніть увагу на кнопку ФільтрМожливо, у вас відображаються не всі атрибути. Наприклад, можна зробити так, щоб відображалися лише атрибути, що мають значення. Адмініструвати об'єкти через adsiedit.mscне найкраща витівка, робіть це через відповідне оснащення.

Для інтересу можна переглянути атрибути об'єкта сервера Exchange 2013, адже Exchange вносить безліч нових класів у схему:

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

Кращі практики

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

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

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

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

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

4) Без крайньої потреби не виконуйте зміни схеми вручну. Якщо це все ж таки потрібно зробити в будь-якому випадку, див. пункт 1.

Від теорії плавно переходимо до практики.

Адміністрація схеми

Насамперед варто сказати, що для управління схемою необхідно мати як мінімум права Адміністратора Схеми (Schema Admin). Всі решта авторизовані користувачімають права лише читання, хоча у принципі дозволу можна змінити. Більшість завдань адміністрування виконуються в оснастці для керування схемою Active Directory, яка недоступна за замовчуванням і щоб її активувати, необхідно зареєструвати бібліотеку schmmgmt.dll. Для цього запускаємо командний рядокз правами адміністратора та виконуємо:

Visual Basic

regsvr32 schmmgmt.dll

regsvr32 schmmgmt. dll

Отримуємо оповіщення:

Після цього в консолі MMCви зможете знайти оснащення Схема Active Directory. Виконувати команду необхідно кожному контролері домену, у якому планується займатися адмініструванням схеми.

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

1. Відкриваємо оснастку на DC01, правою кнопкоюнатискаємо на Схема Active Directoryі вибираємо Змінити контролер домену Active Directory;
2. Далі вибираємо контролер домену, на який ми хочемо перенести роль (у мене це DC02, завжди вибирається сервер-власник ролі). Підтверджуємо попередження;
3. Знову правою кнопкою на Схема Active Directory,але вже вибираємо Господар операцій.;
4. Натискаємо кнопку Змінити.

Після цього необхідно підтвердити вибір та отримати повідомлення про успішне перенесення ролі.

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