Що таке контролер домену. Правильно називаємо домен Active Directory Останні штрихи на шляху до досконалості

Ця процедуранабагато складніше, ніж перейменування рядового сервера, що є звичайним членом домену. Для цього завдання нам знадобиться утиліта NETDOM", яка починаючи з Windows 2008входить до складу ОС, а для Windows 2003знадобиться встановити " Support Tools ".

Для перейменування контролера домену діємо так:
1. Спочатку переконуємось у тому, що функціональний рівень домену не нижчий Windows 2003та перевіряємо наявність прав " Domain Admins " ("Адміністратори домену ").
2. Відкриваємо командний рядок із підвищеними привілеями та додаємо для контролера додаткове ім'я, в яке ми збираємось перейменувати (у нашому прикладі SRV-DC1-OLD.TEST.LOCAL перейменовуємо в SRV-DC1.TEST.LOCAL ):

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /add:SRV-DC1.TEST.LOCAL

3. За допомогою редактора " ADSIEDIT.msc" переконуємося, що ім'я додано коректно. У редакторі знаходимо об'єкт контролера домену та перевіряємо значення якості " msDS-AdditionalDnsHostName", яке має бути рівним" SRV-DC1.TEST.LOCAL ".

4. Тепер необхідно переконатись, що оновлені SPNатрибути встигли повністю реплікуватися інші контролери домену у лісі. У цьому нам допоможе утиліта. REPADMIN" або " REPLMON"для Windows 2003.

Для прискорення процесу реплікацію можна форсувати в оснастці DSSITE.msc". Просто клацніть правою кнопкою миші на підключенні та виберіть " Реплікувати зараз".

5. Тепер робимо первинним нове ім'я контролера домену:

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /makeprimary:SRV-DC1.TEST.LOCAL

6. Перевантажуємо сервер.
7. Знову перевіряємо, що оновлені SPNатрибути та записи в DNSвстигли повністю реплікуватися на інші контролери домену та сервера DNSу лісі, а значення властивості " msDS-AdditionalDnsHostNameТепер дорівнює старому імені сервера.

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

NETDOM computername SRV-DC1.TEST.LOCAL / remove:SRV-DC1-OLD.TEST.LOCAL

9. Форсуємо або чекаємо повної реплікації, і на завершення перевантажуємо та перевіряємо прямі та зворотні доменні зони DNSнаявність записів зі старим ім'ям. Якщо знаходимо такі – видаляємо чи виправляємо за необхідності на нове ім'я. Також варто ще раз перевірити значення атрибута msDS-AdditionalDnsHostName", яке має бути порожнім.

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

Коротше кажучи, 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. Щоб підвищити статус сервера до контролера домену, необхідно переконатися у виконанні всіх необхідних для цього вимог:

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

Розглянемо докладно підвищення ролі сервера до контролера домену 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 – стандартний контейнер для користувачів.

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

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

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

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

Введіть ім'я, ініціал та прізвище користувача у відповідних полях. Ці дані потрібні для створення відображеного імені користувача.
Відредагуйте повне ім'я. Воно має бути унікальним у домені та мати довжину не більше 64 символів.
Введіть ім'я входу. За допомогою розкривного списку виберіть домен, з яким буде пов'язаний обліковий запис.
У разі потреби змініть ім'я користувача для входу в систему з Windows NT 4.0 або ранніми версіями. За промовчанням як ім'я для входу до системи з попередніми версіями Windowsвикористовуються перші 20 символів повного імені користувача. Це ім'я також має бути унікальним у домені.
Клацніть Next (Далі). Вкажіть пароль користувача. Його параметри повинні відповідати вашій політиці паролів;
Confirm Password (Підтвердження) – поле, яке використовується для підтвердження правильності введеного пароля;
User must change password at next logon(Вимагати зміну пароля під час наступного входу в систему) – якщо цей прапорець встановлений, користувачеві доведеться змінити пароль при наступному вході до системи;
User cannot 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 дозволяє істотно знизити витрати адміністративних завдань за рахунок централізації управління доменними обліковими записами комп'ютерів та користувачів, а також дозволяє гнучко керувати правами користувачів, безпекою та масою інших параметрів. Докладніші матеріали з організації доменів можна знайти у відповідній літературі.

