Іменування об'єктів

У службі каталогів має бути механізм іменування об'єктів, що дозволяє однозначно ідентифікувати будь-який об'єкт каталога. У каталогах на базі протоколу LDAP для ідентифікації об'єкту в масштабі всього лісу використовується механізм відмінних імен (Distinguished Name, DN ). У Active Directory обліковий запис користувача з ім'ям User домена company.ru що розміщений в стандартному контейнері Users, матиме наступне відмінне ім'я: "DC=ru, DC=company, CN=Users, CN=User".

Позначення:

• DC (Domain Component) – покажчик на складову частину доменного імені;

• OU (Organizational Unit) – покажчик на організаційний підрозділ (ОП);

• CN (Common Name) – покажчик на загальне ім'я.

Якщо відмінне ім'я однозначно визначає об'єкт в масштабі всього лісу, то для ідентифікації об'єкту відносно|щодо| контейнера, в якому даний об'єкт зберігається, існує відносне відмінне ім'я (Relative| Distinguished| Name|, RDN|). Для користувача User| з|із| попереднього прикладу|зразка| RDN-ім’я| матиме вигляд|вид| " CN=User| ".

Окрім імен DN і RDN, використовується основне ім'я об'єкту (User Principal Name, UPN ). Воно має формат <ім'я субъекта>@<суфікс домена>. Для того ж користувача з прикладу основне ім'я виглядатиме як User@company.ru.

Імена DN|, RDN| можуть мінятися|змінюватися|, якщо об'єкт переміщається з|із| одного контейнера AD| в іншій. Для того, щоб не втрачати|розгублювати| посилання|посилання| на об'єкти при їх переміщенні в лісі, всім об'єктам призначається глобально унікальний ідентифікатор (Globally| Unique| Identifier|, GUID|), що є 128-бітовим числом.

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

• ретельний вибір імен доменів верхнього рівня;

