Методологія впровадження Microsoft Active Directory

Лекція 1. ВСТУП В ACTIVE DIRECTORY

Коротка інструкція: Визначення та призначення служб каталогів, їх основні функції та
завдання. Служби каталогів - провісники Microsoft Active Directory . Ключові переваги
служби Active Directory .
Ключові слова : каталог (directory), служба каталогів (Directory Service), Active Directory
(AD), Lightweight Directory Access Protocol (LDAP).

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

Незалежно від топології мережі компанії, реальної інфраструктури та

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

Визначення каталогу та служби каталогів

Спочатку ми повинні визначити, що таке служба каталогів взагалі, які її цілі та
завдання.
Каталог ( directory ) - це інформаційний ресурс, що використовується для
зберігання інформації про якийсь об'єкт [1]. Наприклад, телефонний довідник (каталог
телефонних номерів) містить інформацію про абонентів телефонної мережі. У файловій
системі каталоги зберігають інформацію про файли.
У розподіленій обчислювальній системі або комп'ютерній мережі загального
користування (наприклад, Інтернет) є безліч об'єктів — сервери, бази даних, додатки,
принтери та ін. Користувачі хочуть мати доступ до кожного з таких об'єктів та працювати
з ними, а адміністратори — керувати правилами використання цих об'єктів.
У цьому документі терміни «каталог» та «служба каталогів» належать до каталогів,
які розміщуються у приватних мережах та мережах загального користування. Служба
каталогів відрізняється від каталогу тим, що вона не тільки є інформаційним ресурсом, але
також є послугою, що забезпечує пошук та доставку користувачеві необхідної йому
інформації [2].
Служба каталогів ( directory service _ — мережна служба, яка ідентифікує всі
ресурси мережі та робить їх доступними користувачам. Служба каталогів централізовано
зберігає всю інформацію, необхідну використання та управління цими об'єктами,
спрощуючи процес пошуку та управління даними ресурсами. Служба каталогів працює як
головний комутатор мережевої ОС. Вона керує ідентифікацією та відносинами між
розподіленими ресурсами та дозволяє їм працювати разом [4].
Active Directory (AD) - служба каталогів , що поставляється з Microsoft Windows
починаючи з Windows 2000 Server . Active Directory містить каталог, в якому зберігається
інформація про мережні ресурси та служби, що надають доступ до цієї інформації.
Active Directory – це не перша і не єдина служба каталогів. У сучасних мережах
використовується кілька служб каталогів і стандартів [3], [ 13 ] :
● Х.500 та Directory Access Protocol (DAP). X.500 - специфікація Internet Standards
Organization ( ISO ), визначальна, як мають бути структуровані глобальні каталоги.
Х.500 також визначає застосування DAP для забезпечення взаємодії між клієнтами
та серверами каталогів;
 ● Lightweight Directory Access Protocol (LDAP). Протокол LDAP був розроблений у
відповідь на критичні зауваження щодо специфікації DAP , яка виявилася надто
складною для застосування в більшості випадків. Специфікація LDAP швидко
стала стандартним протоколом каталогів Інтернету;
● Novell Directory Services ( NDS ). Служба каталогів для мереж Novell NetWare ,
сумісна зі стандартом Х.500;
● Windows NT і SAM . Ядром Windows NT NOS ( Network Operating System -
мережна операційна система) є база даних SAM ( Security Accounts Management –
керування безпечними обліковими записами). Це центральна база даних облікових
записів, яка включає всі облікові записи користувачів та груп у домені. Ці облікові
записи використовуються для керування доступом до спільних ресурсів, які
належать будь-якому серверу в домені Windows NT .

Служба Active Directory , на відміну від перелічених служб каталогів, є захищеною,

розподіленою, сегментованою та реплікованою, що дозволяє забезпечити наступні
можливості [4]:
● спрощене адміністрування;

● масштабованість;

● підтримку відкритих стандартів;

● Підтримка стандартних форматів імен.

За допомогою Active Directory здійснюється централізоване управління

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

Призначення служби каталогів

Служба каталогів є як інструментом адміністрування, і інструментом користувача
(див. рис. 1.1). Користувачі та адміністратори часто не знають точних імен об'єктів, які їм
зараз потрібні. Вони можуть знати одну або кілька їх ознак або атрибутів ( attributes ) і
можуть надіслати запит ( query ) до каталогу, отримавши у відповідь список тих об'єктів,
атрибути яких збігаються із зазначеними у запиті.
 Мал. 1.1. Призначення Active Directory

Служба каталогів дозволяє [1]:

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

● проводити реплікацію (тиражування) каталогу, роблячи його доступним для

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

У міру зростання кількості об'єктів у мережі служба каталогів починає відігравати

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

Функції служби каталогів

Наведемо основні функції служби каталогів та дамо їх короткий опис [3].
● Централізація. Сенс централізації - Зменшення кількості каталогів в мережі.
Включення інформації про всі мережеві ресурси до централізованого каталогу
створює єдину точку управління, що спрощує адміністрування ресурсів та дозволяє
ефективніше делегувати адміністративні завдання. Крім того, в мережі з'являється
єдина точка входу для користувачів (або їх комп'ютерів/додатків), яка потрібна,
коли виникає потреба у пошуку ресурсів.
● Масштабованість. Служба каталогів повинна допускати зростання мережі, не
створюючи при цьому великих витрат, тобто вона повинна підтримувати будь-який
спосіб розбиття бази даних каталогу на розділи, щоб не втратити контроль над
базою даних через її надмірне розростання і при цьому зберегти переваги
централізації.
 ● Стандартизація. Служба каталогів має надавати доступ до своєї інформації за
відкритими стандартами. Це гарантує, що інші програми можуть використовувати
ресурси в службі каталогів (і публікувати їх у ній), а не підтримувати власні
каталоги.
● Розширюваність. Служба каталогів повинна тим чи іншим способом дозволяти
адміністраторам та додаткам розширювати відповідно до потреб організації набір
інформації, що зберігається в каталозі.
● Поділ фізичної мережі. Завдяки службі каталогів топологія фізичної мережі має
бути прозорою для користувачів та адміністраторів. Ресурси можна знаходити (і
звертатися до них), не знаючи, як і де вони підключені до мережі.
● Безпека. Служба каталогів була б вкрай корисною для зловмисника, оскільки вона
зберігає докладну інформацію про цю організацію. Тому служба каталогів повинна
підтримувати захищені засоби зберігання, керування, вибірки та публікації
інформації про мережеві ресурси.

У розрізі перелічених функцій можна вказати й основні завдання, виконання яких

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

Служба каталогів Active Directory також виконує інші функції [4]:

● призначення безпеки для захисту об'єктів бази даних від зовнішніх вторгнень або
внутрішніх користувачів, які не мають доступу до даних об'єктів;
● поширення каталогу на множину комп'ютерів мережі;

● дублювання каталогу для надання доступу більшій кількості користувачів та для

стійкості до відмови;
● розподіл каталогу на кілька сховищ, розташованих на різних комп'ютерах мережі.

Переваги Active Directory

Служба каталогів Active Directory є службою, інтегрованою з MS Windows
починаючи з Windows 2000 Server . Active Directory забезпечує ієрархічну структуру
побудови організації, нарощування та розширюваність, а також функції розподіленої
безпеки. Ця служба дозволяє використовувати прості та інтуїтивно зрозумілі імена
об'єктів, що містяться в ній, при цьому доступ до неї може бути здійснений за допомогою
таких інструментів, як програма перегляду ресурсів Інтернет.
Розподілені служби безпеки також використовують Active Directory як сховища
облікової інформації.
Переваги інтеграції керування обліковими записами зі службою каталогів Active
Directory такі:
● облікові записи користувачів, груп та машин можуть бути організовані у вигляді
контейнерів каталогу, які називаються організаційними підрозділами або просто
підрозділами. У домені може бути довільна кількість підрозділів, організованих як
деревоподібного простору імен. Цей простір імен може бути побудований
відповідно до підрозділів і відділів в організації. Так само як і організаційні
підрозділи, облікові записи користувачів є об'єктами каталогу і можуть бути легко
перейменовані всередині доменних дерев при переміщенні користувачів з одного
відділу в інший;
● у каталозі Active Directory підтримується велика кількість об'єктів: розмір одного
домену не обмежується продуктивністю сервера, що зберігає облікові записи.
Дерево зв'язаних між собою доменів може підтримувати великі та складні
організаційні структури;
● адміністрування облікової інформації розширено за рахунок використання
графічних засобів керування Active Directory , а також за рахунок підтримки OLE у
мовах сценаріїв. Загальні завдання можуть бути реалізовані як сценарії, що
дозволяють автоматизувати адміністрування;
● служба тиражування каталогів дозволяє мати кілька копій облікової інформації,
причому оновлення цієї інформації можуть виконуватись у будь-якій копії, а не
лише на виділених первинних контролерах домену. Протокол LDAP та
синхронізація каталогів дозволяють забезпечувати механізми зв'язку каталогу
Windows з іншими каталогами на підприємстві;
● зберігання облікової інформації в Active Directory означає, що користувачі та групи
представлені у вигляді об'єктів каталогу. Права на читання і запис можуть бути
надані як по всьому об'єкту цілком, так і по відношенню до окремих його
властивостей. Адміністратори можуть точно визначати, хто саме та яку саме
інформацію про користувачів може модифікувати. Наприклад, оператору
телефонної служби може бути дозволено змінювати інформацію про телефонні
номери користувачів, але при цьому він не матиме привілеїв системного оператора
або адміністратора.

Якщо у компанії-замовнику зацікавлені у виконанні найбільш сильно інтегрованої

служби каталогу для Windows Server 2003, то Active Directory є логічним вибором. Інша
дуже популярна причина, що підштовхує до реалізації служби Active Directory , полягає у
підтримці Microsoft Exchange Server 2000 1. Далі описано кілька ключових переваг служби
Active Directory Windows Server 2003 [13].
● Централізований каталог. Active Directory є єдиною централізованою службою
каталогу, яка може бути реалізована у межах підприємства. Це спрощує мережне
адміністрування, оскільки адміністратори не повинні з'єднуватися з кількома

1
Exchange Server 2000 покладається на Active Directory для своєї служби каталогу, тому багато
адміністраторів реалізують Active Directory для модернізації до Exchange Server 2000
 каталогами, щоб керувати обліковими записами. Інша вигода від централізованого
каталогу полягає в тому, що він може також використовуватися іншими додатками,
такими як Exchange Server 2000. Це спрощує повне мережеве адміністрування,
оскільки використовується єдина служба каталогу для всіх програм.
● Єдина реєстрація. Після успішної ідентифікації користувачам буде надано доступ
до всіх мережевих ресурсів, для яких їм надано дозвіл, без необхідності
реєструватися знову на різних серверах або доменах.
● Делеговане адміністрування. Active Directory надає адміністраторам можливість
передавати адміністративні права. Використовуючи майстер Delegation Of Control
Wizard (Делегування керування) або встановлюючи певні дозволи на об'єкти Active
Directory , адміністратори можуть пропонувати тонко налаштовані адміністративні
права. Наприклад, можна призначити певний обліковий запис користувача
адміністративне право скидати паролі в домені, але не створювати, видаляти або
змінювати об'єкт користувача.
● Інтерфейс загального керування. Є кілька способів, якими можна отримати зиск
від інтеграції між Active Directory та операційної системи. Один із шляхів полягає у
використанні інтерфейсу загального управління – консолі управління Microsoft
(ММС – Microsoft Management Console ). При взаємодії з Active Directory через
графічний інтерфейс користувача ММС всі інструментальні засоби управління
дають ураження та відчуття від їх використання, що узгоджується один з одним.
Для Active Directory ці засоби включають Active Directory Users And Computers
(Active Directory: користувачі і комп'ютери ), Active Directory Domains And Trusts
(Active Directory: домени і довірчі відносини ) та Active Directory Sites And Services
(Active Directory: сайти і служби ). Оснащення ММС функціонують так само, як усі
інші засоби адміністрування Windows Server 2003, наприклад оснастки DHCP та
DNS .
● Інтегрована безпека. Служба Active Directory працює пліч-о-пліч з підсистемою
безпеки Windows Server 2003 під час автентифікації безпечних користувачів та
захисту загальнодоступних мережевих ресурсів. Мережевий захист у мережі
Windows Server 2003 починається з автентифікації під час реєстрації. Коли
безпечний користувач входить до домену Windows Server 2003, підсистема захисту
разом із Active Directory створює лексему доступу, яка містить ідентифікатор
захисту ( SID — Security Identifier ) облікового запису користувача, а також
ідентифікатори SID всіх груп, членом яких є цей користувач. Ідентифікатор SID є
атрибутом об'єкта користувача в Active Directory . Потім лексема доступу
порівнюється з дескриптором захисту ресурсі, і, якщо встановлюється
відповідність, то користувачеві надається необхідний рівень доступу.
● Масштабованість. Оскільки організація або поступово зростає в процесі бізнесу,
або це відбувається швидко через ряд злиттів з іншими компаніями і в результаті
придбань служба Active Directory спроектована масштабованою для того, щоб
справлятися з цим зростанням. Можна розширити розмір доменної моделі або
просто додати більше серверів, щоб пристосуватися до збільшення обсягу. Будь-які
зміни в інфраструктурі Active Directory повинні бути ретельно реалізовані
відповідно до проекту Active Directory , яка передбачає таке зростання. Окремий
домен, що представляє найменший розділ інфраструктури Active Directory , який
може реплікуватися на єдиний контролер домену, може підтримувати більше
одного мільйона об'єктів, тому модель окремого домену підходить навіть для
великих організацій.
Короткі підсумки
У цій лекції було дано визначення каталогу та служби каталогів.
Перераховані служби та стандарти, що використовуються в сучасних мережах:
● Х.500 та Directory Access Protocol (DAP) .

● Lightweight Directory Access Protocol (LDAP).

● Novell Directory Services ( NDS ).

● Windows NT та SAM.

Вказано призначення служб каталогу:

● Забезпечувати захист інформації від втручання сторонніх осіб у межах,
встановлених адміністратором системи.
● Розповсюджувати каталог серед інших комп'ютерів у мережі.

● Проводити реплікацію (тиражування) каталогу, роблячи його доступним для

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

Наведено основні функції служби каталогів, що дозволяють забезпечувати такі

можливості:
● централізація;

● масштабованість;

● стандартизація;

● розширюваність;

● розподіл фізичної мережі;

● безпека.

Ключові переваги Active Directory :

● Централізований каталог.

● Єдина реєстрація.

● Делеговане адміністрування.

● Інтерфейс загального керування.

● Інтегрована безпека.

● Масштабованість.
Лекція 2. ПРОЕКТУВАННЯ ACTIVE DIRECTORY
Коротка інструкція : Для розуміння предметної області дано терміни та їх визначення в
контексті Active Directory . Визначається послідовність робіт, необхідних для
проектування служби Active. Directory : збір інформації, її аналіз, розробка структури та
архітектури рішення.
Ключові слова : область дії ( scope ), простір імен, об'єкт, контейнер, дерево, ім'я об'єкта,
контексти імен (сегменти, розділи), домен, довірчі відносини, доменне дерево, ліс,
організаційні одиниці (підрозділи), сайт (вузол).

Ціль лекції
Ввести поняття служби каталогів, що використовуються в курсі, дати уявлення про
етапи проектування служби Active Directory .

Планування є важливим підготовчим етапом при реалізації проекту створення

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

Основні поняття служби каталогів

Перш ніж перейти до огляду процесу проектування, що включає збирання та аналіз
даних про існуючу структуру підприємства і що готує реалізацію Active Directory ,
необхідно ввести та визначити ряд термінів, які використовуються в контексті служби
каталогів Active Directory . Ця термінологія наведена відповідно до інформаційних
матеріалів [1]-[4].

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

Простір імен
Active Directory , як і будь-яка інша служба каталогів, є насамперед простором
імен. Простір імен — це обмежена область, в якій може бути розпізнане дане ім'я.
Розпізнавання імені полягає у його зіставленні з деяким об'єктом чи обсягом інформації,
якому це ім'я відповідає. Наприклад, телефонний довідник є простір імен, в якому іменам
телефонних абонентів можуть бути поставлені у відповідність телефонні номери. Файлова
система Windows утворює простір імен, в якому ім'я файлу може бути поставлене у
відповідність до конкретного файлу.
Active Directory утворює простір імен, в якому ім'я об'єкта в каталозі може бути
поставлене у відповідність до цього об'єкта.

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

Контейнер
Контейнер аналогічний об'єкту тому, що він також має атрибути і належить
простору імен. Однак, на відміну від об'єкта, контейнер не означає нічого конкретного: він
може містити групу об'єктів або інші контейнери.

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

Ім'я
Служба Active Directory допускає існування двох типів імен, які використовуються
для ідентифікації об'єктів:
● Унікальне ім'я Кожен об'єкт у Active Directory має унікальне ім'я ( Distinguished
Name , DN). Це ім'я містить вказівку на домен, в якому знаходиться об'єкт, та
повний шлях у ієрархічній структурі контейнерів, що призводить до даного об'єкта.
Типовим унікальним ім'ям (DN) є ім'я: /O=Internet/DC=COM/DC=Microsoft/CN=
Users /CN=James Smith. Це ім'я позначає об'єкт типу « користувач» з ім'ям « James
Smith », що знаходиться у домені Microsoft.com.
● Відносне ім'я. Відносне унікальне ім'я об'єкта ( Relative Distinguished Name , RDN)
— це частина імені, яка сама є частиною атрибута об'єкта. У наведеному вище
прикладі RDN-ім'ям об'єкта « James Smith » служить групове ім'я (CN) CN = James
Smith. RDN-іменем батьківського об'єкта є ім'я CN= Users .

Контексти імен (сегменти, розділи)

Active Directory може складатися з одного чи кількох контекстів імен чи сегментів
(розділів). Контекстом імен може бути будь-яке безперервне поддерево каталогу.
Контексти імен є одиницями реплікації.
В Active Directory кожен сервер завжди містить не менше трьох контекстів імен:
● логічну структуру;

● конфігурацію (топологію реплікації та відповідні метадані);

● один або кілька контекстів користувача імен (піддерев'я, що містять об'єднані в

каталог об'єкти).

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

Довірчі відносини
Оскільки домени розмежовують зони безпеки, спеціальний механізм, званий
довірчими відносинами . relationships ), дозволяє об'єктам в одному домені [довіряється
( trusted domain )] звертатися до ресурсів в іншому [ trusting domain )].
Windows Server 2003 підтримує шість типів довірчих відносин:
● Довіра до батьківського та дочірнього доменів. Active Directory автоматично
вибудовує транзитивні двосторонні довірчі стосунки між батьківськими та
дочірніми доменами у дереві доменів. При створенні дочірнього домену довірчі
стосунки автоматично формуються між дочірнім доменом та його батьком. Ці
відносини двосторонні. Довіра також є транзитивною, тобто контролери домену,
що довіряється, пересилають запити на автентифікацію контролерам довіряючих
доменів.
● Довіра до кореневого домену дерева. Двосторонні транзитивні довірчі відносини
автоматично створюються між кореневими доменами дерев у одному лісі. Це різко
спрощує керування доменами в порівнянні з тим, що було у версіях Windows , що
передували Windows 2000. Більше не потрібно конфігурувати окремі односторонні
довірчі відносини між доменами.
● Довіра до зовнішнього домену. Зовнішня довіра використовується, коли потрібно
створити довірчі відносини між доменом Windows Server 2003 та доменом
Windows NT 4.0. Оскільки обмежені домени ( down - level domains ) (домени, які не
підтримують Active Directory ) не можуть брати участь у двосторонніх
транзитивних довірчих відносинах, слід використовувати зовнішню довіру, яка є
односторонньою.
● Довіра до скорочення. Довіра до скорочення — це спосіб створення прямих
довірчих відносин між двома доменами, які можуть бути вже пов'язані ланцюжком
транзитивних довір, але потребують оперативнішого реагування на запити один від
одного.
● Довіра до сфери. Довіра до сфери служить для підключення домену Windows
Server 2003 до сфери Kerberos , яка не підтримує Windows та використовує
протокол захисту Kerberos V 5. Довіра до сфери може бути транзитивною або
нетранзитивною , одно- або двосторонньою.
● Довіра до лісу. Довіра до лісу спрощує керування кількома лісами та забезпечує
більш ефективну захищену взаємодію між ними. Цей тип довіри дозволяє
звертатися до ресурсів в іншому лісі за тією самою ідентифікацією користувача
( user IDentification , ID ), що у його власному лісі.

Доменне дерево
Дерево доменів складається з кількох доменів, які мають загальну логічну
структуру та конфігурацію та утворюють безперервний простір імен. Домени у дереві
пов'язані між собою довірчими стосунками. Active Directory є безліччю, якій належать
одне чи кілька дерев доменів.
Дерево доменів графічно можна уявити двома способами:
 ● Подання доменне дерево через довірчі відносини між доменами. Довірчі
відносини між доменами в Windows 2000 встановлюються на основі протоколу
безпеки Kerberos . Відносини, створені за допомогою цього протоколу, мають
властивості транзитивності та ієрархічності: якщо домен А довіряє домену В і
домен В довіряє домену С, то домен А довіряє і домену С.
● Подання доменне дерево через простір імен доменного дерева. Доменне дерево
також можна представити за допомогою простору імен. Унікальне ім'я об'єкта
можна визначити, рухаючись вгору по доменному дереву, починаючи з об'єкта.
Такий метод виявляється зручним при об'єднанні об'єктів у логічну ієрархічну
структуру. Головна перевага безперервного простору імен полягає в тому, що
глибокий пошук, що проводиться від кореня дерева, дозволяє переглянути всі
ієрархічні рівні простору імен.

Декілька доменних дерев можуть бути об'єднані в ліс.

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

Організаційні одиниці (підрозділи)

Організаційні одиниці ( Organizational Units , OU ) чи організаційні підрозділи (ОП)
дозволяють розділяти домен на зони адміністративного управління, т. е. створювати
одиниці адміністративного управління всередині домену. Здебільшого це дає змогу
делегувати адміністративні завдання у домені. До появи Active Directory домен був
найменшим контейнером, якому могли бути призначені адміністративні дозволи.

Сайт (вузол)
Вузлом (сайтом) називається такий елемент мережі, який містить сервери Active
Directory . Вузол зазвичай визначається як одна або кілька підмереж, що підтримують
протокол TCP/IP і характеризуються гарною якістю зв'язку, що має на увазі високу
надійність та швидкість передачі даних. Визначення вузла як сукупності підмереж
дозволяє адміністратору швидко і без великих витрат налаштувати топологію доступу та
реплікації в Active Directory і повніше використовувати переваги фізичного розташування
пристроїв у мережі. Коли користувач входить до системи, клієнт Active Directory шукає
сервери Active Directory , розташовані у вузлі користувача. Оскільки комп'ютери, що
належать до одного вузла, в масштабах мережі можна вважати розташованими близько
один до одного, зв'язок між ними повинен бути швидким, надійним і ефективним.
Розпізнавання локального вузла в момент входу в систему не складно, оскільки робоча
станція користувача вже знає, в якій із підмереж TCP/IP вона знаходиться, а підмережі
безпосередньо відповідають вузлам Active Directory .
Збір та аналіз інформації
На даному етапі передпроектного дослідження збираються основні відомості щодо
існуючої інфраструктури компанії.
● Для планування структури Active Directory — інформація про доменну структуру
та її тип, структуру груп користувачів та розподіл їх по доменам, кількість
існуючих контролерів доменів усередині кожного домену. Визначення існуючих
довірчих відносин між доменами, односторонніх та двосторонніх довірчих
відносин та доменів, які не повинні включатися до лісів Active Directory , простір
імен DNS, що існують в організації, та переліку існуючих доменних імен
організації, зареєстрованих в мережі Інтернет.
● Для планування сайтів Active Directory - інформація про існуючу структуру сайтів,
про топологію мережі, про канали зв'язку та їх пропускну здатність.
● Для планування перенесення поточної структури мережевих сервісів на платформу
Active Directory - інформація про топологію мережевих сервісів DHCP, WINS,
DNS.
● Задля більшої можливості резервного відновлення даних під час міграції — схема
резервного копіювання інформації.
● Для визначення можливої розширюваності рішення - дослідження можливих
варіантів зміни схеми при зростанні організації або її реорганізації, визначення
області Active Directory (дослідження підрозділів, включаючи віддалені філії
організації, необхідні включення до Active Directory ).
● Для планування міграції додатків, які використовують Active Directory — список
програм, пов'язаних із Active Directory , та можливих обмежень, що накладаються
ними на структуру Active Directory , Визначення механізмів ідентифікації
користувачів.

План проектування структури Active Directory

Проектування структури Active Directory починається з компонентів найвищого
рівня, а потім проектуються компоненти нижчих рівнів. Це означає, що перший крок
полягає у створенні проекту лісу, потім слідує проект доменів, проект DNS і, нарешті,
проект організаційної одиниці (OU) [13].
Проектування структури Active Directory має включати такі основні віхи.
1. Планування структури лісів:
● Визначення типових риштувань для основних типів регіональних
представництв.
● Визначення основних типів довірчих відносин між різними лісами.

● Розробка політики контролю за змінами лісу.

● Політика зміни схеми.

● Політика зміни конфігурації.

● Розробка структури DNS для типових риштувань.

2. Планування доменів для кожного лісу:
 ● Реструктуризація існуючих доменів на домени, залежно від
адміністративних потреб.
● Розбиття на домени залежно від фізичного розташування для оптимізації
трафіку реплікації та запитів.
● Вибір кореневого домену для кожного лісу.

● Оптимізація аутентифікації укороченими довірчими стосунками.

3. Планування використання сайтів для кожного лісу:
● Визначення сайтів виходячи з фізичної топології мережі.

● Створення зв'язків між сайтами.

● План розміщення серверів глобального каталогу на сайтах.

● План розміщення серверів DNS у сайтах.

4. Планування структури організаційних одиниць кожного домену:
● Планування реорганізації доменів в організаційних одиницях.

● Планування організаційних одиниць для делегування адміністративних

повноважень.
● Планування організаційних одиниць приховування об'єктів.

● Створення організаційних одиниць застосування групових політик.

5. Планування реорганізації існуючих доменів та їх переведення на нову платформу
Active Directory :
● Планування переміщення користувачів, комп'ютерів та груп.

● Планування модифікації або видалення з структури доменів, що

реструктуризуються.
● Планування зміни довірчих відносин.

● Планування клонування об'єктів безпеки.

6. Тестування впроваджуваних рішень та встановлення стенду:
● Визначення можливостей та цілей тестування.

● Розробка сценаріїв тестування: ціль тестування; тестовані можливості та

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

При плануванні нових облікових записів для запобігання можливим проблемам

слід звернути увагу на вирішення наступних питань:
● правила найменування, які забезпечать унікальні, але зрозумілі імена облікових
записів;
● спеціаліст, відповідальний визначення паролів;
 ● тимчасові періоди, у які користувачеві дозволено та заборонено входити в мережу;

● можливість блокування облікового запису;

● тип профілю користувача;

● зберігання документів користувача: у локальній папці або домашній папці на

сервері.

Короткі підсумки
У цій лекції були наведені терміни для розуміння предметної області Active
Directory , а також згадано про етап передпроектного дослідження, призначеного для
збирання та аналізу інформації.
Основні відомості щодо існуючої інфраструктури в компанії:
● Інформація про доменну структуру та її тип, структуру груп користувачів та
розподіл їх по доменам, про кількість існуючих контролерів доменів усередині
кожного домену.
● Інформація про існуючу структуру сайтів, про топологію мережі, про канали
зв'язку та їх пропускну здатність.
● Інформація про топологію мережевих сервісів DHCP, WINS, DNS.

● Схема резервного копіювання інформації.

● Визначення області Active Directory .

● Список програм, пов'язаних з Active Directory , та можливих обмежень, що

накладаються ними на структуру Active Directory .

Крім цього, представлений типовий план проектування структури Active Directory ,

який без деталізації виглядає так.
● Планування структури лісів.

● Планування доменів для кожного лісу.

● Планування використання сайтів для кожного лісу.

● Планування структури організаційних одиниць кожного домену.

● Планування реорганізації існуючих доменів та їх переведення на нову платформу

Active Directory .
● Тестування впроваджуваних рішень та встановлення стенду.
Лекція 3. АРХІТЕКТУРА ACTIVE DIRECTORY
Коротка інструкція : Наведено модель даних та структуру функціонування служби
Active Directory у вигляді багаторівневої архітектури. В архітектурі служби каталогів
виділяються логічна структура та фізична структура, а також надається опис їх
компонентів.
Ключові слова : об'єкт, модель даних, функціональна структура, сегменти (розділи),
домен, доменне дерево, ліс, сайт, організаційна одиниця, логічна структура, фізична
структура, контролер доменів, господар схеми, господар іменування доменів, господар
RID, емулятор основного контролера домену, господар інфраструктури, сервер
глобального каталогу, зв'язок сайту.

Ціль лекції
Сформувати уявлення про архітектуру служби каталогів Active Directory ,
визначити компоненти структур Active Directory .

Модель даних
Active Directory зберігає інформацію про мережеві ресурси. Ці ресурси (наприклад,
дані користувачів, описи принтерів, серверів, баз даних, груп, комп'ютерів та політик
безпеки) називаються об'єктами.
Об'єкт — це окремий набір атрибутів, якими представлений мережевий
ресурс. Атрибути об'єкта є його характеристиками у каталозі (див. рис. 3.1).
Модель даних Active Directory будується з урахуванням моделі даних специфікації
X.500 [2].

Мал. 3.1. Схема об'єктів Active Directory та їх атрибути

 У каталозі зберігаються об'єкти, які є найрізноманітнішими одиницями зберігання,
що описуються за допомогою атрибутів. Безліч об'єктів, які можуть зберігатися в каталозі,
задається в логічній структурі ( schema ). Для кожного класу об'єктів логічна структура
визначає, які атрибути обов'язково повинен мати представник даного класу, які додаткові
атрибути може мати і який клас об'єктів може бути батьківським по відношенню до
даного класу. Схема Active Directory містить формальний опис змісту та структури Active
Directory , включаючи всі атрибути, класи та властивості класів.

Функціональна структура
Функціональну структуру Active Directory можна представити у вигляді
багаторівневої архітектури, де рівні є процесами, що надають клієнтським додаткам
доступ до служби каталогу.
Active Directory складається з трьох рівнів служб та кількох інтерфейсів і
протоколів, які спільно працюють для надання доступу до служби каталогу. Три рівні
служб охоплюють різні типи інформації, яка потрібна на пошуку записів у базі даних (БД)
каталогу. Вище рівні служб у цій архітектурі знаходяться протоколи та API-інтерфейси,
що здійснюють зв'язок між клієнтами та службою каталогу.
На рис. 3.2 зображено рівні служби Active Directory та відповідні їм інтерфейси та
протоколи. Тут показано, як різні клієнти отримують за допомогою інтерфейсів доступ до
Active Directory .

Мал. 3.2. Багаторівнева архітектура Active Directory

Основні компоненти служб [4]:

● Системний агент каталогу ( Directory System Agent , DSA ). Вибудовує ієрархію
спадкових («предок-нащадок») відносин, які у каталозі. Надає API-інтерфейси для
 дзвінків доступу до каталогу. Клієнти отримують доступ до Active Directory ,
використовуючи механізми, що підтримуються DSA.
● Рівень БД. Надає рівень абстрагування між додатками та БД. Виклики з програм
ніколи не виконуються безпосередньо до БД, а лише через рівень БД.
● Ядро зберігання, що розширюється. Безпосередньо взаємодіє з конкретними
записами в сховище каталогу з урахуванням атрибута відносного складового імені
об'єкта.
● Сховище даних (файл БД NT D S. dit ). Керується за допомогою механізму
зберігання БД, що розширюється, розташованого на контролері домену.
● LDAP/ADSI. Клієнти, що підтримують LDAP, використовуються для зв'язку з
DSA. Active Directory підтримує LDAP версії 2. Клієнти Windows із встановленими
клієнтськими компонентами Active Directory для зв'язку з DSA застосовують LDAP
версії 3. Хоча ADSI є засобом абстрагування API LDAP, Active Directory
використовує лише LDAP.
● API-інтерфейс обміну повідомленнями ( Messaging API, MAPI). Традиційні
клієнти MAPI, наприклад Microsoft Outlook підключаються до DSA,
використовуючи інтерфейс постачальника адресної книги MAPI RPC.
● Диспетчер облікових записів безпеки ( Security Accounts Manager , SAM).
Реплікація із резервних контролерів у домені змішаного режиму також виконується
через інтерфейс SAM.
● Реплікація (REPL). При реплікації каталогу агенти DSA взаємодіють один з одним
за допомогою патентованого інтерфейсу RPC.

База даних Active Directory містить такі структурні об'єкти [13]:

