THE BELL

Є ті, хто прочитали цю новину раніше вас.
Підпишіться, щоб отримувати статті свіжими.
Email
ім'я
Прізвище
Як ви хочете читати The Bell
без спаму

Що таке контролер домену

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

В операційній системі Windows NT, як основний сервер, використовується основний контролер домену. Інші використовувані сервери використовуються як резервні контролери. Основні контролери PDС можуть вирішувати різні завдання, пов'язані з членством користувачів в групах, створення і зміна паролів, додавання користувачів і багато інших. Після чого дані передаються на додаткові контролери BDC.

В якості контролера домену може використовуватися програмне забезпечення Samba 4, якщо встановлена \u200b\u200bопераційна система Unix. Це ПО також підтримує і інші операційні системи, такі як windows 2003 2008, 2003 R2 і 2008 R2. Кожна з операційних систем при необхідності може розширюватися в залежності від конкретних вимог і параметрів.

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

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

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

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

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

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

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

Особливості установки додаткових контролерів домену

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

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

Для безпечної роботи контролера домену необхідно використовувати файлову систему NTFS, що забезпечує більш високу безпеку в порівнянні з файловими системами FAT 32. Для установки на сервері потрібно створити один розділ в файлову систему NTFS, на якому буде знаходитися системний тому. Також обов'язково необхідний доступ до DNS сервера з сервера. Служба DNS встановлюється на цьому або додатковому сервері, який повинен підтримувати ресурсні записи.

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

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

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

попередні вимоги

Перед тим як почати перейменовувати свій домен обов'язково візьміть до уваги наступні відомості:

  • Функціональний рівень лісу Active Directory. Виконувати завдання з перейменування доменів можна лише в тому випадку, якщо всі домени в лісі оснащені як мінімум операційною системою Windows Server 2003 (в цьому випадку по редакціях немає ніяких обмежень). Більш того, функціональний рівень повинен бути підвищений щонайменше до рівня Windows Server 2003. Тобто, якщо у вас в лісі обраний функціональний рівень Windows Server 2000, то виконання наступної операції просто стане неможливим;
  • Розташування домену. У лісі Active Directory може бути різний рівень доменів. Тобто, можуть бути або окремий домен, або ліс може включати дочірні домени. У тому випадку якщо ви будете міняти розташування контролера домену всередині лісу, вам доведеться створити довірчі відносини;
  • зона DNS. Ще до виконання операції перейменування домену вам необхідно створити нову зону DNS;
  • Адміністративні облікові дані. Для виконання операції перейменування домену ви повинні виконати вхід в систему під адміністративної обліковим записом, яка є членом групи адміністраторів підприємства (Enterprise Admins);
  • Сервери розподіленої файлової системи (DFS). Якщо у вашій корпоративному середовищі розгорнуті служби DFS або налаштовані переміщувані профілі, то зверніть увагу на те, що кореневі DFS-сервери повинні працювати, як мінімум, під управлінням операційної системи Windows Server 2000 з пакетом оновлень 3 або під більш сучасними версіями операційних систем;
  • Несумісність з серверами Microsoft Exchange. Самий неприємний момент полягає в тому, що якщо в вашому лісі Active Directory розгорнуть поштовий сервер Microsoft Exchange Server 2003 Service Pack 1, то перейменування домену буде виконано без будь-яких проблем, але обліковий запис користувача, під якою буде виконуватися сам процес перейменування домену повинна бути членом групи Full Exchange Administrator. Все більш сучасні поштові сервери (включаючи Exchange Server 2016) несумісні з операціями перейменування доменів.

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

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

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

Процес перейменування домену Active Directory

Для початку, для того щоб перевірити первинне ім'я вашого домену, ви можете відкрити вікно властивостей системи. Як видно на відповідній ілюстрації, мій домен називається «Biopharmaceutic.local»:

Мал. 1. Перевірка початкового імені домена Active Directory

