Створення нового домену Active Directory

Новий домен Active Directory усередині наявного forest створює окремий DNS namespace, власний набір domain controllers, domain administrators, policies та directory partition. Наприклад, forest `ad.example.com` може отримати дочірній домен `branch.ad.example.com`. Між доменами автоматично формується двосторонній transitive trust, але кожен домен має власні об’єкти, Domain Admins і реплікацію своєї domain partition.

Такий крок значно складніший за створення Organizational Unit. Новий домен потребує окремих контролерів, DNS, резервного копіювання, моніторингу та recovery-процедури. Тому його не варто створювати лише для нового відділу, офісу або набору Group Policy. У більшості випадків OU, delegation і AD Sites дають потрібний поділ без розширення доменної топології.

У цій інструкції створимо child domain `branch.ad.example.com` у forest `ad.example.com` на Windows Server 2022. Сервер матиме ім’я `CHDC01`, а NetBIOS-ім’я нового домену — `BRANCH`. Якщо базовий forest ще не розгорнутий, спочатку виконайте інструкцію зі встановлення Active Directory на Windows Server 2022. Для проєктування доменної топології можна залучити системне адміністрування ITheal, а регулярний супровід контролерів включити в адміністрування Windows та Linux серверів.

Коли потрібен новий домен, а коли достатньо OU

Child domain доцільний, коли потрібна окрема DNS-назва та довготривала administrative boundary всередині спільного forest, є вимоги до локальних domain administrators або велика автономна частина інфраструктури має власний життєвий цикл. Ще один сценарій — поетапна міграція середовища, де об’єкти певного namespace повинні переноситися окремо. Навіть у цих випадках потрібно оцінити складність trust, Global Catalog, Universal Groups, DNS delegation, backup і forest-wide ролей.

Новий домен не створює security boundary, рівнозначну окремому forest. Enterprise Admins та інші forest-level principals зберігають широкі можливості у всіх доменах forest. Schema й Configuration partitions також спільні. Якщо потрібна жорстка ізоляція адміністраторів, окрема schema або незалежне відновлення, слід оцінювати окремий forest, а не child domain.

Для звичайного організаційного поділу використовуйте OU. На OU можна делегувати reset passwords, керування computers або окремими групами, а також прив’язати Group Policy. Філії з повільними каналами описуються через Active Directory Sites and Services та subnet objects; створювати для кожної локації домен не потрібно.

Перед затвердженням child domain письмово дайте відповіді на запитання:

- чому OU та delegation недостатні; - хто відповідає за DNS і domain controllers нового домену; - де розташовуватимуться щонайменше два DC; - як виконуватимуться system state backup і domain recovery; - які групи отримають administrative access; - як зміниться application authentication і UPN naming; - чи вистачає пропускної здатності для initial та звичайної replication.

Після створення child domain видалити його без наслідків значно складніше, ніж OU. Назва також стане частиною service records, permissions, certificates та інтеграцій. Вибір має бути архітектурним, а не тимчасовим способом упорядкувати users.

Підготовка сервера, DNS і прав

Для створення child domain потрібен обліковий запис із правами Enterprise Admins у forest. Не використовуйте цей привілейований account для щоденної роботи. Входьте ним лише на захищеному administrative host або безпосередньо під час promotion, після чого завершуйте сесію.

Новий Windows Server 2022 повинен мати актуальні updates, унікальний hostname, статичну IP-адресу та коректний час. До promotion його DNS client має вказувати на доступні DNS servers parent domain, а не на public resolvers і не на власну адресу майбутнього DC. Для прикладу parent DC працює на `10.20.0.10`, а новий сервер отримує `10.30.0.10/24`:

Rename-Computer -NewName "CHDC01" -Restart

Після restart відкрийте PowerShell від імені Administrator, перевірте interface alias і задайте мережу. Зміни через віддалену сесію виконуйте лише за наявності console або out-of-band доступу:

New-NetIPAddress `
  -InterfaceAlias "Ethernet" `
  -IPAddress "10.30.0.10" `
  -PrefixLength 24 `
  -DefaultGateway "10.30.0.1"

Set-DnsClientServerAddress `
  -InterfaceAlias "Ethernet" `
  -ServerAddresses "10.20.0.10"

Перевірте, що сервер знаходить parent domain, LDAP SRV records і конкретний source DC:

Resolve-DnsName "ad.example.com"
Resolve-DnsName -Type SRV "_ldap._tcp.dc._msdcs.ad.example.com"
Test-NetConnection "DC01.ad.example.com" -Port 53
Test-NetConnection "DC01.ad.example.com" -Port 389