● Розділи (сегменти). Розділи Active Directory називаються контекстами іменування
(NC - Naming Contexts ) і містять такі сегменти: розділ домену каталогу, розділ
конфігурації каталогу, розділ схеми каталогу, розділ глобального каталогу, розділи
додатків каталогу.
● Домени. Домен служить як адміністративний кордон, він визначає і кордон політик
безпеки. Кожен домен має принаймні один контролер домену (оптимально мати
два або більше). Домени Active Directory організовані в ієрархічному порядку.
Перший домен для підприємства стає кореневим доменом лісу, зазвичай він
називається кореневим доменом чи доменом лісу.
● Дерева доменів. Домени, які створюються в інфраструктурі Active Directory після
створення кореневого домену можуть використовувати існуючий простір імен
Active Directory спільно або мати окремий простір імен. Щоб виділити окремий
простір імен для нового домену, потрібно створити нове дерево домену.
● Ліси. Ліс визначає кордон безпеки для підприємства, будучи спільним для всіх
контролерів домену в лісі. Усі домени та доменні дерева існують в межах одного
або декількох лісів Active Directory .
● Сайти. Сайт представляє область мережі, де всі контролери домену пов'язані
швидким, недорогим та надійним мережним підключенням. Незалежність логічних
компонентів від мережевої інфраструктури виникає внаслідок використання сайтів
 у Active Directory : вони забезпечують з'єднання між логічними компонентами
Active Directory та фізичної мережевої інфраструктури.
● Організаційні одиниці. Організаційні одиниці призначені для того, щоб полегшити
керування службою Active Directory . Вони служать для створення ієрархічної
структури в межах домену і використовуються, щоб зробити ефективнішим
управління єдиним доменом (замість управління кількома доменами Active
Directory ).

Компонентами логічної структури Active Directory є домени, тоді як компонентами

фізичної структури є сайти.
● Домен — це об'єднання серверів та інших мережних ресурсів, зібраних під одним
ім'ям.
● Сайт — комбінація однієї чи більше IP-підмереж, які мають бути з'єднані
високошвидкісним каналом зв'язку.

Логічна структура
В Active Directory ресурси організовані в логічну структуру, яка відображає
структуру організації, що дозволяє знаходити ресурс за його ім'ям, а не за фізичним
розташуванням. Завдяки логічному об'єднанню ресурсів у Active Directory фізична
структура мережі не є важливою для користувачів.
Логічна структура Active Directory є моделлю служби каталогу, яка визначає
кожного учасника безпеки на підприємстві та організацію цих учасників.
На рис. 3.3 показані взаємовідносини компонентів Active Directory .
 Мал. 3.3. Ресурси, організовані у логічну структуру

Логічні компоненти Active Directory [3]

● Об'єкти – ресурси зберігаються у вигляді об'єктів.

● Класи об'єктів.

● Схема Active Directory .

● Домени – базова організаційна структура.

● Дерева – кілька доменів поєднуються в ієрархічну структуру.

● Ліси - група з кількох дерев домену.

● Організаційні одиниці дозволяють ділити домен на зони і делегувати права на них.

Логічна структура Active Directory не базується на фізичному розташування

серверів або мережевих з'єднаннях в межах домену. Це дозволяє структурувати домени,
відштовхуючись не від вимог фізичної мережі, а від адміністративних та організаційних
вимог.
При плануванні логічної структури Active Directory необхідно визначити ієрархію
доменів та організаційних підрозділів, а також розробити угоди про простір імен ( DNS /
WINS ), групові політики та схеми делегування повноважень.
 Групова політика служби Active Directory дозволяє здійснювати детальне та гнучке
централізоване управління групами користувачів, комп'ютерів, додатків та мережевих
ресурсів замість того, щоб керувати цими об'єктами на індивідуальній основі. Служба
Active Directory дозволяє делегувати певний набір адміністративних повноважень з метою
розподілу завдань управління та підвищення якості адміністрування. Делегування
повноважень також допомагає компаніям скоротити кількість доменів, необхідних
підтримки великої організації з офісами у різних географічних точках.
Приклади надання доступу до мережевих ресурсів
● Приклад "Єдиний домен у центральному офісі". Припустимо, що у компанії є
єдиний домен у центральному офісі. Менеджерам компанії до виконання своїх
завдань потрібен доступ до інвентаризаційної БД. Для надання доступу необхідно
об'єднати всіх менеджерів у глобальну групу, створити локальну доменну групу,
що має повноваження доступу до інвентарної бази, і додати глобальну групу
менеджерів до цієї локальної доменної групи.
● Приклад "Середовище з кількома доменами в регіонах". Припустимо, що у
компанії використовується середовище з трьома доменами. Кореневий домен
знаходиться в центральному офісі, інші домени — в регіонах. Менеджерам з усіх
трьох доменів для виконання завдань потрібний доступ до інвентаризаційної БД,
розташованої в центральному офісі. Для надання доступу необхідно:
● у кожному домені створити глобальну групу та додати облікові записи
менеджерів у цьому домені до цієї глобальної групи;
● створити локальну доменну групу для доступу до інвентарної бази даних у
домені центрального офісу;
● додати глобальну групу для доступу до бази даних інвентарю до домену
центрального офісу;
● додати глобальні групи менеджерів з кожного домену до локальної
доменної групи бази даних;
● надати права доступу до інвентарної БД локальної доменної групи.

Фізична структура
Фізична структура мережі з Active Directory досить проста в порівнянні з її
логічною структурою. Фізичні компоненти Active Directory – це вузли (сайти) та
контролери домену. Ці компоненти застосовуються розробки структури каталогу, що
відбиває фізичну структуру організації, яка, своєю чергою, впливає створення сайтів для
компанії.
Фізичний прояв служби Active Directory складається з окремого файлу даних,
розташованого на кожному контролері домену. Фізична реалізація служби Active Directory
описується розташуванням контролерів домену, на яких розташована служба. При
реалізації служби Active Directory можна додавати стільки контролерів доменів, скільки
необхідно для підтримки служб каталогу в цій організації. Є п'ять певних ролей, які може
грати кожен із контролерів домену. Вони відомі як ролі господаря операцій ( operations
master roles ). Ще одна роль, яку може виконувати будь-який окремий контролер домену в
домені, пов'язана з глобальним каталогом (GC - Global Catalog ). У цьому розділі ми
розглянемо сховище даних служби Active Directory та контролери домену, на яких воно
розташоване.
Контролери доменів та їх ролі
Контролер домену - це комп'ютер-сервер, що управляє доменом і зберігає репліку
каталогу домену (локальну БД домену). Оскільки в домені може бути кілька контролерів
домену, всі вони зберігають повну копію частини каталогу, яка відноситься до їх домену
[6].
Нижче наведено функції контролерів доменів [4].
● Кожен контролер домену зберігає повну копію всієї інформації Active Directory ,
що відноситься до його домену, а також управляє змінами цієї інформації та
реплікує їх на інші контролери того ж домену.
● Всі контролери в домені автоматично реплікують всі об'єкти в домені. Будь-які
зміни, які вносяться в Active Directory насправді виробляються на одному з
контролерів домену. Потім цей контролер домену реплікує зміни інші контролери у
межах свого домену. Задаючи частоту реплікації та кількість даних, яку Windows
передаватиме при кожній реплікації, можна регулювати мережевий трафік між
контролерами домену.
● Важливі оновлення, наприклад відключення облікового запису користувача,
контролери домену негайно реплікують.
● Active Directory використовує реплікацію з кількома господарями ( multimaster
replication ), в якому жоден із контролерів домену не є головним. Усі контролери
рівноправні, і кожен із них містить копію бази даних каталогу, куди дозволяється
вносити зміни. У короткі періоди часу інформація в цих копіях може відрізнятися,
поки всі контролери не синхронізуються один з одним.
● Наявність у домені кількох контролерів забезпечує відмовостійкість. Якщо один із
контролерів домену недоступний, інший виконуватиме всі необхідні операції,
наприклад записувати зміни в Active Directory .
● Контролери домену управляють взаємодією користувачів та домену, наприклад
знаходять об'єкти Active Directory і розпізнають спроби входу до мережі.

Існує дві ролі господаря операцій, які можуть бути призначені єдиному контролеру
домену в лісі (ролі, що діють у межах лісу) [3]:
● Господар схеми ( Schema Master ). Перший контролер домену в лісі бере участь
господаря схеми та відповідає за підтримку та поширення схеми на решту лісу. Він
підтримує список усіх можливих класів об'єктів та атрибутів, які визначають
об'єкти, які знаходяться в Active Directory . Якщо схему потрібно оновлювати чи
змінювати, наявність Schema Master обов'язково.
● Господар іменування доменів ( Domain Naming Master ). Протоколує додавання та
видалення доменів у лісі та життєво необхідний для підтримки цілісності доменів.
Domain Naming Master запитується при додаванні до лісу нових доменів. Якщо
Domain Naming Master недоступний, то додавання нових доменів неможливе; проте
за необхідності ця роль може бути передана іншому контролеру.

Існує три ролі господаря операцій, які можуть бути призначені одному з
контролерів у кожному домені ( загальнодоменні ролі) [3].
● Господар RID (Relative Identifier (RID) Master). Відповідає за виділення діапазонів
відносних ідентифікаторів (RID) для всіх контролерів у домені. SID у Windows
 Server 2003 складається із двох частин. Перша частина – загальна для всіх об'єктів
у домені; до створення унікального SID до цієї частини додається унікальний RID.
Водночас вони унікально ідентифікують об'єкт та вказують, де його було створено.
● Емулятор основного контролера домену ( Primary Domain Controller (PDC)
Emulator ). Відповідає за емуляцію Windows NT 4.0 PDC для клієнтських машин,
які ще не переведені на Windows 2000, Windows Server 2003 або Windows XP і на
яких не встановлений клієнт служби каталогів. Одне з основних завдань емулятора
PDC – реєструвати застарілі клієнти. Крім того, до емулятора PDC відбувається
звернення, якщо автентифікація клієнта виявилася невдалою. Це дозволяє
емулятору PDC перевіряти недавно змінені паролі для застарілих клієнтів у домені,
перш ніж відхиляти запит на вхід.
● Господар інфраструктури ( Infrastructure Master ). Реєструє зміни, що вносяться
до контрольованих об'єктів у домені. Про всі зміни спочатку повідомляється
Infrastructure Master , і потім вони реплікуються інші контролери домену.
Infrastructure Master обробляє інформацію про групи та членство в них для всіх
об'єктів у домені. Ще одне завдання Infrastructure Master — передавати інформацію
про зміни, внесені до об'єктів, до інших доменів.

Мал. 3.4. Ухвалений за умовчанням розподіл ролей господаря операцій у лісі

Роль "Сервер глобального каталогу" (GC - Global Catalog ) може виконувати будь-
який окремий контролер домену в домені - одна з функцій сервера, яку можна призначити
контролеру домену [13]. Сервери глобального каталогу виконують два важливі завдання.
Вони дають можливість користувачам входити до мережі та знаходити об'єкти у будь-якій
частині лісу. Глобальний каталог містить підмножину інформації з кожного домену і
реплікується між серверами глобального каталогу в домені. Коли користувач намагається
увійти до мережі або звернутися до якогось мережевого ресурсу з будь-якої точки лісу,
відповідний запит дозволяється за участю глобального каталогу. Інше завдання
глобального каталогу, корисне незалежно від того, скільки доменів у вашій мережі, -
участь у процесі автентифікації при вході користувача до мережі. Коли користувач
входить до мережі, його ім'я спочатку звіряється з вмістом глобального каталогу. Це
дозволяє входити в мережу з комп'ютерів у доменах, відмінних від того, де зберігається
потрібний обліковий запис користувача.

Концепція сайтів
Концепція сайтів використовується продуктами сімейства Microsoft BackOffice для
мінімізації трафіку в глобальній мережі та ґрунтується на тому, що її основу становить IP-
мережа, для якої треба забезпечити найкращі умови підключень незалежно від
використовуваних програм.
Сайт Windows Server 2003 - це група контролерів доменів, які знаходяться в єдиній
або декількох IP-підмережах і пов'язані швидкісними та надійними мережевими
з'єднаннями. Сайти переважно використовуються для управління трафіком реплікації.
Контролери доменів усередині сайту можуть вільно реплікувати зміни до бази даних
Active Directory щоразу, коли відбуваються такі зміни. Однак контролери доменів у різних
сайтах стискають трафік реплікації та передають його за певним розкладом, щоб
зменшити мережевий трафік.
Сайти не є частиною простору імен Active Directory . Коли користувач переглядає
логічний простір імен, комп'ютери та користувачі групуються до доменів та OU без
посилань на сайти.
Сайти містять об'єкти лише двох типів [3]:
● Контролери доменів у межах сайту.

● Зв'язки сайту ( site links ), налаштовані для з'єднання даного сайту з іншими. Зв'язок
складається з двох частин: фізичного з'єднання між сайтами (зазвичай WAN-
каналу) та об'єкта зв'язку сайту ( site link object ). Цей об'єкт створюється в Active
Directory та визначає протокол передачі трафіку реплікації (IP або SMTP). Об'єкт
зв'язку також ініціює виконання запланованої реплікації.

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

цьому необхідно враховувати потребу в лініях зв'язку для здійснення міжсайтової
реплікації за розкладом, що створюється.
Сайт з Active Directory складається з однієї або декількох підмереж IP, які можуть
бути визначені адміністратором і змінені ним шляхом включення нових підмереж.
Поділ на сайти не залежить від доменної (логічної) структури, тобто:
● на сайті може бути один домен (або тільки його частина) або кілька доменів;

● у домені (або навіть в організаційному підрозділі) може бути декілька сайтів.

Створення сайтів, структура яких відображає фізичне розташування контролерів

доменів на майданчиках компанії, може бути реалізовано за одним із таких варіантів:
● структура з одним сайтом (єдиний сайт, що включає всі IP-підмережі);

● структура з кількома сайтами (окремий сайт кожного майданчика).

Особливостями сайту є:
● оптимізація трафіку тиражування між сайтами повільними лініями;

● допомога клієнтам швидше виявляти найближчі до них контролери.

 Поняття сайту нерозривно пов'язане із топологією тиражування. Тиражування
всередині сайту та між сайтами використовує різні топології:
● Усередині сайту – це двонаправлене кільце. Тиражування виконується методом
виклику віддалених процедур ( R emote P rokudure Calls , RPC ). Усередині сайту
контролер домену затримує сповіщення про зроблені зміни на деякий проміжок
часу, що встановлюється.
● Для тиражування між сайтами використовується RPC або повідомлення.
Стандартно використовується механізм SMTP, проте якщо у мережі є Microsoft
Exchange , то він також може бути задіяний для тиражування Active Directory .

Служба каталогів відстежує цілісність топології: жоден контролер домену може

бути виключено з процесу тиражування, що забезпечується окремим контрольним
процесом ( Knowledge Консистенція Checker , KCC), виконуваним усім контролерах
домену — у разі порушення топологія тиражування відновлюється KCC.
Для пошуку найближчих ресурсів або контролерів домену клієнти можуть
скористатися інформацією про сайт. Концепція пошуку найближчого ресурсу або
контролера домену дозволяє скоротити трафік у низькошвидкісних частинах глобальних
мереж. На початку процесу входу в мережу клієнт отримує від контролера домену ім'я
сайту, до якого належить, ім'я сайту, до якого належить контролер домену, а також
інформацію про те, чи є контролер домену найближчим до клієнта. Якщо це не
найближчий контролер, то клієнт може звернутися до контролера домену у його власному
сайті та надалі працювати з ним як із найближчим контролером. Так як на клієнті ця
інформація зберігається в реєстрі, вона може бути використана під час наступного входу
до мережі.
Для можливості керування сертифікатами безпеки при багатодоменній
інфраструктурі (впровадження методів захисту інформації), що враховує інтеграцію з
іншими платформами, а також для гарантованої ідентифікації пакетів під час проведення
міжсайтової реплікації у структурі Active Directory планується та створюється архітектура
відкритих ключів (PKI).
Сервер сертифікатів є важливою частиною архітектури відкритих ключів і дозволяє
видавати в компанії власні сертифікати для своїх користувачів, реалізуючи такі
можливості політик PKI , як автентифікація на основі сертифікатів, IPSec , захищена
електронна пошта та ін.

Короткі підсумки
У цій лекції було наведено модель даних та структуру функціонування служби
Active Directory у вигляді багаторівневої архітектури:
● Системний агент каталогу (Directory System Agent, DSA).

● Рівень БД.

● Ядро зберігання, що розширюється.

● Сховище даних (файл БД NT D S. dit ).

● LDAP/ADSI.

● API-інтерфейс обміну повідомленнями ( Messaging API, MAPI).

● Диспетчер облікових записів безпеки ( Security Accounts Manager , SAM).

 ● Реплікація (REPL).

База даних Active Directory містить такі структурні об'єкти:

● Розділи (сегменти).

● Домени.

● Дерева доменів.

● Ліси.

● Сайти.

● Організаційні одиниці.

Логічні компоненти Active Directory

● Об'єкти – ресурси зберігаються у вигляді об'єктів.

● Класи об'єктів.

● Схема Active Directory .

● Домени - Базова організаційна структура.

● Дерева – кілька доменів поєднуються в ієрархічну структуру.

● Ліси - група з кількох дерев домену.

● Організаційні одиниці дозволяють ділити домен на зони і делегувати на них права.

Фізична структура мережі з Active Directory досить проста в порівнянні з її

логічною структурою, тому що фізичні компоненти Active Directory – це вузли (сайти) та
контролери домену.
Необхідно чітко уявляти, що компонентами логічної структури Active Directory є
домени, тоді як компонентами фізичної структури є сайти.
Поділ на сайти не залежить від доменної (логічної) структури, тобто:
● на сайті може бути один домен (або тільки його частина) або кілька доменів;

● у домені (або навіть в організаційному підрозділі) може бути декілька сайтів.

Сайти містять об'єкти лише двох типів:

● контролери доменів у межах сайту;

● зв'язку сайту ( site links ), налаштовані для з'єднання даного сайту з іншими.

Ролі господаря операцій, які можуть бути призначені контролеру домену:

● Господар схеми (Schema Master);

● Господар іменування доменів ( Domain Naming Master );

● Господар RID (Relative Identifier (RID) Master);

 ● Емулятор основного контролера домену (Primary Domain Controller (PDC)
Emulator);
● Господар інфраструктури (Infrastructure Master);

● Сервер глобального каталогу (GC - Global Catalog ).

Особливостями сайту є:
● оптимізація трафіку тиражування між сайтами повільними лініями;

● допомога клієнтам швидше виявляти найближчі до них контролери.

Поняття сайту нерозривно пов'язане із топологією тиражування. Тиражування

всередині сайту та між сайтами використовує різні топології.
● Усередині сайту – це двонаправлене кільце.

● Для тиражування між сайтами використовується RPC або повідомлення.

Служба каталогів відстежує цілісність топології: жоден контролер домену може

бути виключено з процесу тиражування, що забезпечується окремим контрольним
процесом ( Knowledge Консистенція Checker , KCC), виконуваним усім контролерах
домену — у разі порушення топологія тиражування відновлюється KCC.
Лекція 4. ПЛАНУВАННЯ РОЗгортання ACTIVE DIRECTORY
Коротка інструкція : Під час підготовки варіантів розгортання Active Directory необхідно
спланувати структуру доменів (кореневий домен та дерево доменів), а також простір імен
DNS для можливості створення доменної ієрархії. Наводиться типовий план-графік
розгортання Active Directory , і навіть короткий опис його етапів.
Ключові слова : ліс, сегменти (розділи), довірчі відносини, домен, контролер домену,
організаційна одиниця.

Ціль лекції
Визначити порядок розгортання служби каталогу, дати уявлення про початковий
етап планування Active Directory - проектування структури лісу та доменної структури.

Розгортання служби каталогу Active Directory вимагає планування та проектування.

Ми наведемо короткий огляд процесу планування, через який необхідно пройти, перш ніж
розпочати розгортання Active Directory . Найголовніше питання - скільки лісів потрібно
для мережі організації. Потім обговорюється розбиття лісів на домени та планування
доменного простору імен. Під час підготовки варіантів розгортання Active Directory
необхідно спланувати структуру доменів (кореневий домен та дерево доменів), а також
простір імен DNS для можливості створення доменної ієрархії.
Крім того, необхідно виробити підхід щодо розміщення об'єктів в організаційних
підрозділах, що передбачає визначення механізму поділу ресурсів компанії з
організаційних підрозділів, а також аналіз зовнішніх умов, що застосовуються до їхньої
ієрархії. Після створення структури організаційних одиниць для кожного домену
необхідно налаштувати сайти.
Зазначені дії дозволяють врахувати розгалужену структуру компанії при
розгортанні єдиної інфраструктури Active Directory .

План-графік розгортання
Основні віхи у плані-графіці розгортання Active Directory
● Формування проектної групи.

● Ініціація проекту, узгодження плану робіт, ролей та відповідальності.

● Обстеження існуючої інфраструктури:

● Обстеження існуючої структури Active Directory .

● Обстеження інфраструктури (додатки, які використовують Active

Directory ).
● Формалізація результатів обстеження.

● Планування структури Active Directory :

● Аналіз вимог замовника до побудови інфраструктури Active Directory .

● Планування дерев (ліси) та доменів.

● Планування топології сайтів.

● Розробка архітектури PKI.
 ● Планування політики резервного копіювання.

● Планування системи моніторингу на період дослідної експлуатації.

● Формалізація та розробка технічного завдання.

● Розгортання тестового середовища, тестування міграції:

● Визначення переліку додатків, що підлягають тестуванню.

● Визначення апаратної конфігурації тестового стенду.

● Визначення набору ресурсів Active Directory для міграції (для кожної

програми).
● Розгортання репрезентативної копії бойового середовища.

● Верифікація ідентичності тестового середовища в промисловому

середовищі.
● Розгортання спроектованої структури Active Directory у тестовому
середовищі.
● Проведення тестової міграції.

● Деінсталяція копії бойового середовища.

● Верифікація коректності здійсненої міграції.

● Формування проектної документації (типова процедура міграції).

● Розгортання структури Active Directory кореневого домену та центрального офісу.

● Інформування користувачів.

● Розгортання спроектованої структури Active Directory .

● Проведення міграції.

● Спостереження під час адаптації.

● Доопрацювання типової процедури міграції за результатами розгортання.

● Навчання адміністраторів.

● Тиражування рішення на філії організації.

● Доопрацювання та здавання документації.

Аналіз існуючої інфраструктури

Насамперед визначається географічна модель організації, тобто визначаються такі
складові.
● Локальна модель.

● Регіональні моделі.
 ● Національні моделі.

● Міжнародні моделі.

● Філії.

● Дочірні компанії.

З цієї інформації створюється карта територіального розміщення організації та

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

Планування структури Active Directory

Перший крок у плануванні структури Active Directory — Визначення лісів та
доменів. Більш детальна інформація про варіанти побудови лісів та варіанти визначення
доменної структури наведено в наступній лекції.

Проектування структури лісу

Найголовніше рішення, яке необхідно ухвалити на ранньому етапі розробки Active
Directory — скільки лісів потрібно. Розгортання єдиного лісу означає, що буде можливе
просте спільне використання ресурсів та доступ до інформації в межах компанії.
Використання єдиного лісу для великої корпорації потребує високого ступеня довіри між
різноманітними та, можливо, роз'єднаними діловими підрозділами. Зрештою кількість
лісів, що розгортаються, залежить від того, що є найбільш важливим для компанії:
легкість спільного використання інформації в межах усіх доменів лісу або підтримка
повністю автономного та ізольованого управління частинами структури каталогу.
Для більш успішного проектування структури лісів служби Active Directory
необхідне залучення бізнес-замовників, які є основними споживачами послуг ІТ-
інфраструктури. Ці завдання стосуються питань доступності інформації, безпеки,
простоти управління та практичності. Менеджери зазвичай включаються до прийняття
рішень, які не можуть бути змінені відразу після розгортання. Серед цих рішень —
питання про те, скільки лісів та доменів потрібно мережі та скільки має бути розгорнуто
доменних просторів імен.
Ліс Active Directory призначено для того, щоб бути окремим самодостатнім
модулем. Усередині лісу має бути реалізована можливість спільно використовувати
інформацію та співпрацювати з іншими користувачами з того самого підрозділу.
Проектуючи найвищий рівень інфраструктури Active Directory необхідно вирішити, чи
потрібно розгортати один ліс або кілька. Кожен ліс є інтегрованим модулем, тому що він
включає такі складові [13]:
● Світовий каталог. Ліс має один світовий каталог (GC). Каталог GC полегшує
пошук об'єктів у будь-якому домені лісу та вхід на будь-який домен лісу незалежно
від того, на якому домені зареєстровано обліковий запис користувача.
● Розділ конфігурації каталогу. Усі контролери домену спільно використовують той
самий розділ конфігурації каталогу. Ця інформація потрібна для оптимізації
реплікації інформації в межах лісу, для зберігання програм та інформації Active
Directory , що підтримує програми, та для спільного використання інформації за
допомогою розділу додатків каталогу.
 ● Довірчі відносини. Усі домени у лісі пов'язані двосторонніми транзитивними
довірчими відносинами. Немає ніякої опції, що дозволяє змінити це.

Хоча служба Active Directory полегшує спільне використання інформації, вона

наказує безліч обмежень, які вимагають, щоб різні підрозділи компанії співпрацювали
різними способами [13].
● Одна схема. Усі домени у лісі використовують одну схему. Ця обставина начебто
спрощує справу, але вона може бути однією з причин розгортання кількох лісів у
компанії. Якщо один підрозділ вирішує розгортати додаток, який змінює схему, це
впливає на всі підрозділи. Кожна модифікація схеми має бути перевірена для
гарантії того, що вона не суперечить іншим змінам схеми. Це вимагатиме значного
часу та зусиль.
● Централізоване керування. Розгортання єдиного лісу означає, що деякі
компоненти мережевого управління мають бути централізовані. Наприклад, єдина
група, яка має право змінювати схему, - це група Schema Admins (адміністратори
схеми). Єдина група, яка має право додавати та видаляти домени з лісу, - це група
Enterprise Admins (адміністратори підприємства). Група Enterprise Admins
автоматично додається до домену локальної групи Administrators (адміністратори)
кожного контролера домену в лісі.
● Політика керування змінами. Оскільки зміни лісу можуть стосуватися кожного
домену і повинні виконуватися лише централізовано, потрібна чітка політика
управління змінами.
● Довірені адміністратори. Розгортання одного лісу потребує певної міри довіри
адміністраторам усіх доменів. Будь-який адміністратор, який має права управління
контролером домену, може зробити такі зміни, які торкнуться всього лісу. Це
означає, що всі адміністратори доменів мають бути високодовіреними людьми.

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

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

Проектування доменної структури

Як тільки питання про кількість лісів, що розгортаються, улагоджено, необхідно
визначити доменну структуру в межах кожного з лісів. Перше завдання полягає в тому,
щоб задокументувати конфігурацію поточних служб каталогу та визначити, яка частина
поточної інфраструктури може бути модернізована, а яка має бути реструктурована чи
замінена. Потім визначається необхідна кількість доменів та їх ієрархія.
Домени використовуються для поділу великого лісу на дрібніші компоненти для
реплікації або адміністрування. Наступні характеристики домену дуже важливі при
проектуванні Active Directory [13]:
● Кордон реплікації. Межі домену є межами реплікації для розділу домену каталогу
та інформації домену, що зберігається в папці Sysvol на всіх контролерах домену.
У той час як інші розділи каталогу (розділ схеми, конфігурації та GC) реплікуються
по всьому лісі, розділ каталогу домену реплікується лише в межах одного домену.
● Кордон доступу до ресурсів. Межі домену є також межами доступу до ресурсів. За
замовчуванням користувачі одного домену не можуть звертатися до ресурсів,
розміщених в іншому домені, якщо їм не будуть явно надані відповідні дозволи.
 ● Кордон політики безпеки. Деякі політики безпеки можуть бути встановлені лише
на рівні домену. Ці політики, такі як політика паролів, політика блокування
облікових записів та політика квитків Kerberos , застосовуються до всіх облікових
записів домену.

У той час як у більшості компаній впроваджується модель Active Directory з

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

● Спрощення управління користувачами та групами.

● Немає потреби планувати довірчі відносини.

● Для делегування прав використовуються OU.

● Застосування кількох доменів

● Можливість реалізації різних безпекових політик.

● Децентралізоване керування.

● Оптимізація трафіку.

● Різні простір імен.

● Необхідно зберегти існуючу архітектуру доменів Windows NT.

● Розміщення власника схеми в окремий домен.

Застосування одного домену

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

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

Хоча однодоменна модель дає істотну перевагу - простоту, іноді доводиться
використовувати кілька доменів, тому що існує багато серйозних підстав для такого
рішення [13].
● Трафік реплікації має бути обмежений. Розділ каталогу домену, який є найбільшим
і найчастіше змінним розділом каталогу, копіюється на всі контролери домену в
 домені. У деяких випадках це може викликати надто великий трафік реплікації між
офісами компанії (навіть якщо налаштовано декілька сайтів).
● Між офісами компанії існують повільні мережеві підключення або в офісах є
багато користувачів. Єдиний спосіб обмежити в цьому випадку трафік реплікації
полягає в тому, щоб створити додаткові домени.
● Будь-які офіси компанії, зв'язок між якими забезпечується лише простим
протоколом надсилання пошти (SMTP), повинні конфігуруватися як окремі
домени. Інформація домену не може реплікуватись через зв'язки сайту, які
використовують протокол SMTP.
● Єдиний спосіб мати різну політику паролів, політику блокування облікових записів
та політику квитків Kerberos полягає у розгортанні окремих доменів.
● Необхідність обмежувати доступ до ресурсів та мати адміністративні дозволи.

● У деяких випадках додаткові домени створюються тому, що найкращий шлях

переходу для організації полягає в модернізації кількох доменів.

Краще планувати домени так, щоб вони входили в одне дерево доменів. Так як всі
домени в одному дереві ділять один простір імен, адміністративні витрати будуть значно
нижчими, ніж при використанні кількох дерев. При створенні кількох доменів визначати
їх межі краще відповідно до тих розмежувань усередині компанії, ймовірність зміни яких
найменше. Наприклад, створення доменів за територіальним принципом, як правило,
надійніше, ніж створення доменів відповідно до ієрархії підрозділів компанії, оскільки
зміна організаційної структури більш ймовірна, ніж зміна територіальної.
При використанні моделі Active Directory з кількома доменами виконуються такі
правила [3]:
● у кожному домені потрібно хоча б один контролер;

● групова політика та управління доступом діє на рівні домену;

● під час створення дочірнього домену між батьківським і дочірнім доменами

автоматично встановлюються двосторонні транзитивні довірчі відносини;
● адміністративні права, що діють між доменами, видаються лише адміністраторам
підприємства;
● необхідно створювати довірені канали.

Проектування кореневого домену лісу

Інше важливе рішення, яке доцільно прийняти під час планування розгортання
служби Active Directory : необхідність розгорнути призначений кореневий домен
(називається також порожнім коренем). Призначений кореневий домен ( dedicated root
domain ) - це домен, який виконує функції кореневого домену лісу. У цьому домені немає
облікових записів користувачів або ресурсів, за винятком тих, які потрібні для керування
лісом.
Для більшості компаній, що розгортають кілька доменів, рекомендується мати
призначений кореневий домен [13]. Кореневий домен - це критичний домен у структурі
Active Directory , що містить адміністративні групи рівня лісу (групи Enterprise Admins та
Schema Admins ) та господарів операцій рівня лісу (господаря іменування доменів та
господаря схеми). Крім того, кореневий домен повинен бути завжди доступним, коли
користувачі входять на інші домени, що не є їх домашніми доменами, або коли
користувачі звертаються до ресурсів, які розташовані в інших доменах. Кореневий домен
не можна замінювати, якщо він зруйнований, його не можна відновити - необхідно знову
побудувати весь ліс.
Додаткові завдання під час проектування домену [3]:
● планування DNS;

● планування WINS;

● планування інфраструктури мережі та маршрутизації;

● планування підключення до Інтернету;

● планування стратегії віддаленого доступу

Короткі підсумки
У цій лекції наведено план-графік розгортання Active Directory , який без
деталізації виглядає так:
● Формування проектної групи.

● Ініціація проекту, узгодження плану робіт, ролей та відповідальності.

● Обстеження наявної інфраструктури.

● Планування структури Active Directory .

● Розгортання тестового середовища, тестування міграції.

● Розгортання структури Active Directory кореневий домен в центральному офісі.

● Тиражування рішення на філії організації.

● Доопрацювання та здавання документації.

При аналізі існуючої інфраструктури визначається насамперед географічна модель

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

● Розділ конфігурації каталогу.

● Довірчі відносини.

Хоча служба Active Directory полегшує спільне використання інформації, вона

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

● Централізоване керування.

● Політика керування змінами.

● Довірені адміністратори.

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