На подвір'ї 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 і ні в чому більше. Однак наслідки, які спричинить неправильний вибір імені, в майбутньому завдадуть вам чимало проблем і тому на етапі планування дуже важливо все зробити якісно. Зайвий раз непогано почитати статті бувалих адмінів

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

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

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

Функціональний рівень лісу 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» ( На всіх DNS серверах керування домашніми контролерами в цьому будинку: 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

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

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

Помилки у виборі імені Active Directory

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

Я впевнений, що більшість з вас знають, що DNS імена в інтернеті будуються за певним принципом, воно складається тільки з цифр, літер, точок і тире. різні видизаписів DNS я не говорю)..com. Є стандарт із документа RFC 1123 про іменування доменів, де чорним по білому прописано, що в назвах не повинні бути присутні такі спецсимволи: знак собаки @, тильда ~, знак номера #, слеш / і \, нижнє підкреслення, якщо ви за своїм незнанням як доменного імені вибрали, що те, що містить нижнє підкреслення, то у вас наприклад будуть великі проблеми з поштовим сервером MS Exchange. Якби не було стандартів, то був би хаос.
Як локальні імена Active Directory, люди вибирають зовнішні адреси, точніше імена другого рівня. Простий приклад, у мене допустимо є підприємство Pyatilistnik.inc і адміністратор вирішив встановити контролер Active Directory і створити доменну структуру, але як локальне ім'я для нього він узяв pyatilistnik. Уявіть який хаос почнеться, коли людям потрібно буде до нього достукатися з локальної мережі, буде конфлікт з ім'ям AD, щоб вирішити проблему доведеться тримати і зовнішню зону DNS і внутрішню, що не зручно і призведе до помилок. Нижче я розповім, як правильно назвати домен active directory
Імена зон, що не входять до глобального офіційно зареєстрованого реєстру ICANN.Прикладами може служити зони.local або наприклад.nn, хоча я впевнений, що і до них дійде стандарт, тому що даній організації вигідно робити гроші з повітря, продаючи імена, яких зараз доменів не зустрінеш, але сьогодні не про це. Ці імена неправильно використовувати в Activer Directory, оскільки їх не можна буде використовувати поза вашою контори, не можна буде випустити ssl сертифікат на домен .

Хоча якщо ви робите це у тестовому середовищі, то можна

Disjoint Namespace > бувають ситуації, коли DNS ім'я контролера домену або комп'ютера не збігаються з його ім'ям NETBIOS, наприклад якщо б у мене контролер мав NETBIOS ім'я dc6, а доменне dc.сайт. Такі конструкції працездатні і можуть бути при злитті підприємств, але при Disjoint Namespace можуть бути граблі з тим же MS Exchenge. Нижче є приклад збігу і NETBIOS і DNS імені.

Як правильно назвати домен active directory

Як неправильно робити ми зрозуміли і знаємо, зробимо тепер все красиво, одразу повторюся, що якщо у вас тестове середовище називати AD, ви можете як вам захочеться, хоч microsoft.com. А якщо серйозно, то повернемося до нашої компанії Pyatilistnik.inc. Для доменної зони Active Directory я вибрав би зону третього рівня, ad.сайт. Веб-сайт компанії повісив би на логічний сайт. Завдяки цьому не було б проблем із MS Exchange сервером. Якщо у вас кілька філій, то я раджу вам використати один ліс, приклад є Нижній Новгород і Москва, для Москви я вибираю сайт ad..ad. Сподіваюся, ви тепер зрозуміли як краще і правильніше називати домен Active Directory.