• якість комунікацій в компанії (зв'язок між окремими підрозділами і філіями);

• організаційна структура компанії;

• кількість користувачів і комп'ютерів у момент планування|планування|;

• прогноз темпів зростання|зросту| кількості користувачів і комп'ютерів.

При плануванні|плануванні| імен доменів верхнього рівня можна викристовувати різні стратегії і правила. В першу чергу необхідно враховувати питання інтеграції внутрішнього простору|простір-час| імен і простору|простір-час| імен мережі Інтернет – оскільки простір|простір-час| імен AD| базується на просторі|простір-час| імен DNS|, при неправильному плануванні|плануванні| можуть виникнути проблеми з|із| безпекою, а також конфлікти із|із| зовнішніми іменами.

Розглянемо|розглядуватимемо| основні варіанти.

1. Один домен, одна зона DNS (рис. 5.4).

На малюнку в лівій частині|частці| – внутрішня мережа компанії, справа – мережа Інтернет, дві мережі розділено маршрутизатором " R " (окрім|крім| маршрутизатора, на кордоні|межі| можуть бути також проксі-сервер або міжмережевий екран).

Рис. 5.4.

Такий спосіб максимально спрощує роботу системного адміністратора, але|та| при цьому DNS-сервер|, доступний для всієї мережі Інтернет, зберігає зону company|.ru і надає доступ до записів цієї зони всім користувачам Інтернету. Таким чином, зовнішні зловмисники можуть отримати|одержувати| повний|цілковитий| список внутрішніх вузлів корпоративної мережі. Навіть якщо мережа надійно захищена міжмережевим екраном і іншими засобами захисту, надання потенційним зломщикам інформації про структуру внутрішньої мережі – річ дуже ризикована, тому даний спосіб організації простору|простір-час| імен AD| не рекомендується (хоча на практиці зустрічається досить часто).

2. "Розщеплювання" простору імен DNS - одне ім'я домена, дві різні зони DNS (рис. 5.5).

Рис. 5.5.

В даному випадку на різних серверах DNS| створюються різні зони з|із| одним і тим же ім'ям company|.ru. На внутрішньому DNS-сервері| функціонує зона company|.ru.для Active| Directory|, на зовнішньому DNS-сервере| – зона з|із| таким же ім'ям, але|та| для посилань|посилань| на зовнішні ресурси. Важливий|поважний| момент – дані зони ніяк між собою не зв'язані – ні механізмами реплікації, ні ручною синхронізацією.

Тут в зовнішній зоні зберігаються посилання|посилання| на зовнішні ресурси, а у внутрішній на внутрішні ресурси, використовувані для роботи Active| Directory|. Даний варіант нескладно реалізувати, але|та| для мережевого|мережного| адміністратора виникає навантаження управління двома різними доменами з|із| одним ім'ям.

3. Піддомен в просторі імен DNS для підтримки Active Directory (рис. 5.6).

Рис. 5.6.

У даному прикладі|зразку| кореневий домен компанії company|.ru служить для зберігання посилань|посилань| на зовнішні ресурси. У домені company|.ru відбувається|налаштовує| делегування управління піддоменом corp|.company.ru на внутрішній DNS-сервер|, і саме на базі домена corp|.company.ru створюється домен Active| Directory|.

В цьому випадку в зовнішній зоні зберігаються посилання|посилання| на зовнішні ресурси, а також посилання|посилання| на делегування управління піддоменом на внутрішній DNS-сервер|. Таким чином, користувачам Інтернету доступний мінімум|мінімум-ареал| інформації про внутрішню мережу. Такий варіант організації простору|простір-час| імен досить часто використовується компаніями.

4. Два різні домени DNS для зовнішніх ресурсів і для Active Directory (рис. 5.7.).

Рис. 5.7

У цьому сценарії компанія реєструє в інтернеті два доменні імена: одне для публікації зовнішніх ресурсів, інше – для розгортання Active| Directory|.

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

Висновки:

1. Служба каталогів Active| Directory| є основою логічної структури корпоративних мереж, що базуються на системі Windows.

2. Основа мережевої|мережної| безпеки – база даних облікових записів (accounts|) користувачів, груп користувачів і комп'ютерів, за допомогою якої здійснюється управління доступом до мережевих|мережних| ресурсів.

3. В ОС Windows Server використовуються наступні моделі: «Робоча група», «Доменна модель».

4. Active| Directory| відповідає не лише|не те що| за створення|створіння| і організацію невеликих об'єктів (ім’я каталогу, атрибути), але також і за великі об'єкти, такі як домени, OU| (організаційні підрозділи) і сайти. Визначено можливості Active| Directory|.

5. Протокол LDAP| чітко визначає коло|коло| операцій над каталогами, які може виконувати клієнтське застосування. Окрім|крім| протоколу LDAP| служба каталогів Active| Directory| використовує також протокол аутентифікації Kerberos| і службу DNS| для пошуку в мережі компонент| служб каталогів (контролери доменів, сервери глобального каталога, службу Kerberos| і ін.).

6. Основною одиницею системи безпеки Active| Directory| є домен. Домен формує область адміністративної відповідальності. База даних домена містить|утримує| облікові записи користувачів, груп і комп'ютерів. Найбільш крупна структура в Active| Directory – ліс. Нові дерева в лісі створюються у тому випадку, коли необхідно побудувати ієрархію доменів з простором імен, відмінним від інших просторів лісу. Організаційні підрозділи ( Organizational| Units|, OU| ) – контейнери усередині|всередині| AD|, які створюються для об'єднання об'єктів в цілях делегування адміністративних прав і вживання|застосування| групових політик в домені.

7. У каталогах на базі протоколу LDAP для ідентифікації об'єкту в масштабі всього лісу використовується механізм відмінних імен (Distinguished Name, DN ). У Active Directory обліковий запис користувача з ім'ям User домена company.ru що розміщений в стандартному контейнері Users, матиме наступне відмінне ім'я: "DC=ru, DC=company, CN=Users, CN=User".

5.2. Установка контролерів доменів

Тепер перейдемо до опису процедур установки контролерів доменів Active| Directory|.

Розберемо установку найпершого контролера найпершого домена найпершого лісу в структурі AD|.

Установка починається із запуску з командного рядка майстра установки Active Directory – dcpromo (рис. 5.8).

Рис. 5.8

Натискуємо кнопку "ОК" і бачимо стартову сторінку майстра (рис. 5.9):

Рис. 5.9.

Далі йде попередження, що операційні системи Windows 95, Windows NT 4.0 SP3 і раніші не зможуть функціонувати в доменах Windows 2003 (рис. 5.10). Відмітимо, що в доменах на базі Windows 2000 такої проблеми немає (та і в доменах на базі windows 2003 ця проблема вирішувана).

Рис. 5.10

Потім вибираємо варіанти установки контроллера домена в новому домені (рис. 5.11) і створення нового домена в новому лісі (рис. 5.12):

Рис. 5.11

Рис. 5.12

Наступний крок – вибір імені домена (для Active Directory це буде кореневий домен). У нашому прикладі виберемо ім'я world.ru (рис. 5.13):

Рис. 5.13

Задамо NetBIOS-ім’я домена (за замовчуванням, буде запропонована ліва частина повного імені домена, вибраного на попередньому кроці). У нашому прикладі – WORLD (рис. 5.14):

Рис. 5.14.

Далі майстер запропонує вибрати місце на жорстких дисках для розміщення бази даних Active Directory, журналу транзакцій цієї БД (рис. 5.15) і папки системного тому SYSVOL (рис. 5.16). Системний том обов'язково має бути розміщений на розділі з файловою системою NTFS.

Рис. 5.15

Рис. 5.16.

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

Рис. 5.17

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

Рис. 5.18.

Потім задаємо пароль адміністратора при запуску системи в режимі відновлення служб каталогів (рис. 5.19). даний режим використовується для відновлення БД Active Directory з резервної копії.

Рис. 5.19

Потім слідує екран із зведенням інформації про створюваний домен і параметри контроллера домена (рис. 5.20). На цьому кроці в разі виявленої помилки в конфігурації можна повернутися назад і виправити помилку.

Рис. 5.20.

Після цього починається робота із створення бази даних AD і наповненню її потрібними записами (рис. 5.21).

Рис. 5.21

Останній крок – натискувати кнопку "Готовий" і перезавантажити сервер (рис. 5.22).

Рис. 5.22

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

Коротко опишемо процес установки додаткового контроллера у вже створеному домені.

Якщо у нас є другий сервер, який ми хочемо зробити додатковим контроллером домена, то спочатку бажано включити його в домен як сервера–члена домен. Кнопка "Пуск" – Панель управління – Система – Закладка "Ім'я комп'ютера" – Кнопка "Змінити". Далі в полі "Є членом домена" ввести ім'я домена, натискувати ОК, ввести ім'я і пароль адміністратора домена, знову натискувати ОК і перезавантажити сервер (рис. 5.23).

Рис. 5.23

Після перезавантаження входимо в систему з обліковим записом адміністратора домена і запускаємо майстер установки Active Directory – команда dcpromo. Вибираємо варіант "Додатковий контроллер в існуючому домені" (рис. 5.24).

Рис. 5.24

Вказуємо облікові дані адміністратора домена (рис. 5.25):

Рис. 5.25

Знову вказуємо ім'я домена – world.ru. Починається процес імпорту БД Active Directory на створюваний контроллер (рис. 5.26):

Рис. 5.26

Після закінчення процесу – знову натискувати|натискати| кнопку "Готовий" і перезавантажити сервер.

Важливе зауваження. При додаванні додаткового контроллера в домені локальна база SAM, що існувала на сервері, з сервера віддаляється.

Опишемо процес установки додаткового контроллера домена з|із| резервної копії AD| існуючого контроллера.

Спочатку створимо резервну копію AD. Запустимо на існуючому контроллері домена утиліту ntbackup, виберемо архівацію стану системи (System State), вкажемо дорогу для створення файлу з резервною копією і натискуватимемо кнопку "Архівувати" (рис. 5.27):

Рис. 5.27

На наступному кроці – натискувати кнопку "Додатковий" (рис. 5.28):

Рис. 5.28

У панелі, що відкрилася, – прибрати галочку в поля "Автоматично архівувати захищені системні файли разом із станом системи" (рис. 5.29):

Рис. 5.29

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

Рис. 5.30

Тепер на сервері, який перетворюваний з простого сервера в контроллер домена, запускаємо утиліту dcpromo з параметром "/adv" (рис. 5.31):

Рис. 5.31

На етапі вибору джерела БД Active Directory – вибрати варіант "використовуючи файли з архіву" і вказати дорогу до папки, в яку розархівували резервну копію (рис. 5.32):

Рис. 5.32

Після закінчення процесу – перезавантажити сервер.