Тепер слід створити нову зону DNS «biopharm.local» для того щоб після успішного виконання перейменування домену ваші рядові сервери і клієнти могли без проблем приєднатися до новому доменному імені. Для цього відкрийте « Диспетчер DNS» ( DNS Manager) І перебуваючи в « Зоні прямого перегляду» ( Forward Lookup Zone) Виберіть опцію оп створенню нової зони. По суті, зона створюється як зазвичай: на першій сторінці майстра створення зон слід прочитати вступну інформацію і перейти до другої сторінки. На сторінці типу зони виберіть основну зону ( Primary Zone) І зверніть увагу на те, щоб була активована опція збереження зони в Active Directory. На сторінці області реплікації зони слід залишити опцію, обрану за замовчуванням - « Для всіх DNS-серверів, що працюють на контролерах домену в цьому домені: Biopharmaceutic.local» ( To all DNS servers running on domain controllers in this domain: Biopharmaceutic.local). На сторінці імені зони слід вказати нове ім'я домену (biopharm.local), а на сторінці динамічного оновлення також залиште опцію « Дозволити тільки безпечні динамічні оновлення (рекоменд. Для Active Directory)» ( Allow only secure dynamic updates (recommended for Active Directory)), Яка обрана за замовчуванням. Кілька етапів створення нової зони ви можете побачити нижче:

Мал. 2. Створення нової зони DNS

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

Для створення такого файлу слід під відповідною обліковим записом відкрити командний рядок і в ній виконати команду « random / list». Згенерований файл буде збережений в кореневому каталозі облікового запису вашого користувача. Далі вам потрібно буде відкрити цей файл за допомогою будь-якого текстового редактора.

Усередині цього файлу вам потрібно змінити ім'я домену усередині секції, яка обмежена тегами і і ім'я NetBIOS усередині тегів і). Обов'язково зверніть увагу на те, що ви не повинні змінювати ідентифікатор GUID всередині відповідних тегів.

На наступній ілюстрації ви побачите процес виконання вищезгаданої команди, розташування файлу Domainlist.xml і зміни для першої секції цього файлу. У моєму випадку ім'я домену в цьому конфигурационном буде змінено 4 рази:

Мал. 3. Генерація і зміна файлу Domainlist.xml

Для того щоб упевнитися в тому, що ви внесли до відповідного файл необхідні зміни, ви можете виконати команду « rendom / showforest». Як бачите на наступній ілюстрації, у мене все записи змінилися на «Bopharm»:

Мал. 4. Перегляд потенційних змін

При виконанні наступної команди ( rendom / upload) Утиліта Rendom переводить нову структуру лісу, зазначену у відредагованому файлі, в послідовність інструкцій з оновлення каталогу, які будуть запускатися локально і віддалено на кожному контролері домену в лісі. Якщо говорити в загальних рисах, то на цьому етапі в розділі каталогу конфігурації майстра іменування доменів будуть внесені зміни для перейменування домену Active Directory. Крім цього, буде створено файл Dclist.xml, який використовується для відстеження прогресу і стану кожного контролера домену в лісі для операції перейменування домену. Між іншим, в цей момент утиліта Rendom заморожує ваш ліс Active Directory від внесення будь-яких змін в його конфігурацію. Процес виконання цієї команди видно нижче:

Мал. 5. Виконання команди rendom / upload

Наступна команда виконується для перевірки готовності контролерів домену перед операцією з перейменування домену. Під час виконання цього етапу ви повинні запустити команду підготовчої перевірки на кожному контролері домену в лісі. Це необхідно для того, щоб бути впевненим, що база даних Active Directory на кожному контролері домену в лісі знаходиться в правильному стані і готова виконати зміни, які дозволять перейменувати ваш домен. Отже, виконайте команду « rendom / prepare», Як це зроблено на наступній ілюстрації:

Мал. 6. Підготовка домену до перейменування

Найвідповідальніший момент. Виконання команди « rendom / execute». Під час виконання цієї команди на домені виконуються інструкції з перейменування домену. По суті, в цей самий момент виконується звернення до кожного контролера домену в лісі індивідуально, що змушує кожен контролер домену виконувати інструкції з перейменування домену. За виконання цієї операції кожен контролер домену буде перезавантажений. Процес виконання перейменування домену дивіться на наступній ілюстрації:

Мал. 7. Процес перейменування домену

