Active Directory, мабуть, найпоширеніша і популярна на сьогодні служба каталогів. Ми вирішили трохи відступити від звичайного формату викладу матеріалу про AD і простою, зрозумілою мовою розповісти про досить складні речі, навмисно спростивши деякі моменти. На початковому етапі набагато важливіше мати цілісне уявлення про предмет і на цьому фундаменті поглиблювати свої знання, ніж намагатися розібратися в каші з малозрозумілих речей.
Active Directory - складний програмний продукт, здатний задовольнити потреби як невеликих фірм, так і великих корпорацій, і уявна простота освоєння не повинна створювати помилкового враження, що вивчення продукту можна обмежити "методом наукового тику" а виникаючі проблеми вирішувати в міру їх надходження.
Так, AD має низький поріг входження, що дозволяє за півгодини методом Next -> Next -> Finish отримати цілком працездатний результат не маючи ніяких специфічних знань в даній області. Багато матеріалів для початківців висвітлюють саме практичну сторону розгортання AD, залишаючи без уваги більш загальні і складні речі, як непотрібні на даному етапі. Можливо це так, адміністратору невеликої фірми немає діла до лісів і доменних дерев, але в міру зростання IT-інфраструктури ці питання з'являться на порядку денному і виявиться що поточна схема каталогу, побудована за принципом "що бачу, про те й співаю", не дозволяє "малою кров'ю" провести необхідні зміни і в ряді випадків буває простіше створити інфраструктуру заново.
Тому ми вважаємо, що структурі AD слід приділити найпильнішу увагу і вже з урахуванням отриманих знань підходити до проектування служби каталогів на вашому підприємстві, адже бачачи картину в цілому виявиться що дрімучий ліс не настільки вже й дрімучі, а рішення будуть враховувати як поточні, так і майбутні завдання з розумінням навіщо і чому потрібно робити саме так, а не інакше.
Найчастіше в межах однієї організації достатньо одного лісу, створення схеми з декількома лісами може знадобитися коли до складу фірми входять організації мають низький рівень довіри між собою і мають абсолютно різні напрямки діяльності, в кожній з яких свій IT-персонал і своя інфраструктура. Це дозволяє надійно ізолювати організації один від одного, залишаючи свободу дій всередині кожної з них.
Основою структури каталогу є домен, це адміністративна одиниця усередині якої діють свої правила і політики, домен являє собою ще одну межу безпеки і реплікації. Якщо кордон лісу можна порівняти з державним кордоном, то кордону домену представляють межі адміністративних одиниць, будь-який користувач будь-якого домену може отримати доступ до будь-якого об'єкта іншого домену якщо, звичайно, має на це права. Реплікація (синхронізація каталогу між контролерами домена) також обмежена межами домену, це означає що записи про об'єкти цього домену будуть зберігатися тільки в його межах і не будуть доступні адміністратору іншого домену. Це дозволяє розмежувати повноваження IT-персоналу: кожен відділ відповідає за свій домен і помилки адміністратора одного з доменів не приведуть до виходу з ладу всієї мережі.
Розглянемо схему AD гіпотетичної організації. Спочатку, коли фірма була невелика в лісі існував єдиний домен domain.org. який містив у собі всі об'єкти підприємства: користувачів, групи, сервера, комп'ютери, ресурси.
Поступово фірма розвивається і виникає необхідність виділити окремо регіональні підрозділи, припустимо російське і українське, поточний підрозділ виконуватиме адміністративні функції і також має управлятися окремо. Немає проблем, створюємо ще два домена: ru.domain.org і ua.domain.org. які мають з кореневим доменом спільний простір імен, що отримала схема носить назву дерева доменів. У свою чергу в просторі імен регіональних доменів можна створити домени для більш дрібних підрозділів, наприклад spb.ru.domain.org.
Що дає виділення підрозділів в окремі домени? Перш за все безпека, користувачі мають доступ тільки до ресурсів свого домену, облікові записи зберігаються тільки на "своїх" контролерів, адміністратори можуть налаштовувати політики не озираючись на інші відділи і підрозділи і, в той же час, не побоюючись що невдалі експерименти іншого IT-відділу приведуть до непрацездатності мережі.
Згодом в організації з'являється підрозділ не пов'язане з основним видом діяльності, наприклад своя транспортна компанія або служба техпідтримки, яка обслуговує як підприємство, так і сторонніх клієнтів. Для неї створюється окремий домен в окремому просторі імен office.com. точно також ми можемо виділити в окремий домен якусь структурну одиницю даного підрозділу, наприклад ou.office.com. Таким чином ми створимо нове дерево доменів в поточному лісі.
Чому нове дерево? Просто так зручніше, інший вид діяльності, інший простір імен. Як ми вже говорили, положення домену в лісі ніяк не впливає на його налаштування і взаємодія з іншими доменами, тому будувати одне розгалужене дерево доменів або декілька окремих питання суто організаційний, зазвичай структура дерева повторює структуру компанії.
Розібравшись з доменами, перейдемо до більш глобальним речам, а саме до глобального каталогу. Глобальний каталог призначений для обробки запитів інформацією про яких не має контролер домену, наприклад при зверненні до ресурсів іншого домену або універсальним ресурсів. Глобальний каталог містить повну копію об'єктів, які підтримуються вашим і часткову копію об'єктів всіх інших доменів, які саме атрибути об'єктів включаються в глобальний каталог визначається схемою AD.
Одна з основних функцій глобального каталогу - пошук об'єктів, дозволяючи здійснювати пошук в рамках лісу максимально швидко і з мінімальним трафіком. Припустимо користувач Іванов Іван з домену office.com шукає комп'ютер sales1 входить в домен ua.domain.org. при звичайному пошуку довелося б послідовно опитувати контролери доменів, поки один з них не повернув би необхідну інформацію, реально досить одного запиту до глобального каталогу.
Друга роль глобального каталогу - перевірка справжності користувача при вході, якщо контролер домену не має відомостей про обліковий запис, наприклад при вході в систему фізично перебуваючи в іншому домені. Реально глобальний каталог використовується при будь-якому вході користувача в домен і при його недоступності вхід буде неможливий.
Чому? Тому що глобальний каталог зберігає відомості про універсальні групах, в які можуть входити будь-які облікові записи лісу і дозволу яким можуть бути призначені для будь-якого домену. Це важливо для роботи таких сервісів як Exchange, який при відмові глобального каталогу просто перестане працювати. Глобальним каталогом може бути будь-який контролер домену або кілька, рекомендується мати, як мінімум один глобальний каталог в кожному домені, це дозволяє знизити трафік між доменами і підвищити відмовостійкість і автономність доменів (пропав зв'язок, відмовив сервер і т.д. і т.п. )
Крім глобального каталогу існують ролі звані майстрами (господарями) операцій. які відстежують унікальність критично важливих об'єктів AD. Наприклад, відразу два адміністратора вирішать створити домени з однаковим ім'ям або внести зміни в схему. Тому в кожному лісі існує тільки один контролер з роллю господаря операцій і при його недоступності відповідні дії будуть неможливі. Всього існує п'ять ролей FSMO (flexible single master operation): дві для лісу і три для кожного домена, зараз ми не будемо їх детально розглядати, це тематика окремої статті, просто коротко перерахуємо виконувані ними функції:
Господар іменування домену та господар схеми одні на весь ліс, інші ролі FSMO припадають по одній на кожен домен. Відмова ролей FSMO не приводить до непрацездатності домену, однак унеможливлює багато операцій, фактично переводячи домен в режим "тільки читання".
На цьому ми закінчимо наша сьогоднішня розповідь. Незважаючи на те, що порушена тема досить обширна, для розуміння структури наведених знань цілком достатньо і, на наш погляд, не варто надмірно ускладнювати початкову модель. Більш докладно про елементи AD ми поговоримо пізніше, коли будемо розглядати конкретні рішення.