визначити доменну структуру в межах кожного з лісів.
Домени використовуються для поділу великого лісу на дрібніші компоненти для
реплікації або адміністрування. Наступні характеристики домену дуже важливі при
проектуванні Active Directory :
● межа реплікації;

● межа доступу до ресурсів;

● кордон політики безпеки.

У той час як у більшості компаній впроваджується модель Active Directory з

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

● спрощення управління користувачами та групами;

● немає потреби планувати довірчі відносини;

● для делегування прав застосовуються OU.

● Застосування кількох доменів:

● можливість реалізації різних безпекових політик;

● децентралізоване керування;

● оптимізація трафіку;

● різні простори імен;

● потрібно зберегти існуючу архітектуру доменів Windows NT;

● розміщення господаря схеми окремий домен.

Більш детальна інформація про варіанти побудови лісів та варіанти визначення

доменної структури наведено в наступній лекції.

Лекція 5. МОДЕЛІ ПОБУДУВАННЯ ЛІСІВ І ДЕТАЛІЗАЦІЯ ДОМІННОЇ

СТРУКТУРИ

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

Ціль лекції
Дати уявлення про можливі моделі побудови лісів та відповідну їм деталізацію
доменної структури.

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

Варіанти побудови лісу

У даному розділі ми дамо опис різних моделей побудови лісів Active Directory та
проведемо їх порівняльний аналіз.
● Варіант 1 "Єдиний ліс, кожен регіон - окреме дерево".

● Варіант 2 "Єдиний ліс, адміністративний кореневий домен, кожен регіон - домен".

● Варіант 3 "Єдиний ліс, кожен регіон - дочірній домен центрального домену".

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

Єдиний ліс, кожен регіон – окреме дерево

Існує окреме дерево з кореневим доменом, що зберігає групи Enterprise Admins та
Schema Admins , що дозволить гнучко контролювати членство у цих групах та виключити
присутність у них за умовчанням всіх адміністраторів центрального офісу (група Admins
кореневого домену входить до груп Enterprise Admins , Schema Admins ).
Різні дерева можуть мати різні простори імен DNS. Кореневі домени дерев
пов'язані транзитивними довірчими стосунками.
Плюси моделі:
● користувачі можуть переглядати ресурси центрального офісу та регіонів за
відповідних прав доступу до об'єктів Active Directory ;
● можливість реєстрації мобільних користувачів у будь-якій точці організації;

● єдиний обмін у створенні;

● підвищена захищеність - автентифікація за протоколом Kerberos , групи Enterprise

Admins , Schema Admins знаходяться в окремому кореневому домені, Schema
Master знаходиться в окремому домені;
● найкоротший шлях довіри.

Мінуси моделі:
● видимість списку доменів усієї організації;
 ● для наявності права створення нових дерев/доменів адміністратор повинен бути
присутнім у групі Enterprise Admins ;
● тиражування конфігурації та схеми Active Directory для всіх регіонів;

● якщо в організації вже розгорнуто структуру Active Directory , то контролери

домену в цій організації необхідно перевстановити.

Єдиний ліс, адміністративний кореневий домен, кожен регіон — домен

Існують спільне дерево Active Directory для регіонів та загальна система
іменування, заснована на географічному принципі. Кожен регіональний підрозділ
представлений доменом. Регіональні домени додаються як дочірні до кореневого домену.
Адміністративні групи Enterprise Admins , Schema Адміни , що дають їх членам
адміністративні повноваження в лісі, винесені в окремий кореневий домен.
Існує єдиний простір доменних імен, дочірні домени успадковують ім'я
батьківського домену DNS. Також існує єдина пошукова служба, що дозволяє знаходити
об'єкти у будь-якому домені служби Active Directory .
Плюси моделі:
● користувачі можуть переглядати ресурси центрального офісу та регіонів за
відповідних прав доступу до об'єктів Active Directory ;
● можливість реєстрації мобільних користувачів у будь-якій точці організації;

● єдиний обмін у створенні;

● підвищена захищеність - автентифікація за протоколом Kerberos , групи Enterprise

Admins , Schema Admins знаходяться в окремому кореневому домені, Schema
Master знаходиться в окремому домені.

Мінуси моделі:
● видимість списку доменів усієї організації;

● для наявності права створення нових дерев/доменів адміністратор повинен бути

присутнім у групі Enterprise Admins ;
● тиражування конфігурації та схеми Active Directory для всіх регіонів;

● шлях довіри довший.

Єдиний ліс, кожен регіон – дочірній домен центрального домену

У кореневому домені поряд із групами Enterprise Admins та Schema Admins існують
інші облікові записи центрального офісу. Будь-який користувач, який потрапляє до групи
Admins , стає Enterprise Admins , оскільки група Admins входить до груп Enterprise Admins
та Schema Admins . Регіональні домени стають дочірніми для кореневого домену.
Існує єдиний простір доменних імен, дочірні домени успадковують ім'я
батьківського домену DNS. Є єдина пошукова служба, що дозволяє знаходити об'єкти у
будь-якому домені служби Active Directory .
Плюси моделі:
● користувачі можуть переглядати ресурси центрального офісу та регіонів за
відповідних прав доступу до об'єктів Active Directory ;
 ● можливість реєстрації мобільних користувачів у будь-якій точці організації;

● єдиний обмін у створенні; підвищена захищеність - автентифікація за протоколом

Kerberos ;
● скорочення кількості комп'ютерів - контролерів домену через відсутність
кореневого "порожнього" домену.

Мінуси моделі:
● видимість списку доменів усієї організації;

● для наявності права створення нових дерев/доменів, адміністратор повинен бути

присутнім у групі Enterprise Admins ;
● тиражування конфігурації та схеми Active Directory для всіх регіонів;

● необхідні додаткові зусилля щодо контролю членства у групах Enterprise Admins ,

Schema Admins (не допускати в них групу Admins );
● структурне підпорядкування регіонів;

● шлях довіри довший.

Застосування кількох лісів

Ліси є крайні межі зон безпеки. Між лісами неможливе адміністративне управління
або доступ, якщо на те немає явного дозволу в конфігурації. Для цього призначено тип
довіри, введений у Windows Server 2003 — довіра до лісу ( forest trust ), що застосовується
при управлінні відносинами між двома лісами.
Довіра до лісу перестав бути транзитивним лише на рівні лісів. Іншими словами,
якщо перший ліс довіряє другому, а другий — третьому, це ще не означає, що перший
автоматично довіряє третьому. Також необхідно враховувати, що для використання
довіри до лісу потрібно, щоб обидва ліси знаходилися на функціональному рівні Windows
2003 - всі контролери доменів в обох лісах повинні працювати під керуванням Windows
Server 2003
Є кілька випадків, описаних далі, у яких може знадобитися реалізація кількох лісів,
проте у принципі слід за можливості уникати використання моделі з кількох лісів з
причин, наведених нижче.

Випадки реалізації кількох лісів

Реалізація моделі побудови кількох лісів допускається у таких випадках [3]:
● Об'єднання двох існуючих організацій. Незалежно від того, чи це злиття або
поглинання, можна зіткнутися з тим, що з'являться два повністю роздільні ліси, які
потрібно пов'язати один з одним для спільного використання ресурсів. Цей зв'язок
може бути тимчасовим, якщо надалі один ліс планується зробити частиною іншого,
або постійним, якщо обидві компанії мають залишитися відносно автономними.
● Створення автономного підрозділу. Оскільки ліси є крайніми зонами безпеки,
окремий ліс можна використовувати для створення мережі, в якій адміністрування
значною мірою незалежно від основного лісу. У такому випадку для окремого лісу
схема може підтримуватися та змінюватися, не впливаючи на інші ліси.
 ● Створення ізольованого підрозділу. В ізольованому лісі гарантується, що
адміністратор поза лісом не зможе вплинути на керування ним.

Недоліки структури кількох лісів

Перш ніж приступити до планування структури кількох лісів, необхідно взяти до
відома, що більшість функціональності, доступної не більше одного лісу, недоступна між
лісами. Крім того, підтримка кількох лісів потребує значно більших зусиль в
адмініструванні, ніж підтримка одного лісу.
Архітектура з кількома лісами має такі вади [3].
● При пошуку ресурсів від користувачів потрібний високий рівень підготовки. З
погляду користувача, пошук ресурсів у межах одного лісу порівняно простий
завдяки єдиному глобальному каталогу. За наявності кількох лісів є кілька
глобальних каталогів, і користувачам доводиться вказувати, у якому лісі вести
пошук ресурсів.
● Співробітники, яким потрібно входити на комп'ютери, включені до зовнішніх лісів,
повинні вказувати при вході основне ім'я користувача ( User Principal Name (UPN)
за замовчуванням. Від таких співробітників також потрібний більш високий рівень
підготовки.
● Адміністраторам доводиться зберігати кілька схем.

● До кожного лісу використовуються окремі контейнери конфігурації. Зміни у

топології необхідно реплікувати до інших лісів.
● Будь-яку реплікацію інформації між лісами доводиться налаштовувати вручну.
Адміністратори повинні конфігурувати дозвіл DNS-імен між лісами, щоб
забезпечити функціонування контролерів доменів та підтримку пошуку ресурсів.
● Адміністраторам доводиться налаштовувати списки управління доступом (ACL) до
ресурсів, щоб відповідні групи з різних лісів могли звертатися до цих ресурсів, а
також створювати нові групи, щоб можна було використовувати ролі одних лісів в
інших лісах.
● Часто для спостереження за окремими лісами та управління ними потрібен
додатковий персонал, а отже витрачаються кошти на підготовку більшого штату
співробітників та на оплату їхньої праці.

Деталізація доменної структури

Для деталізації доменної структури компанії необхідно вибрати оптимальну
структуру лісу. Варіанти побудови лісів було наведено у попередньому розділі. Тепер
необхідно визначитися з варіантами деталізації доменної структури, які будуть більш
докладно описані в наступних підрозділах:
● Варіант 1 "Повторення існуючої доменної структури".

● Варіант 2 "Кілька лісів, мінімальна кількість доменів".

● Варіант 3 "Єдиний ліс".

Повторення існуючої доменної структури
Домен для міграції існує у окремому лісі. Необхідно створити два облікові записи
для кожного користувача центрального офісу та регіонального користувача: один у
домені, інший — у існуючому. Всі ресурси DMZ (а також front - end поштові сервери)
розміщуються в дочірньому домені ( DMZ Internal VLAN ). При цьому доступ облікових
записів користувачів з домену до ресурсів нового домену автоматично заборонено на рівні
довірчих відносин між доменами. Облікові записи користувачів у домені, що мігрується ,
надає право доступу до поштової скриньки відповідного користувача у домені, що
створюється. Поштові скриньки користувачів знаходяться на сервері нового домену ( LAN
центрального офісу). Для спрощення створення подвійного облікового запису можна
використовувати продукт Microsoft Metadirectory Service » ( MMS ).
Необхідно відзначити, що при створенні DMZ у регіонах за схемою, аналогічною
центральному офісу, неминуче впровадження ще одного лісу Active Directory для кожного
регіону та синхронізація цього лісу з іншими лісами.
Плюси цього варіанта:
● структура Active Directory наближена до існуючої доменної структури, не
вимагатиме додаткової конфігурації мережного обладнання;
● користувачі, перебуваючи всередині корпоративної мережі, зможуть отримати
доступ до ресурсів усієї мережі (регіони та центральний офіс) згідно з правами
доступу.

Мінуси:
● ведення подвійної бази даних облікових записів користувачів;

● використання MMS для синхронізації каталогів.

Декілька лісів, мінімальна кількість доменів

Дана схема пропонує консолідувати створюваний домен та його дочірній домен у
єдиний домен. Домен для міграції існує у окремому лісі.
Необхідно створити два облікові записи для кожного користувача центрального
офісу та регіонального користувача: один у новому домені, інший — у існуючому домені.
Усі ресурси DMZ (і навіть front - end поштові сервери) розміщуються у створюваному
домені (DMZ Internal VLAN). Контролери нового домену знаходяться у зонах LAN та
DMZ. При цьому доступ облікових записів користувачів з існуючого домену до ресурсів
створюваного домену, що знаходяться в зоні LAN, повинен бути заборонений
виставленням прав доступу до об'єктів нового домену та/або правилами на брандмауері.
Облікові записи користувачів у домені, що мігрується , надає право доступу до поштової
скриньки відповідного користувача у домені, що створюється. Поштові скриньки
користувачів знаходяться на сервері нового домену (LAN центрального офісу). Для
спрощення створення подвійного облікового запису можна використовувати продукт
Microsoft Metadirectory Service » ( MMS ), що дозволяє синхронізувати об'єкти різних
каталогів.
Необхідно відзначити, що при створенні DMZ у регіонах за схемою, аналогічною
центральному офісу, неминуче впровадження ще одного лісу Active Directory для кожного
регіону та синхронізація цього лісу з іншими лісами.
Плюси цього варіанта:
● структура Active Directory наближена до існуючої доменної структури, не
вимагатиме додаткової конфігурації мережного обладнання;
 ● користувачі, перебуваючи всередині корпоративної мережі, зможуть отримати
доступ до ресурсів усієї мережі (регіони та центральний офіс) згідно з правами
доступу;
● порівняно з варіантом № 1 зменшено кількість доменів, у тому числі скорочено
кількість використовуваних комп'ютерів та адміністративне навантаження.

Мінуси:
● ведення подвійної бази даних облікових записів користувачів;

● використання MMS для синхронізації каталогів.

Єдиний ліс
Негативним моментом попередніх варіантів є існування двох лісів Active Directory ,
що змушує впроваджувати додаткову систему синхронізації двох лісів чи вести дублюючі
записи у двох лісах (фактично ручна синхронізація). Виникає бажання уникнути
існування двох лісів.
У даному варіанті побудови Active Directory всі домени знаходяться в загальному
лісі. Колишній домен, підготовлений для міграції, відсутній: він може бути дочірнім по
відношенню до домену, що створюється, або кореневого домену.
Даний варіант побудови Active Directory дозволяє уникнути двох облікових записів
для кожного користувача. Усі ресурси DMZ (і навіть front - end поштові сервери)
розміщуються у дочірньому домені (DMZ Internal VLAN). Поштові скриньки користувачів
знаходяться на сервері нового домену (LAN центрального офісу). Облікові записи
користувачів центрального офісу заведені в домені. Облікові записи мобільних
користувачів, які потребують доступу до ресурсів зони DMZ Internal , заведено в
дочірньому домені. Для таких користувачів доступ до ресурсів буде обмежений із
застосуванням прав доступу користувачів та групової політики дочірнього домену.
Зокрема, використовуючи групу Domain Users дочірнього домену, можна настроїти
автоматичну початкову заборону доступу до ресурсів Active Directory для нових
користувачів для підвищення безпеки системи.
Плюси цього варіанта:
● унікальність облікових записів у межах Active Directory для будь-якого
користувача;
● користувачі, перебуваючи як усередині корпоративної мережі, так і в Інтернеті,
зможуть отримати доступ до ресурсів усієї мережі (регіони та центральний офіс)
згідно з правами доступу.

Мінус цього варіанта: модернізація мережевої інфраструктури компанії, в якій

планується розгорнути службу Active Directory .

Призначення власників доменів

Для кожного домену, включеного до проекту Active Directory необхідно
призначити власника домену. Найчастіше власники домену є адміністраторами
підрозділів, у яких було визначено домен.
Роль власника домену полягає у керуванні індивідуальним доменом [13].
● Створення політик безпеки рівня домену. Це включає політику паролів, політику
блокування облікових записів та політику автентифікації за протоколом Kerberos .
 ● Проектування конфігурації групової політики ( Group Policy ) рівня домену.
Власник домену може проектувати групову політику для всього домену та
делегувати право пов'язувати групову політику з адміністратором рівня OU.
● Створення домену OU-структури високого рівня. Після цього завдання створення
підлеглих OU може бути передане адміністраторам рівня OU.
● Делегування адміністративних прав у межах домену. Власник домену повинен
встановити адміністративну політику рівня домену (включаючи політики схем
іменування, проекту груп тощо), а потім делегувати права адміністраторам рівня
OU.
● Управління адміністративними групами рівня домену. Як уже говорилося,
адміністратори в кожному домені повинні мати високий рівень довіри, тому що
їхні дії можуть викликати наслідки на рівні лісу. Роль власника домену полягає в
обмеженні членства адміністративної групи рівня домену та делегуванні
адміністративних прав нижчого рівня завжди, коли це можливо.

Короткі підсумки
У цій лекції дано опис різних моделей (із зазначенням переваг та недоліків)
побудови лісів Active Directory :
● Варіант 1 "Єдиний ліс, кожен регіон - окреме дерево".

● Варіант 2 "Єдиний ліс, адміністративний кореневий домен, кожен регіон - домен".

● Варіант 3 "Єдиний ліс, кожен регіон - дочірній домен центрального домену".

Наведено випадки реалізації кількох лісів та вказано недоліки структури Active

Directory , що складається з кількох лісів.
Після вибору моделі структури лісу необхідно визначитися з варіантами
(враховуючи наведені плюси та мінуси кожного варіанта) деталізації доменної структури:
● Варіант 1 "Повторення існуючої доменної структури".

● Варіант 2 "Кілька лісів, мінімальна кількість доменів".

● Варіант 3 "Єдиний ліс".

Для кожного домену, включеного до проекту Active Directory , необхідно

призначити власника домену, який керуватиме індивідуальним доменом, а саме:
● створювати політики безпеки рівня домену;

● проектувати конфігурацію групової політики ( Group Policy ) рівня домену;

● створювати у домені OU-структуру високого рівня;

● делегувати адміністративні права у межах домену;

● керувати адміністративними групами рівня домену.

Лекція 6. СТРАТЕГІЯ ІМЕНУВАННЯ ОБ'ЄКТІВ
Коротка інструкція: Наведено різні формати імен для об'єктів, що використовуються
Active Directory . Короткий огляд служби дозволу імен DNS , яка визначає угоду про
іменування, що використовується в Active Directory . Сформульовано правила іменування
доменів та учасників системи безпеки.
Ключові слова: ім'я об'єкта, DNS , власник іменування доменів, власник RID, об'єкти
учасників системи безпеки.

Ціль лекції
Дати уявлення про планування стратегії іменування об'єктів у Active Directory .

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

Угода про іменування

Кожен об'єкт у Active Directory є екземпляром класу, визначеного у схемі Active
Directory . Кожен клас має атрибути, що забезпечують унікальну ідентифікацію кожного
об'єкта каталогу.
Щоб це реалізувати, в Active Directory діє угода про іменування, яку повинні
дотримуватися і користувачі, і програми. Ця угода дозволяє логічно впорядкувати
зберігання об'єктів і надати клієнтам стандартизовані методи доступу до об'єктів,
наприклад, щоб знайти мережевий ресурс, необхідно знати ім'я об'єкта або одну з його
властивостей. Служба каталогів Active Directory , що використовує та підтримує LDAP
(стандартний протокол для пошуку інформації в каталозі), індексує всі атрибути всіх
об'єктів, що зберігаються в каталозі, та публікує їх [6]. Клієнти, що підтримують LDAP,
можуть виконувати різні запити до сервера.
Active Directory слідує угоді про іменування, прийнятому в DNS. Active Directory
підтримує кілька типів імен, тому під час роботи з Active Directory можна
використовувати різні формати імен [3]:
● відносні складові імена;

● складові імена;

● канонічні імена;

● основні імена користувачів

Відносні складові імена

Відносне складове ім'я (RDN) об'єкта унікально ідентифікує об'єкт, але тільки у
його батьківському контейнері. Таким чином, воно унікально ідентифікує об'єкт щодо
інших об'єктів у тому самому контейнері. Наприклад:
CN = wjglenn , CN = Users , OC = kd , DC = ru .
Тут відносним складовим ім'ям об'єкта є CN = wjglenn . RDN батьківської
організаційної одиниці (OU) - Users . Більшість об'єктів RDN — це те саме, що й атрибут
Common Name .
Active Directory автоматично створює RDN за інформацією, що вказується при
створенні об'єкта, і не допускає, щоб в тому самому батьківському контейнері існували
два об'єкти з однаковими RDN.
 У нотації відносних складових імен застосовуються спеціальні позначення, які
називаються тегами LDAP-атрибутів та ідентифікують кожну частину імені:
● DC - тег Domain Component , який ідентифікує частину DNS-ім'я домену на зразок
СОМ або ORG;
● OU - тег Organizational Unit , що ідентифікує організаційну одиницю, яка є
контейнером;
● CN - тег Common Name , який ідентифікує просте ім'я, присвоєне Active Active
Directory .

Складові імена
У кожного об'єкта в каталозі є складове ім'я (DN), яке унікальне на глобальному
рівні та ідентифікує не тільки сам об'єкт, але й місце, яке об'єкт займає в загальній ієрархії
об'єктів. DN можна як відносне DN об'єкта, об'єднане з відносними DN всіх батьківських
контейнерів, утворюють шлях до об'єкта.
Ось типовий приклад складеного імені:
CN= wjglenn , CN=Users, DC= kd , DC= ru .
Це DN означає, що об'єкт користувача wjglenn міститься в контейнері Users , який у
свою чергу міститься в домені kd.ru. Якщо об'єкт wjglenn переміститься в інший
контейнер, його DN зміниться і відображатиме нове розташування в ієрархії. DN
гарантовано унікальні у лісі, існування двох об'єктів з однаковими DN неможливе.

Канонічні імена
Канонічне ім'я об'єкта використовується багато в чому так само, як складове.
Просто має інший синтаксис. Складове ім'я, наведене у попередньому підрозділі,
відповідало б наступне канонічне ім'я: kd . ru / Users / wjglenn .
Таким чином, у синтаксисі складових та канонічних імен — дві основні
відмінності. Перше – канонічне ім'я формується від кореня до об'єкта, а друге – в
канонічному імені не використовуються теги LDAP-атрибутів (наприклад, CN та DC).

Основні імена користувачів

Основне ім'я користувача (UPN), що генерується для кожного об'єкта користувача,
має вигляд ім'я_користувача@ім'я_домену . Користувачі можуть входити у мережу під
своїми основними іменами, а адміністратор за бажання може визначити цих імен суфікси.
Основні імена користувачів мають бути унікальними, але Active Directory не перевіряє
дотримання цієї вимоги. Найкраще прийняти угоду про іменування, яка не допускає
дублювання основних імен користувачів.

Короткий огляд DNS

DNS є службою дозволу імен та використовує ієрархічний простір імен для пошуку
комп'ютерів (див. рис. 6.1). Кореневий домен позначається точкою ("."). Він є верхній
рівень DNS, решта простір імен розташовується нижче. На наступному рівні під
кореневим доменом розташовуються домени першого рівня, включаючи кілька основних (
generic ) доменних імен ( com , edu , mil , net , org і т. д.), близько двохсот скорочень назв
країн, кілька доменів, які були введені пізніше ( biz , info , pro і т. д.). Під доменами
верхнього рівня розташовані домени другого рівня, які зазвичай належать до назв
компаній і мають бути зареєстровані владою Інтернету. Нижче доменів другого рівня
розташовуються піддомени . Піддомени зазвичай належать до відділів чи підрозділів у
межах компанії. Ці піддомени реєструються та управляються з DNS-серверів, які містять
інформацію про домени другого рівня.
 Мал. 6.1. Ієрархічна структура простору імен домену

Оскільки DNS використовує ієрархічний простір імен, досить просто налаштувати

його як розподілену базу даних. Перш ніж в Інтернеті було реалізовано доменну систему
імен, вся інформація, необхідна для дозволу імен, зберігалася в єдиному файлі. Оскільки
кількість хостів в Інтернеті дуже збільшилася, то керування одним файлом стало
непрактичним. Було розроблено систему DNS, що використовує розподілену базу даних.
Застосування розподіленої бази даних означає, що інформація DNS зберігається на
багатьох комп'ютерах у всьому світі (у разі Інтернету) та всюди в корпоративній мережі (у
разі внутрішньої мережі). Кожен сервер DNS обслуговує лише одну невелику частину
бази даних DNS. Вся база даних поділена на зонні файли на основі доменів. Зонні файли
розподілені між кількома серверами. Наприклад, існує близько дюжини серверів, які
містять зонні файли для кореневого домену. Вони зберігають інформацію про DNS -
cepвери , які несуть зонну інформацію для доменів вищого рівня. Кореневі сервери не
містять всю інформацію про домени вищого рівня, але знають, які сервери мають цю
інформацію.
DNS-сервери, що зберігають інформацію про домени вищого рівня, містять
інформацію про те, на яких серверах знаходяться зонні файли для доменів наступного
рівня. Наприклад, сервер може містити зонні файли для домену com , тобто сервер знає
про всі домени другого рівня, які зареєстровані з доменом com , але він може не знати
окремі деталі про домен другого рівня. Сервер домену вищого рівня знає, який комп'ютер
на наступному рівні містить деталі, що стосуються домену другого рівня, і так
продовжується до самого низу простору імен DNS. Сервер, відповідальний за домен com
може мати домен kd , зареєстрований як домен другого рівня. Цей сервер може надсилати
будь-які запити на інформацію про домен kd на сервер, який містить зонні файли для kd .
com .
Використання методу розподіленої бази даних означає, що серверу в Інтернеті не
потрібно мати всю інформацію DNS. Більшість серверів зберігають інформацію про деяку
частину дерева, але коли надходить запит, який вони не можуть виконати, їм відомо, який
DNS-сервер зберігає необхідну інформацію. DNS-сервери використовують делеговані
записи, ретранслятори ( forwarders ) та кореневі посилання для визначення того, який
DNS-сервер має необхідну інформацію.
Поточні записи, що зберігаються в зонних файлах DNS, називаються записами
ресурсів (RR — Resource Records ). Записи ресурсів містять поточну інформацію про
домен на DNS-сервері системи Windows Server 2003 можна створити двадцять два різні
типи записів ресурсів [13].

Служба DNS Locator

Служба DNS Locator (покажчик DNS ) дуже важлива для Active Directory , тому що
DNS забезпечує інформацію, яка потрібна клієнтам для пошуку контролерів домену в
мережі.
Щоб полегшити знаходження контролерів домену, Active Directory використовує
покажчик служб ( service locator ) або запису SRV. Перша частина запису SRV ідентифікує
службу, на яку вказує запис SRV [13]:
● _ ldap Active Directory є службою каталогу, сумісною з LDAP-протоколом, з
контролерами домену, які функціонують як LDAP-сервери. Записи _ldap SRV
ідентифікують LDAP-сервери, наявні в мережі. Ці сервери можуть бути
контролерами домену Windows Server 2003 чи іншими LDAP-серверами;
● _ kerberos – основний розпізнавальний протокол для всіх клієнтів Windows 2000 та
Windows XP. SRV-записи _ kerberos ідентифікують всі ключові центри розподілу
( Key Distribution Centers , KDC) у мережі. Вони можуть бути контролерами домену
з Windows Server 2003 чи іншими KDC-серверами;
● _ kpassword ідентифікує сервери зміни паролів Kerberos в мережі ( це контролери
домену або з Windows Server 2003, або з іншими системами зміни пароля
Kerberos );
● _ gc - специфічний запис, що відноситься до функції глобального каталогу в Active
Directory .

Інтегровані зони Active Directory

Один із найбільших плюсів виконання DNS в операційній системі Windows Server
2003 полягає у використанні інтегрованих зон ( integrated zones ) Active Directory , які
дають безліч переваг [13].
● Зонна інформація більше не зберігається в зонних файлах на жорсткому диску
сервера DNS, вона зберігається в базі даних Active Directory , що забезпечує
додатковий захист.
● Процес зонної передачі замінено реплікацією Active Directory . Оскільки зонна
інформація зберігається в Active Directory , дані копіюються через нормальний
процес реплікації Active Directory . Це означає, що реплікація відбувається лише на
рівні атрибутів отже копіюються лише зміни зонної інформації. Трафік реплікації
між сайтами можна стиснути, збільшивши пропускну здатність. Використання
інтегрованої зони Active Directory дає можливість використовувати розділи
програм для тонкої настройки реплікації інформації DNS.
● Інтегровані зони дозволяють конфігурувати DNS-сервер з кількома господарями.
Без Active Directory DNS може підтримувати лише один основний сервер імен для
 кожного домену. Це означає, що всі зміни в зонній інформації повинні бути
зроблені на основному сервері імен, а потім передані додаткові сервери імен. З
інтегрованими зонами Active Directory кожен DNS-сервер має копію доменної
інформації, що перезаписується, так що зміни зонної інформації можуть бути
зроблені в будь-якому місці в організації. Інформація потім копіюється на всі інші
DNS сервери.
● Інтегровану зону можна налаштувати так, щоб використовувати лише безпечні
оновлення, тобто контролювати, які користувачі та комп'ютери оновлюють записи
ресурсів у Active Directory .

Найбільшим недоліком інтегрованої зони Active Directory є необхідність

встановлення DNS на контролері домену Windows Server 2003, що створює додаткове
навантаження на нього.
Коли зона налаштована як інтегрована зона Active Directory , можна переглядати
інформацію DNS в Active Directory [6].

Визначення стратегії іменування

При виробленні стратегії іменування необхідно враховувати вимоги до
найменування, що пред'являються як Active Directory , і DNS [3]:
● підтримується ієрархія, довжина імені 64 символів;

● підтримується підключення до зовнішніх мереж.

Клієнти використовують DNS для дозволу IP-адрес серверів, на яких виконуються

важливі мережеві сервіси Active Directory . Отже, Active Directory та DNS нерозривно
пов'язані.
У DNS імена утворюють ієрархію та формуються шляхом «руху» від батьківських
доменів до дочірніх доменів. Так, домен kd.ru може мати дочірній домен sales.kd . jw.org
uk у того, у свою чергу, є дочірній домен europe.sales.kd.ru. Ім'я кожного домену
відповідає шляху, що ідентифікує домен в ієрархії DNS, тобто шляху до кореневого
домену (кореневий домен позначається точкою).
Коли створюється перший домен Active Directory , він стає кореневим для лісу та
першого дерева доменів у цьому лісі. З цього кореневого домену починається простір
імен. Кожен домен, що додається, отримує ім'я від батьківського домену та ієрархії, в яку
входить батьківський домен.
Усі імена доменів Active Directory ідентифікуються за DNS, але можна
використовувати і NetBIOS -імена ( Network Basic Input / Output System ) - успадковану
систему іменування, яка застосовувалася в старих версіях Windows і, як і раніше,
підтримується в Windows Server 2003. Windows автоматично генерує NetBIOS -імена для
кожної служби, що виконується на комп'ютері, додаючи до імені комп'ютера додатковий
символ. Доменам також надаються NetBIOS- імена, при цьому сумісність з NetB IOS-
іменами - це плоска модель, довжина імені не більше 16 символів.
Існує можливість призначати різні NetBIOS -і DNS-імена, але такий підхід не
допустимий.
В ідеалі слід розробити стратегію іменування, що визначає одноманітний підхід до
формування імен.

Ідентифікатори захисту
Active Directory використовує модель реплікації з кількома господарями, коли на
кожному контролері домену зберігається своя копія розділу Active Directory ; Контролери
домену є рівноправними господарями. Можна змінити об'єкти, які зберігаються на будь-
якому контролері домену, і ці зміни реплікуються на інші контролери.
Модель із кількома господарями добре підходить для більшості операцій, але не
для всіх. Деякі операції повинні виконуватися лише одним контролером у кожному
домені чи навіть у кожному лісі. Для виконання цих спеціальних операцій певні
контролери доменів призначаються господарями операцій.
При виробленні стратегії іменування становлять інтерес дві ролі господарів
операцій [3]:
● Господар іменування доменів ( domain naming master ). Один домен у кожному
лісі, обробляє додавання та видалення доменів та генерує унікальний
ідентифікатор захисту (SID);
● Власник RID (relative ID master). Генерує послідовності кожного з контролерів
домену. Чинить у межах домену. Генерує для кожного контролера домену пул 500
RID.

Два сервери, що виконують ці ролі, повинні бути доступні, коли створюються та

іменуються нові учасники системи безпеки ( security principals ).

Правила імен учасників системи безпеки

Об'єкти учасників системи безпеки – це об'єкти Active Directory , яким призначені
ідентифікатори захисту та які вказуються при вході в мережу та надання доступу до
ресурсів домену.
Адміністратор повинен давати об'єктам учасників системи безпеки (обліковим
записам користувачів, комп'ютерів та груп) імена, унікальні в межах домену. Отже,
потрібно виробити стратегію іменування, яка дозволить це продати.
Додаючи обліковий запис нового користувача до каталогу, адміністратор повинен
задати таку інформацію [3]:
● ім'я, яке користувач повинен вказувати при вході до мережі;

● ім'я домену, що містить обліковий запис користувача;