Однієї перевірки TCP 389 недостатньо: AD replication, Kerberos, DNS, SMB і RPC використовують кілька протоколів та dynamic RPC ports. Між sites мають бути дозволені потоки відповідно до документованої мережевої політики. NAT між domain controllers і фільтрація, що пропускає лише LDAP, створюють нестабільну конфігурацію.

В Active Directory Sites and Services заздалегідь створіть site і subnet `10.30.0.0/24`, якщо child DC розміщується в новій локації. Інакше promotion може прив’язати сервер до невідповідного site, а replication topology обиратиме неочікувані partners.

Перед зміною forest перевірте здоров’я чинних контролерів:

dcdiag /e /q
repadmin /replsummary
repadmin /showrepl

Порожній output `dcdiag /e /q` означає відсутність виявлених errors. Не створюйте новий домен поверх уже зламаної DNS або replication: promotion може завершитися частково, а діагностика стане складнішою.

Встановлення ролі та створення child domain

На `CHDC01` встановіть AD DS і management tools. Саме встановлення ролі ще не змінює forest:

Install-WindowsFeature `
  -Name AD-Domain-Services `
  -IncludeManagementTools

Get-WindowsFeature AD-Domain-Services
Get-Command -Module ADDSDeployment

Підготуйте два secure values: credentials Enterprise Admin і окремий пароль Directory Services Restore Mode для нового DC. Не записуйте passwords у script або plain-text variable:

$EnterpriseCredential = Get-Credential "AD\ForestAdmin"
$DsrmPassword = Read-Host `
  -Prompt "Введіть окремий пароль DSRM" `
  -AsSecureString

Запустіть prerequisite check із тими самими ключовими параметрами, які використовуватиме installation. Для child domain значення `NewDomainName` — одна DNS-label `branch`, а `ParentDomainName` — повний FQDN parent domain:

Test-ADDSDomainInstallation `
  -DomainType "ChildDomain" `
  -NewDomainName "branch" `
  -NewDomainNetbiosName "BRANCH" `
  -ParentDomainName "ad.example.com" `
  -Credential $EnterpriseCredential `
  -InstallDns `
  -CreateDnsDelegation `
  -SiteName "Branch-Site" `
  -SafeModeAdministratorPassword $DsrmPassword

`CreateDnsDelegation` створює delegation з parent zone до DNS server нового child domain. Якщо parent DNS не інтегрований з AD, delegation може потребувати ручного створення адміністратором authoritative DNS. Не ігноруйте warning автоматично: переконайтеся, що клієнти parent domain справді зможуть знайти authoritative DNS для `branch.ad.example.com`.

Після успішного тесту запустіть promotion. Domain functional level не може бути нижчим за forest functional level. Для forest на рівні Windows Server 2016 використовуйте `Win2016`:

Install-ADDSDomain `
  -DomainType "ChildDomain" `
  -NewDomainName "branch" `
  -NewDomainNetbiosName "BRANCH" `
  -ParentDomainName "ad.example.com" `
  -DomainMode "Win2016" `
  -Credential $EnterpriseCredential `
  -InstallDns `
  -CreateDnsDelegation `
  -SiteName "Branch-Site" `
  -SafeModeAdministratorPassword $DsrmPassword

Перевірте summary і підтвердьте операцію. Не додавайте `-SkipPreChecks`; Microsoft не рекомендує обходити prerequisite phase. Сервер автоматично перезавантажиться. Не зупиняйте promotion після початку й не використовуйте `-NoRebootOnCompletion` у звичайному deployment: до restart сервер не працюватиме коректно ні як member server, ні як DC.

У Server Manager той самий сценарій починається з `Promote this server to a domain controller`. Виберіть `Add a new domain to an existing forest`, тип `Child Domain`, parent `ad.example.com` і new domain name `branch`. На Review Options експортуйте PowerShell script для документації, але не зберігайте в ньому DSRM password.

Перевірка DNS, trust і replication

Після reboot увійдіть як `BRANCH\Administrator` або використайте дозволений administrative account. Перевірте, що сервер бачить правильні domain і forest, публікує SYSVOL та NETLOGON і зареєстрований як DC:

Get-ADDomain
Get-ADForest
Get-ADDomainController -Filter *
Get-SmbShare -Name SYSVOL, NETLOGON
Get-Service ADWS, DNS, DFSR, KDC, Netlogon

`Get-ADDomain` має повертати `branch.ad.example.com`, а forest root залишається `ad.example.com`. Перевірте DNS records child domain і delegation із parent namespace:

Resolve-DnsName -Type NS "branch.ad.example.com"
Resolve-DnsName -Type SRV "_ldap._tcp.dc._msdcs.branch.ad.example.com"
Resolve-DnsName -Type SRV "_kerberos._tcp.branch.ad.example.com"

Запустіть діагностику локального DC і DNS, потім forest-wide replication summary:

dcdiag /v
dcdiag /test:DNS /v
repadmin /showrepl
repadmin /replsummary

Зверніть увагу на inbound neighbors для Configuration, Schema, forest DNS partitions і domain-specific partitions. Domain partition parent domain не реплікується як повна writable копія на child DC, але Global Catalog зберігає partial attribute set об’єктів інших доменів. Це нормальна відмінність, а не ознака втрати даних.

Перевірте автоматичний trust з обох сторін і пошук domain controllers:

Get-ADTrust -Filter *
nltest /domain_trusts
nltest /dsgetdc:branch.ad.example.com
nltest /dsgetdc:ad.example.com

Не вважайте перший успішний logon завершенням робіт. Додайте другий writable DC із DNS безпосередньо до `branch.ad.example.com`, бажано на іншому host або в іншій зоні відмови. Для цього використовується `Install-ADDSDomainController`, а не повторний `Install-ADDSDomain`. Після promotion другого DC знову перевірте `repadmin`, DNS і DFS Replication events.

Створіть OU-структуру нового домену, окремі privileged accounts та delegation за принципом найменших прав. Налаштуйте system state backup обох child DC, централізований збір Directory Service, DNS Server і DFS Replication events, а також alerts на replication errors. Окремо задокументуйте видалення останнього DC: випадкове demotion останнього контролера фактично видаляє домен.

Типові помилки

Перша помилка — створювати домен замість OU. Новий домен додає DNS, DC, backup і recovery obligations, але не дає незалежної від forest security boundary. Якщо потрібні лише policy та delegation, використовуйте OU.

Друга — вказати public DNS на майбутньому DC. До promotion сервер має використовувати DNS parent domain, інакше він не знайде SRV records, Enterprise Admin credentials або replication source.

Третя — передати повний FQDN у `NewDomainName` для `ChildDomain`. Для child domain цей параметр містить одну label `branch`, тоді як `ParentDomainName` містить `ad.example.com`. Повний FQDN у `NewDomainName` використовується для `TreeDomain`.

Четверта — створювати child domain при наявних `dcdiag` або `repadmin` errors. Спочатку відновіть DNS і replication чинного forest, і лише потім змінюйте topology.

П’ята — не створити DNS delegation або не перевірити її з parent network. Локальний child DC може працювати, але clients і DC інших доменів не знаходитимуть child namespace.

Шоста — використовувати один child DC. Відмова єдиного сервера забирає local DNS, authentication і writable copy domain partition. Потрібні щонайменше два DC, system state backup і протестована recovery-процедура.

Сьома — залишити Enterprise Admin credential у script або використовувати forest-level account щодня. Вводьте credentials інтерактивно, обмежуйте privileged sessions і делегуйте рутинні операції на нижчому рівні.

Восьма — плутати child domain із новим tree domain. Child успадковує contiguous namespace `branch.ad.example.com`; tree domain має інший DNS root, наприклад `example.net`, але залишається в тому самому forest. Перед вибором зафіксуйте потрібну namespace topology.

Висновок

Створення нового домену Active Directory — це зміна topology всього forest, а не спосіб додати ще одну administrative папку. Спочатку доведіть, що OU, delegation і Sites не розв’язують задачу. Потім підготуйте щонайменше два DC, DNS delegation, статичні addresses, site/subnet, backup і recovery plan.

Для child domain на Windows Server 2022 встановіть `AD-Domain-Services`, перевірте параметри через `Test-ADDSDomainInstallation` і виконайте `Install-ADDSDomain` з `DomainType ChildDomain`. Parent domain задається повним FQDN, а new domain — однією DNS-label. DSRM password і Enterprise Admin credentials не повинні зберігатися у відкритому script.

Після reboot перевірте SYSVOL, NETLOGON, DNS SRV records, delegation, automatic trust і replication через `dcdiag`, `repadmin` та `nltest`. Лише після чистих результатів додавайте другий контролер, OU, policies і accounts. Такий порядок дозволяє виявити topology або DNS-помилку до того, як новий домен стане залежністю для користувачів і сервісів.