м. Київ, вул. Кирилівська 102

5 жовтня 2026 р.

Встановлення Active Directory на Windows Server 2022

Встановлення Active Directory на Windows Server 2022

Active Directory Domain Services перетворює окремі Windows-сервери й робочі станції на кероване середовище зі спільною автентифікацією, груповими політиками, DNS та централізованим контролем доступу. Проте встановлення ролі AD DS — лише невелика частина роботи. До підвищення сервера до domain controller потрібно правильно вибрати DNS-ім’я домену, призначити статичну адресу, перевірити час, продумати відновлення та не залишити єдиний контролер домену без резерву.

У цій інструкції створимо новий forest на Windows Server 2022 за допомогою PowerShell. Приклад використовує домен `ad.example.com`, NetBIOS-ім’я `EXAMPLE` і сервер `DC01`. Замініть ці значення на власні ще до виконання команд. Матеріал розрахований на нове середовище; додавання контролера до наявного домену потребує окремої перевірки schema, DNS, sites, replication і чинних administrative credentials.

Якщо потрібне проєктування доменної інфраструктури, міграція користувачів або супровід контролерів, ці роботи входять у системне адміністрування ITheal. Для регулярного обслуговування Windows і Linux серверів можна окремо залучити адміністрування серверної інфраструктури.

Планування домену перед встановленням AD DS

Почніть не з Server Manager, а зі схеми майбутнього середовища. DNS-ім’я Active Directory змінити значно складніше, ніж hostname звичайного сервера. Для нового forest практичним варіантом є окремий піддомен зареєстрованого домену, наприклад `ad.example.com` або `corp.example.com`. Це підтверджує контроль над namespace і не створює конфліктів із випадковими зовнішніми зонами. Однокомпонентні назви на кшталт `COMPANY` та вигадані public suffix використовувати не варто.

Внутрішній DNS і зовнішня authoritative zone виконують різні функції. Зона `ad.example.com` може обслуговуватися лише domain controllers усередині мережі, тоді як `example.com` залишається у зовнішнього DNS-провайдера. Клієнти домену повинні використовувати AD DNS, оскільки через SRV records вони знаходять LDAP, Kerberos, Global Catalog та інші служби. Public resolvers не знають цих записів і не можуть бути основним DNS для domain-joined hosts.

До початку зафіксуйте:

- FQDN forest і коротке NetBIOS-ім’я до 15 символів; - hostname, статичну IPv4-адресу, gateway і subnet кожного контролера; - AD site та підмережі для кожної локації; - джерело точного часу для PDC Emulator; - окремий пароль Directory Services Restore Mode; - спосіб system state backup і порядок forest recovery; - адресу другого domain controller в іншому fault domain.

Один domain controller допустимий лише для лабораторії. У робочому середовищі щонайменше два writable DC із DNS зменшують залежність від одного сервера. Їх не слід розміщувати на одному фізичному host, одному datastore або в одній зоні доступності. Snapshot віртуальної машини не є повноцінною заміною підтримуваного system state backup.

Підготовка Windows Server 2022, мережі та DNS

Встановіть актуальні cumulative updates, перезавантажте сервер і відкрийте PowerShell від імені Administrator. Переконайтеся, що ОС справді Windows Server 2022, а hostname та мережева конфігурація відповідають плану:

powershell
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber
Get-NetAdapter
Get-NetIPConfiguration
Get-TimeZone

Перейменуйте сервер до встановлення AD DS. Після restart перевірте нове ім’я:

powershell
Rename-Computer -NewName "DC01" -Restart

Наступні команди є прикладом для interface `Ethernet`, адреси `10.20.0.10/24` і gateway `10.20.0.1`. Спершу звірте `InterfaceAlias`, переконайтеся, що адреса вільна, і виконуйте зміну через console, iLO, iDRAC або інший out-of-band доступ: віддалена сесія може обірватися.

powershell
New-NetIPAddress `
  -InterfaceAlias "Ethernet" `
  -IPAddress "10.20.0.10" `
  -PrefixLength 24 `
  -DefaultGateway "10.20.0.1"

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