● інші атрибути (ім'я, прізвище, телефон тощо)

До створюваних імен для учасників системи безпеки висуваються такі вимоги [3]:
● імена можуть містити будь-які символи Unicode , крім наступних символів: #, +,
«, \, < , > ;
● довжина імен облікових записів користувачів не повинна перевищувати 20
символів;
● довжина імен облікових записів комп'ютерів не повинна перевищувати 15
символів;
● довжина імен облікових записів груп не повинна перевищувати 63 символи;

● імена учасників системи безпеки не можуть складатися тільки з точок, пробілів та

знаків @;
● будь-які точки або пробіли на початку імені користувача відкидаються.
 Допускається застосування одного й того самого імені учасника системи безпеки у
різних доменах. Так, можна створити користувача wjglenn у доменах hr.kd.ru та sales.kd.ru.
Це не призведе до проблем, оскільки складне, відносне складове та канонічне імена
кожного об'єкта автоматично генеруються Active Directory все одно дозволяють глобально
ідентифікувати цей об'єкт.

Правила іменування доменів

Дозволяється зміна доменних імен після розгортання, але це може виявитися
скрутним. Краще з самого початку вибрати правильні доменні імена, при виборі яких
рекомендується дотримуватися таких правил [3].
● Використовувати лише символи, дозволені стандартами Інтернету: а-z, 0-9 та дефіс
(-). Хоча реалізація DNS у Windows Server 2003 підтримує інші символи,
застосування стандартних символів гарантує можливість взаємодії з іншими
реалізаціями DNS.
● Використовувати короткі доменні імена, які легко ідентифікувати та відповідають
угоді про іменування в NetBIOS .
● Як основу імені кореневого домену застосовувати лише зареєстровані доменні
імена. Навіть якщо в якості імені кореня лісу не використовується зареєстроване
ім'я DNS, це допоможе уникнути плутанини. Наприклад, компанія може бути
зареєстрована домен kd.ru. Якщо навіть ім'я kd.ru і не задіяне як ім'я кореневого
домену лісу, то доцільно формувати ім'я, похідне від kd.ru (скажімо, sales.kd.ru).
● Не використовувати двічі одне й те доменне ім'я. Інше можливе лише в мережах,
які не взаємодіють між собою (наприклад, можна створити домен microsoft.com у
приватній мережі, яка не підключена до Інтернету). Але це поганий підхід, який
колись обов'язково призведе до плутанини.
● Для більшої безпеки створити окремий внутрішній і зовнішній простір імен, щоб
запобігти несанкціонованому доступу до закритих ресурсів. При цьому
рекомендується створювати внутрішнє ім'я на основі зовнішнього (наприклад, kd .
ru та local . kd . ru ).

Короткі підсумки
У цій лекції наведено угоду про іменування в Active Directory , з описом різних
форматів імен:
● Відносні складові імена.

● Складові імена.

● Канонічні імена

● Основні імена користувачів.

Дано короткий огляд служби доменних імен DNS та вказано її взаємозв'язок із

Active Directory . Один із найбільших плюсів виконання DNS в операційній системі
Windows Server 2003 полягає у використанні інтегрованих зон ( integrated zones ) Active
Directory , які дають безліч переваг.
● Зонна інформація більше не зберігається в зонних файлах на жорсткому диску
сервера DNS, вона зберігається в базі даних Active Directory .
 ● Процес зонної передачі замінено реплікацією Active Directory .

● Інтегровані зони дозволяють конфігурувати DNS-сервер з кількома господарями.

● Інтегровану зону можна налаштувати так, щоб використовувати лише безпечні

оновлення.

При виробленні стратегії іменування необхідно враховувати вимоги до

найменування, що пред'являються як Active Directory , і DNS:
● підтримується ієрархія, довжина імені 64 символів;

● підтримується підключення до зовнішніх мереж.

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

операцій:
● Власник імені доменів;

● Хазяїн RID.

Два сервери, що виконують ці ролі, повинні бути доступні, коли створюються та

іменуються нові учасники системи безпеки ( security principals ).
Сформульовано правила іменування учасників системи безпеки та доменів.
Лекція 7. ПЛАНУВАННЯ ІНФРАСТРУКТУРИ DNS І
СТРУКТУРИ OU
Коротка інструкція: У цій лекції продовжено розгляд питання, як планувати службу
Active Directory перед її розгортанням. Розглянуто процеси планування доменного
простору імен (від дослідження існуючої інфраструктури DNS до вибору доменних імен)
та створення структури організаційних одиниць (різні моделі ієрархії, типова
конфігурація).
Ключові слова: DNS , ім'я об'єкта, організаційна одиниця, об'єкт групової політики.

Ціль лекції
Дати уявлення про процеси планування доменного простору імен та створення
структури організаційних одиниць.

Проектування інфраструктури DNS

У службі Active Домени Directory мають DNS-імена. Перш ніж використовувати
DNS в мережі, необхідно спланувати простір імен DNS, тобто потрібно продумати, як
застосовуватиметься іменування DNS і для яких цілей.
Ключове рішення проекту полягає в тому, щоб визначити, де розміщувати домени
Active Directory в межах цього простору імен. Крім цього, необхідно також спроектувати
конфігурацію сервера DNS. Якщо компанія вже має свою інфраструктуру DNS,
доведеться спроектувати власний простір імен, щоб вписатися в поточний простір імен, а
також налаштувати DNS-сервери Windows Server 2003 для взаємодії з серверами DNS.

Дослідження існуючої інфраструктури DNS

Перший крок у проектуванні інфраструктури DNS має полягати у дослідженні вже
наявної інфраструктури DNS. Найчастіше служба DNS в Active Directory повинна
взаємодіяти з наявною інфраструктурою DNS. Це може означати просто конфігурування
ретранслятора в існуючому DNS сервері, використання наявного DNS-сервера як
основного для Active Directory або відсутність розгортання DNS у Windows Server 2003.
Active Directory вимагає, щоб працювала служба DNS, проте існує кілька варіантів її
розгортання.
При дослідженні існуючої інфраструктури DNS необхідно виконати такі дії [13]:
● задокументувати всі DNS-імена доменів, які використовуються в даний час у
межах компанії. Сюди входять імена, що трапляються в Інтернеті, а також
внутрішні імена;
● задокументувати всі додаткові імена, які компанія зареєструвала для використання
в Інтернеті;
● документувати існуючу конфігурацію серверів DNS. Ця документація повинна
включати типи DNS-серверів, які розгорнуті в мережі. Крім того, конфігурація
DNS повинна містити інформацію про ретранслятори, делегування зон і
конфігурацію основних і додаткових серверів.

Вибір доменних імен DNS

При налаштуванні DNS-серверів рекомендується спочатку вибрати та
зареєструвати унікальне батьківське ім'я DNS, яке представлятиме організацію в
Інтернеті. Це ім'я є доменом другого рівня всередині одного з доменів верхнього рівня, які
використовуються в Інтернеті.
Перш ніж задавати батьківське ім'я DNS для організації, необхідно переконатися,
що це ім'я не присвоєно іншій організації. Ім'я батьківського DNS можна з'єднати з ім'ям
розташування або підрозділу всередині організації для формування інших імен доменів
наступних рівнів.
Для впровадження Active Directory існують два види просторів імен (внутрішній та
зовнішній), при цьому простір імен Active Directory збігається із заданим зареєстрованим
простором імен DNS або відрізняється від нього [4]:
● Збігаються внутрішній і зовнішній простір імен. Згідно з цим сценарієм,
організація використовує те саме ім'я для внутрішнього і зовнішнього просторів
імен — ім'я компанії застосовується як усередині, так і поза організацією. Для
реалізації цього сценарію треба дотримуватись наступних умов. Користувачі
внутрішньої приватної мережі компанії повинні мати доступ як до внутрішніх, так і
зовнішніх серверів (по обидва боки брандмауера). Для захисту конфіденційної
інформації клієнти, які здійснюють доступ ззовні, не повинні мати доступ до
внутрішніх ресурсів компанії або мати можливість дозволяти свої імена. Крім того,
необхідні дві окремі зони DNS, одна з яких, за межами брандмауера, забезпечує
дозвіл імен для загальнодоступних ресурсів. Вона не налаштована для дозволу імен
внутрішніх ресурсів, тому доступ до них ззовні отримати не можна.
● Відмінні внутрішній і зовнішній простір імен. У цьому випадку компанія
використовує різні внутрішні і зовнішні простори імен — спочатку в зонах по різні
сторони брандмауера імена розрізняються. Для цього необхідно зареєструвати два
простори імен у Інтернеті DNS. Мета реєстрації — запобігти дублюванню
внутрішнього імені іншою загальнодоступною мережею. Якщо ім'я не
зарезервоване, внутрішні клієнти не зможуть відрізнити внутрішнє ім'я від імені,
зареєстрованого у загальнодоступній мережі простору імен DNS. Таким чином,
встановлюються дві зони: одна відповідає за дозвіл імен у зовнішньому просторі,
інша - у внутрішньому. Користувачам не важко розрізняти внутрішні та зовнішні
ресурси.

Проектування структури OU
Після визначення структури домену організації та планування доменного простору
імен необхідно розробити структуру організаційних одиниць ( OU чи підрозділів – ВП). За
інформацією, зібраною про компанію та її персонал, необхідно визначити, як найкраще
делегувати адміністративні повноваження у доменах. Можна створити ієрархію ОП в
домені: в окремому домені розмістити користувачів та ресурси, повторивши структуру
компанії у конкретному підрозділі. Таким чином, можна створити логічну та осмислену
модель організації та делегувати адміністративні повноваження на будь-який рівень
ієрархії.
У кожному домені дозволяється впроваджувати свою ієрархію ВП. Якщо
організація має кілька доменів, можна створити структури ОП всередині кожного домену
незалежно від структури в інших доменах.
Організаційний підрозділ дозволяє [4]:
● відобразити структуру підприємства та організації всередині домену. Без ОП усі
користувачі підтримуються та відображаються в одному списку незалежно від
підрозділу, розташування та ролі користувача;
 ● делегувати управління мережевими ресурсами, але зберегти здатність керувати
ними, тобто надавати адміністративні повноваження користувачам чи групам лише
на рівні ОП;
● змінювати організаційну структуру підприємства;

● групувати об'єкти те щоб адміністратори легко шукали мережеві ресурси.

Не слід створювати структуру OU виключно для того, щоб просто мати якусь
структуру: OU використовуються з певною метою. До цих цілей відносяться [3]:
● делегування адміністративного управління об'єктами Правильно розроблена
структура OU дозволяє адміністраторам ефективно делегувати повноваження.
Кожне OU за замовчуванням успадковує дозволи для батьківського OU.
Аналогічно об'єкти, що містяться в OU, успадковують дозволи, задані для цього
OU (і кожного з його батьків). Спадкування – ефективний спосіб надати або
делегувати дозволи на доступ до об'єктів. Перевага спадкування в тому, що
адміністратор може керувати дозволами на доступ до всіх об'єктів у OU, задаючи
дозволи для самого OU, а не конфігуруючи всі дочірні об'єкти окремо;
● обмеження видимості об'єктів. У деяких організаціях певні об'єкти мають бути
приховані від певних адміністраторів чи користувачів. Навіть якщо заборонити
зміну атрибутів об'єкта, користувачі, які мають доступ до контейнера з таким
об'єктом, все одно зможуть бачити, чи цей об'єкт існує. Однак можна приховати
об'єкти, помістивши їх в OU і обмеживши коло користувачів, які мають дозвіл на
список вмісту ( List Contents ) для цієї OU. Тоді об'єкти, поміщені в контейнер,
будуть невидимі користувачам, які не мають цього дозволу;
● керування застосуванням групової політики. Групова політика дозволяє
застосовувати одні й самі параметри конфігурації відразу до кількох об'єктів. З її
допомогою можна визначати параметри користувачів (наприклад, обмеження
паролів) або комп'ютерів. При використанні групової політики створюється об'єкт
групової політики ( Group Policy Object , GPO) — об'єкт, пов'язаний з доменом,
сайтом або OU і містить параметри конфігурації, які потрібно застосувати.

Можливості ВП полегшать забезпечення безпеки та виконання будь-яких

адміністративних завдань.
Перший етап проектування адміністративної структури захисту – планування
використання організаційних одиниць (OU) у кожному домені. Наступний етап
проектування цієї структури - вироблення стратегії управління обліковими записами
користувачів, комп'ютерів та груп. Після цього необхідно розробити ефективну реалізацію
групової політики.
OU служить контейнером, в який можна розмістити ресурси та облікові записи
домену. Потім можна призначити OU адміністративні дозволи і дозволити об'єктам, що
містяться в ньому, успадковувати ці дозволи. OU можуть містити будь-які об'єкти таких
типів [3]: користувачі; комп'ютери; групи; принтери; додатки; політики безпеки; спільні
папки; інші OU.

Планування ієрархії OU
При плануванні ієрархії ВП важливо дотриматися таких правил [4]:
● Хоча глибина ієрархії ВП не обмежена, продуктивність дрібної ієрархії вища, ніж
глибокої.
 ● ОП повинні відбивати постійні структурні одиниці організації.

Існує багато способів структурування ВП в організації. На етапі планування

розгортання Active Directory важливо визначити, яка модель ляже основою ієрархії ОП.
Наприклад, існують такі моделі класифікації ВП в ієрархії ВП [4]:
● Модель поділу на ОП відповідно до виконуваних завдань. ОП можна створювати з
огляду на функції, які необхідно виконувати всередині організації. Верхній рівень
ВП може відповідати бізнес-підрозділам компанії, при цьому такі рівні ВП - це
функціональні підрозділи всередині бізнес-підрозділів.
● Географічна модель поділу на ОП. Іноді під час створення ОП враховується місце
розташування філій компанії. Верхній рівень ВП відповідає регіональним
підрозділам організації, а другий рівень представляє фізичне розташування офісів
компанії.
● Модель поділу на ОП відповідно до виконуваних завдань та географічного
розташування. У деяких випадках дві описані вище моделі створення ВП
поєднують. Верхній рівень ВП враховує, де розташовані географічно офіси
компанії. Другий рівень ОП побудований з урахуванням функціональних
особливостей кожного підрозділи всередині організації.

Слід приділяти особливу увагу верхньому рівню структури OU, який завжди
повинен відображати відносно незмінну частину структури підприємства, щоб його не
доводилося змінювати у разі реорганізації. Так, такі типи структури верхнього рівня
засновані на постійних характеристиках підприємства, зміна яких є малоймовірною [3]:
● Фізичні ділянки. У філіях, фізично розташованих у різних місцях (особливо, коли
компанія діє на великій території, наприклад у кількох країнах), часто є свої ІТ-
відділи, тому філії мають різні вимоги до адміністрування. Створення окремого OU
верхнього рівня для кожної філії - один із варіантів архітектури, заснованої на
завданнях; Залежно від місцезнаходження визначаються різні адміністративні
завдання.
● Типи адміністративних завдань. Структура верхнього рівня, що ґрунтується на
адміністративних завданнях, відносно постійна. Які б реорганізації не відбувалися
в компанії, основні типи адміністративних завдань навряд чи зміняться.
● Типи об'єктів. Як і структура, заснована на завданнях, структура, в якій OU
верхнього рівня відповідають типу об'єктів, забезпечує стійкість архітектури до
змін.

При плануванні структури OU верхнього рівня для середовища з кількома

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

Стандартні моделі структури OU

Поряд із переліченими вище моделями класифікації ГП в ієрархії ГП можна
використовувати наступну термінологію (див. рис. 7.1) для стандартних моделей [3]:
● Модель структури OU на основі розташування.

● Модель структури OU з урахуванням структури організації.

● Модель структури OU з урахуванням функцій.

● Змішана модель структури OU - спочатку за місцем розташування, потім за

структурою організації.
● Змішана модель структури OU - спочатку за структурою, потім за місцем
розташування.
 Мал. 7.1. Моделі побудови структури організаційних одиниць

Модель структури OU на основі розташування

У моделі OU на основі місцезнаходження адміністративні повноваження
розподілені між кількома філіями, розташованими у різних місцях. Ця модель корисна,
коли кожна філія має свої вимоги до адміністрування, відмінні від вимог інших філій.
Переваги моделі:
 ● OU стійкі до змін;

● для центрального ІТ-відділу легко реалізувати загальнодоменні політики;

● легко визначати становище ресурсів;

● легко створювати нові OU під час розширення компанії.

Недоліки:
● передбачається наявність адміністратора у кожному філії;

● архітектура відповідає адміністративної структурі підприємства.

Модель структури OU на основі структури організації

У моделі OU з урахуванням структури організації адміністративні повноваження
розподілені між відділами чи підрозділами, кожному з яких є власний адміністратор. Ця
модель корисна, коли компанія має чітку структуру відділів.
Переваги моделі:
● забезпечує певний рівень автономії кожному за відділу;

● підтримує злиття та розширення;

● зручна для адміністраторів.

Недолік:
● вразлива при реорганізації, оскільки може знадобитися зміна верхнього рівня
структури ОU.

Модель структури OU на основі функцій

У моделі OU на основі функцій адміністративний персонал децентралізований та
використовує модель управління, яка ґрунтується на бізнес-функціях, що існують в
організації. Це ідеальний вибір для малих компаній, у яких низка бізнес-функцій
виконується кількома відділами одночасно.
Основна перевага моделі – стійкість при реорганізаціях, нестача моделі – створення
додаткових OU для делегування адміністративного управління користувачами,
комп'ютерами, принтерами тощо.

Змішана модель структури OU — спочатку за місцем розташування,

потім за структурою організації
У цій моделі спочатку створюються OU верхнього рівня, які представляють
географічні ділянки, у яких перебувають філії компанії, та був — OU нижчого рівня, які
мають структуру організації.
Переваги моделі:
● підтримує зростання числа підрозділів;

● дозволяє створювати зони безпеки.

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

Змішана модель структури OU - спочатку за структурою, потім за місцем

розташування
У цій моделі спочатку створюються OU верхнього рівня, що представляють
організаційну структуру компанії, а потім - OU нижчого рівня, що становлять
територіальні ділянки.
Переваги моделі:
● надійний захист на рівні відділів та підрозділів;

● можливість делегувати адміністративні повноваження залежно від розташування.

Недолік:
● уразливість при реорганізаціях.

Типова конфігурація OU
Як правило, звичайна конфігурація — це якраз змішана модель ієрархії ВП,
наприклад: OU вищого рівня, засновані на географічних регіонах, з наступним рівнем OU
у межах кожного регіону, заснованих на ділових підрозділах. Деякі компанії можуть
вибрати OU вищого рівня, що базуються на ділових підрозділах, а потім створювати під
вищим рівнем структуру OU, засновану на географії.
OU найвищого рівня можуть включати OU служби облікових записів для всіх
службових облікових записів, які використовуються в домені. Створення на вищому рівні
OU для спеціальних облікових записів користувачів, таких як службові облікові записи,
спрощує їхнє адміністрування. OU найвищого рівня можуть включати OU серверів, якщо
всі сервери керуються централізовано. Крім цих адміністративних OU можуть бути
створені також OU вищого рівня, засновані на географії корпорації. Організаційні одиниці
вищого рівня, що ґрунтуються на географії, можуть використовуватися для делегування
адміністративних завдань.
OU другого рівня у кожному географічному регіоні засновані на ділових
підрозділах регіону. OU бізнес-підрозділів могли б застосовуватися для делегування
адміністрування, а також призначення групових політик. Під діловими OU розташовані
OU, засновані на відділах. На цьому рівні OU використовуватиметься для призначення
групових політик чи певних адміністративних завдань, типу права скидання паролів.
OU відділів можуть містити інші OU [13]:
● OU облікових записів. Містить облікові записи користувачів та груп відділу. У
деяких випадках OU облікових записів розбиваються на OU, які містять групи,
облікові записи користувачів або видалених користувачів.
● OU комп'ютери. Містить всі комп'ютери користувача і включає окремі OU
комп'ютерів з різними операційними системами.
● OU ресурсів. Містить ресурси, пов'язані з цією OU. Включає домени локальних
груп, сервери, принтери та спільно використовувані папки.
 ● OU додатків чи проектів. Якщо група людей і ресурсів працюють над певним
проектом (додатком), який потребує унікального управління, можна створити
структуру OU для цих користувачів, а потім згрупувати користувачів, ресурси та
комп'ютери, необхідні для цього проекту, у OU.

Короткі підсумки
У цій лекції було продовжено розгляд питання, як планувати службу Active
Directory перед її розгортанням.
У службі Active Домени Directory мають DNS-імена. При дослідженні існуючої
інфраструктури DNS слід виконати такі дії.
● Задокументувати всі DNS-імена доменів, які використовуються в даний час у
межах компанії.
● Задокументувати всі додаткові імена, які компанія зареєструвала для використання
в Інтернеті.
● Задокументувати існуючу конфігурацію DNS-серверів.

Для впровадження Active Directory існують два види просторів імен (внутрішній та
зовнішній), при цьому простір імен Active Directory збігається із заданим зареєстрованим
простором імен DNS або відрізняється від нього.
Після визначення структури домену організації та планування доменного простору
імен необхідно розробити структуру організаційних одиниць ( OU чи підрозділів – ВП).
Організаційний підрозділ дозволяє:
● відобразити структуру підприємства та організації всередині домену;

● делегувати управління мережевими ресурсами, але зберегти здатність керувати

ними;
● змінювати організаційну структуру підприємства;

● групувати об'єкти те щоб адміністратори легко шукали мережеві ресурси.

OU використовуються з певною метою:

● Делегування адміністративного керування об'єктами.

● Обмеження видимості об'єктів.

● Управління застосуванням групової політики.

Можна використовувати таку класифікацію для моделей структури OU:

● Модель структури OU на основі розташування.

● Модель структури OU з урахуванням структури організації.

● Модель структури OU з урахуванням функцій.

● Змішана модель структури OU - спочатку за місцем розташування, потім за

структурою організації.
● Змішана модель структури OU - спочатку за структурою, потім за місцем
розташування.
Лекція 8. СТРАТЕГІЯ УПРАВЛІННЯ ОБЛІКОВИМИ
ЗАПИСЯМИ
Коротка інструкція : Для можливості планування облікових записів в Active Directory
перераховано їх типи, дано правила та рекомендації управління обліковими записами
комп'ютерів та користувачів. Висвітлено питання, пов'язані з безпекою, — планування
політики мережної безпеки, планування груп та групових політик.
Ключові слова : обліковий запис, домен, об'єкт, LDAP , організаційна одиниця, сайт,
групова політика, об'єкт групової політики.

Ціль лекції
Виробити стратегію управління обліковими записами для можливості її
застосування під час розгортання Active Directory .

Типи облікових записів

Обліковий запис Active Directory - це список атрибутів, що визначають учасника
системи безпеки ( security principal ), наприклад користувача або групу користувачів.
В Active Directory можна створити п'ять типів облікових записів [3], наведених
нижче.
● Комп'ютер. Щоразу, коли домен додається комп'ютер під керуванням Microsoft
Windows NT, Windows 2000, Windows XP чи Windows Server 2003 для нього
створюється обліковий запис комп'ютера. Облікові записи комп'ютерів служать для
автентифікації комп'ютерів, які звертаються до мережі та ресурсів домену.
● Користувач. Обліковий запис користувача – це набір атрибутів для користувача.
Об'єкт-користувач зберігається в Active Directory і дозволяє користувачеві входити
до мережі. Користувач повинен вказати посвідчення (ім'я та пароль) лише один раз,
потім йому надаються відповідні дозволи на доступ до мережних ресурсів.
● Група. Це набір користувачів, комп'ютерів або інших груп, для яких можна вказати
дозволи. Задаючи дозволи групам і додаючи члени до цих груп, можна заощадити
час, оскільки не доводиться призначати дозволи кожному окремому члену групи.
● InetOrgPerson . Обліковий запис InetOrgPerson працює багато в чому аналогічно до
облікового запису користувача за винятком того, що облікові записи InetOrgPerson
сумісні з іншими службами каталогів, заснованими на LDAP. Це забезпечує
сумісність між Active Directory та іншими системами.
● Контакт. Цей об'єкт зберігається в Active Directory , але йому не задаються
дозволу. Тобто, контакт не можна використовувати для входу в мережу або
доступу до ресурсів. Часто контакти пов'язують із користувачами, які працюють
поза мережею, яким надсилає повідомлення поштова система.

Планування облікових записів комп'ютерів

Облікові записи комп'ютерів дозволяють застосовувати до комп'ютерів, що входять
до домену, багато в чому такі засоби захисту, як і для користувачів. Ці записи дають
можливість виконувати аутентифікацію комп'ютерів - членів домену прозорим для
користувачів чином, додавати сервери додатків як рядові сервери ( members) servers )
довіряються домени і запитувати автентифікацію користувачів або служб, які звертаються
до цих серверів ресурсів.
Оскільки дозволяється розміщувати облікові записи комп'ютерів в OU і призначати
їм групову політику, можна керувати тим, як виконується аутентифікація і забезпечується
захист комп'ютерів різних типів. Наприклад, для комп'ютерів, встановлених у
загальнодоступному інформаційному кіоску, діють інші вимоги безпеки, ніж робочих
станцій, встановлених у керованому середовищі з обмеженим доступом.
Щоразу, коли домен додає новий комп'ютер, створюється новий обліковий запис
комп'ютера. Таким чином, ще одна складова стратегії управління обліковими записами —
визначення користувачів, які мають право додавати комп'ютери до домену, створюючи їх
облікові записи.
Крім того, необхідно продумати угоду про назву комп'ютерів. Хороша угода
повинна дозволяти без проблем ідентифікувати комп'ютер за власником,
місцезнаходженням, типом або будь-якою комбінацією цих даних.

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

Облікові записи користувачів дозволяють ідентифікувати користувачів, що входять
до мережі, задавати, до яких ресурсів вони мають право звертатися, і вказувати про них
різноманітну інформацію. Адміністратори теж користувачі, але з більш широкими
правами доступу до ресурсів, пов'язаних з управлінням мережею. Групи служать для того,
щоб формувати набори користувачів, для яких потрібно задати ті самі вимоги до безпеки
або права доступу.
Облікові записи користувачів надають користувачам можливість входити до
домену або на локальний комп'ютер і звертатися до ресурсів. Об'єкти облікових записів
користувачів містять інформацію про користувачів та пов'язують з ними певні привілеї чи
обмеження. Кожен об'єкт Active Directory пов'язаний зі списком управління доступом
( Access Control List , ACL), який є список дозволів на доступ до об'єкта, заданих для
користувачів та груп.

Типи облікових записів користувачів

У Windows Server 2003 існує два основних типи облікових записів користувачів [3]:
● Локальні облікові записи користувачів. Створюються в базі даних захисту
локального комп'ютера та керують доступом до ресурсів комп'ютера. Локальні
облікові записи користувачів призначені для керування доступом до ізольованих
комп'ютерів або комп'ютерів, що входять до робочої групи.
● Доменні облікові записи користувачів. Створюються в Active Directory дають
можливість користувачам входити в домен і звертатися до будь-яких ресурсів
мережі. Такі облікові записи користувачів реплікуються на всі контролери в
домені, тому після реплікації будь-який контролер домену зможе автентифікувати
користувача.

Крім цих облікових записів, Windows автоматично створює кілька облікових

записів користувачів, які називаються вбудованими. І на локальних комп'ютерах, і в
доменах створюється два ключові облікові записи [3]:
● Адміністратор ( Administrator ). Цей обліковий запис має найбільші можливості,
оскільки він автоматично включається до групи «Адміністратори»
( Administrators ). Члени цієї групи мають вищий рівень прав з управління
комп'ютером, їм надаються майже всі права користувача. Обліковий запис
«Адміністратор рівня домену» дає максимум можливостей для управління доменом
в цілому; за умовчанням вона включається до групи «Адміністратори домену»
 ( Domain Admins ) (а адміністратор кореневого домену лісу, крім того, входить до
групи «Адміністратори підприємства» ( Enterprise Admins ) та «Адміністратори
схеми» ( Schema Admins )]. Обліковий запис «Адміністратор» не можна видалити,
але його можна перейменувати (і це слід зробити для більшої безпеки). Також слід
задати для цього облікового запису непустий пароль та не передавати його іншим
користувачам.
● Гість ( Guest ). Цей обліковий запис призначений для того, щоб адміністратор міг
задати єдиний набір дозволів для будь-яких користувачів, які іноді входять до
мережі, але не мають звичайного облікового запису. Обліковий запис "Гість"
дозволяє це зробити, оскільки автоматично включається до локальної групи "Гості"
( Guests ). У середовищі, де є домен, цей обліковий запис також включається до
групи «Гості домену» ( Domain Guests ). За замовчуванням обліковий запис «Гість»
вимкнено. І справді, її слід використовувати лише в мережах, які не потребують
особливого захисту. Цей обліковий запис не можна видалити, але можна вимкнути
та/або перейменувати.

Правила іменування облікових записів

Ретельне планування схеми облікових записів користувачів дозволяє
стандартизувати ідентифікацію користувачів домену. Єдина угода також полегшує
розпізнавання та запам'ятовування імен користувачів.
Існує багато різних угод, які застосовуються при створенні імен, і кожен
адміністратор або проектувальник мережі має свої переваги. Однак хороша угода про
іменування має бути такою, щоб імена для входу легко запам'ятовувалися, а також щоб
можна було розрізняти співробітників зі схожими іменами.
Є кілька правил, яких потрібно дотримуватись при плануванні стратегії іменування
користувачів [3]:
● Кожен користувач повинен мати унікальне ім'я (логін) у домені.

● Довжина імені не повинна перевищувати 20 символів (для сумісності з

попередніми версіями Windows ).
● Імена не чутливі до регістру літер.

● Імена не повинні містити наступних символів: ", /, \, [ , ] , :, ;, =, ,, +, *, ?, <, >.

● Повинна підтримуватись гнучка система іменування.

● Необхідно враховувати сумісність іменування для інших програм (наприклад, для

електронної пошти).

Планування політики мережної безпеки

Контролери домену повинні перевіряти ідентифікацію користувача або комп'ютера,
перш ніж надати доступ до системних та мережевих ресурсів. Така перевірка називається
автентифікацією і виконується щоразу під час входу в мережу.
При плануванні стратегії аутентифікації рекомендується дотримуватися ряду
правил [3]:
● Політика блокування облікових записів (рекомендоване значення для користувача
– 5 спроб).
● Обмеження часу, коли дозволено вхід.
 ● Політика закінчення термінів квитків ( tickets ) (за замовчуванням — 10 годин).

● Не використовуйте адміністративні облікові записи для нормальної роботи.

● Перейменувати або вимкнути вбудовані облікові записи.

Наступний найважливіший аспект мережевої безпеки – паролі, тому політику

визначення паролів користувачів необхідно ретельно продумати. У Windows За
промовчанням Server 2003 діють більш суворі обмеження на паролі, ніж у попередніх
версіях. Наприклад, у Windows Server 2003 є новий засіб, що перевіряє складність пароля
облікового запису «Адміністратор» ( Administrator ). Якщо пароль порожній або
недостатньо складний, Windows попереджає, що нестійкий пароль небезпечно; при цьому
користувач, який залишив поле для пароля порожнім, не зможе звертатися до облікового
запису через мережу.
Надійна політика управління паролями гарантує, що користувачі повною мірою
дотримуються принципів завдання паролів, встановлених компанією. При плануванні
політики управління паролями рекомендується дотримуватися ряду правил [3]:
● Політика збереження останніх паролів (рекомендоване значення: 24).

● Зміна пароля не частіше ніж 1 раз на добу.

● Довжина пароля не повинна бути коротшою за 7 символів.

● Використання складної схеми для паролів (малі, великі літери, цифри та інші
символи).

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

Типи груп [3]

● Групи безпеки:

● використовуються для об'єднання одну адміністративну одиницю;

● використовуються ОС.

● Групи розповсюдження:

● використовуються програмами (не ОС) для завдань, не пов'язаних із

захистом.

Області дії груп [3]

 ● Глобальні групи:

● містять облікові записи користувачів і комп'ютерів лише домену, в якому

створено цю групу;
● їм можна призначати дозволи або додавати до локальних груп будь-якого
домену в даному лісі.
● Локальні групи домену:

● існують на контролерах домену та використовуються для управління

доступом до ресурсів локального домену;
● можуть включати користувачів та глобальні групи у межах лісу.

● Універсальні групи:

● використовуються для призначення дозволів доступу до ресурсів кількох

доменів;
● існують поза межами доменів;

● можуть включати користувачів, глобальні групи та інші універсальні групи

у межах лісу.

Active Directory дозволяє вкладати групи, тобто поміщати одні групи до інших.
Вкладення груп – ефективний спосіб упорядкування користувачів. При вкладенні груп
потрібно прагнути до того що, щоб рівень вкладення був мінімальним; по суті краще
обмежитися одним рівнем. Чим глибше вкладення, тим складніше підтримувати
структуру дозволів.
Групи користувачів допомагають досягти найбільших успіхів у стратегії
управління обліковими записами при виконанні наступних правил [3]:
● Уникати дозволу на облікові записи.

● Створювати локальні групи домену.

● Для впорядкування користувачів використовувати глобальні групи.

● Поміщати глобальні групи до локальних груп домену.

● Не включати користувачів до універсальних груп.