Але це ще не все. Незважаючи на те, що ваш домен, по суті, вже перейменований, вам ще належить завдання по виправленню об'єктів групової політики та їх посилань після завершення операції перейменування домену. Для відновлення об'єктів групової політики, а також посилань GPO в кожному перейменованому домені використовується утиліта командного рядка Gpfixup.exe. Не можна нехтувати цією процедурою з огляду на те, що без її використання, після завершення операції перейменування домену в новому лісі, групові політики просто не буду правильно функціонувати. Врахуйте, що ця команда повинна бути запущена раз в кожному перейменованому домені. Отже, один раз виконайте команду gpfixup з параметрами /olddns:Biopharmaceutic.local (Старе ім'я перейменованого вами домену) і /newdns:Biopharm.local (Нове ім'я перейменованого домену), а потім команду gpfixup з параметрами / Oldnb: Biopharmaceutic і / Newnb: Biopharm (Відповідно, старе і нове NETBIOS-ім'я вашого домену). Ця процедура видно нижче:

Мал. 8. Виправлення об'єктів групової політики

Залишилося виконати лише дві команди: команду « rendom / clean», Яка дозволяє видалити всі посилання на старі імена домену всередині вашої Active Directory, а також команду« rendom / end», По суті, розморожуючу ліс Active Directory від внесення змін до його конфігурацію. Процес виконання цих команд ви можете побачити на наступній ілюстрації:

Мал. 9. Завершення перейменування домену Active Directory

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

Вчора, до нас в студію, надійшов лист від нашого постійного читача Андрія, з питанням:

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

Давайте коротко розберемося яке ж краще використовувати ім'я при найменуванні домену всередині організації.

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

1. Домен з ім'ям example.local

Лідером нашого хіт-параду є іменування домену із закінченням на local. Існують і інші варіації на цю тему, наприклад test, firma, factory, nn, loc, і так далі. Зараз навіть уже й не згадаєш звідки пішла така любов, у всіх своїх книгах компанія Microsoft завжди використовує свої іменування виду contoso.com, Де ми чітко бачимо формат іменування домену. Однак протягом майже 10 років домен .local займав лідируючі позиції. Ситуація стала вирівнюватися з приходом сервісів використовують в своїй роботі SSL сертифікати. Де використання доменів «пофіг і так зійде» стає неможливим. Дивіться, припустимо, що ваша компанія використовує всередині організації Exchange server, Якому необхідний ssl сертифікат для шифрування клієнтських підключень. Згідно з вашим сценарієм для реалізації цього завдання вам потрібні сертифікати зовнішнього центру сертифікації, В якому необхідно вказати всі імена серверів використовуваних для зовнішнього підключення. Здавалося б що такого, записуємо все імена серверів і подаємо заявку на випуск сертифікатів, але є одне але. З ім'ям такого домену ви не зможете пройти валідацію, Так як домен «пофіг і так зійде» не існує і на спробу пояснити зовнішньому центру сертифікації, що вам в SAN потрібно засунути FQDN ім'я неіснуючого домену отримаєте м'який відмова:

It's not possible, we issue only certificates for real domain names.

Але існує ще одна неприємність. Використання доменного імені що не належить вам в імені домена може привести до плачевних наслідків. Уявіть ситуацію якщо зона local матиме статус публічної. як зона com або ru. Далі я думаю продовжувати не варто 🙂

2. Ім'я домену збігається з зовнішнім ім'ям домену

Друге місце нашого хіт-параду. Не дивлячись на те, що такий сценарій є менш популярним, він все ж має право на життя. Крім того, що в найближчому майбутньому ви все ж отримаєте деякі незручності при обслуговуванні мережі, більше вам нічого не загрожує. Основною проблемою в цьому сценарії є те, що вам доведеться підтримувати два DNS сервера: внутрішній і зовнішній. За такої умови комп'ютери знаходяться всередині мережі будуть використовувати для розпізнавання імен внутрішній DNS сервер, а комп'ютера за периметром компанії зовнішній. Припустимо ваш домен носить горду назву example.com. В DMZ зоні у вас знаходиться сайт компанії з ім'ям example.com. В описаному сценарії вище комп'ютери знаходяться всередині організації не зможуть отримати до нього доступ з огляду на те що для них example.com це ім'я домену і при введенні цієї адреси в браузері вони будуть потрапляти на контролер домену. Як я вже зазначив вище крім незручності це ні до чого не приведе. Ви завжди можете використовувати милиці, які будуть перекидати вас на зовнішній сайт, але погодьтеся це не потрібна подвійна робота, або всередині мережі використовувати ім'я сайту починається з www, Або зовні.

3. Ім'я домену з одного слова

Мабуть самий не правильний варіант з наведених вище. Однорівневі домени: Single-label domain - це домен, який містить тільки одну складову. По всій видимості їх почали використовувати за часів NT, коли компанія Microsoft перейняла вдалий досвід компанії Novell. Так склалося, що спочатку я був адміністратором FreeBSD і великого парку серверів NetWare починаючи з версії 4.11, так ось в ті стародавні часи NetWare використовувала в своїй роботі Bindery, яка як раз імена схему одноуровнего домену, Яку потім і перейняла компанія Microsoft.

Best practices

Пора підвести підсумок. Яке ж іменування домену використовувати? Тільки домен третього рівня в домені яким ви володієте. Не варто використовувати чужі красивіші доменні імена :-). Приклад такого домену ви можете побачити нижче.

