Логічне простір імен
Приступаючи до планування інфраструктури AD, необхідно продумати структуру простору імен, іншими словами, визначити спосіб організації мережевих ресурсів в каталозі AD. У Windows NT 4.0 існує всього кілька способів організації простору імен, так що вибір зробити нескладно - домени дозволяють задіяти всього два рівні ієрархії, всередині домену не існує розмежування повноважень, а NetBIOS не підтримує ієрархічне іменування. Концепція AD базується на ієрархічній специфікації X.500 і службі іменування DNS, тому питання про вибір, як використовувати площину імен насправді значно ширше. Простір імен AD використовує три основних структурних рівня: домени, дерева доменів і лісу.
Так само, як і в NT 4.0, домен в AD є кордоном загальної області безпеки. Домен AD використовує загальну політику захисту і ті ж самі локальні і глобальні групи домену. Крім того, домен служить кордоном реплікації: AD допускає реплікацію об'єктів домену тільки на контролери даного домену.
Ліс доменів - це ще одне нововведення AD. Ліс являє собою одне або кілька дерев доменів, що використовують загальну схему і спільний кордон захисту Kerberos. Кожен ліс може мати тільки одну схему, яка визначає об'єкти і властивості AD. В межах лісу діють транзитивні довірчі відносини Kerberos, які об'єднують всі домени. По відношенню до «чужих» доменів ліс може встановлювати довірчі відносини подібно до того, як будуються довірчі відносини між доменами в NT 4.0. Так що якщо в корпоративній мережі створено кілька лісів, то для організації спільного використання ресурсів необхідно визначити нетранзитивність довірчі відносини між цими лісами, як це робилося в NT 4.0. В даний час можливості об'єднати два лісу не існує.
На рисунку 1 показано співвідношення довірчих відносин між доменами, деревами доменів і лісами в AD. Звертаю увагу читачів на двунаправленное Транзитивне довірливе ставлення Kerberos між деревами mycompany.com і yourcompany.com. Особливість AD полягає в тому, що між усіма доменами в межах одного лісу встановлюються транзитивні довірчі відносини.
При проектуванні простору імен слід враховувати не тільки існуючу модель доменів NT 4.0. Визначаючи кількість доменів і плануючи структуру дерев доменів і лісів, слід також розглядати політичні, організаційні, географічні та технічні чинники.
Чи повинно простір імен відображати і зберігати існуючі політичні кордони організації? Адже скорочення кількості доменів, крім усього іншого, вимагає певних дипломатичних здібностей і навичок. Після примусового об'єднання самостійних доменів (і структурних одиниць) в один домен ситуація може стати просто вибухонебезпечною. Недооцінка політичних (в рамках організації) наслідків зміни мережевої структури може дорого обійтися.
Проект, що розробляється організаційної структури підприємства багато в чому залежить від того, яка обрана модель технічної підтримки: централізована або розподілена. Щоб побудувати більш компактний механізм делегування повноважень, можна або створити більшу кількість OU, або використовувати групи безпеки в рамках єдиної OU. Якщо вирішено формувати велику кількість OU, то кожну зміну, що зачіпає всі OU, додаватиме клопоту, а крім того, ускладнюється структура простору імен AD. Використання груп безпеки для делегування повноважень вимагає повного розуміння всіх нюансів моделі безпеки AD, при цьому схема безпеки не буде відображатися на екрані в графічному вигляді, як у випадку окремих OU.
При роботі у великій транснаціональній корпорації або компанії, орієнтованої на багатонаціональні ринки, простір імен повинно забезпечувати можливість розширення за межі кордонів держав. Необхідно, щоб формування нових зарубіжних філій або відділень технічної підтримки не викликало логічних протиріч в просторі імен.
Скільки буде потрібно доменів і лісів?
При плануванні багаторівневої доменної структури корінь лісу (перший домен, який є контейнером інфраструктури) рекомендується залишити порожнім, вільним від рядових користувачів. Цей домен відіграє особливу роль в ієрархії доменів: тут «прописані» групи Enterprise Admins і Schema Admins (адміністратори підприємства і адміністратори схеми), в які слід включати тільки деяких адміністраторів мережі.
Оскільки домен обмежує область реплікації, для скорочення трафіку реплицируемой даних між контроллерами доменів число доменів можна збільшити, особливо якщо це пов'язано з передачею даних по повільних каналах (наприклад, коли локальні мережі підрозділів об'єднані за допомогою глобальної мережі). Нижче буде описано спосіб управління реплікацією даних шляхом проектування вузлів. Але все ж занадто великий домен слід розділяти на піддомени: це дозволить скоротити мережевий трафік.
Вимірювання контролерів домену
Після того як питання логічної організації простору імен вирішено, слід з'ясувати, як реально здійснити проект. Це завдання не так вже проста, оскільки при реалізації на фізичному рівні потрібно вирішити безліч питань, від необхідної апаратної конфігурації контролерів домену до вибору топології вузлів для реплікації AD. При цьому слід взяти до уваги поточні обмеження AD. Зрештою, необхідно вибрати реалізацію служби DNS. Ступінь готовності сервера DNS впливає на виконання реплікації AD і час відгуку системи при аутентифікації користувачів.
Вирішуючи питання про характеристики контролерів домену AD, необхідно визначити, що означає «великий». Якщо потрібно об'єднати в один домен AD десять доменів NT 4.0, що містять 100 000 облікових записів користувачів, то виявиться, що кожен контролер домену AD повинен бути більш потужним і володіти великим обсягом дискового простору, ніж використовувані контролери доменів NT 4.0. Питання в тому, наскільки більш потужними повинні бути нові сервери? Компанія Microsoft надає інструментарій для швидкого розрахунку вимог контролера домену (більш детальну інформацію можна знайти в урізанні «Active Directory Sizer»).
На розмір каталогу AD впливають і інші, менш очевидні чинники. Так, наприклад, кожен запис елемента управління доступом (access control entry, ACE) в списку ACL об'єкта AD займає приблизно 70 байт. Беручи до уваги реалізовану в AD модель успадкування, яка використовується під час застосування захисту, зроблене в ACL зміна може автоматично додавати нові записи ACE до тисяч об'єктів каталогу. Тому у разі делегування прав на управління об'єктами в інфраструктурі AD потрібно бути особливо обережними. По можливості, слід призначати права для груп, а не для окремих користувачів. Цей підхід скорочує число записів ACE, необхідних для об'єктів і атрибутів.
Проектування топології вузлів (site) - можливо, найбільш відповідальний етап планування AD. Перш за все, необхідно ознайомитися з використовуваними в AD концепціями вузлів і зв'язків вузлів, ім'ям контекстів, глобальним каталогом GC і об'єктами підключення. Вузли є об'єктами AD, що визначають спосіб копіювання даних AD в мережі. Вузли зв'язані зі створюваними об'єктами «підмережа» (subnet objects), які в свою чергу відповідають подсетям TCP / IP у фізичній мережі.
Малюнок 2. Зв'язок вузлів.
Вузли з'єднуються між собою зв'язками - каналами, що формують групи вузлів. На рисунку 2 зображена схема компанії, що має чотири регіональні центри дистрибуції. У кожному центрі робочі станції і контролери доменів об'єднані швидкісний локальною мережею. Кожен з центрів з'єднаний з іншими центрами лініями T-1. Кожен центр являє собою вузол. В даному випадку адміністратор AD з'єднав все вузли між собою, оскільки з'єднання між вузлами мають однакову пропускну здатність. При описі зв'язків вузлів можна вказати розклад в рамках кожної зв'язку і вартість обміну. Розклад визначає частоту і час реплікації даних між вузлами, вартість представляє довільне значення, яке встановлює пріоритет підключення між вузлами.
Всі вузли, з'єднані зв'язками, виконують реплікацію за єдиним розкладом. Один і той же вузол може бути включений в різні зв'язки, і в цьому випадку починає грати роль вартість зв'язку. У прикладі з центрами дистрибуції можна додати додаткову зв'язок по комутованій лінії для дублювання виділеного каналу T-1 на випадок збою. Для зв'язку з цим встановлюється вартість вище, ніж для більш швидкісних з'єднань. Це дозволяє AD вибирати більш дешевий шлях реплікації в тому випадку, якщо все нормально, і перемикатися на модемну лінію при несправності каналу T-1.
AD використовує два протоколи реплікації. Стандартний протокол RPC підтримує реплікацію трьох контекстів іменування і GC, при цьому допускається компресія даних при реплікації між вузлами. Стандартний протокол SMTP використовується тільки для реплікації між вузлами контекстів іменування схеми і конфігурації, а також GC. Протокол SMTP корисний для з'єднань повільних, ненадійних або ж недоступних більшу частину дня. При використанні для реплікації протоколу SMTP трафік, в порівнянні з протоколом RPC, зростає в два рази. Для визначення зв'язків вузлів і використовуваних протоколів застосовується модуль AD Sites and Services консолі MMC.
Малюнок 3. Створений KCC об'єкт «з'єднання».
Об'єкти «з'єднання» представляють собою односпрямовані шляхи. Кожен з контролерів домену матиме власні з'єднання, що зв'язують цей контролер з іншими контролерами доменів. Якщо в домені є значна кількість контролерів, між якими здійснюється реплікація, можлива ситуація, коли пара доменів не вставлений двонаправленими зв'язками. Сервер, який ініціює подія реплікації в рамках вузла, повідомляє сервер, з яким він пов'язаний об'єктом «з'єднання», що відбулися зміни. Після цього отримує сервер «витягує» дані з ініціював реплікацію сервера.
KCC також будує об'єкти «з'єднання» для реплікації між вузлами. При створенні вузла KCC вибирає сервер, який буде виконувати роль моста (bridgehead) при повідомленнях між створеним вузлом і віддаленими вузлами. Цей сервер обміну використовує свої об'єкти «з'єднання» для реплікації на віддалені вузли відповідно до графіка, який адміністратор задає в об'єктах зв'язку з вузлами. У разі збою даного сервера його обов'язки бере на себе інший сервер вузла.
Проектування топології вузла
При проектуванні топології вузла необхідно відповісти на наступні питання.
- Де слід встановити межі вузла?
- Яка смуга пропускання необхідна для отримання малої затримки реплікації AD?
- У яких точках слід встановити локальні контролери домену, щоб не проводити віддалену аутентифікацію користувачів?
Як вже говорилося вище, вузли визначають частоту і розклад реплікації AD. Реплікація всередині вузла відбувається з інтервалом в 5 хв; реплікація між вузлами відбувається через 15 хв або рідше. Багатьох адміністраторів цікавить, яке мінімальне значення смуги пропускання, починаючи з якого контролери домену слід поміщати в різні вузли. Універсального правила не існує, зазвичай розподіл контролерів з різних сайтів слід в тих випадках, коли службовий трафік створює в мережі значне навантаження. У цих випадках потрібно розділити вузол на два і встановити реплікацію через більш тривалий інтервал. При реплікації між вузлами використовується компресія даних для блоків більше 32 Кбайт. Використовуваний алгоритм компресії досить ефективний, так що трафік може скорочуватися до 90%. Втім, ступінь стиснення залежить від характеру переданих даних - паролі практично не стискаються, тому що передаються в зашифрованому вигляді.
Екран 4. Результати роботи AD Sizer.
Груба оцінка обсягу даних реплікації AD в мережі дозволяє встановити частоту реплікації для зв'язків вузла. Слід пам'ятати, що зв'язку між вузлами повинні мати приблизно однакову пропускну здатність. Так, якщо вузли A, B, і C з'єднані, то реплікація буде виконуватися за єдиним розкладом, встановленим для цих питань. При установці розкладу слід використовувати можливість компресії даних між вузлами і мінімізувати час очікування між контролерами домена. Можна було б встановити мінімальну затримку - 15 хв, але якщо при цьому обсяг даних при кожній реплікації менше 32 Кбайт, то компресія не включається. В результаті може виявитися, що при частій реплікації пересилаються великі обсяги даних, ніж якби реплікація виконувалася рідше.
При виборі топології вузла крім трафіку реплікації даних AD, що викликається змінами контексту іменування домену, слід врахувати і інші джерела трафіку. Нижче перераховані деякі з найбільш очевидних.
Сервери, призначені в якості серверів GC, отримують зміни від кожного домена в лісі. Обсяг цих даних не набагато менше, ніж сумарний обсяг змін в кожному окремому домені, так як GC зберігає тільки усічену копію кожного контексту іменування домену.
Колективні ресурси SYSVOL
Записи зони DNS
Таким чином, практична реалізація AD вимагає ретельного планування і проектування. Беручи рішення про конкретні аспекти реалізації проекту, необхідно враховувати реальні потреби конкретної компанії і особливості інфраструктури. При грамотному використанні допоміжних інструментів, Resource Kit і AD Sizer, в справі проектування AD можна обійтися без ворожіння на кавовій гущі. Потрібно просто ретельно все зважити, реально оцінити потреби і можливості, а отриманий результат подвоїти - просто так, для підстраховки.
Таблиця 1. Витрати дискового простору для об'єктів AD.
Необхідна дисковий простір