Планування групової політики

Групова політика — потужний та ефективний засіб, що дозволяє встановити
параметри відразу для декількох користувачів та комп'ютерів. Крім того, групова політика
застосовується для поширення та оновлення програмного забезпечення в організації.
Групова політика визначає набір параметрів конфігурації користувачів та
комп'ютерів, який можна зв'язати з комп'ютерами, сайтами, доменами та OU у Active
Directory . Такий набір параметрів групової політики називається об'єктом групової
політики ( Group Policy Object , GPO).
Будь-який комп'ютер під керуванням Windows 2000, Windows ХР або Windows
Server 2003 (незалежно від того, входить він у Active Directory чи ні) містить один
локальний GPO, в якому задані політики, які застосовуються до цього комп'ютера. Якщо
комп'ютер входить до Active Directory , до нього можна застосувати кілька додаткових
GPO, які є локальними.
Існує два основних типи групової політики [3]:
● Конфігурація комп'ютера Використовується для завдання групових політик, які
застосовуються до певних комп'ютерів.
● Конфігурація користувача. Використовується для завдання групових політик, які
застосовуються до певних користувачів.

Незалежно від типу параметрів групової політики є три наступні категорії [3].
● Параметри програм ( Software Settings ). Категорія містить параметри для
встановлення програмного забезпечення на клієнтських комп'ютерах
(підтримуються ОС Windows 2000 та новіші), до яких застосовується групова
політика. Використовуються два компоненти:
● служба інсталяції Windows . Встановлення та оновлення ПЗ відповідно до
інструкцій у інсталяційних пакетах;
● інсталяційні пакети Windows . Виконувані файли сценаріїв з усіма
вказівками ( msi ).
● Параметри Windows ( Windows Settings ). Категорія призначена для зміни низки
параметрів конфігурації, пов'язаних із середовищем Windows :
● сценарії ( Scripts ). Настроюючи конфігурацію комп'ютера, можна
встановити сценарії, які виконуються під час його увімкнення або
вимкнення. При налаштуванні конфігурації для користувача можна
встановити сценарії, що виконуються під час входу або виходу користувача;
● параметри безпеки ( Security Settings ). Це параметри безпеки, що
задаються для комп'ютерів та користувачів;
● налаштування Internet Explorer (Internet Explorer Maintenance). Цей вузол
доступний лише користувачам і служить керувати роботою Internet Explorer
на клієнтських комп'ютерах;
● служби віддаленої установки (Remote Installation Services, RIS). RIS
дозволяє автоматично виконувати віддалене встановлення операційної
системи на нові клієнтські комп'ютери. Ці параметри також доступні лише
для конфігурацій користувачів. Вони керують віддаленим встановленням
операційних систем;
● перенаправлення папок ( Folder Redirection ). Ці настройки доступні лише
для конфігурацій користувачів. Вони дозволяють перевизначити спеціальні
папки Windows , змінивши їх місцезнаходження за умовчанням на
мережевий каталог. Це дозволяє централізовано керувати папками
користувачів.
● Адміністративні шаблони ( Administrative Templates ). Категорія містить усі
параметри групової політики, які зберігаються в реєстрі, які можна
використовувати для конфігурацій комп'ютерів та користувачів.
Дозвіл GPO з кількох джерел
Оскільки GPO, які застосовуються до користувача або комп'ютера, можуть
надходити з кількох джерел, потрібен спосіб визначення того, як ці GPO поєднуються
один з одним. GPO обробляються в наступному порядку [3]:
● локальний GPO. Обробляється локальний GPO комп'ютера, і використовуються
всі параметри захисту, задані в цьому GPO;
● GPO сайту. Обробляються GPO, пов'язані із сайтом, до якого належить комп'ютер.
Параметри, задані цьому рівні, перевизначають будь-які параметри попереднього
рівня, із якими конфліктують. Якщо з веб-сайтом пов'язано кілька GPO,
адміністратор веб-сайту може задати, в якому порядку обробляються ці GPO;
● GPO домену. Обробляються GPO, пов'язані з доменом, до якого належить
комп'ютер, і застосовуються параметри, що містяться в них. Параметри, задані на
рівні домену, перевизначають параметри, застосовані на локальному рівні або рівні
сайту, з якими вони конфліктують. Якщо з доменом пов'язано кілька GPO,
адміністратор, як і в попередньому випадку, може встановити порядок їх обробки;
● GPO OU. Обробляються GPO, які пов'язані з будь-якими OU, які містять
користувача чи комп'ютер. Параметри, задані на рівні OU, перевизначають
параметри, застосовані на локальному рівні або на рівні домену та/або сайту, з
якими вони конфліктують. Один і той самий об'єкт може входити в кілька OU. У
цьому випадку спочатку обробляються GPO, пов'язані з OU, що знаходиться на
найвищому рівні ієрархії Active Directory , потім з OU, що знаходиться на
наступному рівні, і т. д. Якщо з однією OU пов'язано кілька GPO, адміністратор, як
і в попередніх випадках, може задати порядок їх обробки.

Наслідування групової політики

За умовчанням дочірні контейнери успадковують групову політику батьківських
контейнерів. Однак можна перевизначити успадковані параметри, задавши інші значення
параметрів для дочірнього об'єкта. Крім того, GPO можна задати, що той чи інший
параметр активний, неактивний або не визначений. Параметри, які не визначені для
батьківського контейнера, не успадковуються взагалі дочірніми контейнерами, а
параметри, які активні або неактивні, успадковуються.
Якщо GPO визначено і для батька, і для нащадка і якщо задані параметри сумісні,
ці параметри комбінуються. Наприклад, якщо в батьківській OU задана певна довжина
пароля, а в дочірній OU — певна політика блокування облікових записів, будуть
використовуватися обидва параметри. Якщо параметри несумісні, то за умовчанням з
дочірнім контейнером зв'язується значення, яке перевизначає значення параметра, який
пов'язаний з батьківським контейнером.
Якщо політику не потрібно застосовувати до користувача або групи, можна
заборонити читання або застосування цієї політики для цього користувача або групи.
У більшості політик задіяна лише частина доступних параметрів, тому
рекомендовані параметри конфігурації комп'ютера або користувача, що містяться в GPO,
рекомендується відключати. Якщо параметри, що не використовуються, включені, вони
все одно обробляються, що призводить до зайвої витрати системних ресурсів.
Відключивши параметри, що не використовуються, ми знизимо навантаження на
клієнтські комп'ютери, що обробляють політику.
Є ще два додаткові механізми, що застосовуються при управлінні успадкуванням
групових політик [3]:
 ● Не перекривати ( Override ). При зв'язуванні GPO з контейнером можна вибрати,
щоб параметри, задані в цьому GPO, не перевизначалися параметрами GPO,
пов'язаних з дочірніми контейнерами. Це гарантує, що для дочірніх контейнерів
застосовуватиметься задана політика.
● Блокувати успадкування політики ( Block Policy Inheritance ). Якщо вибрати
цей параметр, контейнер не успадковує параметри GPO, задані для батьківського
контейнера. Однак, якщо для батьківського контейнера вказано параметр «Не
перекривати», дочірній контейнер не може заблокувати спадкування від свого
батька.

Планування структури GPO

При реалізації групової політики спочатку створюються GPO, потім ці об'єкти
зв'язуються із сайтами, доменами та OU. Може знадобитися застосування деяких GPO на
рівні доменів або сайтів, але в більшості випадків слід застосовувати GPO на рівні OU [3].

Зв'язування GPO з доменом

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

Зв'язування G P O із сайтом
GPO пов'язують із сайтами дуже рідко, оскільки набагато ефективніше пов'язувати
GPO з OU, структура яких ґрунтується на територіальному розподілі.
Але за певних обставин зв'язування GPO з сайтом є прийнятним рішенням. Якщо
параметри мають бути спільними для всіх комп'ютерів, що фізично знаходяться в певному
місці, і для цього місця створено сайт, є сенс зв'язати GPO з сайтом. Наприклад, для
комп'ютерів, розташованих у певній філії, потрібно задати певну мережну конфігурацію
за допомогою підключення до Інтернету. В цьому випадку ідеально підходить GPO,
пов'язаний із сайтом.

Зв'язування GPO з OU
Найчастіше краще зв'язувати GPO з добре продуманою структурою OU, ніж із
сайтами чи доменами. OU забезпечують найбільшу гнучкість, оскільки дозволяють
спроектувати структуру, хоча б частково спрощує застосування групової політики. Крім
того, OU гнучкіші в адмініструванні: можна без проблем переміщувати користувачів та
комп'ютери між OU, змінювати структуру OU і навіть перейменовувати самі OU.

Короткі підсумки
В Active Directory можна створити п'ять типів облікових записів:
● Комп'ютер;

● Користувач;

● Група;
 ● InetOrgPerson ;

● Контакт.

У Windows Server 2003 існує два основних типи облікових записів користувачів:
● локальні;

● доменні.

І на локальних комп'ютерах, і в доменах створюється два ключові облікові записи:

● Адміністратор ( Administrator );

● Гість ( Guest ).

Є кілька правил, які потрібно дотримуватись при плануванні стратегії іменування

користувачів. При плануванні стратегії аутентифікації (у тому числі керування паролями)
рекомендується дотримуватися ряду правил.
При плануванні груп можуть використовуватися такі типи груп і області дії:
● групи безпеки;

● групи розповсюдження;

● глобальні групи;

● локальні групи домену;

● універсальні групи:

Групи користувачів допомагають досягти найбільших успіхів у стратегії

управління обліковими записами при виконанні таких правил:
● уникати видачі дозволів на облікові записи;

● створювати локальні групи домену;

● для упорядкування користувачів використовувати глобальні групи;

● поміщати глобальні групи до локальних груп домену;

● не включати користувачів до універсальних груп.

При плануванні групової політики є два основних її типи:

● конфігурація комп'ютера;

● конфігурація користувача.

Незалежно від типу групової політики є три наступні категорії:

● параметри програм (Software Settings);

● параметри Windows (Windows Settings);

 ● адміністративні шаблони (Administrative Templates).

Оскільки GPO, які застосовуються до користувача або комп'ютера, можуть

надходити з кількох джерел, потрібен спосіб визначення того, як ці GPO обробляються.
● Локальний GPO.

● GPO сайту.

● GPO домену.

● GPO OU.
Лекція 9. ПЛАНУВАННЯ ТОПОЛОГІЇ САЙТІВ
Коротка інструкція: У цій лекції продовжено розгляд питання, як планувати службу
Active Directory перед її розгортанням. Розглянуто процес планування топології сайтів для
моделювання фізичної структури Active Directory .
Ключові слова : фізична структура, сайт, контролер домену, логічна структура, ліс,
домен, організаційна одиниця, зв'язок сайту, DNS , господар схеми, господар іменування
доменів, господар RID , емулятор основного контролера домену, господар
інфраструктури, сервер глобального каталогу.

Ціль лекції
Дати уявлення про процес планування топології сайтів.

Нагадаємо, що сайт - це група контролерів домену, які існують в одній або

декількох IP-підмережах, пов'язаних швидким та надійним мережевим з'єднанням.
Оскільки сайти засновані на IP-підмережах, вони зазвичай відповідають топології мережі,
а отже, відповідають і географічній структурі компанії. Сайти з'єднуються з іншими
WAN-каналами.
В Active Directory структура сайту пов'язана з фізичним середовищем та
підтримується окремо від логічного середовища та структури домену. Таким чином, сайти
Active Directory дозволяють відокремити логічну організацію структури каталогів
(структури лісів, доменів та OU) від фізичної структури мережі. Сайти представляють
фізичну структуру мережі на основі Active Directory . Оскільки сайти не залежать від
структури доменів, до одного домену може входити кілька сайтів, або, навпаки, один сайт
може містити кілька доменів або частин кількох доменів.
Сайти містять об'єкти лише двох типів: контролери доменів, що входять до сайту,
та зв'язки сайтів ( site links ), що налаштовуються для з'єднання з іншими сайтами.
Загалом сайти служать для управління трафіком WAN-каналами. Основне завдання
сайту – забезпечувати хороше мережне з'єднання.
Налаштування сайтів впливає на роботу Windows таким чином [4]:
● Реєстрація робочої станції та автентифікація. При вході користувача
операційна система спробує знайти контролер домену на сайті комп'ютера
користувача, щоб обслужити запит реєстрації в системі та наступні запити
мережевої інформації.
● Реплікація каталогу. Розклад та маршрут реплікації каталогу домену можуть бути
налаштовані для внутрішньо- та міжсайтової реплікації окремо. Зазвичай система
налаштовується те щоб міжсайтова реплікація здійснювалася рідше, ніж
внутрисайтовая .

Планування структури сайту

При плануванні сайтів мають бути вирішені два наступні завдання [4]:
● Оптимізація трафіку реєстрації робочої станції. Щоб встановити реєстрацію
робочої станції тільки на певних контролерах доменів, необхідно спланувати сайти
так, щоб тільки ці контролери доменів розташовувалися в тій же підмережі, що й
робоча станція.
● Оптимізація реплікації каталогів. Оскільки кожен контролер домену повинен
виконувати реплікацію каталогу з іншими контролерами свого домену, необхідно
 спланувати сайти так, щоб реплікація виконувалася в період мінімального
навантаження на мережу. Можливо, знадобиться створення серверів-плацдармів
( bridgehead servers ), щоб забезпечити вибір контролера домену, що
використовується як приймач для реплікації між сайтами.

Основні етапи налаштування сайту:

● Створення сайту.

● Зіставлення підмережі сайту.

● Підключення сайту із використанням зв'язків сайту.

● Вибір комп'ютера, що ліцензує для сайту.

Основні етапи налаштування реплікації між сайтами:

● Створення зв'язку сайту

● Налаштування атрибутів зв'язків сайту – такі як вартість зв'язку сайту, частота

реплікації та можливість реплікації (див. рис. 9.1).
● Створення мостів зв'язків сайту (див. рис. 9.2).

Мал. 9.1. Конфігурація зв'язків між сайтами

Мал. 9.2. Зв'язки, мости, транзитивність зв'язків сайтів

 Вибір структури сайтів визначається такою інформацією [3].
● Інформація про фізичну структуру мережі:

● територіальне розташування філій;

● структура та швидкість LAN філій;

● відомості про TCP/IP-підмережі філій;

● швидкість та вартість WAN-з'єднань.

● Інформація про логічну архітектуру Active Directory :

● план лісів;

● план доменів;

● план адміністративної ієрархії.

Основні принципи, яких рекомендується дотримуватись при плануванні структури

сайтів [3]:
● створювати сайт для LAN чи групи LAN;

● створювати сайт для кожної територіальної ділянки з контролером домену;

● створювати сайт для ділянок із сервером, на якому виконується програма, що

працює з даними про сайти.

При плануванні сайту слід подумати і про те, хто керуватиме структурою сайту
після його розгортання. Зазвичай відповідальними за топологію сайтів призначають
адміністратора (або адміністраторів). Він повинен у міру зростання та зміни фізичної
мережі вносити необхідні зміни до структури сайтів. Відповідальний за топологію сайтів
виконує такі обов'язки [3]:
● змінює топологію сайтів відповідно до змін у фізичній топології мережі;

● відстежує відомості про підмережі в мережі: IP-адреси, маски підмереж та

місцезнаходження підмереж;
● спостерігає за мережевими з'єднаннями та задає ціни зв'язків між сайтами.

Інфраструктура топології мережі

Оскільки проектування сайту сильно залежить від організаційної інфраструктури
мережі, необхідно здійснити документування цієї інфраструктури [13]:
● схеми топології глобальної (WAN) та локальної мережі (LAN), що деталізують
мережу корпорації, в яких міститься інформація про повну пропускну
спроможність та доступну пропускну спроможність між усіма офісами компанії;
● список усіх офісів компанії, у яких комп'ютери пов'язані через високошвидкісні
мережеві з'єднання. Визначення високошвидкісного підключення змінюється в
залежності від таких факторів, як кількість користувачів в офісах компанії,
загальна кількість об'єктів у домені та доменів у лісі. Крім того, потрібно
визначити, яка частина повної смуги пропускання мережі доступна для реплікації;
 ● кількість користувачів, комп'ютерів, серверів та локальних підмереж IP для
кожного офісу компанії.

Створення моделі сайту

Як тільки інформація про мережу компанії зібрана, можна розпочинати
проектування сайту. Кожен сайт повинен мати контролер домену, а більшість із них – і
GC -сервер.
Після визначення кількості сайтів для Active Directory здійснюється проектування
кожного сайту. Кожен сайт в Active Directory пов'язані з однією або більше підмережами
IP, тому потрібно визначити, які підмережі будуть включені до кожного сайту. Якщо
прийнято рішення не розгортати контролер домену в якомусь офісі компанії, то потрібно
визначити, до якого сайту належатиме цей офіс, і додати цю IP-підсіть до відповідного
сайту. У цьому випадку клієнти, які знаходяться у віддаленому офісі, з'єднаються з
найближчими контролерами домену.
При проектуванні структури кожного сайту для організації можна дотримуватись
правил, перелічених далі [4].
1. З'ясувати особливості фізичного середовища. Вивчити інформацію, зібрану щодо
структури домену, зокрема розташування сайтів, швидкість обміну даними у мережі,
організацію та використання мережевих підключень і підмереж IP.
2. Визначити фізичні мережі, які формують домени. З'ясувати, які їх включені у кожен
домен.
3. Визначити, які мережі планується призначити сайтами. Якщо ділянці мережі потрібен
контроль реєстрації робочих станцій або реплікація каталогу, цю ділянку необхідно
зробити сайтом.
4. Визначити фізичні сполуки сайтів. З'ясувати типи з'єднань, швидкості та призначення,
щоб їх вдалося визначити як об'єкти з'єднань сайтів. Об'єкт міжсайтового зв'язку ( site link
object ) містить план, де встановлено час виконання реплікації між сайтами, які він
з'єднує.
5. Для кожного об'єкта міжсайтового зв'язку задати розклад (графік та інтервал реплікації)
та вартість. Для реплікації застосовується найдешевший міжсайтовий зв'язок. Задати
пріоритет кожного зв'язку, вказавши вартість (за замовчуванням — 100 одиниць; що
менше витрати, то більше пріоритет). За замовчуванням реплікація здійснюється кожні
3:00. Необхідно задати час відповідно до потреб компанії.
6. Забезпечити надмірність конфігуруванням моста зв'язків сайтів. Міст зв'язків сайтів
( site link bridge ) забезпечує відмовостійкість реплікації.
7. Якщо призначено сервери-плацдарми для реплікації кожного сайту, то мають бути
ідентифіковані всі розділи Active Directory , які будуть розміщені на сайті, і призначений
сервер-плацдарм для кожного розділу.

Проектування розміщення серверів

У проектування сайту входить визначення місць розміщення серверів, необхідні
забезпечення потрібних служб каталогу Active Directory [13].

Розміщення DNS-серверів
Без служби DNS користувачі не зможуть знаходити контролери домену Active
Directory , а контролери домену не можуть знаходити один одного для реплікації. DNS
повинна бути розгорнута в кожному офісі організації, за винятком, можливо, тільки дуже
маленьких офісів з кількома користувачами. Служба DNS Windows Server 2003 забезпечує
кілька варіантів розгортання. Можна розміщувати DNS-сервери в офісі там, де немає
контролера домену. Наприклад, контролер домену небажано розташовувати в маленькому
офісі з повільним мережним підключенням до центрального офісу через трафіку
реплікації, спрямованого на контролер домену. Однак DNS-сервер в цей офіс помістити
можна, оскільки він може бути налаштований так, щоб трафік реплікації був дуже малий
або взагалі був відсутній. Якщо налаштувати DNS-сервер як сервер, призначений тільки
для кешування, він оптимізуватиме пошуки клієнта, але не створить трафіку зонної
передачі. Можна настроїти DNS-сервер зі скороченими зонами для доменів Active
Directory . Оскільки скорочені зони містять лише кілька записів, до віддаленого офісу
надсилатиметься дуже невеликий трафік реплікації.

Розміщення контролерів домену

Як правило, контролери домену слід розміщувати в більшості офісів компанії, де є
значна кількість користувачів. І тому існує принаймні дві причини. По-перше, у разі
відмови в мережі користувачі все одно змогли б увійти до мережі. По-друге, трафік входу
клієнтів у систему гарантовано не перетинається із WAN-підключеннями до різних офісів.
Для створення надмірності бажано помістити два контролери домену в кожен офіс. Якщо
розгортати контролер домену в даному місці компанії, необхідно створити і сайт, щоб
весь трафік входу в систему залишився в межах сайту.
Є також дві причини, чому можна не розміщувати контролер домену в цьому офісі
компанії. Якщо трафік реплікації на контролер домену, розташований у цьому місці,
вищий, ніж трафік входу клієнтів у систему, можна розробити таку конфігурацію, щоб
клієнти входили на суміжний контролер. Якщо місце розташування не має жодних засобів
фізичного захисту серверів, можливо, не слід розміщувати тут контролер домену.
Коли прийнято рішення не розгортати контролер домену в цьому місці компанії,
існує два способи керувати реєстрацією клієнтів. По-перше, можна налаштувати сайт для
офісу, а потім налаштувати зв'язки сайту до одного з існуючих сайтів. По-друге, можна
додати IP-підсіть для даного офісу до існуючого сайту.
Якщо планується розгорнути кілька доменів, дуже важливо визначити місце
розміщення контролера кореневого домену лісу. Він потрібно кожного разу, коли
користувач звертається до ресурсу, розташованого в іншому дереві домену, або коли
користувач входить до домену, розташованого в іншому дереві домену, не в його
власному дереві. Через це потрібно розміщувати контролери кореневого домену лісу у
будь-яких офісах з великою кількістю користувачів або там, де на контролери кореневого
домену буде спрямовано значний трафік. Якщо мережева топологія компанії включає
централізовані регіональні офіси, необхідно розгорнути контролер кореневого домену у
кожному з центральних офісів. Контролери кореневого домену лісу мають бути
розподілені за географічним принципом. Навіть якщо немає важливих причин поміщати
контролер кореневого домену в офіси, розташовані за межами головного офісу, це можна
зробити просто для забезпечення географічної надмірності. Однак контролери кореневого
домену ніколи не повинні розташовуватися в офісі, де вони не можуть бути фізично
захищені.

Розміщення серверів глобального каталогу

GC-сервери потрібні користувачам для входу на домени, які працюють на
основному ( native ) функціональному рівні Windows 2000, або коли користувачі роблять
пошук інформації каталогу в Active Directory . Якщо домен працює на основному
функціональному рівні Windows 2000, потрібно помістити GC-сервер в кожен сайт. В
ідеалі все це має бути збалансоване трафіком реплікації, який створюється внаслідок
розміщення GC-сервера в кожному сайті. Загальне правило полягає в тому, щоб
розміщувати GC-сервер у кожному сайті та кілька GC-серверів у великих сайтах.
Одне з покращень Active Directory Windows Server 2003 полягає в тому, що ця
система підтримує входи до системи домену без доступу до GC-сервера за рахунок
кешування універсального групового членства. Коли цю функцію увімкнено, контролери
домену можуть кешувати універсальне групове членство користувачів у домені. Коли
користувач входить на сайт вперше, універсальне членство групи користувача має бути
знайдено у GC-сервері. Після першого входу в систему контролер домену кешуватиме
універсальне групове членство користувача невизначено довго. Кеш на контролері домену
модифікується кожні 8 годин у результаті контакту із призначеним GC-сервером.

Розміщення серверів господарів операцій

Найбільш важливим господарем операцій для щоденної роботи є емулятор
основного контролера домену (PDC). Цей сервер особливо важливий, якщо домен працює
на змішаному функціональному рівні Windows 2000 або тимчасовому функціональному
рівні Windows Server 2003, тому що всі резервні контролери домену (BDC) із системою
Windows NT4 покладаються на емулятор PDC для синхронізації каталогу. Крім того, якщо
компанія має багато користувачів низького рівня без встановлених служб Directory
Services Client (клієнт послуг каталогу), ці користувачі повинні підключатися до
емулятора PDC, щоб змінити свої паролі. Навіть в основному режимі емулятор PDC
отримує пріоритетні оновлення змін пароля користувача, тому дуже важливо, де він
розташований. Емулятор PDC має бути розташований у центральному офісі, де
максимальна кількість клієнтів з'єднується із сервером.
Розміщення інших господарів операцій не таке критично. Приймаючи рішення про
те, де розміщувати цих господарів, можна скористатися такими рекомендаціями:
● По можливості господар схеми, господар іменування домену та господар відносних
ідентифікаторів (RID) повинні бути розташовані у сайті, що має інший контролер
домену як прямий партнер по реплікації. Причина пов'язана із відновленням
системи у разі відмови. Якщо один із цих серверів перестане працювати, то,
можливо, доведеться захопити роль господаря операцій та передати її іншому
контролеру домену. Цю роль бажано передати такий контролер домену, який
повністю реплікується з початковим господарем операцій. З найбільшою мірою
ймовірності це станеться в тому випадку, якщо два контролери домену будуть
знаходитися в одному і тому ж сайті і будуть налаштовані як прямі партнери з
реплікації.
● Господар RID повинен бути доступний для всіх контролерів домену через
підключення за віддаленим запитом процедури (RPC). Коли контролер домену
потребує більше ідентифікаторів RID, він буде використовувати RPC-підключення,
щоб запросити їх у господаря RID.
● Господар інфраструктури не повинен розташовуватись на GC-сервері, якщо в
компанії є більше одного домену. Роль господаря інфраструктури полягає в
оновленні посилань на відображені імена користувачів між доменами. Наприклад,
якщо обліковий запис користувача перейменовано і користувач є членом
універсальної групи, власник інфраструктури оновлює ім'я користувача. Якщо
господар інфраструктури розташований на GC-сервері, він не функціонуватиме,
тому що GC постійно оновлюється найсучаснішою глобальною інформацією. В
результаті господар інфраструктури не виявить жодної застарілої інформації і
таким чином ніколи не оновить перехресну міждоменну інформацію.
● Якщо організація має центральний офіс, де знаходиться більшість користувачів,
всіх господарів операцій слід поміщати на сайт цього офісу.

Короткі підсумки
При плануванні сайтів мають бути вирішені два завдання:
● оптимізація трафіку реєстрації робочої станції;
 ● оптимізація реплікації каталогів

Основні етапи налаштування сайту:

● Створення сайту.

● Зіставлення підмережі сайту.

● Підключення сайту із використанням зв'язків сайту.

● Вибір комп'ютера, що ліцензує для сайту.

Основні етапи налаштування реплікації між сайтами:

● Створення зв'язку сайту

● Настроювання атрибутів зв'язків сайту.

● Створення мостів зв'язків сайту.

Вибір структури сайтів визначається такою інформацією:

● інформація про фізичну структуру мережі;

● інформація про логічну архітектуру Active Directory .

Основні принципи, яких рекомендується дотримуватись при плануванні структури

сайтів:
● Створення сайту для LAN або групи LAN.

● Створювати сайт для кожної територіальної ділянки із контролером домену.

● Створювати сайт для ділянок із сервером, на якому виконується програма, яка

працює з даними про сайти.

Відповідальний за топологію сайтів виконує такі обов'язки:

● Змінює топологію сайтів відповідно до змін у фізичній топології мережі.

● Відстежує інформацію про підмережі в мережі: IP-адреси, маски підмереж та

місцезнаходження підмереж.
● Спостерігає за мережевими з'єднаннями та задає ціни зв'язків між сайтами.

Оскільки проектування сайту сильно залежить від організаційної інфраструктури

мережі, необхідно здійснити документування цієї інфраструктури:
● схеми топології глобальної (WAN) та локальної мереж (LAN);

● список усіх офісів компанії, у яких комп'ютери пов'язані через високошвидкісні

мережеві з'єднання;
● кількість користувачів, комп'ютерів, серверів та локальних підмереж IP для
кожного офісу компанії.
 При проектуванні структури кожного сайту для організації можна дотримуватись
правил, перелічених далі.
1. З'ясувати особливості фізичного середовища.
2. Визначити фізичні мережі, які формують домени.
3. Визначити, які мережі планується призначити сайтами.
4. Визначити фізичні сполуки сайтів.
5. Для кожного об'єкта міжсайтового зв'язку задати розклад (графік та інтервал реплікації)
та вартість.
6. Забезпечити надмірність конфігуруванням моста зв'язків сайтів.
7. Якщо призначено сервери-плацдарми для реплікації кожного сайту, то мають бути
ідентифіковані всі розділи Active Directory , які будуть розміщені на сайті, і призначений
сервер-плацдарм для кожного розділу.

У проектування сайту входить визначення місць розміщення серверів, необхідні

забезпечення потрібних служб каталогу Active Directory :
● Розміщення серверів DNS.

● Розміщення контролерів домену.

● Розміщення серверів глобального каталогу.

● Розміщення серверів господарів операцій.

Лекція 10. РЕПЛІКАЦІЯ В ACTIVE DIRECTORY
Коротка інструкція: Вказано модель реплікації, яка використовується в Active Directory .
Наведено типи та протоколи реплікації, види інформації, що реплікується.
Ключові слова : реплікація, домен, контролер домену, Knowledge Консистенція Checker
(КРС).

Ціль лекції
Дати уявлення про процес реплікації в Active Directory .

Кожна компанія, що реалізує проект із впровадження служби каталогу Active

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

Модель реплікації Active Directory