На дворі 2015 рік, інтернет отримав масове поширення, у кожної поважаючої себе компанії давно є свій веб-сайт. Не потрібно далеко ходити - навіть у кожній міській лікарні є свої веб-ресурси. Але тим не менше все одно сисадміни не навчилися створювати нормальні імена для своїх доменів.

Вартість домена другого рівня (наприклад, bissquit.com) становить трохи більше 500 рублів на рік. Це дуже мало навіть для звичайних громадян, як ми з вами, і це сущі копійки для компаній тим більше. Свій домен я придбав ще задовго до того, як з'явилася ідея «запив» цей бложік. Це просто зручно. Візьмемо навіть віддалене підключення по rdp - я вводжу ім'я свого домену, замість похмурого ip-адреси.

В інтернеті на запит «active directory domain best practices» майже на кожному сайті написані комплексні рекомендації щодо іменування доменів AD і дані пояснення чому потрібно зробити саме так. Давайте розглянемо докладніше про які рекомендації йдеться:

  • Для іменування домену AD використовуйте піддомен вашого офіційно зареєстрованого домену організації.

Ви все зрозуміли правильно, тільки одна порада. Це все! Можна багато розмірковувати про деталі і дрібних нюансах, але 80-90% міркувань зводяться до одного єдиного раді, озвученого вище. Всі проблеми виходять з того, що людина знає, що так потрібно робити, але не розуміє чому не можна або вкрай не рекомендується робити по-іншому. З цього моменту докладніше.

1. Чому не можна використовувати внутрішні, Не дозволяється зовні імена тіпа.local, .corp, .lan?

Можна, можливо. Ще як можна. Більшість саме їх і використовують. У мене є приклади серед знайомих, у яких в організаціях 2000+ людина і використовується домен.local. Всі труднощі почнуться, якщо раптом стане потрібен реальний домен AD. Таке може статися при використанні гібридних хмарних розгортання (яскравий тому приклад Exchange + Office365). «Чому б просто не перейменувати домен, адже з певною версією AD це цілком можливо?» - запитаєте ви. Так в принципі можна, проте вам доведеться зіткнутися зі складнощами міграції доменнозавісімих сервісів. Серед них все той же Exchange та ін., Але тут і одного Exchange більш ніж достатньо.

2. «Ок, купуємо реальне зовнішнє ім'я - my-company.com, також назвемо і домен AD» - теж не варіант. Виникнуть проблеми з дозволом інших ресурсів, розташованих на адресу my-company.com, наприклад, веб-сайт компанії. Та й до того ж ваші DNS-сервери не будуть авторитативні для цього домену, хоча вважатимуть себе такими. Це теж викличе проблеми.