Для першого DC у новому forest DNS client тимчасово вказує на майбутню власну адресу. Після додавання другого контролера задайте кожному DC preferred DNS на партнера, а alternate — відповідно до узгодженої схеми. Не додавайте `8.8.8.8` або DNS провайдера до списку DNS client на domain controllers. Зовнішні імена AD DNS вирішуватиме через налаштовані forwarders.

Перевірте адресу, gateway і відсутність конфлікту імені:

powershell
Get-NetIPConfiguration -InterfaceAlias "Ethernet"
Test-Connection -ComputerName "10.20.0.1" -Count 2
Resolve-DnsName "DC01" -ErrorAction SilentlyContinue

Остання команда до створення DNS-зони може не знайти запис, але не повинна повертати інший host із таким ім’ям. Також перевірте синхронізацію часу з hypervisor або зовнішнім NTP. Kerberos чутливий до різниці часу, тому випадковий clock drift згодом проявляється як помилки входу, а не як очевидна проблема NTP.

Встановлення ролі та створення нового forest

Роль AD DS і локальні management tools встановлюються однією командою. На цьому етапі сервер ще не є контролером домену:

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

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

У результаті `Install State` для ролі має бути `Installed`. Далі створіть DSRM-пароль як `SecureString`. Не записуйте його у `.ps1`, ticket, README або command history у відкритому вигляді:

powershell
$DsrmPassword = Read-Host `
  -Prompt "Введіть окремий пароль DSRM" `
  -AsSecureString

Перед реальною інсталяцією запустіть prerequisite check. Він перевіряє параметри, доступність компонентів і конфігурацію, не створюючи forest:

powershell
Test-ADDSForestInstallation `
  -DomainName "ad.example.com" `
  -DomainNetbiosName "EXAMPLE" `
  -InstallDns `
  -SafeModeAdministratorPassword $DsrmPassword

Уважно прочитайте warnings. Типове попередження про неможливість створити DNS delegation може бути очікуваним для ізольованого піддомену, але network, naming чи permission errors ігнорувати не можна. Не використовуйте `-SkipPreChecks` заради швидкого проходження невдалої конфігурації.

Після успішної перевірки створіть forest. На Windows Server 2022 найновішим доступним рівнем для нового середовища є `Win2016`; назва рівня не означає, що контролер працюватиме на Windows Server 2016:

powershell
Install-ADDSForest `
  -DomainName "ad.example.com" `
  -DomainNetbiosName "EXAMPLE" `
  -ForestMode "Win2016" `
  -DomainMode "Win2016" `
  -InstallDns `
  -SafeModeAdministratorPassword $DsrmPassword

Підтвердьте операцію. Сервер установить AD DS database, SYSVOL і DNS, після чого автоматично перезавантажиться. Не додавайте `-NoRebootOnCompletion` без конкретної операційної причини: promotion завершується саме після restart. Після завантаження входьте як `EXAMPLE\Administrator` або через UPN `[email protected]`.

Для GUI-процедури аналогічні параметри доступні в Server Manager: Add Roles and Features, роль Active Directory Domain Services, потім `Promote this server to a domain controller` і `Add a new forest`. На сторінці Review Options можна експортувати PowerShell script. Незалежно від способу обов’язково дочекайтеся успішного Prerequisites Check.

Перевірка domain controller і базове налаштування

Після restart не починайте одразу створювати сотні accounts. Спершу перевірте, що контролер публікує необхідні shares, DNS records і служби:

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

Служби мають працювати, `NETLOGON` і `SYSVOL` — бути доступними, а AD cmdlets — повертати створений domain та forest. Запустіть повну діагностику і окремий DNS test з elevated console:

powershell
dcdiag /v
dcdiag /test:DNS /v

Не орієнтуйтеся лише на останній рядок output. Перевірте failed tests, DNS registration і події в журналах `Directory Service`, `DNS Server`, `DFS Replication` та `System`. Для першого DC `repadmin /replsummary` ще не покаже корисної міжсерверної реплікації; команда стане обов’язковою після появи другого контролера.

Перевірте SRV records, через які клієнти знаходять LDAP і Kerberos:

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

Налаштуйте DNS forwarders лише на перевірені resolver addresses вашої мережі або провайдера:

powershell
Set-DnsServerForwarder -IPAddress "1.1.1.1", "9.9.9.9"
Get-DnsServerForwarder

Forwarders використовуються DNS server для зовнішніх запитів; це не те саме, що додати public DNS у network adapter контролера. На клієнтах у DHCP option 006 вкажіть тільки адреси внутрішніх AD DNS servers.

Створіть власну OU-структуру замість розміщення всіх об’єктів у стандартних containers. Наприклад, окремі OU для users, workstations, servers, service accounts і privileged accounts дозволяють точніше застосовувати Group Policy та делегування. Не перейменовуйте системні containers і не прив’язуйте неперевірені GPO до кореня домену.

До приєднання масових клієнтів додайте другий Windows Server 2022 як domain controller через `Install-ADDSDomainController`, перевірте двосторонню replication та DNS. Розмістіть його окремо від `DC01`. Після цього перевіряйте:

powershell
repadmin /replsummary
repadmin /showrepl
dcdiag /e /q

Налаштуйте регулярний system state backup щонайменше для контролерів домену й перевірте процедуру відновлення в ізольованому середовищі. Загальні принципи зберігання кількох копій та тестового restore описані в матеріалі про критичність резервного копіювання. Для AD важливо документувати не лише запуск backup job, а й DSRM-доступ, порядок authoritative/non-authoritative restore та сценарій втрати всього forest.

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

Перша помилка — динамічна IP-адреса на domain controller. Після зміни lease DNS records і client settings можуть вказувати на стару адресу. Призначайте статичну адресу до promotion і резервуйте її поза DHCP pool.

Друга — public DNS у network adapter DC або domain client. Такий host іноді знаходить інтернет, але не знаходить SRV records домену, через що нестабільно працюють logon, GPO, Kerberos і domain join. Використовуйте тільки AD DNS, а зовнішні запити передавайте через forwarders.

Третя — випадкове DNS-ім’я або single-label domain. Назву forest складно змінювати, і вона впливає на certificates, UPN, applications та інтеграції. Оберіть піддомен власного namespace й задокументуйте його до встановлення.

Четверта — однаковий пароль для domain Administrator і DSRM або зберігання пароля у відкритому script. DSRM credential потрібен для аварійних процедур, тому він має бути окремим, складним, контрольовано збереженим і регулярно перевіреним за процедурою доступу.

П’ята — єдиний domain controller без system state backup. RAID, hypervisor snapshot і копія VHDX не замінюють підтримувану стратегію AD recovery. Другий DC захищає від відмови одного сервера, але не від логічного видалення, шифрування або пошкодження, що реплікується.

Шоста — пропуск prerequisite warnings і відсутність перевірки після reboot. Успішний вхід у домен ще не доводить справність DNS, SYSVOL та replication. Зберігайте результати `dcdiag`, перевіряйте event logs і усувайте errors до підключення клієнтів.

Сьома — щоденна робота під Domain Admin. Створіть окремі privileged accounts, делегуйте рутинні задачі на рівні OU, захистіть administrative workstations і не запускайте web browser або пошту в привілейованій сесії.

Висновок

Коректне встановлення Active Directory на Windows Server 2022 починається з DNS-плану, статичної адреси, стабільного часу та моделі відновлення. Після підготовки сервер отримує роль `AD-Domain-Services`, проходить `Test-ADDSForestInstallation` і підвищується через `Install-ADDSForest`. DSRM-пароль вводиться як SecureString, DNS встановлюється разом із forest, а prerequisite errors не приховуються параметром skip.

Після перезавантаження обов’язково перевірте AD services, `SYSVOL`, `NETLOGON`, SRV records і результати `dcdiag`. Потім налаштуйте forwarders, OU-структуру, окремі administrative accounts, другий domain controller і system state backup із тестовим відновленням.

Не поспішайте приєднувати всі робочі станції після першого успішного входу. Спочатку доведіть, що DNS працює лише через внутрішні resolvers, обидва контролери реплікуються, час синхронізований, а recovery-процедура задокументована. Саме ці перевірки відрізняють встановлену роль від надійної доменної інфраструктури.

📞Active Directory на Windows Server 2022 — встановлення AD DS | ITheal