Active Directory складається з кількох логічних розділів. Реплікація інформації між
контролерами домену з репліками всіх розділів здійснюється однаково всім розділів. Коли
атрибут змінюється в розділі конфігурації каталогу, він реплікується так само, як і в разі
зміни атрибуту будь-якого іншого розділу. Єдина відмінність полягає в списку
контролерів домену, які отримають копію зміни, що реплікується. Реплікація між
контролерами домену в тому самому сайті обробляється інакше, ніж між контролерами
домену різних сайтів, але основна модель не змінюється.
На відміну від моделі реплікації з єдиним власником, яка використовується в
системі Microsoft Windows NT, Active Directory застосовує модель реплікації із кількома
господарями. У Windows NT основний контролер домену ( Primary Domain Controller
(PDC) є єдиним контролером домену, який може приймати зміни інформації домену.
Після того, як зміна зроблена, вона реплікується на всі резервні контролери домену
( Backup Domain Controllers , BDC). Недоліком моделі реплікації з єдиним господарем є
те, що вона не масштабується для великого розподіленого середовища. Оскільки зміни
(наприклад, пароля користувача) можуть виконуватися лише на контролері PDC, це може
стати вузьким місцем, якщо відбувається відразу тисяча змін. Контролер PDC знаходиться
лише в одному місці компанії, і будь-які зміни інформації домену, розташованого у
віддаленому місці, мають бути зроблені на цьому контролері PDC. Інша проблема полягає
в тому, що контролер PDC є єдиною точкою відмови. Якщо він недоступний, ніяких змін
інформації каталогу зробити не можна, доки він не повернеться до інтерактивного режиму
або поки інший BDC-контролер не буде призначений на роль контролера PDC.
В Active Directory зміни інформації домену можуть бути зроблені на будь-якому
контролері домену, тобто кожен контролер домену має копію каталогу, що
перезаписується, а контролера PDC не існує. Як тільки зміна була зроблена, вона
копіюється на всі інші контролери домену. Така модель реплікації з кількома господарями
спрямована на підвищення надійності та масштабованості, адже зміни в каталозі можна
робити на будь-якому контролері домену незалежно від того, де він розташований.
Оскільки всі контролери домену забезпечують ті самі служби, відмова одного з них не є
критичною для всієї системи.
Модель реплікації, що використовується в Active Directory представляє модель з
нежорстким узгодженням, що володіє збіжністю [13]. Реплікація не є жорстко
узгодженою, оскільки контролери домену, що містять репліку розділу, не завжди мають
ідентичну інформацію. Наприклад, якщо новий користувач створено одному з контролерів
домену, інші контролери домену не отримають цю інформацію до наступного циклу
реплікації. Процес реплікації завжди сходиться, тобто, якщо система підтримується в
стаціонарному стані, без внесення нових змін до каталогу протягом деякого часу, то всі
контролери домену досягнуть одноманітного стану і матимуть ідентичну інформацію.
При реплікації використовується також процес зберігання та ретрансляції ( store
and forward ). Це означає, що контролер домену може отримувати зміну до каталогу, а
потім надсилати його на інші контролери домену. Це вигідно в тих випадках, коли кілька
контролерів домену, що знаходяться у різних офісах компанії, з'єднані повільними WAN-
з'єднаннями. Зміна до каталогу може реплікуватися з контролера домену одного із сайтів
на єдиний контролер домену другого сайту. Контролер домену, який отримує оновлення,
може потім переправити зміни на інші контролери домену на другому сайті. Контролер
домену, на якому було зроблено зміни каталогу, не повинен копіювати зміни
безпосередньо на всі контролери домену, як це відбувається в моделі реплікації з єдиним
господарем.

Планування стратегії реплікації

Реплікація Active Directory - життєво важлива операція, яку необхідно ретельно
планувати. Правильно спланована реплікація прискорює відповідь каталогу, зменшує
мережевий трафік WAN-каналами і скорочує адміністративні витрати.
У Windows Server 2003 використовується модель реплікації з кількома
господарями, коли на всіх контролерах домену зберігаються рівноправні копії БД Active
Directory . Коли створюється, видаляється або переноситься об'єкт або змінюються
атрибути на будь-якому контролері домену, ці зміни реплікуються на інші контролери
домену.
Внутрішньосайтова (між контролерами домену одного сайту) та міжсайтова
реплікація (між контролерами домену, що належать до різних сайтів) виконується по-
різному [3], [4].

Реплікація всередині сайту

В межах сайту Active Directory автоматично створює топологію реплікації між
контролерами одного домену за допомогою кільцевої структури. Топологія визначає шлях
передачі оновлень каталогу між контролерами домену доти, доки оновлення не будуть
передані на всі контролери домену.
Кільцева структура забезпечує існування мінімум двох шляхів реплікації від
одного контролера домену до іншого, і якщо один контролер домену тимчасово стає
недоступним, то реплікація інші контролери домену все одно продовжиться.
При внутрішньосайтовій реплікації трафік реплікації передається в форматі, що не
стисло. Це пояснюється тим, що контролери домену, що належать одному сайту, як
передбачається, пов'язані каналами з високою пропускною здатністю. Крім того, що дані
не стискаються, використовується механізм реплікації, що базується на повідомленні про
зміни. Значить, якщо до даних домену вносяться зміни, ці зміни швидко реплікуються
попри всі контролери домену.
Реплікація між сайтами
Для забезпечення реплікації між вузлами необхідно подати мережеві з'єднання як
зв'язків сайтів. Active Directory використовує інформацію про мережеві з'єднання для
створення об'єктів-з'єднань, що забезпечує ефективну реплікацію та відмовостійкість.
Необхідно надати інформацію про застосовуваний для реплікації протокол,
вартість зв'язку сайтів, час доступності зв'язку і про те, як часто вона буде
використовуватися. Виходячи з цього Active Directory визначить, як зв'язати веб-сайти для
реплікації.
При міжсайтовій реплікації усі дані передаються у стислому вигляді. Причина в
тому, що трафік, ймовірно, передається більш повільними WAN-каналами (див. рис. 10.1)
порівняно зі з'єднаннями локальної мережі, що використовуються при
внутрішньосайтовій реплікації .

Мал. 10.1. Міжсайтова реплікація

Однак при цьому збільшується навантаження на сервери, оскільки, крім інших

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

Види інформації, що реплікується

Інформація, що зберігається в каталозі, ділиться на три категорії, які називаються
розділами каталогу. Розділ каталогу є об'єктом реплікації. У кожному каталозі міститься
така інформація [4]:
● інформація про схему - визначає, які об'єкти дозволяється створювати в каталозі та
які у них можуть бути атрибути;
● інформація про конфігурацію — описує логічну структуру розгорнутої мережі,
наприклад, структуру домену або топологію реплікації. Ця інформація є спільною
для всіх доменів у дереві чи лісі;
● дані домену - описують всі об'єкти в домені. Ці дані стосуються лише одного
певного домену, підмножина властивостей всіх об'єктів у всіх доменах зберігається
у глобальному каталозі для пошуку інформації у дереві доменів чи лісі.
 Схема та конфігурація реплікуються на всі контролери домену в дереві чи лісі.
Всі дані певного домену реплікуються на кожен контролер цього домену. Усі
об'єкти кожного домену, а також частина властивостей усіх об'єктів у лісі реплікуються у
глобальний каталог.
Контролер домену зберігає та реплікує [4]:
● інформацію про схему дерева доменів чи лісу;

● інформацію про конфігурацію всіх доменів у дереві чи лісі;

● всі об'єкти та їх властивості для свого домену. Ці дані реплікуються на всі

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

Глобальний каталог зберігає та реплікує:

● інформацію про схему у лісі;

● інформацію про конфігурацію всіх доменів у лісі;

● частина властивостей усіх об'єктів каталогу у лісі (реплікується лише між

серверами глобального каталогу);
● всі об'єкти каталогу і всі їхні властивості для домену, в якому розташований
глобальний каталог.

Протоколи реплікації
Видалені дзвінки процедур виконуються при надсиланні повідомлень реплікації
всередині сайту та між сайтами. Протокол RPC використовується за умовчанням при всіх
операціях реплікації Active Directory , оскільки є галузевим стандартом та сумісний з
більшістю типів мереж [3].
Обмін даними з каталогу здійснюється за допомогою різних мережевих протоколів,
таких як IP або SMTP [4]:
● ІР-реплікація. Використовує віддалений виклик процедур ( R emote P rokudure C
all , R P C) для реплікації через зв'язки сайтів (міжсайтовий) і всередині сайту
( внутрісайтовий ). За замовчуванням міжсайтова IP-реплікація виконується за
відповідним розкладом, проте можна налаштувати реплікацію Active Directory ,
щоб ігнорувати розклад. Для IP-реплікації не потрібний центр сертифікації.
● SMTP-реплікація. Виробляється тільки через зв'язки сайтів (міжсайтова), але не в
межах сайту. Оскільки протокол SMTP асинхронний, зазвичай усі розклади ним
ігноруються. Необхідно встановити та налаштувати центр сертифікації ( C
ertification A uthority , CA) компанії для використання SMTP-зв'язків сайтів. Центр
сертифікації підписує повідомлення SMTP, якими обмінюються контролери
домену для підтвердження автентичності оновлень каталогу.

Процес реплікації
Реплікація дозволяє відображати зміни в одному контролері домену на інших
контролерах домену. Інформація каталогу реплікується на контролери домену як у межах
вузлів, і між ними. При цьому з будь-якого комп'ютера в дереві доменів або лісі
користувачі та служби могли постійно отримувати доступ до інформації в каталозі.
Існують два типи оновлень інформації Active Directory , що стосується певного
контролера домену [13]. Перший тип оновлень - Вихідне оновлення ( originating update ).
Вихідне оновлення виконується при додаванні, зміні або видаленні об'єкта на контролері
домену. Другий тип оновлень - репліковане оновлення ( replicated update ). Реплікація
виконується тоді, коли зміна, зроблена на одному контролері домену, копіюється на інший
контролер домену. За визначенням вихідне оновлення, що стосується будь-якої
конкретної зміни, тільки одне, воно виконується на тому контролері домену, де було
зроблено. Потім вихідне оновлення копіюється на всі контролери домену, які мають
репліку розділу Active Directory , порушеного оновленням.
Вихідні оновлення Active Directory відбуваються у таких випадках [13]:
● до Active Directory доданий новий об'єкт;

● з Active Directory видалено існуючий об'єкт;

● атрибути існуючого об'єкта Active Directory змінено. Ця модифікація може містити

додавання нового значення атрибуту, видалення значення атрибута або зміна
існуючого значення;
● об'єкт Active Directory переміщено у новий батьківський контейнер. Якщо
змінюється ім'я батьківського контейнера, кожен об'єкт контейнера переміщається
в перейменований контейнер.

Усі вихідні оновлення Active Directory є елементарними операціями. Це означає,

що у процесі передачі модифікація має бути передана повністю, як ціла транзакція, і її
частина не передається окремо з інших частин.
Після передачі вихідного оновлення зміна повинна реплікуватися на інші
контролери домену, які містять репліку цього розділу. У межах сайту контролер домену,
на якому відбулося вихідне оновлення, чекає 15 секунд перед початком копіювання змін
своїм прямим партнерам з реплікації. Це очікування призначене для того, щоб кілька
модифікацій до бази даних можна реплікувати одночасно, що збільшує ефективність
реплікації. Між сайтами вихідне оновлення копіюватиметься партнерам з реплікації
відповідно до графіка, налаштованого на зв'язках сайту.
Active Directory реплікує інформацію в межах сайту частіше, ніж між сайтами,
зіставляючи необхідність оновленої інформації каталогу з обмеженнями пропускної
спроможності мережі. Краще виконувати реплікацію у той час, коли мережевий трафік
мінімальний, що зведе до мінімуму тимчасові затримки, пов'язані з реплікацією даних.
Щоб переконатися, що топологія реплікації все ще ефективна, Active Directory
періодично її аналізує. Якщо додати або усунути контролер домену з мережі або вузла, то
Active Directory змінить топологію належним чином. Перевірка топології реплікації ось у
чому. Active Directory запускає процес, який визначає вартість міжсайтових підключень,
перевіряє, чи доступні відомі контролери домену і чи були додані нові, і потім на основі
отриманих відомостей додає або видаляє об'єкти-підключення для формування
ефективної топології реплікації. Цей процес не торкається об'єктів-підключень, створених
вручну.
Кожен контролер домену на сайті представляється об'єктом-сервером. У кожного
об'єкта-сервера є дочірній об'єкт NTDS Settings , що управляє реплікацією даних
контролера домену всередині сайту, а у кожного об'єкта NTDS Settings — об'єкт-
з'єднання, в якому зберігаються атрибути з'єднання і який представляє комунікаційний
канал, який застосовується при реплікації даних з одного контролера домену на інший.
Для реплікації потрібно, щоб по обидва боки було з об'єкту-соединению.
Сервіс Knowledge Консистенція Checker (КСС) автоматично створює набір
об'єктів-з'єднань для реплікації з одного контролера домену на інший. Однак за потреби
можна створити об'єкти-з'єднання вручну.
 КСС створює різні топології (тобто задає місцезнаходження об'єктів-з'єднань та
його конфігурацію) для внутрисайтовой і межсайтовой реплікації. Крім того, КСС змінює
створені ним топології щоразу, коли додаються або видаляються контролери домену, а
також при їх переміщенні з одного сайту в інший.

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

Види реплікації: внутрішньосайтова (між контролерами домену одного сайту) та

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

● інформація про конфігурацію;

● дані домену.

Схема та конфігурація реплікуються на всі контролери домену в дереві чи лісі.

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

● інформацію про конфігурацію всіх доменів у дереві чи лісі;

● всі об'єкти та їх властивості для свого домену.

Глобальний каталог зберігає та реплікує:

● інформацію про схему у лісі;

● інформацію про конфігурацію всіх доменів у лісі;

● частина властивостей усіх об'єктів каталогу у лісі (реплікується лише між

серверами глобального каталогу);
● всі об'єкти каталогу і всі їхні властивості для домену, в якому розташований
глобальний каталог.

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

таких як IP або SMTP.
 ● ІР-реплікація. Використовує віддалений виклик процедур ( Remote P rokudure C all
, R P C) для реплікації через зв'язки сайтів (міжсайтовий) і всередині сайту
( внутрісайтовий ).
● SMTP-реплікація. Виробляється тільки через зв'язки сайтів (міжсайтова), але не в
межах сайту.

Існують два типи оновлень інформації Active Directory , що стосується певного

контролера домену - Вихідне оновлення ( originating update ) та репліковане оновлення
( replicated update ).
Лекція 11. ВПРОВАДЖЕННЯ ACTIVE DIRECTORY
Коротка інструкція: Описано процес поетапного розгортання Active Directory , що
включає такі етапи, як встановлення та впровадження. Коротко дано уявлення про умови,
необхідні для встановлення Active Directory і про функціонування майстра інсталяції.
Наведено опис етапу тестової експлуатації з наступним переходом з існуючої структури
промислового середовища компанії до спроектованої структури Active Directory .
Ключові слова : домен, контролер домену, доменне дерево, DNS , LDAP, ліс, об'єкт, сайт,
реплікація.

Ціль лекції
Навчитися впроваджувати Active Directory , сформулювати умови встановлення,
розібрати питання тестування.

Після вибору стратегії розгортання Active Directory здійснюється поетапне

впровадження єдиної служби каталогів відповідно до плану-графіка розгортання.

Розгортання Active Directory

Під час встановлення Active Directory виконуються такі функції:
● Додавання контролера домену до існуючого домену. Створюється рівноправний
контролер домену, що забезпечує стійкість до відмови і зменшення навантаження
на наявні контролери доменів.
● Створення першого контролера домену у новому домені. Створюється новий
домен, необхідний для розподілу інформації, що дозволить налаштувати Active
Directory відповідно до потреб організації. При створенні нового домену можна
створити новий дочірній домен або нове дерево.
● Створення нового дочірнього домену.
● Створення нового дерева домену.
● Встановлення сервера DNS.
● Створення БД та журналів БД.
● Створення загального системного тому.

Причини створення кількох доменів: розподілене адміністрування мережі,

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

Встановлення служби каталогу Active Directory

Процес установки служби каталогу Active Directory на комп'ютері з Microsoft
Windows Server 2003 нескладний : простота забезпечується за рахунок майстри інсталяції
Active Directory (Active Directory Installation Wizard) .
Два інші методи встановлення Active Directory [13] - інсталяція без допомоги
майстра та встановлення з відновлених резервних файлів.

Попередні умови встановлення Active Directory

 Будь-який сервер, який відповідає умовам, описаним далі, може містити Active
Directory і стати контролером домену. Кожен новий контролер домену фактично є
автономним сервером, доки не завершиться процес інсталяції Active Directory . У ході
цього процесу вирішуються два важливі завдання [13] — створюється або заповнюється
база даних каталогу та запускається Active Directory , щоб сервер відповідав на спроби
входу в систему домену та запити полегшеного протоколу служби каталогу LDAP.
База даних каталогу зберігається на жорсткому диску контролера домену у файлі
Ntds . dit . У процесі інсталяції Windows Server 2003 файл Ntds.dit зберігається в папці %
systemroot %\system32 на локальному диску. У процесі інсталяції Active Directory файл
Ntds.dit копіюється в місце, ідентифіковане під час інсталяції, або в задану за
замовчуванням папку % systemroot %\NTDS, якщо не визначено інше місце. За наявності
файлу Ntds.dit , скопійованого на жорсткий диск у процесі інсталяції Windows Server 2003,
Active Directory може бути встановлена у будь-який час без необхідності звертатися до
інсталяційного середовища.
Далі наводяться умови, необхідні для того, щоб Active Directory могла працювати у
Windows Server 2003 [13].
● Жорсткий диск. Розмір простору на жорсткому диску, необхідного для зберігання
Active Directory буде залежати від кількості об'єктів у домені і від того, чи є даний
контролер домену сервером глобального каталогу (GC). Для підтримки установки
папки Sysvol принаймні один логічний диск має бути відформатований під
файлову систему NTFS v.5 (версія NTFS, яка використовується у системах
Microsoft Windows 2000 та Windows Server 2003 ). Щоб встановити Active Directory
на сервер, на якому виконується система Windows Server 2003, жорсткий диск
повинен задовольняти такі мінімальні вимоги:
● 15 Мб вільного простору – на розділ установки системи;

● 250 Мб вільного простору – для бази даних Active Directory ( Ntds.dit );

● 50 Мб вільного простору – для файлів реєстраційного журналу транзакцій

процесора нарощування пам'яті (ESENT). ESENT є системою взаємодії бази
даних, яка використовує файли реєстраційних журналів для підтримки
семантики відкатів ( rollback ), щоб гарантувати передачу транзакцій базі
даних.
● Забезпечення мережного зв'язку. Після інсталяції Windows Server 2003 і до
початку встановлення Active Directory необхідно переконатися, що сервер
належним чином налаштований для забезпечення мережного зв'язку.
● Служба DNS, необхідна Active Directory як покажчик ресурсів. Клієнтські
комп'ютери покладаються на DNS при пошуку контролерів домену, щоб вони
могли автентифікувати себе та користувачів, які входять до мережі, а також робити
запити до каталогу для пошуку опублікованих ресурсів. Крім того, служба DNS
повинна підтримувати записи служби покажчика ресурсів (SRV) та динамічні
модифікації. Якщо служба DNS не була встановлена заздалегідь, то майстер
інсталяції Active Directory встановить та налаштує DNS одночасно з Active
Directory . Якщо DNS вже встановлена в мережі, необхідно перевірити її
конфігурацію, щоб вона могла підтримувати Active Directory .
● Адміністративні дозволи, які повинен мати обліковий запис користувача для
можливості встановлення Active Directory .
Майстер установки
Майстер установки Active Directory виконує такі функції [4]:
● додає контролер домену до існуючого домену;

● створює перший контролер домену у новому домені;

● створює новий дочірній домен;

● створює нове дерево домену;

● встановлює DNS-сервер;

● створює БД та журнали БД;

● створює загальний системний том;

● видаляє служби Active Directory з контролера домену.

Коли служба Active Directory встановлюється на сервер із Windows Server 2003,

комп'ютер фактично стає контролером домену. Якщо це перший контролер домену в
новому домені та лісі, то створюється чиста база даних каталогу, яка очікує надходження
об'єктів служби каталогу. Якщо це додатковий контролер домену у вже існуючому домені,
процес реплікації розмножить на новий контролер домену всі об'єкти служби каталогу
даного домену. Якщо це контролер домену, що має модернізовану систему Microsoft
Windows NT 4, база даних облікових записів буде автоматично оновлена до Active
Directory після того, як на цьому контролері домену буде встановлено Windows Server
2003
Під час встановлення Active Directory можна додати новий контролер домену до
існуючого домену або створити перший контролер нового домену [4].
● Додавання контролера до існуючого домену. І тут створюється рівноправний
контролер домену. Він забезпечить стійкість до відмови і зменшить навантаження
на наявні контролери доменів.
● Створення першого контролера для нового домену. І тут створюється новий
домен. Він потрібний для розподілу інформації, що дозволить налаштувати Active
Directory відповідно до потреб організації. При створенні нового домену можна
створити новий дочірній домен або нове дерево.

При встановленні служби каталогів Active Directory на першому контролері домену