Є й інші міркування щодо іменувань доменів, серед них створення аналогічного реальному домену але в іншому TLD. Але мені здається великого сенсу так робити немає, адже частина проблем все одно залишається, а явних переваг в порівнянні з використанням домену corp.my-company.com (ім'я взято для прикладу) просто немає.

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

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

Коротше кажучи, AD дозволяє використовувати єдину точку адміністрування для всіх публікованих ресурсів. В основі AD використовується стандарт іменування X.500, система доменних імен - Domain Name System (DNS) для визначення місця розташування, і в якості основного протоколу використовується Lightweight Directory Access Protocol (LDAP).

AD об'єднує логічну і фізичну структуру мережі. Логічна структура AD складається з наступних елементів:

  • організаційне підрозділ (organizational unit) - підгрупа комп'ютерів, як правило, відображає структуру компанії;
  • домен (domain) - група комп'ютерів, спільно використовують загальну базу даних каталогу;
  • дерево доменів (domain tree) - один або декілька доменів, спільно використовують безперервне простір імен;
  • ліс доменів (domain forest) - одне або кілька дерев, спільно використовують інформацію каталогу.

До фізичної структурі відносяться такі елементи:

  • підмережа (subnet) - мережева група із заданою областю IP-адрес і мережевий маскою;
  • сайт (site) - одна або декілька підмереж. Сайт використовується для настройки доступу до каталогу і для реплікації.

У каталозі зберігаються відомості трьох типів: дані домену, дані схеми і дані конфігурації. AD використовує тільки контролери доменів. Дані домену реплицируются на всі контролери домену. Всі контролери домену рівноправні, тобто всі зміни, що вносяться з будь-якого контролера домену будуть реплікуються на всі інші контролери домену. Схема і дані конфігурації реплицируются в усі домени дерева або лісу. Крім того, всі об'єкти індивідуального домену та частина властивостей об'єктів лісу реплицируются в глобальний каталог (GC). Це означає, що контролер домену зберігає і реплицирует схему для дерева або лісу, інформацію про конфігурацію для всіх доменів дерева або лісу і всі об'єкти каталогу і властивості для власного домену.

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

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

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

У кожному лісі AD існують такі ролі:

  • Господар схеми (schema master) - керує оновленнями і змінами схеми каталогу. Для оновлення схеми каталога необхідний доступ до господаря схеми. Щоб визначити, який сервер в даний час є господарем схеми в домені, потрібно у вікні командного рядка набрати команду dsquery server -hasfsmo schema
  • Господар іменування доменів (domain naming master) - керує додаванням і видаленням доменів в лісі. Щоб додати або видалити домен потрібен доступ до господаря іменування доменів. Щоб визначити, який сервер в даний час є господарем іменування доменів, у вікні командного рядка введіть dsquery server -hasismo name

Ці ролі, загальні для всього лісу в цілому і є в ньому унікальними.

У кожному домені AD обов'язково існують такі ролі:

  • Господар відносних ідентифікаторів (relative ID master) - виділяє відносні ідентифікатори контролерам доменів. Кожен раз при створенні об'єкта користувача, групи, або комп'ютера, контролери призначають об'єкту унікальний ідентифікатор безпеки, що складається з ідентифікатора безпеки домена і унікального ідентифікатора, який був виділений господарем відносних ідентифікаторів. Щоб визначити, який сервер в даний час є господарем відносних ідентифікаторів домену, в командному рядку введіть dsquery server -hasfsmo rid
  • Емулятор PDC (PDC emulator) - в змішаному або проміжному режимі домену діє як головний контролер домену Windows NT. Він аутентифікує вхід в Windows, обробляє зміни пароля і реплицирует поновлення на BDC, якщо вони є. Щоб визначити, який сервер в даний час є емулятором PDC домену, в командному рядку введіть dsquery server -hasfsmo pdc
  • Господар інфраструктури (infrastructure master) - оновлює посилання об'єктів, порівнюючи дані свого каталогу з даними GC. Якщо дані застаріли, він запитує з GC поновлення і реплицирует їх на інші контролери домену. Щоб визначити, який сервер в даний час є господарем інфраструктури домена, в командному рядку введіть dsquery server -hasfsmo infr

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

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

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

Інсталяція контролера домену (DC) на базі Windows Server 2003 за допомогою майстра установки Active Directory

Установка контролера домену проводиться за допомогою майстра Active Directory Installation Wizard. Щоб підвищити статус сервера до контролера домену необхідно переконатися у виконанні всіх необхідних для цього вимог:

  1. На сервері повинен бути хоча б один розділ NTFS для розміщення системного тому SYSVOL.
  2. Сервер повинен мати доступ до DNS сервера. Бажано встановити службу DNS на цьому ж сервері. Якщо використовується окремий сервер, то необхідно переконатися, що він підтримує ресурсні записи Service Location (RFC 2052) і протокол Dynamic Updates (RFC 2136).
  3. Необхідно мати обліковий запис з правами локального адміністратора на сервері.

Розглянемо докладно підвищення ролі сервера до контролера домену Active Directory по кроках:

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

Ряд засобів в оснащеннях Microsoft Management Console (MMC) спрощує роботу з Active Directory.

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

Для запуску оснащення (Active Directory - користувачі і комп'ютери) виберіть однойменну команду в меню Administrative Tools (Адміністрування).

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

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

  • Saved Queries (Сохраненниезапроси) - збережені критерії пошуку, що дозволяють оперативно повторити виконаний раніше пошук в Active Directory;
  • Builtin - список вбудованих облікових записів користувачів;
  • Computers - контейнер за умовчанням для облікових записів комп'ютерів;
  • Domain Controllers - контейнер за умовчанням для контролерів домену;
  • ForeignSecurityPrincipals - містить інформацію про об'єкти з довіреної зовнішнього домену. Зазвичай ці об'єкти створюються при додаванні до групи поточного домену об'єкта з зовнішнього домену;
  • Users - контейнер за умовчанням для користувачів.

Деякі папки консолі за замовчуванням не відображаються. Щоб вивести їх на екран, виберіть у меню View (Вид) команду Advanced Features (Додаткові функції). Ось ці додаткові папки:

  • LostAndFound - втратили власника, об'єкти каталогу;
  • NTDS Quotas - дані про квотування служби каталогів;
  • Program Data - збережені в службі каталогів дані для додатків Microsoft;
  • System - вбудовані параметри системи.

Ви можете самостійно додавати папки для організаційних підрозділів в дерево AD.

Розглянемо приклад створення облікового запису користувача домену. Щоб створити обліковий запис користувача клацніть правою кнопкою контейнер, в який ви хочете помістити обліковий запис користувача, виберіть у контекстному меню New (Створити), а потім - User (Користувач). Відкриється вікно майстра New Object - User (Новий об'єкт - Користувач):

  1. Введіть ім'я, ініціал і прізвище користувача у відповідних полях. Ці дані потрібні для створення Імен користувача.
  2. Відредагуйте повне ім'я. Воно повинно бути унікальним в домені і мати довжину не більше 64 символів.
  3. Введіть ім'я для входу. За допомогою списку виберіть домен, з яким буде пов'язана обліковий запис.
  4. При необхідності змініть ім'я користувача для входу в системи з ОС Windows NT 4.0 або більш ранніми версіями. За умовчанням як ім'я для входу в системи з попередніми версіями Windows використовуються перші 20 символів повного імені користувача. Це ім'я також має бути унікальним в домені.
  5. клацніть Next (Далі). Вкажіть пароль для користувача. Його параметри повинні відповідати вашій політиці паролів;
    Confirm Password (Підтвердження) - поле, яке використовується для підтвердження правильності введеного пароля;
    User must change password at next logon (Вимагати зміну пароля при наступному вході в систему) - якщо цей прапорець встановлений, користувачеві доведеться змінити пароль при наступному вході в систему;
    User can not change password (Заборонити зміну пароля користувачем) - якщо цей прапорець встановлений, користувач не може змінити пароль;
    Password never expires (Термін дії пароля не обмежений) - якщо цей прапорець встановлений, час дії пароля для цього облікового запису не обмежена (цей параметр перекриває доменну політику облікових записів);
    Account is disabled (Відключити обліковий запис) - якщо цей прапорець встановлений, обліковий запис не діє (параметр зручний для тимчасової заборони використання будь-ким цього облікового запису).

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

Сценарії входу визначають команди, які виконуються при кожному вході в систему. Вони дозволяють налаштувати системний час, мережеві принтери, шляхи до мережевих дисків і т.д. Сценарії застосовуються для разового запуску команд, при цьому параметри середовища, що задаються сценаріями, не зберігаються для подальшого використання. Сценаріями входу можуть бути файли сервера сценаріїв Windows з расшіреніямі.VBS, .JS і інші, пакетні файли з расшіреніем.ВАТ, командні файли з расшіреніем.CMD, програми з расшіреніем.ЕХЕ.

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

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

  • створювати централізовано керовані спеціальні папки, наприклад My Documents (Мої документи);
  • керувати доступом до компонентів Windows, системним і мережевих ресурсів, інструментів панелі управління, робочого столу і меню Start (Пуск);
  • налаштувати сценарії користувачів і комп'ютерів на виконання завдання в заданий час;
  • налаштовувати політики паролів і блокування облікових записів, аудиту, присвоєння призначених для користувача прав і безпеки.

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

Оснащення Active Directory Domains and Trusts (Active Directory - домени і довіра), щоб виконувати завдання доменами, деревами доменів і лісами доменів.

Оснащення Active Directory Sites and Services (Active Directory - сайти і служби) дозволяє управляти сайтами і подсетями, а так само межсайтовой репликацией.

Для управління об'єктами AD існують засоби командного рядка, які дозволяють здійснювати широкий спектр адміністративних завдань:

  • Dsadd - додає в Active Directory комп'ютери, контакти, групи, організаційні підрозділи та користувачів. Для отримання довідкової інформації введіть dsadd /? , Наприклад dsadd computer /?
  • Dsmod - змінює властивості комп'ютерів, контактів, груп, організаційних підрозділів, користувачів і серверів, зареєстрованих в Active Directory. Для отримання довідкової інформації введіть dsmod /? , Наприклад dsmod server /?
  • Dsmove - переміщує одиночний об'єкт в нове розташування в межах домену або перейменовує об'єкт без переміщення.
  • Dsget - відображає властивості комп'ютерів, контактів, груп, організаційних підрозділів, користувачів, сайтів, підмереж і серверів, зареєстрованих в Active Directory. Для отримання довідкової інформації введіть dsget /? , Наприклад dsget subnet /?
  • Dsquery - здійснює пошук комп'ютерів, контактів, груп, організаційних підрозділів, користувачів, сайтів, підмереж і серверів в Active Directory за заданими критеріями.
  • Dsrm - видаляє об'єкт з Active Directory.
  • Ntdsutil - дозволяє переглядати інформацію про сайт, домен або сервері, управляти господарями операцій (operations masters) і обслуговувати базу даних Active Directory.

Так само існують засоби підтримки Active Directory:

  • Ldp - Здійснює в Active Directory Administration операції по протоколу LDAP.
  • Replmon - Управляє репликацией і відображає її результати в графічному інтерфейсі.
  • Dsacls - Управляє списками ACL (списками управління доступом) для об'єктів Active Directory.
  • Dfsutil - Управляє розподіленої файлової системою (Distributed File System, DFS) і відображає відомості про її роботі.
  • Dnscmd - Управляє властивостями серверів, зон і записів ресурсів DNS.
  • Movetree - переміщує об'єкти з одного домену в інший.
  • Repadmin - Управляє репликацией і відображає її результати у вікні командного рядка.
  • Sdcbeck - Аналізує поширення, реплікацію і успадкування списків управління доступом.
  • Sidwalker - Задає списки управління доступом для об'єктів, в минулому належали переміщеним, віддаленим або втраченим облікових записів.
  • Netdom - Дозволяє управляти доменами і довірчими стосунками з командного рядка.

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

THE BELL

Є ті, хто прочитали цю новину раніше вас.
Підпишіться, щоб отримувати статті свіжими.
Email
ім'я
Прізвище
Як ви хочете читати The Bell
без спаму