сайту в контейнері Sites створюється об'єкт з ім'ям Default - First - Site - Name . На цьому
сайті необхідно встановити перший контролер домену. Додаткові контролери
розміщуються на сайті першого контролера домену (передбачається, що IP-адреса
жорстко пов'язана з сайтом) або в іншому існуючому сайті. Після встановлення першого
контролера домену ім'я Default - First - Site - Name можна змінити будь-яке інше.
Коли виконується установка Active Directory на додаткові сервери, а сховище
визначені додаткові сайти, то можливі два варіанти. Якщо I Р-адреса комп'ютера, що
встановлюється, відповідає наявній в існуючому сайті підмережі, то контролер додається
в цей сайт. Інакше контролер додається до сайту вихідного контролера домену.

Конфігурування DNS для Active Directory

Active Directory використовує DNS як службу пошуку, дозволяючи комп'ютерам
знаходити контролери доменів. Для пошуку контролера в певному домені клієнт запитує
DNS про записи ресурсів, що містять імена та IP-адреси LDAP-серверів домену. LDAP —
це протокол, який використовується для здійснення запитів та оновлення Active Directory
та виконується на всіх контролерах домену. Неможливо встановити Active Directory , не
маючи на комп'ютері служби DNS, тому що Active Directory використовує DNS як службу
пошуку. Однак можна встановити DNS без встановлення Active Directory .
Для автоматичного конфігурування DNS-сервера треба скористатися майстром
установки Active Directory : не доведеться вручну налаштовувати DNS для підтримки
Active Directory , але це не стосується тих випадків, коли планується використовувати
сервер DNS без Windows 2000/2003 або потрібно створити особливу конфігурацію. Щоб
задати конфігурацію, відмінну від стандартної установки, можна вручну налаштувати
DNS, скориставшись консоллю DNS.

База даних та загальний системний том

Під час встановлення Active Directory створюється БД та її журнал, а також
загальний системний том [4].
● БД та її журнал – це каталог для нового домену. За замовчуванням БД та її журнал
розміщуються в каталозі % systemroot %\NTDS, де % systemroot % - це каталог
Windows . Для підвищення продуктивності рекомендується розміщувати БД та
журнал на різних жорстких дисках.
● Загальний системний том – це структура папки, яка існує на всіх контролерах
доменів Windows . Він зберігає сценарії та деякі об'єкти групової політики для
поточного домену та підприємства. За промовчанням загальний системний том
розміщений у каталозі % systemroot %\ SYSVO L. Загальний системний том
повинен розташовуватися в розділі або томі, відформатованому під NTFS 5.0.

Реплікація загального системного тому йде за тим самим розкладом, що й

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

Режими домену
Існують два режими домену - змішаний та основний [4].
● Змішаний режим. При першому встановленні або оновленні контролера домену
до Windows 2000 Server контролер запускається в змішаному режимі ( mixed
mode ), що дозволяє йому взаємодіяти з будь-якими контролерами доменів під
керуванням попередніх версій Windows NT.
● Основний режим. Якщо на всіх контролерах домену встановлено Windows 2000
Server і не планується більше додавати до цього домену контролери нижнього
рівня, то рекомендується перевести домен в основний режим ( native mode ).

При зміні режиму зі змішаного на основний відбувається таке:

● припиняється підтримка реплікації нижнього рівня, після чого в цьому домені
забороняється мати контролери, які не працюють під керуванням Windows
2000/2003 Server ;
● забороняється додавання нових контролерів нижнього рівня у цей домен;
 ● сервер, який виконував роль основного контролера домену, перестає бути таким,
тому всі контролери стають рівноправними.

Зміна режиму домену можлива лише в одному напрямку - зі змішаного в основний

режим, але не навпаки.

Тестування Active Directory

Згідно з планом проведення розгортання, всі рішення повинні попередньо
тестуватись на стенді, розгорнутому на обладнанні у тестовому середовищі. У тестовому
середовищі підприємства створюється модель, ідентична моделі промислового
середовища чи його фрагментам.
На тестовому стенді, який належним чином налаштований залежно від переліку
необхідних для тестування додатків, виконуються попередні роботи з налагодження
роботи даних додатків, пов'язаних з Active Directory , а також тестова міграція даних та
перевірка коректності її проведення.
Тестування проводиться відповідно до процедур та сценаріїв тестування
(здійснюється функціональне та навантажувальне тестування); однією з його цілей є
перевірка стійкості до відмови рішення з високим показником надійності.
Тестування міграції доменів зазвичай починається з робіт із створення
односайтової моделі лісу Active Directory , що складається з кореневого домену та
різнорівневих дочірніх доменів. Потім планується реалізувати поетапну міграцію даних із
створених доменів, додаючи в них тестові робочі станції Windows , щоб мати можливість
перевірити вхід користувачів та виконання сценаріїв входу до нових доменів.
На наступному етапі створення стенду необхідно протестувати:
● розподіл ролей між серверами;

● роботу сервісу DNS, встановлений на серверах;

● проходження реплікації між контролерами доменів;

● налаштування з'єднання між контролерами доменів;

● додавання контролера домену до Internet V L AN;

● перенесення баз WINS, DHCP;

● автентифікацію користувачів на контролері

Після цього необхідно виконати таку послідовність дій:

● Встановити в Internet VLAN standalone -сервер (сервер не повинен бути
встановлений як контролер домену або member -сервер), що належить робочій
групі.
● Налаштувати на standalone сервері обмін даними по протоколу IPSec в тунельному
режимі з іншими контролерами доменів.
● Додати standalone -сервер в домен як member -сервер, вказати у властивостях
TCP/IP адресу DNS-сервера.
● Встановити на сервер послуги DHCP, WINS і перенести на нього копіюванням
бази, потім перетворити їх на формат Windows .
 ● Оновити member -сервер Windows до статусу контролера домену.

● Авторизувати сервер DHCP у Active Directory .

● Провести синхронізацію між standalone -сервером та контролерами домену.

● На контролері домену встановити DNS-сервіс. У властивостях TCP/IP цього

сервера вказати адресу DNS-сервера, що дорівнює власної адреси сервера.
● Призначити функцію глобального каталогу для standalone сервера.

● Перевірити проходження реплікації між контролерами домену.

● Запустіть тест перевірки функціонування контролерів домену.

● Перевірити вхід користувачів до мережі та виконання сценаріїв входу.

● Створити імідж першого розділу контролера домену та зберегти його на другому

розділі.

Тестування реструктуризації домену - протестувати перенесення облікових записів

користувачів та комп'ютерів з існуючого домену до нового домена за допомогою утиліти
ADMT [4].
● Налагодити двосторонні довірчі стосунки між доменами.

● Включити аудит успішних та неуспішних подій з управління користувачами та

групами в обох доменах.
● Перенести користувачів та групи з існуючого домену до нового домену.

● Перевірити вхід користувачів до домену.

● Видалити довірчі відносини між новим доменом та існуючим доменом.

Тестування перенесення баз DHCP, WINS - протестувати коректність перенесення

баз у процесі міграції.
● Встановити на сервері послуги DHCP, WINS і перенести на нього копіюванням
бази з існуючих серверів, потім перетворити їх на формат Windows .
● Авторизувати сервер DHCP у Active Directory .

Тестування багатосайтової конфігурації фізичної топології Active Directory —

створити додатковий сайт для віддаленого майданчика, встановити контролер домену на
цей сайт і перевірити такі характеристики:
● Час реплікації між контролерами домену, розташованими у центральному офісі та
на віддаленому майданчику.
● Аутентифікація користувачів.

● Час проходження реплікації для «миттєвих подій» (зміна пароля).

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

Короткі підсумки
Під час встановлення Active Directory виконуються такі функції:
● Додавання контролера домену до існуючого домену.

● Створення першого контролера домену у новому домені.

● Створення нового дочірнього домену.

● Створення нового дерева домену.

● Встановлення сервера DNS.

● Створення БД та журналів БД.

● Створення загального системного тому.

Існують два режими домену - змішаний та основний. Зміна режиму домену

можлива лише в одному напрямку - зі змішаного режиму в основний режим, але не
навпаки. При зміні режиму зі змішаного на основний відбувається таке:
● припиняється підтримка реплікації нижнього рівня, після чого в цьому домені
забороняється мати контролери, які не працюють під керуванням Windows
2000/2003 Server ;
● забороняється додавання нових контролерів нижнього рівня у цей домен;

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

Згідно з планом проведення розгортання, всі рішення повинні попередньо

тестуватись на стенді, розгорнутому на обладнанні у тестовому середовищі. У тестовому
середовищі підприємства створюється модель, ідентична моделі промислового
середовища чи його фрагментам.
Тестування проводиться відповідно до процедур та сценаріїв тестування
(здійснюється функціональне та навантажувальне тестування), однією з його цілей є
перевірка відмовостійкості рішення з високим показником надійності.
На наступних етапах створення стенду необхідно протестувати:
● Розподіл ролей між серверами.

● Роботу сервісу DNS, встановлений на серверах.

● Проходження реплікації між контролерами доменів.

● Налаштування з'єднання між контролерами доменів.

● Додавання контролера домену до Internet V L AN.

● Перенесення баз WINS та DHCP.

 ● Аутентифікація користувачів на контролері.

Далі процес тестування можна описати так:

● Тестування реструктуризації домену.

● Тестування перенесення баз DHCP, WINS.

● Тестування багатосайтової конфігурації фізичної топології Active Directory .

Після завершення тестової експлуатації здійснюється перенесення даних з існуючої

структури промислового середовища компанії до спроектованої структури Active
Directory .
Лекція 12. МІГРАЦІЯ ДАНИХ
Коротка інструкція: Наведено короткий опис процесу міграції даних при впровадженні
служби Active Directory , що здійснюється в єдину структуру служби каталогів Active
Directory . Сформульовано завдання, які необхідно виконати під час міграції, надано
варіанти модернізації та критерії їх вибору. Вказані ймовірні проблеми при проведенні
міграції даних, їх причини та можливі способи усунення.
Ключові слова: домен, логічна структура, обліковий запис, DNS , групова політика,
резервне копіювання.

Ціль лекції
Дати уявлення про процес міграції під час розгортання Active Directory .

Для можливості функціонування в компанії різних програм, що використовуються

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

● Визначення послідовності модернізації доменів облікових записів.

● Визначення послідовності модернізації ресурсних доменів.

● Визначення моменту перемикання кожного домену зі змішаного режиму ( Mixed

mode ) в основний режим ( Native mode ) Windows .
● Тестування наявних критичних програм в оточенні Active Directory у змішаному
режимі роботи контролерів доменів.

У процесі міграції даних забезпечується безперервність роботи користувачів та

мінімальний час простою інформаційних систем компанії.

Загальні положення модернізації доменної інфраструктури

При модернізації доменної інфраструктури здійснюється міграція даних:
перенесення до єдиної служби каталогу інформаційних систем та додатків, робота яких
тісно пов'язана з Active Directory . При цьому можлива міграція з існуючої структури
DNS/WINS, з інтеграцією нової та існуючої структури DNS/WINS на етапі міграції.
Під час проведення міграції необхідно виконати такі завдання [4]:
● перевести існуючі домени ресурсів до організаційних одиниць нових доменів, що
дозволить спростити управління мережевими ресурсами;
● «імітувати» перебіг міграції, у своїй реального перенесення даних немає;

● скасувати зроблені дії, пов'язані з міграцією;

● перемістити облікові записи служб;

● відновити довірчі відносини між вихідним та цільовим доменами;

 ● перетворити безліч доменів на один або кілька великих доменів у вже створеному
середовищі Active Directory ;
● реструктуризувати існуючі групи або об'єднати кілька груп в одну в цільовому
домені;
● провести аналіз процесу перенесення даних за допомогою журналізації
міграційних подій.

Міграція користувачів та робочих станцій у єдину структуру Active Directory

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

Варіанти модернізації
Існує два основні варіанти модернізації доменної інфраструктури [4]:
● Оновлення доменів. Даний спосіб є найпоширенішим і найпростішим для
реалізації при міграції доменів. Цей спосіб дозволяє зберегти поточну структуру
доменів, налаштування системи, структуру користувачів та груп. Оновлення
домену ( in - place оновлення) включає переведення контролерів існуючого домену
в створюваний домен.
● Реструктуризація доменів. Цей спосіб дозволяє змінити існуючу структуру
доменів, об'єднати домени або перетворити домени на організаційні підрозділи.

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

Критерії вибору шляху переходу

При виборі шляху переходу мається на увазі, що це стосується лише одного
домену, тобто цілком справедливо використовувати різні шляхи переходу для різних
доменів в межах однієї організації.
Розглянемо основні критерії, які використовуються при виборі найбільш
сприятливого шляху переходу [13], наведені в таблицях 12.1-12.6 .
● Критерій 1. Задоволеність наявною моделлю існуючого домену.

Таблиця 12.1. Вибір шляху переходу за критерієм 1

Шлях переходу Відповідність критерію
Якщо немає жодних істотних змін, які хотілося б зробити в доменній
моделі, оновлення домена забезпечить найлегший шлях. Ім'я домену
Оновлення домену
залишиться тим самим, як і існування всіх облікових записів
користувачів та груп
Якщо існуюча доменна модель більше не задовольняє
Реструктуризація організаційним потребам або більше не є найбільш оптимальною для
домену підрозділів організації, то найкращим вибором буде
реструктуризація домену
 ● Критерій 2. Ступінь ризику під час переходу до нової моделі домену.

Таблиця 12.2. Вибір шляху переходу за критерієм 2

Шлях переходу Відповідність критерію
Оновлення домену є методом з мінімальним ризиком. Процес
модернізації контролера домену виконується автоматично, отже без
взаємодії з користувачем можливостей для помилок виникає
небагато. Методологія відновлення після збою при оновленні домену
Оновлення домену
також відносно проста: якщо оновлення пройшло невдало, необхідно
вимкнути основний контролер домену (PDC), призначити будь-який
резервний контролер домену (BDC), що має свіжі дані, на роль PDC,
і розпочати процедуру знову
Реструктуризація домену є шлях з більш високим ризиком, ніж
оновлення домену. Треба виконати більшу кількість завдань, і тому
Реструктуризація багато процесів можуть йти не так, як треба. В результаті зростає
домену невдоволення користувачів, які не можуть увійти в систему,
звернутися до необхідних ресурсів або отримати доступ до своїх
поштових скриньок.

● Критерій 3. Час виконання переходу 3.

Таблиця 12.3. Вибір шляху переходу за критерієм 3

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

● Критерій 4. Робочий час служби каталогу, який потрібно витратити на процес

переходу.

Таблиця 12.4. Вибір шляху переходу за критерієм 4

Шлях переходу Відповідність критерію
Об'єкти облікових записів недоступні в процесі переходу, оскільки
Оновлення домену
вони самостійно модернізуються під час оновлення домену
Реструктуризація Хороший вибір для організацій, у яких робочий час системи є
домену критичною величиною. Так як вона включає створення
незаповненого, «чистого» лісу та залишає вихідне середовище по
суті без змін, то працездатність служби каталогу зберігається,
оскільки користувачі продовжують функціонувати у існуючому
середовищі. Можна переносити великі або маленькі партії
3
p align="justify"> Графік часу переходу не є вирішальним фактором при виборі шляху переходу,
проте він може бути визначальним для невеликих організацій з обмеженими ресурсами.
 Шлях переходу Відповідність критерію
користувачів протягом непікових годин роботи і залишати ці нові
облікові записи бездіяльними до того часу, як з'явиться готовність
залишити стару систему

● Критерій 5. Наявність ресурсів до виконання переходу.

Таблиця 12.5. Вибір шляху переходу за критерієм 5

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

● Критерій 6. Бюджет проекту переходу.

Таблиця 12.6. Вибір шляху переходу за критерієм 6

Шлях переходу Відповідність критерію
Чинники, що сприяють зменшенню необхідних бюджетних коштів:
● можливість використовувати наявні серверні апаратні засоби;

Оновлення домену ● нижчі витрати на людські ресурси;

● зменшення витрат на тестування, оскільки потрібно буде

тестувати меншу кількість завдань модернізації

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

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

Якщо компанія не зовсім задовольняє умовам, що дозволяють впевнено вибрати

оновлення або реструктуризацію домену як шлях оновлення, або якщо для неї підходять
обидва шляхи, можна вибрати третій шлях — оновлення домену з подальшою
реструктуризацією.
Цей шлях переходу до Active Directory дозволить отримати негайну вигоду
(делегування адміністрування, групові політики, публікація додатків та багато іншого), а
також довготривалу вигоду від реструктуризації домену (менша кількість доменів зі
збільшеним обсягом домену, проект домену відповідно до ділових та організаційних цілей
компанії).
Перехід до Active Directory
Підготовка переходу до Active Directory відбувається в три етапи [13]:
1. Планування переходу.
2. Випробування плану переходу.
3. Проведення експериментального переходу.

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

який слідує за переходом до Active Directory .

Планування модернізації
Перший крок у плануванні модернізації Active Directory полягає в документуванні
існуючого каталогу та платформи мережевих служб, опис яких необхідно включити до
плану [13]:
● Поточна доменна структура. Ця інформація буде потрібна для можливості
відкату переходу. Найкраща практика полягає в документуванні наступної
інформації про поточний каталог, мережеві служби та середовище, в якому вони
виконуються:
● всі домени організації (домени ресурсів та облікових записів);

● всі довірчі відносини між доменами (включаючи тип та напрямок довірчих

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

● Поточні мережі. Необхідно задокументувати такі служби, що використовуються

в організації, включаючи сервер, на якому вони виконуються:
● сервери DNS;

● сервери протоколу динамічної конфігурації хоста (DHCP), а також

параметри налаштування області дії ( scope );
● сервери служби імен Інтернет для Windows (WINS);

● сервери служби віддаленого доступу (RAS);

● файлові сервери та сервери друку.

● Апаратні засоби сервера та конфігурації програмного забезпечення. Важливо

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

● оперативна пам'ять;
 ● системи зберігання інформації;

● мережна операційна система, що виконується кожному сервері;

● операційна система, що виконується на робочих станціях;

● всі програми, пов'язані з бізнесом, що виконуються на контролері домену.

Як тільки поточне середовище буде описано, необхідно ухвалити рішення про те,
як і коли модернізувати Active Directory , тобто створити сценарій (план) модернізації -
покроковий список завдань та порядок їх виконання.
У плані модернізації рекомендується мати такі складові [13]:
● порядок модернізації;

● дії, які необхідно вжити для того, щоб гарантувати продовження роботи мережевих
служб у процесі оновлення;
● дії щодо перевірки правильності виконання;

● користувачі, групи, комп'ютери та облікові записи служб, які потрібно переносити;

● вихідні та цільові домени;

● час до виконання процесу модернізації;

● дії, необхідні для перемикання користувачів на нове середовище;

● кроки щодо перевірки правильності переходу;

У плані модернізації рекомендується визначити як те, що потрібно робити

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

Тестування плану модернізації

Існує кілька серйозних підстав для тестування плану модернізації [13].
● Тестування підтвердить, що дії щодо оновлення призведуть до бажаних
результатів.
● Тестування дасть змогу визначити час, необхідний повного завершення
модернізації.
● Тестування дасть можливість ознайомитися з інструментальними засобами та
процедурами, які будуть використані під час переходу до Active Directory .

Необхідно перевірити всі елементи переходу, розглянувши план модернізації, та

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

Проведення експериментальної модернізації

Перш ніж розгортати модернізацію по всій організації, потрібно провести
експериментальний перехід з обмеженою та керованою групою користувачів. Це дасть
змогу ретельно проаналізувати результати переходу в керованому середовищі перед
виконанням повного плану модернізації. Експериментальна модернізація має кілька
переваг [13].
● Тестує план переходу у виробничому середовищі.

● Дозволяє виявити непередбачені помилки щодо модернізації.

● Надає можливість ознайомитись із інструментальними засобами модернізації.

Завдяки експериментальній модернізації можна оцінити результати плану переходу

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

Резервне копіювання даних

Міграцію даних під час переходу до Active Directory необхідно супроводжувати їх
резервним копіюванням, у своїй треба враховувати, що централізоване зберігання даних
спрощує цей процес. Резервне копіювання призначене для збереження даних та, у разі
невдалої спроби міграції, їх повторного використання для здійснення переходу до Active
Directory .
Важлива частина резервного копіювання Active Directory - Виконання підготовчих
операцій. Наприклад, слід перевірити, чи закриті файли, які планується архівувати.
Сеанси програм, запущених системами або користувачами, сповістити яких неможливо
(наприклад, користувач підключився через Інтернет), будуть завершені, Windows Backup
не архівує файли, заблоковані програмами.
При використанні знімних носіїв необхідно переконатися в наступному [4]:
● пристрій резервного копіювання підключено до комп'ютера мережі та увімкнено;

● відповідний пристрій перерахований у списку сумісних із Windows пристроїв

( Hardware Compatibility List , HCL).

Типові проблеми під час міграції

Під час проведення міграції даних у єдину структуру служби каталогів Active
Directory можуть виникати такі проблеми:
● Неефективна реплікація викликає падіння продуктивності служби Active Directory ,
наприклад, можуть не розпізнавати нові користувачі.
● Через повну синхронізацію всіх даних у домені розширення схеми може впливати
на великі мережі через виникнення великих тимчасових затримок. Щоб
мінімізувати тимчасові затримки, пов'язані з реплікацією даних, краще виконувати
реплікацію в нічний час.
● Проблеми з реплікацією даних:
 ● реплікація інформації каталогу припинилася;

● уповільнення реплікації даних.

● Найчастіше в результаті неефективної обробки запитів інформація каталогу

застаріває, а контролери домену стають недоступними.
● Збереження наявних поштових повідомлень під час міграції поштових скриньок
користувачів з системи UNIX в Exchange Server .
● Автоматизація прописування шляхів до профілів, що переміщуються після міграції
користувачів - для вирішення створюється спеціалізований сценарій ( VBScript ).
● Збільшення бази даних каталогу в міру розширення організації без обмежень щодо
продуктивності сервера або за місцезнаходженням у мережі — каталог поділяється
на розподілені розділи.

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

● скасувати зроблені дії, пов'язані з міграцією;

● перемістити облікові записи служб;

● відновити довірчі відносини між вихідним та цільовим доменами;

● перетворити безліч доменів на один або кілька великих доменів у вже створеному
середовищі Active Directory ;
● реструктуризувати існуючі групи або об'єднати кілька груп в одну в цільовому
домені;
● провести аналіз процесу перенесення даних за допомогою журналізації
міграційних подій.

Визначення порядку модернізації доменів

● Визначення домену, який має бути модернізований першим.

● Визначення послідовності модернізації доменів облікових записів.

● Визначення послідовності модернізації ресурсних доменів.

● Визначення моменту перемикання для кожного домену з Mixed mode в Native mode
Windows .
 ● Тестування наявних критичних програм в оточенні Active Directory у змішаному
режимі роботи контролерів доменів.

Існує три основні варіанти модернізації доменної інфраструктури.

● Оновлення доменів.

● Реструктуризація доменів.

● Оновлення доменів з їх подальшою реструктуризацією.

Основні критерії, які використовуються при виборі найбільш відповідного

варіанта:
● Задоволеність наявною моделлю існуючого домену.

● Ступінь ризику під час переходу до нової моделі домену.

● Час виконання переходу.

● Робочий час служби каталогу, який потрібно витратити на процес переходу.

● Наявність ресурсів до виконання переходу.

● Бюджет проекту переходу.

Підготовка переходу до Active Directory відбувається в три етапи.

1. Планування переходу.
2. Випробування плану переходу.
3. Проведення експериментального переходу.

Міграцію даних під час переходу до Active Directory слід супроводжувати їх

резервним копіюванням.
Лекція 13. МОНІТОРИНГ ACTIVE DIRECTORY
Коротка інструкція: У цій лекції обговорюється, що таке моніторинг Active Directory ,
чому його слід проводити, як це робити, і які саме параметри функціонування служби
необхідно відстежувати. Розглядаються деякі інструменти для моніторингу Active
Directory , доступні в системі Microsoft Windows Server 2003
Ключові слова: угода про рівень сервісу, ліс, домен, контролер домену, сайт, господарі
операцій, реплікація, Knowledge Консистенція Checker (КСС), DNS .

Ціль лекції
Висвітлити процес моніторингу Active Directory .

Служба Active Directory є складною розподіленою мережевою службою. У великих

організаціях вона буде піддана тисячам змін щодня (створення або видалення облікових
записів користувача та їх атрибутів, групового членства та дозволів). Для гарантії того, що
ці зміни в мережі та робочому середовищі не будуть негативно впливати на роботу Active
Directory потрібно щодня робити профілактичні дії — моніторинг стану служби каталогу,
який необхідний для підтримки надійності Active Directory .
Окремого інструменту або пакета програм для моніторингу Active Directory , не
існує, тому моніторинг служби каталогу є комбінацією завдань, що мають спільну мету
[4], [13] - вимірювання поточної характеристики деякого ключового індикатора (займаний
об'єм диска, ступінь використання процесора, період працездатного стану служби тощо)
порівняно з відомим станом (відправна точка) 4.

Причини проведення моніторингу, реалізовані переваги та

супутні витрати
Основна причина проведення моніторингу Active Directory (як і моніторингу будь-
якої іншої служби) полягає в тому, що він ідентифікує потенційні проблеми, перш ніж
вони виявляться і закінчаться тривалими періодами простою служби. Необхідно стежити
за станом Active Directory , щоб вирішувати виникаючі проблеми якнайшвидше, перш ніж
відбудеться переривання роботи служби.
Моніторинг дає можливість підтримувати угоду про рівень сервісу ( Service - Level
Agreement , SLA) з користувачем мережі. У контексті Active Directory SLA угода між ІТ-
відділом і спільнотою користувачів може містити такі параметри, як максимально
прийнятний рівень часу простою системи, час входу в систему і час отримання відповіді
на довідковий запит.
Ще одна причина для моніторингу Active Directory полягає в тому, що необхідно
відстежувати такі зміни інфраструктури 5[13]:
● збільшення розміру бази даних Active Directory ;

● функціонування серверів глобального каталогу (GC) у інтерактивному режимі;

● час реплікації між географічно рознесеними контролерами доменів

4
Існують набори інструментів, які можуть поєднати моніторинг цих ключових індикаторів в один
легко керований інтерфейс, і для великих організацій наявність таких коштів дуже суттєва, але вони дорогі,
складні та потребують багато ресурсів.
5
Можливо, ця інформація не допоможе запобігти виникненню сьогоднішньої помилки, але вона
дозволить отримати цінні дані, з якими можна будувати плани щодо подальшого розвитку інфраструктури
компанії.
 Переваги, які можна отримувати від моніторингу Active Directory , включають такі
компоненти [13]:
● здатність підтримувати SLA-угоду з користувачами, уникаючи простою служби;

● досягнення високої продуктивності служби шляхом усунення «вузьких місць» у

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

За всіх зазначених переваг моніторинг Active Directory пов'язані з витратами, які

необхідні його ефективної реалізації [13],
● Для проектування, розгортання та управління системою моніторингу потрібні
відповідні людські ресурси (людина-годинник), які вимагають оплати.
● На придбання необхідних засобів управління, навчання та на апаратні засоби, які
призначені для реалізації моніторингу, потрібні певні фонди.
● Частина пропускної спроможності мережі буде задіяна для моніторингу Active
Directory на всіх контролерах домену підприємства.
● Для виконання додатків-агентів на цільових серверах і комп'ютері, що є
центральним пультом моніторингу, використовуються пам'ять і ресурси процесора.

Вартість моніторингу швидко підвищується при впровадженні глобального

моніторингу підприємства типу комплексу Microsoft Operations Manager (MOM 2005 або
його сучасний аналог - MSCOM 2007). Інструментальні засоби MOM хоч і розширюють
можливості моніторингу, але досить дорогі, вимагають навчання оператора та витрачають
більшу кількість системних ресурсів на відміну від моніторингових рішень Windows
Server 2003, які є перевіреними, інтегрованими та підтримуваними продуктами, але з
базовими можливостями моніторингу.
Рівень моніторингу залежатиме від результатів аналізу переваг та витрат. У будь-
якому випадку вартість ресурсів, які будуть витрачені на систему моніторингу, не повинна
перевищувати очікувану від моніторингу економію. Тому великі організації знаходять
більш рентабельним вкладати капітал у комплексні рішення з управління підприємством.
Для менших організацій більш виправдано використовувати інструментальні засоби
моніторингу, вбудовані в Windows Server 2003

Процес моніторингу Active Directory

Здійснюючи моніторинг Active Directory , необхідно відстежувати ключові
індикатори продуктивності та порівнювати їх з базовими показниками, які представляють
роботу служби в межах нормальних параметрів. Коли індикатор працездатності
перевищує цей поріг, видається попередження, що повідомляє адміністрацію мережі (або
оператора моніторингу) про поточний стан системи. Попередження може також
ініціювати автоматичні дії, спрямовані на вирішення проблеми або зменшення
подальшого погіршення стану служби.
 Нижче наводиться схема процесу моніторингу служби Active Directory високого
рівня [13].
1. Визначити, який із індикаторів функціонування служби слід відстежувати.
2. Здійснити моніторинг індикаторів функціонування служби, щоб встановити та
задокументувати базовий (нормальний) рівень.
3. Визначити пороги для цих індикаторів функціонування, тобто вказати, за якого рівня
індикатора необхідно вживати заходів, що запобігають розладу функціонування служби.
4. Спроектувати необхідну аварійну систему, призначену для обробки подій під час
досягнення порогового рівня. Аварійна система повинна включати наступні компоненти:
● повідомлення оператора;

● автоматичні дії, якщо вони можливі;

● дії, які ініціюються оператором.

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

Елементи моніторингу
Для моніторингу стану Active Directory слід відстежувати роботу, пов'язану зі
службою, та індикатори функціонування, пов'язані з сервером, а також події. Мета
моніторингу – гарантувати, що Active Directory та контролери домену, на яких вона
виконується, працюють в оптимальному режимі.
При проектуванні моніторингу рекомендується планувати спостереження за
такими елементами (областями роботи) [5], [13]:
● Продуктивність служб Active Directory . Ці індикатори функціонування
відстежуються за допомогою лічильників NTDS в інструменті адміністрування
Performance .
● Реплікація Active Directory . Функціонування реплікації істотно задля забезпечення
збереження даних у межах домену.
● Функціонування служби DNS та стан DNS-сервера. Оскільки Active Directory
покладається на DNS при пошуку ресурсів у мережі, то сервер DNS і сама служба
повинні працювати в нормальному режимі, щоб Active Directory задовольняла
заданий рівень якості обслуговування.
● Сховище Active Directory . Дискові томи, які містять файл бази даних Active
Directory Ntds . dit та файли журналів. log повинні мати достатньо вільного
простору, щоб допускати нормальне зростання і функціонування. Крім того, якщо
моніторинг функціонування служби показує, що диск, на якому розташована база
даних Active Directory , фрагментований, необхідно його дефрагментувати .
● Служба реплікації файлів (File Replication Service, FRS). Служба FRS повинна
працювати в межах норми, щоб гарантувати, що загальний системний том
( Sysvol ) реплікується по всьому домену.
● "Здоров'я" системи контролера домену. Моніторинг цієї області повинен
охоплювати всі аспекти стану сервера, включаючи лічильники, що характеризують
використання пам'яті, процесора та розбиття на сторінки.
 ● "Здоров'я" лісу. Ця область повинна відстежуватися для того, щоб перевірити
довірчі стосунки та доступність сайту.
● Господарі операцій. Необхідно відстежувати кожного господаря операцій, щоб
гарантувати здоров'я сервера. Крім того, слід проводити моніторинг для
забезпечення доступності GC-каталогу, що дозволяє користувачам входити до
системи та підтримувати членство універсальних груп.

Далі наведено короткий опис деяких основних елементів Active Directory ,

моніторинг яких необхідний.

Моніторинг продуктивності
Як і будь-яка критична для бізнесу система, Active Directory повинна бути під
постійним контролем. Для вирішення цього завдання Microsoft вбудувала механізм Active
Directory цілий ряд можливостей, що включає як розширену діагностику в EventLog
контролерів домену, звіти та логи в текстові файли, так і вбудовані лічильники
продуктивності.
Дані про продуктивність Active Directory дозволяють [4]:
● оцінити продуктивність Active Directory та її вплив на ресурси системи;

● спостерігати за змінами та тенденціями продуктивності та використанням ресурсів

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

У Windows є кілька засобів моніторингу продуктивності Active Directory .

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

Моніторинг реплікації
Один із критичних компонентів Active Directory , за роботою якого необхідно
спостерігати, - це реплікація.
Існують два стандартні засоби адміністрування серверів для моніторингу та
пошуку несправностей реплікації. Перший інструмент – Event Viewer (Засіб перегляду
подій). Журнал подій Directory Service (Служба каталогу) — це один із журналів
реєстрації подій, який додається до всіх контролерів домену. Більшість подій, пов'язаних з
реплікацією каталогу, записується в нього, і це перше місце, яке необхідно переглянути у
разі виникнення збою при реплікації.
Інструмент адміністрування Performance (Продуктивність) корисний для контролю
діяльності, пов'язаної з реплікацією, що відбувається на сервері. Коли сервер
призначається контролером домену, до списку лічильників продуктивності додається
об'єкт NTDS Performance . Лічильники продуктивності можна використовувати для
контролю обсягу трафіку реплікації, а також іншої діяльності, пов'язаної з Active Directory
.
Один із найбільш корисних інструментальних засобів, призначених для
моніторингу та пошуку несправностей реплікації, — це Replication Monitor (Монітор
реплікації). Монітор реплікації контролює один або більше серверів за списком серверів,
що створюється адміністратором, надаючи можливість керувати майже всіма аспектами
реплікації Active Directory – наприклад, відстежувати поточний стан реплікації, останню
успішну реплікацію або будь-які відмови при реплікації; змушувати реплікацію;
змушувати КСР до повторного обчислення топології маршрутизації. Використовуючи цей
інструмент моніторингу, можна контролювати реплікації на всіх контролерах домену
корпоративної мережі.
Другий корисний інструмент моніторингу реплікацій - Repadmin , що входить до
набору Windows Server 2003 Support Tools (Кошти обслуговування Windows Server 2003) і
забезпечує такі ж функціональні можливості, як і Replication Monitor , але через інтерфейс
командного рядка. Інструмент Repadmin додатково дозволяє змінювати топологію
реплікації, додаючи об'єкти зв'язку, та повідомляє про відмови реплікаційних зв'язків між
двома партнерами по реплікації.
Також до складу пакета Windows Server 2003 Support Tools входить інструмент
командного рядка Dcdiag , який може перевіряти DNS-реєстрацію домену контролера. Він
відстежує наявність ідентифікаторів захисту (SID) у заголовках контексту іменування
( naming context ), відповідні дозволи для реплікації, аналізує стан контролерів домену в
лісі чи підприємстві та багато іншого.

Моніторинг служби DNS

У Windows передбачено два способи контролю роботи сервера DNS [4]:
● Запис стандартних подій у журнал сервера DNS. Повідомлення про події
сервера DNS зберігаються в журналі ( log -файлі) сервера окремо від файлів подій,
пов'язаних з іншими програмами. Цей журнал можна переглянути з оснастки Event
Viewer . В нього записується обмежений набір подій, що виявляються службою
DNS, таких як запуск та зупинення сервера. Event Viewer також дозволяє
спостерігати події DNS на комп'ютерах клієнтів: ці події заносяться у файл
журналу на кожному комп'ютері.
● Використання команд налагодження для запису подій у текстовий файл.
Консоль DNS дозволяє встановити додаткові параметри для створення тимчасового
текстового файлу журналу (DNS.log), що зберігається в папці % systemroot %\DNS.
Сервери DNS у Windows підтримують такі налагоджувальні команди:
● Query - записувати запити, отримані від клієнтів;

● Notify — записувати повідомлення, отримані з інших серверів DNS;

● Update — записувати зміни зони, отримані з інших комп'ютерів;

● Questions - записувати вміст розділу питання для кожного запиту,

обробленого сервером DNS;
● Answers — записувати вміст розділу відповіді кожного запиту, обробленого
сервером DNS;
● Send - підраховувати запити, надіслані сервером DNS;
 ● Received – підраховувати запити, отримані сервером DNS;

● UDP - підраховувати запити, отримані за протоколом UDP;

● TCP - підраховувати запити, отримані за протоколом TCP;

● Full Packets - підраховувати повні пакети, отримані та записані сервером

DNS;
● Write Through – підраховувати пакети, що пройшли через сервер DNS туди
та назад.

За замовчуванням всі ці додаткові можливості налагодження вимкнено. Після

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

Автоматизація моніторингу Active Directory

Active Directory у процесі своєї роботи постійно займається самодіагностикою.
Частина збоїв Active Directory вміє виправляти самостійно, але деякі дії вимагають
кваліфікованого персоналу. Вкрай важливо своєчасно помітити такий збій і вжити
коригуючих дій.
Для цього поряд фірм розроблено спеціальне програмне забезпечення, що дозволяє
в реальному часі відстежувати роботу Active Directory та надає адміністратору
розширений набір інструментів для діагностики та усунення проблем.
Компанія Microsoft також випустила на ринок своє рішення під назвою Microsoft
Operations Manager ( MOM 2005, MSCOM 2007). Можливості цього продукту дозволяють
контролювати абсолютну більшість ключових параметрів Active Directory [6]:
● AD DIT/Log Free Space.

● All Performance Data.

● Database and Log Overview.

● Database Size.

● DC OS Metrics Overview.

● DC Response Time.

● DC/Gc Response.

● GC Response Time.

● Log File Size.

● LSASS Processor Time.

● Memory metrics.

● Intersite Replication Traffic.

 ● Replication Alerts останні 7 днів.

● Replication Inbound Bytes/sec.

● Replication Latency.

● Replication Performance Overview.

У MOM є вбудований механізм оповіщення адміністраторів про проблеми, що

виникли, а також можливість будувати цільові звіти для виявлення вузьких місць системи
та небезпечних тенденцій, що дозволяє запобігти збою ще до того, як він виникне і
ситуація стане критичною. MOM включає управління подіями, моніторинг служб та
попереджень, генерацію звітів та аналіз тенденцій. Це робиться через центральний пульт:
агенти, що виконуються на керованих вузлах (серверах, що є об'єктами моніторингу),
надсилають дані, які будуть проаналізовані, відстежені та відображені на єдиному пульті
управління. Ця централізація дає можливість мережному адміністратору керувати
великою сукупністю серверів з одного місця за допомогою потужних інструментів,
призначених для дистанційного керування серверами. Системи MOM використовують
пакети керування для розширення базової інформації щодо певних мережевих послуг, а
також серверних додатків. Пакет управління Base Management Pack містить
характеристики всіх служб сервера Windows Server 2003, включаючи Active Directory ,
службу доменних імен (DNS) та Інтернет-службу Microsoft Internet Information Services
(IIS). Пакет керування Application Management Pack включає характеристики серверів
Microsoft .NET Enterprise Servers , таких як Microsoft Exchange 2000 Server та Microsoft
SQL Server 2000.
У великих компаніях, які мають відповідні достатні ресурси, рекомендується
впроваджувати цей комплекс моніторингу (або аналогічні системи) вже на ранніх стадіях
розгортання Active Directory .

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

Переваги, які можна отримувати від моніторингу Active Directory :

● Здатність підтримувати SLA-угоду з користувачами, уникаючи простою служби.

● Досягнення високої продуктивності служби шляхом усунення «вузьких місць» у

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

За всіх зазначених переваг моніторинг Active Directory пов'язані з витратами, які

необхідні його ефективної реализации:
● Для проектування, розгортання та управління системою моніторингу потрібні
відповідні людські ресурси (людина-годинник), які вимагають оплати.
● На придбання необхідних засобів управління, навчання та на апаратні засоби, які
призначені для реалізації моніторингу, потрібні певні фонди.
● Частина пропускної спроможності мережі буде задіяна для моніторингу Active
Directory на всіх контролерах домену підприємства.
● Для виконання додатків-агентів на цільових серверах і комп'ютері, що є
центральним пультом моніторингу, використовуються пам'ять і ресурси процесора.

Схема процесу моніторингу служби Active Directory високого рівня:

1. Визначити, який із індикаторів функціонування служби слід відстежувати.
2. Здійснити моніторинг індикаторів функціонування служби, щоб встановити та
задокументувати базовий (нормальний) рівень.
3. Визначити пороги цих індикаторів функціонування,
4. Спроектувати необхідну аварійну систему, призначену для обробки подій під час
досягнення порогового рівня.
5. Спроектувати систему створення звіту, що фіксує історію стану Active Directory .
6. Реалізувати рішення, яке вимірюватиме вибрані ключові індикатори відповідно до
розкладу, що відображає зміни даних індикаторів та їх вплив на стан Active Directory .

При проектуванні моніторингу рекомендується планувати нагляд за такими

елементами:
● Продуктивність служб Active Directory .

● Реплікація Active Directory.

● Функціонування служби DNS та стан DNS-сервера.

● Сховище Active Directory.

● Служба реплікації файлів.

● "Здоров'я" системи контролера домену.

● "Здоров'я" лісу.

● Господарі операцій.

Автоматизація моніторингу Active Directory можлива за допомогою комплексу

Microsoft Operations Manager ( MOM 2005, MSCOM 2007) та його аналогів.
Лекція 14. Усунення неполадок з ACTIVE DIRECTORY
Коротка інструкція: Описано типові проблеми при функціонуванні Active Directory ,
включаючи помилки реплікації, неполадки з DNS та схемою, проблеми при заданні
дозволів та відомостей про довіру. Наведено можливі варіанти вирішення цих проблем.
Ключові слова : об'єкт, домен, контролер домену, господар схеми, господар іменування
доменів, господар RID , емулятор основного контролера домену, господар
інфраструктури, сервер глобального каталогу, реплікація, сайт, зв'язок сайту, DNS , ліс,
довірчі відносини, обліковий запис.

Ціль лекції
Дати уявлення про можливі проблеми з Active Directory та способи їх усунення.

У разі виникнення неполадок у роботі Active Directory необхідно спочатку

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

Типові проблеми з Active Directory

Перелічимо деякі типові проблеми з Active Directory , з якими можна зіткнутися, та
їх можливі рішення [4], [5].
● Неможливо додати або видалити домен. Можлива причина: власник іменування
доменів недоступний, що може бути викликано проблемами з мережевим
з'єднанням чи відмовою комп'ютера, що грає роль власника іменування доменів.
Пропоноване рішення: вирішити проблему з мережевим з'єднанням, або
полагодити/замінити комп'ютер, що грає роль господаря іменування доменів, або
перепризначити роль господаря іменування доменів.
● Неможливо створити об'єкти в Active Directory . Можлива причина:
недоступний майстер відносних ідентифікаторів, що може бути викликано
проблемами з мережевим з'єднанням або відмовою комп'ютера, що відіграє роль
майстра відносних ідентифікаторів. Пропоноване рішення: вирішити проблему з
мережевим з'єднанням, або полагодити/замінити комп'ютер, що грає роль майстра
відносних ідентифікаторів, або перепризначити роль майстра відносних
ідентифікаторів.
● Зміни членства групи не набирають чинності. Можлива причина: недоступний
господар інфраструктури, що може бути викликано проблемами з мережевим
з'єднанням або відмовою комп'ютера, що відіграє роль господаря інфраструктури.
Пропоноване рішення: вирішити проблему з мережевим з'єднанням, або
полагодити/замінити комп'ютер, що грає роль господаря інфраструктури, або
перепризначити роль господаря інфраструктури.
● Користувачі без програмного забезпечення Active Directory не можуть увійти
до системи. Можлива причина: Емулятор основного контролера домену
недоступний, що може бути викликано проблемами з мережевим з'єднанням або
відмовою комп'ютера, що відіграє роль емулятора основного контролера домену.
Пропоноване рішення: вирішити проблему з мережевим з'єднанням, або
 полагодити/замінити комп'ютер, що відіграє роль емулятора основного контролера
домену, або перепризначити роль емулятора основного контролера домену.
● Користувачеві не вдається локально увійти до системи на контролері домену.
Можлива причина: можливість локального входу до системи контролера домену
управляється політиками безпеки, які встановлюються в параметрах групової
політики. Пропоноване рішення: у об'єкті «Політика контролера домену», що
використовується за умовчанням, призначити певному користувачеві або групі
право «Локальний вхід до системи».
● Не вдається підключитися до контролера домену, який працює під керуванням
Windows 2000. Можлива причина: на контролері домену під керуванням Windows
2000, до якого здійснюється підключення, не встановлено пакет оновлень версії 3
або пізнішої. Пропоноване рішення: встановити на контролер домену під
керуванням Windows 2000 пакет оновлень версії 3 або пізнішої.
● Повідомлення про помилки "Домен не знайдено", "Сервер недоступний" або
"Сервер RPC недоступний". Можлива причина: помилка реєстрації або дозволу
імені. Пропоноване рішення: перевірити доступність та правильність роботи
служби DNS (у тому числі реєстрацію NetBIOS ) на відповідному сервері.

Помилки реплікації
Неефективна реплікація викликає падіння продуктивності служби Active Directory ,
наприклад, можуть не розпізнавати нові користувачі. Найчастіше внаслідок неефективної
обробки запитів та неефективної реплікації інформація каталогу застаріває, а контролери
домену стають недоступними.
Журнал служби каталогу повідомляє про помилки реплікації, які відбуваються
після встановлення реплікаційного зв'язку. Потрібно переглядати журнал реєстрації подій
служби каталогу в пошуках подій реплікації, які мають тип Error (Помилка) або Warning
(Попередження).
Далі наведено два приклади типових помилок реплікації у тому вигляді, як вони
відображені в журналі реєстрації подій служби каталогу [13].
● Подія з ID 1311. Інформація про конфігурацію реплікації в інструменті Active
Directory Sites And Services (Сайти та служби Active Directory ), не відображає
точно фізичну топологію мережі. Ця помилка вказує на те, що один або більше
контролерів домену або сервер-плацдарм знаходяться в автономному режимі (або
відключені), або що сервери-плацдарми підключені, але не містять потрібних
контекстів іменування (NC) або при реплікації необхідного контексту
найменування між сайтами Active Directory виникають помилки. Також можлива
причина цієї помилки полягає в тому, що один або кілька вузлів не включені у
зв'язку сайтів або зв'язку сайтів містять усі сайти, але не всі зв'язки сайтів, що
взаємодіють між собою.
● Подія з ID 1265 ( Access denied - Доступ заборонено). Ця помилка може виникати
в тому випадку, якщо локальний контролер домену не зміг підтвердити
справжність свого партнера щодо реплікації при створенні реплікаційного зв'язку
або при спробі реплікувати існуючий зв'язок. Помилка виникає тоді, коли
контролер домену був від'єднаний від решти мережі протягом тривалого часу і
його пароль облікового запису комп'ютера не синхронізовано з паролем облікового
запису комп'ютера, що зберігається в каталозі його реплікаційного партнера.
 Якщо отримано повідомлення про подію з ID 1265 та помилку «Помилка пошуку в
DNS» або про помилку «RPC-сервер недоступний» у журналі служби каталогів, можлива
причина свідчить про проблеми DNS.
Реплікація Active Directory залежить від наступних факторів:
● Записи повинні реплікуватися на сервери DNS, які використовуються партнерами
реплікації.
● Кожна зона DNS повинна мати потрібне делегування дочірніх зон.

● В ІР-конфігурації контролерів доменів повинні бути правильно задані основні та

альтернативні DNS-сервери.

Як правило, проблеми, які можна усунути засобами консолі Active Directory Sites
and Services , такі [4]:
● нова інформація каталогу не поширюється своєчасно;

● запити обслуговування не обробляються вчасно.

Далі наведено деякі типові помилки реплікації та способи їх усунення [4]-[6].

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

Таблиця 14.1. Причини та рішення при уповільненні реплікації

Можлива причина
Хоча всі сайти пов'язані зв'язками, існуюча
структура міжсайтової реплікації
недостатньо повна. Інформація каталогу
реплікується на всі контролери домену,
якщо вони об'єднані зв'язками, але це не є
оптимальним рішенням. За наявності
зв'язків сайтів та відсутності мостів
поширення змін з одних контролерів
доменів на інші, з якими відсутні прямі
зв'язки, виконується надто довго
Поточних мережевих ресурсів недостатньо
обслуговування сумарного трафіку
реплікації. Така ситуація може вплинути на
служби, які не стосуються Active Directory ,
оскільки обмін інформацією каталогу
потребує значних мережевих ресурсів
Пропоноване рішення
Необхідно переконатися, що служба Active
Directory настроєно правильно. Для
об'єднання кількох зв'язків сайтів, що
вимагають більш ефективної реплікації,
рекомендується створити міст або об'єднати
у міст усі зв'язки сайтів
Збільшити частку вільних мережевих
ресурсів, що виділяються трафіку каталогу.
Зменшити частоту реплікації у розкладі.
Налаштувати вартість зв'язків сайтів.
Створити зв'язки сайтів або мости зв'язків
сайтів, щоб отримати підключення до
мережі з підвищеною пропускною
 Можлива причина
Інформація каталогу, що змінилася на
контролерах домену в одному сайті,
своєчасно не оновилася на контролерах
домену в інших сайтах, оскільки задана в
розкладі частота міжсайтової реплікації
дуже низька
Клієнти намагаються запитати
автентифікацію, інформацію та служби у
контролера домену з підключення з
низькою пропускною здатністю. Це може
сповільнити відповідь на запити клієнтів.
Пропоноване рішення
здатністю
Збільшити частоту реплікації. Якщо
реплікація виконується через міст,
перевірити, який сайт стримує реплікацію.
Збільшити інтервал часу, відведений для
реплікації, або частоту реплікації заданий
інтервал часу для проблемного зв'язку
сайтів.
Перевірити, чи є сайт, який може краще
обслуговувати підсіти клієнта. Якщо клієнт,
що повільно обслуговується, ізольований
від контролера домену, спробувати
створити інший сайт з власним
контролером домену, до якого потім
приєднати клієнта. Створити підключення з
більшою пропускною здатністю.

● При спробі реплікації вручну отримано повідомлення «Відмовлено у доступі»

від оснастки Active Directory Sites And Services (Сайти та служби Active
Directory ). Можлива причина: примусова реплікація, що виконується
користувачем вручну, тягне за собою реплікацію не всіх загальних каталогів
додатків партнерів реплікації, а можлива тільки для тих контейнерів, для яких
дозволено синхронізувати реплікацію, при цьому реплікація інших каталогів
додатків дасть збій. Пропоноване рішення: для примусової реплікації вручну
вказаного каталогу програм використовувати засоби командного рядка Repadmin із
набору інструментів підтримки Windows .
● Не вдається підключитися до контролера домену під керуванням Windows 2000
за допомогою оснастки Active Directory Sites And Services (Сайти та служби
Active Directory ). Можлива причина: на контролері домену, який працює під
керуванням Windows 2000 і до якого потрібно підключитися, не інстальовано пакет
оновлень версії 3 або пізніший. Пропоноване рішення: встановити на контролер
домену під керуванням Windows 2000 пакет оновлень версії 3 або пізніший.

Перевірка топології реплікації полягає в тому, що Active Directory запускає процес,

який визначає вартість міжсайтових підключень, перевіряє доступність відомих
контролерів домену та факт додавання нових. На основі отриманих відомостей Active
Directory додає або видаляє об'єкти підключення для формування ефективної топології
реплікації. Цей процес не торкається об'єктів-підключень, створених вручну за допомогою
інструмента Active Directory Sites and Служби .

Усунення несправностей DNS

Наведемо деякі можливі проблеми DNS і способи їх вирішення [4], [6].
● Переривання делегування зони. Можлива причина: делегування зони неправильно
налаштовано. Пропоноване рішення: перевірити параметри делегування зони та
виправити конфігурацію, якщо це необхідно.
● Проблеми, пов'язані із зонною передачею. Можливі причини та запропоновані
рішення наведено у таблиці 14.2.
 Таблиця 14.2. Причини та рішення при неполадках, пов'язаних із зонною передачею
Можлива причина
Призупинення служби DNS
на сервері
Розрив зв'язку через мережу
між серверами DNS, що
використовуються в процесі
зонної передачі
Серійні номери зони на
сервері-одержувачі та сервері- DNS) для сервера-джерела, щоб він перевищив серійний
джерелі збігаються, що
перешкоджає передачі
Виникають проблеми при
взаємодії сервера-джерела та
сервера-отримувача
Зона містить записи ресурсів
та інші дані, які сервер DNS
не може правильно
інтерпретувати
Дані повноважної зони
некоректні
● Проблеми динамічного оновлення. Можливі причини та запропоновані рішення
наведено у таблиці 14.3.
Таблиця 14.3. Причини та рішення при неполадках динамічного оновлення
Можлива причина
Клієнт (або сервер DHCP) не
підтримує протокол
динамічного оновлення DNS
Клієнт не зміг зареєструватися
на сервері DNS для динамічного
оновлення через неповну
конфігурацію DNS
Клієнт DNS не зміг оновити
інформацію з сервера DNS
через проблеми на сервері
Пропоноване рішення
Необхідно переконатися, що всі сервери, що
використовуються в процесі передачі, доступні та служби
DNS на них не призупинені
Перевірити (використовуючи команду PING) із двох
сторін наявність мережного каналу між двома серверами
DNS. У разі невдачі одного з двох тестів необхідно
шукати причину безпосередньо у мережі
Збільшити серійний номер (використовуючи консоль
номер сервера-отримувача, після чого ініціювати
передачу зони на сервері-отримувачі
Перевірити, чи не встановлена на одному із серверів
стара версія DNS (наприклад, версія BIND)
Необхідно переконатися, що зона не містить несумісних
типів даних (наприклад, записів ресурсів
непідтримуваних типів) та помилок. Вказати в
конфігурації сервера припинення завантаження
некоректних даних та визначити метод перевірки імен (ці
параметри задаються в консолі DNS)
Якщо при передачі зони постійно відбуваються помилки,
необхідно переконатися, що зона не містить
нестандартних даних. Щоб визначити можливе джерело
помилок, потрібно переглянути повідомлення в журналі
DNS
Пропоноване рішення
Необхідно переконатися, що користувачі підтримують
протокол динамічного оновлення та увімкнені опції
динамічної підтримки. Щоб зареєструвати комп'ютери
клієнтів для динамічного оновлення, рекомендується
встановити на них Windows 2000 або встановити в
мережі DHCP сервер для обслуговування клієнтів
Необхідно переконатися, що клієнт правильно
налаштований, і при необхідності оновити
конфігурацію. Для оновлення конфігурації клієнтів
потрібно встановити первинний суфікс «DNS» на
комп'ютері клієнта з постійною IP-адресою або задати
залежний від з'єднання суфікс «DNS» на одному з
мережевих підключень клієнта
Якщо клієнт може звертатися до свого основного та
альтернативних серверів DNS, зазначених у його
конфігурації, це означає, що джерело проблеми не в
комп'ютері клієнта. На клієнтах під керуванням
Windows 2000 рекомендується використовувати Event
 Можлива причина
Сервер DNS не підтримує
динамічні оновлення
Сервер DNS здатний
підтримувати динамічне
оновлення, але не робить цього
База даних зони недоступна
Пропоноване рішення
Viewer для перегляду системного log -файлу та
визначення причин невдач під час оновлення записів
ресурсів вузлів та покажчиків
Необхідно переконатися, що DNS-сервер, до якого
звертається клієнт, здатний підтримувати протокол
динамічного оновлення
Необхідно переконатися, що основна зона, звідки
клієнти отримують зміни, налаштована на їхню
підтримку. За промовчанням сервер DNS з Windows
2000 для основної зони не підтримує динамічні
оновлення. Потрібно відредагувати властивості зони на
основному сервері DNS, якщо це необхідно
Необхідно переконатися, що зона існує та доступна для
змін. Для основних серверів DNS потрібно перевірити,
чи файл зони на сервері існує і зона не призупинена.
Додаткові сервери не підтримують динамічного
оновлення. Для зони, інтегрованої в Active Directory ,
сервер DNS повинен бути контролером домену і мати
доступ до бази даних Active Directory , де зберігається
файл зони

Усунення несправностей схеми

Далі наведено деякі типові неполадки схеми Active Directory та способи їх
усунення [5].
● Неможливо змінити чи розширити схему. Можливі причини та запропоновані
рішення наведено у таблиці 14.4.

Таблиця 14.4. Причини та рішення при неможливості змінити схему

Можлива причина
Господар схеми недоступний, що може
бути викликано проблемами з мережевим
з'єднанням або відмовою комп'ютера, що
відіграє роль власника схеми.
Користувач, який намагається змінити
схему, не входить до групи
«Адміністратори схеми»
Контролер домену, що є господарем схеми,
працює під керуванням Windows 2000, і на
ньому не дозволено зміну схеми
Пропоноване рішення
Вирішити проблему з мережевим
з'єднанням, або полагодити/замінити
комп'ютер, що грає роль господаря схеми,
або перепризначити роль господаря схеми
Додати відповідний обліковий запис
користувача до групи «Адміністратори
схеми»
Дозволити зміну схеми на цьому контролері
домену

● Неможливо додати атрибути до класу. Можливі причини та запропоновані

рішення наведено у таблиці 14.5.

Таблиця 14.5. Причини та рішення при неможливості додати атрибути до класу

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

● Неможливо знайти або запустити оснастку «Схема Active Directory ».

Можлива причина: Оснащення «Схема Active Directory » не встановлена або не
зареєстрована. Пропоноване рішення: встановити та/або зареєструвати оснастку
«Схема Active Directory » [6].
● Не вдається підключитися до контролера домену, який працює під керуванням
Windows 2000, за допомогою оснастки «Схема Active Directory ». Можлива
причина: на контролері домену під керуванням Windows 2000, до якого
здійснюється підключення, не встановлений пакет оновлень версії 3 або пізнішої.
Пропоноване рішення: встановити на контролер домену під керуванням Windows
2000 пакет оновлень версії 3 або пізнішої.

Усунення несправностей у відомостях про довіру

Далі наведено деякі типові неполадки у відомостях про довіру Active Directory та
способи їх усунення [5].
● Клієнти не можуть звернутися до ресурсів в іншому домені. Можлива причина:
розрив довірчих відносин між доменами. Пропоноване рішення: відновити та
перевірити довірчі відносини між доменами; Для успішного відновлення довіри
знадобиться емулятор основного контролера домену (емулятор PDC), який має
бути доступний.
● Клієнтам не вдається отримати доступ до ресурсів домену поза лісом.
Можлива причина: стався збій зовнішньої довіри між доменами. Пропоноване
рішення: відновити та перевірити довірчі відносини між доменами; Для успішного
відновлення довіри знадобиться емулятор основного контролера домену (емулятор
PDC), який має бути доступний.
● Помилки довіри між серверами чи робочими станціями. Можлива причина: час
синхронізації між контролерами домену чи робочими станціями невірно, сервер
перебуває у неробочому стані чи порушено довірче ставлення. Пропоноване
рішення: здійснити перевірку та встановлення довірчих відносин між
комп'ютерами, за необхідності в режимі пакетного керування довірами, а також
забезпечити захист каналів між комп'ютерами.

Проблеми при заданні дозволів

При призначенні або зміні дозволів NTFS на доступ до файлів/папок іноді
виникають проблеми, які важливо вчасно усунути. Далі описані деякі типові проблеми з
дозволами, а також способи їх усунення [4].
● Користувач не може отримати доступ до файлу або папки. Якщо файл або
папка були скопійовані або переміщені на інший том NTFS , дозволи могли
змінитися. Необхідно перевірити дозволи, призначені для облікового запису
користувача та груп, членом яких він є. Наприклад, іноді користувач не має
дозволу або доступу для нього заборонено в індивідуальному порядку або як члену
групи.
 ● Обліковий запис користувача додано до групи, щоб надати цьому
користувачеві доступ до файлу або папки, але він не може отримати доступ.
Щоб увійти до нової групи, до якої додано обліковий запис, користувач повинен
або вийти з системи і потім увійти до неї повторно, або закрити всі мережеві
підключення до комп'ютера, на якому розміщено файл або папку, а потім створити
нове підключення.
● Користувач із роздільною здатністю Full Control для папки видаляє файл у
папці, хоча немає дозволу видаляти цей файл. Необхідно запобігти подальшому
видаленню користувачем файлів. Необхідно скасувати спеціальну роздільну
здатність для папки, щоб позбавити користувача з роздільною здатністю Full
Control права видаляти файли у цій папці.

Далі наведено рекомендації щодо впровадження дозволів NTFS, які допоможуть

уникнути можливих проблем [4].
● Рекомендується призначати найсуворіші дозволи NTFS, що дозволяють
користувачам та групам виконувати лише необхідні завдання.
● Рекомендується призначати всі дозволи лише на рівні папок, а не на рівні файлів.
Необхідно згрупувати файли, доступ до яких потрібно обмежити, в окрему папку
та обмежити доступ до неї.
● Для всіх файлів програм, що виконуються, рекомендується призначити групі
Administrators (Адміністратори) дозволи Read & Execute і Change Permissions , а
групі Users (Користувачі) — роздільна здатність Read & Execute . Пошкодження
файлів програм зазвичай є результатом діяльності вірусів та несанкціонованих дій.
Призначивши ці дозволи, можна запобігти зміні або видаленню виконуваних
файлів.
● Рекомендується призначити групі CREATOR OWNER (Творець-власник) дозвіл
Full Control для спільних папок даних, щоб користувачі могли видаляти та
змінювати створені ними файли/папки. Дана роздільна здатність надає
користувачеві, який створив файл/папку, повний доступ до спільної папки даних
лише до файлів/папок, створених безпосередньо ним.
● Для спільних папок CREATOR OWNER рекомендується призначити роздільну
здатність Full Control , а групі Everyone – дозвіл Read and Write . Користувачі
отримають повний доступ до створених ними файлів, однак члени групи Everyone
(Всі) зможуть лише зчитувати та додавати файли до каталогу.
● Якщо до ресурсу не звертатись по мережі, рекомендується використовувати довгі і
докладні імена. Якщо планується відкрити спільний доступ до папки, імена
папок/файлів повинні підтримуватися всіма клієнтськими комп'ютерами.
● Рекомендується призначати, але не скасувати дозволи. Якщо потрібно, щоб
користувач або група не мали доступу до конкретної папки або файлу,
рекомендується не призначати відповідну роздільну здатність. Скасування дозволів
має бути винятком, а не звичайною практикою.

Короткі підсумки
Деякі типові проблеми з Active Directory , з якими можна зіткнутися:
● Неможливо додати або видалити домен.

● Неможливо створити об'єкти в Active Directory .

● Зміни членства групи не набирають чинності.

● Користувачі без програмного забезпечення Active Directory не можуть увійти до

системи.
● Користувачеві не вдається локально увійти до системи на контролері домену.

● Не вдається підключитися до контролера домену, який працює під керуванням

Windows 2000.
● Повідомлення про помилку "Домен не знайдено", "Сервер недоступний" або
"Сервер RPC недоступний".

Деякі типові помилки реплікації:

● Будь-яка відмова у реплікації між контролерами домену.

● Реплікація інформації каталогу припинилась.

● Реплікація інформації каталогу сповільнилася, але не зупинилась.

● При спробі реплікації вручну отримано повідомлення "Відмовлено у доступі".

● Не вдається підключитися до контролера домену під керуванням Windows 2000 за

допомогою оснастки Active Directory Sites And Services (Сайти та служби Active
Directory ).

Деякі можливі проблеми DNS:

● Переривання делегування зони.

● Проблеми, пов'язані із зонною передачею.

● Проблеми динамічного оновлення.

Деякі типові проблеми схеми Active Directory :

● Неможливо змінити чи розширити схему.

● Неможливо додати атрибути до класу.

● Неможливо знайти або запустити оснастку «Схема Active Directory ».

● Не вдається підключитися до контролера домену, який працює під керуванням

Windows 2000, за допомогою оснастки «Схема Active Directory ».

Деякі типові неполадки у відомостях про довіру Active Directory :

● Клієнти не можуть звернутися до ресурсів в іншому домені.

● Клієнтам не вдається отримати доступ до ресурсів домену поза лісом.

● Помилки довіри між серверами чи робочими станціями.

Деякі типові проблеми з дозволами:

● Користувач не може отримати доступ до файлу або папки.

● Обліковий запис користувача додано до групи, щоб надати цьому користувачеві

доступ до файлу або папки, але він не може отримати доступ.
● Користувач із роздільною здатністю Full Control для папки видаляє файл у папці,
хоча немає дозволу видаляти цей файл.
Лекція 15. ВІДНОВЛЕННЯ ACTIVE DIRECTORY
Короткий анотація: Даний короткий огляд процесу відновлення Active Directory , у тому
числі описані попередні дії під час підготовки до відмов.
Ключові слова : контролер домену, резервне копіювання, реплікація, організаційна
одиниця.

Ціль лекції
Вказати на необхідність спланувати підготовку до відмов для можливості
відновлення Active Directory .

Служба каталогу Active Directory – це найбільш критична мережна служба, яка

розгорнута у мережі. Якщо інфраструктура Active Directory буде невдалою, користувачі
мережі будуть надзвичайно обмежені у своїй роботі у мережі. Майже всі мережі в
Microsoft Windows Server 2003 виконують автентифікацію користувачів Active Directory ,
перш ніж вони отримають доступ до будь-якого мережного ресурсу. Тому треба
заздалегідь приготуватися до запобігання відмовам та відновленню служби.

Підготовка до відмовимо
Перші кроки у відновленні системи після відмови виконуються набагато раніше,
ніж станеться сама відмова.
Підготовка включає перегляд усіх елементів, що становлять нормальну мережеву
інфраструктуру, а також деякі специфічні для Active Directory речі.
Наведені нижче процедури є критично важливими [13].
● Розробити послідовне створення резервної копії та відновити управління
контролерів домену. Перший крок у будь-якому плані відновлення полягає у
встановленні відповідних апаратних засобів та програмного забезпечення для
підтримки створення резервних копій контролерів домену; після цього
рекомендується створити та протестувати план резервування та відновлення.
● Розгорнути контролери домену Active Directory з апаратною надмірністю.
Більшість серверів можна замовляти з деяким рівнем апаратної надмірності за
невеликої додаткової вартості. Наприклад, сервер з подвійним джерелом живлення,
надмірними мережевими картками та надмірною апаратною системою жорсткого
диска має бути стандартним обладнанням для контролерів домену. У багатьох
великих компаніях апаратна надмірність піднята на такий рівень, коли всі
контролери домену пов'язані з різними ланцюгами живлення та підключені до
різних комутаторів Ethernet або мережевих сегментів.

Зберігання даних у Active Directory

База даних Active Directory зберігається у файлі на ім'я Ntds.dit , який за
умовчанням розташований у папці % systemroot %\ NTDS , що містить також такі файли
[13]:
● Edb . chk — файл контрольних точок, який вказує на те, які транзакції з журналів
реєстрації були записані в базу даних Active Directory ;
● Edb . log - журнал реєстрації поточних транзакцій, що має фіксовану довжину 10
Мб;
 ● Edbxxxxx . log . Після того, як Active Directory пропрацювала деякий час, можуть
з'явитися один або більше журналів, у яких частина імені файлу, позначена як
ххххх , являє собою шістнадцятковий порядковий номер, що збільшується. Ці
журнали є попередніми журналами; щоразу, коли поточний журнал заповнений,
він перейменовується на наступний попередній журнал, і створюється новий
журнал Edb . log . Старі журнали автоматично видаляються у міру того, як зміни,
представлені в журналах, переносяться до бази даних Active Directory . Кожен із
цих журналів займає 10 Мб;
● Edbtemp . log — тимчасовий журнал, який використовується тоді, коли заповнений
поточний журнал ( Edb . log ). Новий журнал створюється під ім'ям Edbtemp.log, у
ньому зберігаються всі транзакції, а потім журнал Edb.log перейменовується на
наступний попередній журнал. Далі журнал Edbtemp.log перейменовується на
журнал Edb.log;
● Res1.log та Res2.log — резервні журнали, які використовуються лише в ситуації,
коли на жорсткому диску закінчується вільний простір. Якщо поточний журнал
заповнений, а сервер не може створити новий журнал, тому що на жорсткому
диску немає вільного простору, сервер придушить будь-які транзакції Active
Directory , що знаходяться в пам'яті, використовує місце для резервних журналів, а
потім завершить роботу Active Directory . Розмір кожного з цих журналів – 10 Мб.

Кожна модифікація у базі даних Active Directory називається транзакцією.

Транзакція може складатися з кількох кроків. Наприклад, коли користувач переміщається
з однієї організаційної одиниці (OU) в іншу, в OU-адресаті повинен бути створений новий
об'єкт, а в OU-джерелі видалено старий об'єкт. Щоб транзакція була закінчена, обидва
кроки мають бути виконані; якщо один із кроків зазнає невдачі, вся транзакція має
отримати відкат, щоб ніякий крок не було зараховано. Коли всі кроки у транзакції
виконано, транзакція вважається закінченою. Використовуючи модель транзакцій,
Windows Server 2003 гарантує, що база даних завжди залишається у погодженому стані.
Щоразу, коли в базі даних Active Directory робиться якась зміна (наприклад,
змінюється номер телефону користувача), вона спочатку записується до журналу
транзакцій. Оскільки журнал транзакцій є текстовим файлом, у якому зміни записуються
послідовно, запис до журналу відбувається набагато швидше, ніж запис до бази даних.
Тому використання журналів транзакцій покращує роботу контролера домену.
Як тільки транзакція була записана в журнал транзакцій, контролер домену
завантажує сторінку бази даних, що містить об'єкт користувача, в пам'ять (якщо вона ще
не знаходиться в пам'яті). Усі зміни в базі даних Active Directory робляться в пам'яті
контролера домену. Контролер домену використовує максимально доступний обсяг
пам'яті та зберігає в пам'яті максимально велику частину бази даних Active Directory .
Контролер домену видаляє сторінки бази даних із пам'яті лише тоді, коли вільна пам'ять
стає обмеженою або коли контролер домену вимикається. Зміни, зроблені до сторінок
бази даних, переписуються до бази даних лише тоді, коли сервер мало використовується
або при вимкненні.
Журнали транзакцій не тільки покращують роботу контролера домену,
забезпечуючи місце для швидкого запису змін, але й забезпечують можливість
відновлення даних у разі відмови сервера. Наприклад, якщо було зроблено зміну, що
стосується Active Directory , воно записується в журнал транзакцій, а потім на сторінку
бази даних, що знаходиться в пам'яті сервера. Якщо сервер несподівано вимикається, то
зміни не будуть передані з пам'яті сервера в базу даних. Коли контролер домену буде
перезапущено, він знайде в журналі всі транзакції, які ще не були передані до бази даних.
Потім ці зміни застосовуються до бази даних під час запуску служб контролера домену. У
процесі відновлення використовується файл контрольної точки. Файл контрольної точки є
вказівником на те, які транзакції з журналу були переписані в базу даних. У процесі
відновлення контролер домену читає файл контрольної точки, визначаючи, які транзакції
були передані до бази даних, а потім він додає до бази даних зміни, які ще не були
передані. Використання журналів транзакцій покращує роботу контролерів домену та
збільшує можливість відновлення даних у разі несподіваного вимкнення сервера. Ці
переваги максимальні, якщо журнал транзакцій та база даних розташовані на окремих
жорстких дисках.
Служба Active Directory Windows Server 2003 налаштована для циркулярної
( circular ) реєстрації, і ця конфігурація не може бути змінена. При циркулярній реєстрації
зберігаються лише попередні журнали, містять транзакції, які були переписані до бази
даних. У міру передачі інформації з попереднього журналу базу даних журнал
видаляється. Циркулярна реєстрація запобігає втраті даних у разі збою на жорсткому
диску контролера домену, коли відновлюватиметься база даних із резервної копії.
Припустимо, що виконується резервне копіювання Active Directory щоночі, але жорсткий
диск контролера домену зламався о 17:00, після того, як було зроблено кілька сотень змін
у базі даних протягом дня. У міру виконання змін попередні журнали транзакцій
видалялися, оскільки інформація з них передавалася до бази даних Active Directory . Коли
буде відновлено базу даних до стану, який відповідає резервній копії попередньої ночі, всі
зміни, які були зроблені протягом дня, будуть втрачені. Єдиний спосіб запобігти цій
втраті даних полягає у розгортанні принаймні двох контролерів домену, які реплікують
інформацію один одному протягом дня. Якщо буде збій на одному з контролерів домену,
можна буде відновити на ньому базу даних з резервної копії, а всі зміни, зроблені
протягом дня, будуть скопійовані на відновлений сервер.

Створення резервної копії Active Directory

Найважливіше з обмежень, що накладаються створення резервної копії служби
каталогу, у тому, що Active Directory може копіюватися лише як частина даних
системного стану контролера домену.
Дані системного стану контролера домену включають [13]:
● базу даних Active Directory та журнали транзакцій;

● системні файли та файли запуску, що знаходяться під захистом Windows ;

● системний реєстр контролера домену;

● всю зонну інформацію DNS, інтегровану з Active Directory ;

● папку Sysvol ;

● базу даних реєстрації класів СОМ+;

● базу даних служби сертифікатів (якщо контролер домену є сервером служби

сертифікатів);
● інформацію кластерної служби;

● метакаталоги інформаційної Інтернет-служби Microsoft (IIS) (якщо служба IIS

інстальовано на комп'ютері).

Всі ці компоненти повинні копіюватися та відновлюватися повністю через їх тісну

інтеграцію. Наприклад, якщо на сервері служби сертифікатів було створено сертифікат,
призначений для об'єкта Active Directory , то база даних служби сертифікатів (що містить
запис про створення об'єкта) та об'єкт Active Directory (який містить запис про те, що
сертифікат призначений на об'єкт) повинні бути збережені.
Програми резервного копіювання можуть робити різні типи резервних копій,
включаючи нормальні, додаткові, диференційовані і т. д. Резервне копіювання системного
стану контролера домену завжди є нормальним копіюванням, коли всі файли, що
відносяться до System State (Стан системи), копіюються та відзначаються як копіювані.
Загальна практика у тому, що це контролери домену повинні брати участь у циклі
регулярного резервного копіювання. Один виняток до цього правила можна зробити, якщо
є кілька контролерів домену, які розташовані в одному офісі. В цьому випадку можна
здійснювати таку процедуру відновлення контролерів домену, в якій спочатку буде
встановлюватися новий контролер домену, а потім заповнювати його каталог шляхом
реплікації. Однак навіть у цьому сценарії слід створювати резервні копії принаймні
деяких контролерів домену на випадок такої аварії, коли будуть виведені з ладу всі
контролери домену в офісі. У будь-якому разі необхідно створити резервні копії
господаря операцій.
Інша проблема, яку потрібно розглянути через резервне копіювання контролера
домену? - Це частота створення резервної копії. Служба Active Directory передбачає, що
давність резервної копії не може перевищувати життя об'єктів-пам'ятників. За умовчанням
час життя об'єкта-пам'ятника становить 60 днів. Причина цього обмеження пов'язана з тим
способом, яким Active Directory використовує об'єкти-пам'ятники. Коли об'єкт видалено,
він фактично не видаляється з каталогу доти, доки закінчиться час життя об'єкта-
пам'ятника. Натомість об'єкт маркується як об'єкт-пам'ятник, і більшість його атрибутів
видаляються. Потім об'єкт-пам'ятка копіюється на інші контролери домену. Після
закінчення життя об'єкта-пам'ятника він нарешті видаляється з каталогу кожному
контролері домену. Якщо відновити контролер домену з резервної копії, давність якої
перевищує час життя об'єкта-пам'ятника, то в каталозі можна знайти інформацію, не
узгоджену між контролерами домену. Припустимо, що користувач був видалений з
каталогу через день після створення резервної копії, а відповідний об'єкт-пам'ятник
залишався у каталозі 60 днів. Якби резервна копія була відновлена на контролері домену
більш ніж через 60 днів, після того як об'єкт став пам'ятником, то на відновленому
контролері домену був би цей об'єкт користувача, і оскільки об'єкт-пам'ятник більше не
існує, то контролер домену не став би його видаляти. У такому сценарії відновлений
контролер домену мав би копію об'єкта, який не існує в жодному іншому каталозі. Через
це система резервування та програма відновлення запобігають спробам відновлення
каталогу з резервної копії, що зберігається довше, ніж період видалення об'єктів-
пам'ятників.
Хоча час життя об'єктів-пам'ятників накладає жорстке обмеження частоту
резервного копіювання, очевидно, що створювати резервні копії контролерів домену
краще набагато частіше, ніж кожні 60 днів. Виникне багато проблем, якщо відновлювати
контролер домену з резервної копії, давнішої за пару днів. Оскільки відновлення Active
Directory включає відновлення всієї інформації про стан системи, цю інформацію буде
відновлено до попереднього стану. Якщо сервер також є сервером служби сертифікатів,
всі посвідчення, випущені до створення резервної копії, не будуть включені до бази даних
служби сертифікатів. Якщо були оновлені драйвери або встановлені нові програми, вони
не зможуть працювати, тому що буде зроблено відкат системного реєстру до
попереднього стану. Майже всі компанії підтримують такий режим резервного
копіювання, де деякі сервери копіюються щоночі. Контролери домену повинні
включатися до режиму резервування.

Процес відновлення
Існують дві причини, через які, можливо, доведеться відновлювати Active Directory
[13].
 ● Перша причина виникне, коли база даних стане непридатною для використання,
тому що на одному з контролерів домену відбулася відмова в роботі жорсткого
диска або база даних зіпсована настільки, що її більше не вдається завантажити.
● Друга причина виникне, коли в результаті помилки хтось видалив організаційну
одиницю, яка містить кілька сотень облікових записів користувачів та груп. І тут
бажано відновити інформацію, ніж вводити її повторно.

Якщо планується відновлювати Active Directory , тому що базу даних на одному з

контролерів домену більше не можна використовувати, є наступні два варіанти процесу
[13].
● Перший варіант полягає в тому, щоб взагалі не відновлювати Active Directory на
сервері, що відмовив, а створити ще один контролер домену, призначивши інший
сервер, на якому виконується система Windows Server 2003, контролер домену. У
такий спосіб буде відновлено функціональні можливості контролера домену, а не
служба Active Directory на певному контролері домену.
● Другий варіант полягає у відновленні сервера, що відмовив, і подальшому
відновленні бази даних Active Directory на цьому сервері. У цьому випадку буде
виконано відновлення за відсутності повноважень ( non - authoritative ). При такому
відновленні база даних Active Directory відновлюється на контролері домену, а
потім всі зміни, зроблені до Active Directory після створення резервної копії
реплікуються на відновлений контролер домену.

Якщо планується відновлювати Active Directory , тому що хтось видалив велику

кількість об'єктів з каталогу, необхідно відновити базу даних Active Directory на одному з
контролерів домену, використовуючи резервну копію, яка містить віддалені об'єкти.
Потім потрібно зробити відновлення за наявності повноважень ( authoritative ), у якого всі
відновлені дані відзначаються те щоб вони реплікувалися на всі інші контролери домену,
перезаписуючи віддалену інформацію.
Для відновлення Active Directory необхідно архівувати дані стану служби [4], [6]:
реєстр, базу даних реєстрації СОМ+, системні завантажувальні файли та базу даних служб
сертифікації (якщо це сервер служб сертифікації). При перезавантаженні комп'ютера в
режимі відновлення служб каталогів необхідно увійти до системи з адміністраторськими
правами, використовуючи правильні ім'я та пароль облікового запису Security Accounts
Manager . При цьому не можна використовувати обліковий запис адміністратора Active
Directory , оскільки служби Active Directory вимкнені та не можна їх засобами перевірити
справжність облікового запису. Для цього використовується база даних облікових записів
SAM: пароль облікового запису SAM задається в процесі встановлення Active Directory .

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

● системні файли та файли запуску, що знаходяться під захистом Windows ;

● системний реєстр контролера домену;

● всю зонну інформацію DNS, інтегровану з Active Directory ;

● папку Sysvol ;

● базу даних реєстрації класів СОМ+;

● базу даних служби сертифікатів (якщо контролер домену є сервером служби

сертифікатів);
● інформацію кластерної служби;

● метакаталоги інформаційної Інтернет-служби Microsoft (IIS) (якщо служба IIS

інстальовано на комп'ютері).

Всі ці компоненти повинні копіюватися та відновлюватися повністю через їх тісну

інтеграцію.
Причини, через які, можливо, доведеться відновлювати Active Directory :
● База даних стане непридатною для використання.

● Видалення організаційної одиниці, що містить кілька сотень облікових записів

користувачів та груп.

Для відновлення Active Directory необхідно архівувати дані стану служби: реєстр,
базу даних реєстрації СОМ+, системні завантажувальні файли та базу даних служб
сертифікації (якщо це сервер служб сертифікації).