Развёртывание Active Directory с нуля для офиса на 30 человек
Инфраструктура · 16 мин чтения · Семёнов Е.С., руководитель ITfresh

Развёртывание Active Directory с нуля для компании на 30 человек

Развёртывание Active Directory с нуля для компании на 30 человек

Знаете, к нам в ITfresh частенько приходят молодые, но уже активно растущие компании. Вот они выросли с пяти человек до тридцати и вдруг понимают: управлять учётками по принципу «у каждого свой пароль на ноутбуке» — это уже просто невозможно! Именно для таких случаев мы и подготовили этот материал. Это такой пошаговый план, по которому мы за одну рабочую неделю превращаем полный хаос из рабочих групп в прекрасно управляемый домен Active Directory на Windows Server 2022. Никакой воды, только суть, все команды PowerShell и реальные значения параметров, которые мы используем для наших клиентов.

Зачем малой компании Active Directory

Когда сотрудников 5-10, на peer-to-peer ещё можно жить: расшаренные папки, локальные учётные записи, общая почта в облаке. Но к 25-30 сотрудникам начинается боль:

Именно AD решает все эти задачи разом, да ещё и с запасом! Вы получаете единую базу пользователей, мощные групповые политики, централизованное управление всеми сетевыми ресурсами и, что немаловажно, прозрачный и понятный аудит. А бонусом — корректную работу сервера 1С, файлового сервера на DFS, сетевых принтеров через Print Management и целой кучи других нужных сервисов.

Подготовка: что должно быть на столе до начала работ

Перед стартом проекта я согласовываю с заказчиком:

Что касается железа, то для офиса на 30 человек я всегда ставлю два виртуальных контроллера домена, размещая их на разных физических хостах гипервизора. Минимальные требования для каждого DC таковы: 4 vCPU, 8 GB RAM, 80 GB SSD под систему и ещё 40 GB под NTDS, SYSVOL и логи. Поверьте, этого хватит с хорошим запасом на 5-7 лет роста компании.

Этап 1. Базовая настройка первого сервера

Лично я предпочитаю ставить Windows Server 2022 Standard в редакции Desktop Experience. Server Core я, конечно, очень люблю, но для небольшого офиса, где администратор заказчика тоже будет периодически заходить, графический интерфейс (GUI) всё-таки удобнее и понятнее. После установки я сразу же выполняю первые команды:

# Переименовать сервер
Rename-Computer -NewName "DC01" -Restart

# После перезагрузки — настроить статический IP
New-NetIPAddress -InterfaceAlias "Ethernet0" `
  -IPAddress 192.168.20.10 `
  -PrefixLength 24 `
  -DefaultGateway 192.168.20.1

# DNS пока на самого себя через 127.0.0.1 (заменим после установки роли)
Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" `
  -ServerAddresses ("127.0.0.1")

# Часовой пояс Москва
Set-TimeZone -Id "Russian Standard Time"

# Все доступные обновления — критично перед dcpromo
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -AcceptAll -Install -AutoReboot

После всех обновлений я выполняю проверку дисков, отключаю IPv6 на интерфейсе (если он не используется в инфраструктуре — иначе AD начнёт выдавать предупреждения о динамической регистрации) и убеждаюсь, что Windows Defender активен и базы свежие.

Этап 2. Установка роли AD DS

Установка всегда проходит в два простых шага: сначала мы добавляем нужную роль, а затем запускаем повышение сервера до контроллера домена.

# Установка роли AD DS вместе с инструментами управления
Install-WindowsFeature -Name AD-Domain-Services `
  -IncludeManagementTools

# Установка роли DNS — без него dcpromo всё равно поставит, но явно лучше
Install-WindowsFeature -Name DNS -IncludeManagementTools

Теперь повышаем сервер до DC и создаём новый лес. Это эквивалент классического dcpromo, но в современной форме:

$DSRMPassword = ConvertTo-SecureString "СложныйПарольDSRM!2026" -AsPlainText -Force

Install-ADDSForest `
  -DomainName "corp.company.ru" `
  -DomainNetbiosName "CORP" `
  -DomainMode "WinThreshold" `
  -ForestMode "WinThreshold" `
  -InstallDns:$true `
  -DatabasePath "C:\Windows\NTDS" `
  -LogPath "C:\Windows\NTDS" `
  -SysvolPath "C:\Windows\SYSVOL" `
  -SafeModeAdministratorPassword $DSRMPassword `
  -NoRebootOnCompletion:$false `
  -Force:$true

Параметр WinThreshold — это уровень функциональности «Windows Server 2016», который остаётся максимальным для лесов AD до сих пор (даже на Windows Server 2025). Microsoft не повышала функциональный уровень с 2016 года — все новые фичи едут отдельно, а не через раздутие FFL.

После перезагрузки сервер становится контроллером домена. Проверяю работоспособность:

# Состояние DC
dcdiag /v /c

# Проверка SYSVOL и DFSR
Get-DfsrState
Get-DfsrMembership -GroupName "Domain System Volume"

# Проверка репликации (для одного DC покажет, что реплицировать не с кем)
repadmin /replsummary

# Проверка DNS
nslookup corp.company.ru
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.company.ru

На этом моменте у нас есть рабочий домен с одним контроллером. Дальше — структура и второй DC.

Этап 3. Проектирование OU и групп безопасности

Поверьте моему опыту, грамотно построенная структура OU — это уже половина успеха всего проекта. Я никогда не оставляю пользователей в стандартном контейнере CN=Users, потому что на него, к сожалению, нельзя привязать GPO. Вот мой стандартный шаблон, который я обычно разворачиваю для офиса на 30 человек:

$Domain = "DC=corp,DC=company,DC=ru"

# Корневые OU
New-ADOrganizationalUnit -Name "Sotrudniki" -Path $Domain -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Workstations" -Path $Domain -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Servers" -Path $Domain -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Groups" -Path $Domain -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "ServiceAccounts" -Path $Domain -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "PrivilegedAccounts" -Path $Domain -ProtectedFromAccidentalDeletion $true

# Подразделения внутри Sotrudniki
$DepartmentsPath = "OU=Sotrudniki,$Domain"
"Buhgalteria","Prodazhi","Marketing","IT","Rukovodstvo","Razrabotka" |
  ForEach-Object {
    New-ADOrganizationalUnit -Name $_ -Path $DepartmentsPath -ProtectedFromAccidentalDeletion $true
  }

# Зеркальная структура для Workstations
$WSPath = "OU=Workstations,$Domain"
"Buhgalteria","Prodazhi","Marketing","Rukovodstvo","Razrabotka" |
  ForEach-Object {
    New-ADOrganizationalUnit -Name $_ -Path $WSPath -ProtectedFromAccidentalDeletion $true
  }

# Серверные OU
$SrvPath = "OU=Servers,$Domain"
New-ADOrganizationalUnit -Name "FileServers" -Path $SrvPath -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "1C" -Path $SrvPath -ProtectedFromAccidentalDeletion $true
New-ADOrganizationalUnit -Name "Apps" -Path $SrvPath -ProtectedFromAccidentalDeletion $true

Группы безопасности я создаю по модели AGDLP (Account → Global → Domain Local → Permission). Для каждого подразделения — Global-группа с пользователями, а на ресурсах права назначаются через Domain Local-группы:

$GroupsPath = "OU=Groups,DC=corp,DC=company,DC=ru"

# Глобальные группы — содержат пользователей
"GG_Buhgalteria","GG_Prodazhi","GG_Marketing","GG_IT","GG_Rukovodstvo" |
  ForEach-Object {
    New-ADGroup -Name $_ -GroupScope Global -GroupCategory Security -Path $GroupsPath
  }

# Domain Local группы — назначаются на ресурсы (примеры)
"DL_Share_Buh_Read","DL_Share_Buh_Modify",
"DL_Share_Common_Read","DL_Share_Common_Modify",
"DL_1C_Buh_Users","DL_1C_Sales_Users" |
  ForEach-Object {
    New-ADGroup -Name $_ -GroupScope DomainLocal -GroupCategory Security -Path $GroupsPath
  }

# Связываем
Add-ADGroupMember -Identity "DL_Share_Buh_Modify" -Members "GG_Buhgalteria"
Add-ADGroupMember -Identity "DL_Share_Common_Read" -Members "GG_Buhgalteria","GG_Prodazhi","GG_Marketing","GG_Rukovodstvo"

Этап 4. Заведение пользователей

Когда структура готова, заводим учётки. Я никогда не делаю это руками через ADUC при создании 30+ учёток — только импорт из CSV:

$Users = Import-Csv -Path "C:\install\users.csv" -Delimiter ";" -Encoding UTF8

foreach ($User in $Users) {
    $UPN = "$($User.Login)@corp.company.ru"
    $Password = ConvertTo-SecureString $User.InitialPassword -AsPlainText -Force
    $OUPath = "OU=$($User.Department),OU=Sotrudniki,DC=corp,DC=company,DC=ru"

    New-ADUser `
      -Name "$($User.Surname) $($User.GivenName)" `
      -GivenName $User.GivenName `
      -Surname $User.Surname `
      -SamAccountName $User.Login `
      -UserPrincipalName $UPN `
      -DisplayName "$($User.Surname) $($User.GivenName)" `
      -EmailAddress $User.Email `
      -Title $User.Position `
      -Department $User.Department `
      -Office $User.Office `
      -OfficePhone $User.Phone `
      -Path $OUPath `
      -AccountPassword $Password `
      -Enabled $true `
      -ChangePasswordAtLogon $true

    # Добавление в групповую безопасность
    Add-ADGroupMember -Identity "GG_$($User.Department)" -Members $User.Login
}

В CSV-файле — колонки Login, Surname, GivenName, Email, Position, Department, Office, Phone, InitialPassword. Файл я готовлю вместе с HR заказчика, начальные пароли генерирую через [System.Web.Security.Membership]::GeneratePassword(14,3) и передаю клиенту в зашифрованном виде.

Этап 5. Установка второго контроллера домена

Один DC — это, по сути, потенциальная катастрофа. Поэтому я обязательно поднимаю второй контроллер на отдельной физической ноде гипервизора. Базовая настройка почти такая же: даём ему имя DC02, присваиваем статический IP 192.168.20.11, а в DNS-настройках сетевой карты первым указываем 192.168.20.10 (это наш DC01), а вторым — 127.0.0.1.

Install-WindowsFeature -Name AD-Domain-Services,DNS -IncludeManagementTools

$DSRMPassword = ConvertTo-SecureString "СложныйПарольDSRM!2026" -AsPlainText -Force
$Cred = Get-Credential -Message "Учётка Domain Admin"

Install-ADDSDomainController `
  -DomainName "corp.company.ru" `
  -InstallDns:$true `
  -Credential $Cred `
  -DatabasePath "C:\Windows\NTDS" `
  -LogPath "C:\Windows\NTDS" `
  -SysvolPath "C:\Windows\SYSVOL" `
  -SafeModeAdministratorPassword $DSRMPassword `
  -SiteName "Default-First-Site-Name" `
  -NoGlobalCatalog:$false `
  -ReadOnlyReplica:$false `
  -Force:$true

После перезагрузки проверяю репликацию между DC01 и DC02:

repadmin /replsummary
repadmin /showrepl
dcdiag /e /v

Если всё в порядке — на DC01 меняю DNS-настройки сетевой карты: первичный 192.168.20.11 (DC02), вторичный 127.0.0.1. На DC02 — наоборот. Это правильная схема: каждый DC спрашивает «соседа», а себя как fallback.

Этап 6. Распределение FSMO-ролей

В лесу AD есть пять важных ролей хозяина операций, их ещё называют FSMO: это Schema Master, Domain Naming Master, RID Master, PDC Emulator и Infrastructure Master. По умолчанию все они всегда находятся на первом контроллере домена. В офисе на 30 человек я обычно оставляю их все на DC01, но всегда тщательно проверяю, что они действительно там, и самое главное — что я прекрасно знаю, как их перенести, если вдруг возникнет такая необходимость.

# Где сейчас FSMO
netdom query fsmo

# Перенос (graceful) — если планово
Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC02" `
  -OperationMasterRole PDCEmulator,RIDMaster,InfrastructureMaster,SchemaMaster,DomainNamingMaster

# Захват (seize) — только если DC1 умер и не вернётся
Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC02" `
  -OperationMasterRole PDCEmulator -Force

PDC Emulator — это сервер, на который должна быть направлена внешняя синхронизация времени. Настраиваю NTP только на держателе PDC, остальные DC синхронизируются с ним по умолчанию:

# На DC, держателе PDC Emulator
w32tm /config /manualpeerlist:"pool.ntp.org,0x9 time.windows.com,0x9" `
  /syncfromflags:manual /reliable:yes /update
Restart-Service w32time
w32tm /resync /force
w32tm /query /status

Этап 7. DNS — корректная настройка под AD

DNS в AD — это нервная система. Все клиенты находят DC через SRV-записи в зоне домена. Проверяю и настраиваю:

# Создаём reverse-зону для адресного плана пользователей и серверов
Add-DnsServerPrimaryZone -NetworkId "192.168.20.0/24" -ReplicationScope "Domain"
Add-DnsServerPrimaryZone -NetworkId "192.168.10.0/24" -ReplicationScope "Domain"

# Включаем scavenging (очистка устаревших записей) — раз в 7 дней
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 `
  -ApplyOnAllZones

# Forwarders для разрешения внешних имён — Yandex и Cloudflare
Set-DnsServerForwarder -IPAddress 77.88.8.8,1.1.1.1

Я никогда не использую публичный DNS Гугла (8.8.8.8) у российских клиентов — слишком долгие пинги и риск замедления резолвинга в рабочее время.

Этап 8. DHCP — на отдельной роли с failover

Для офиса на 30 человек DHCP я настраиваю одним из двух проверенных способов. Либо я ставлю роль DHCP на оба DC с настроенным failover в режиме Hot-Standby, либо настраиваю DHCP прямо на роутере (например, на MikroTik с failover между двумя устройствами) и оставляю серверы исключительно под AD. Первый вариант — это классика для Windows-инфраструктур, а второй — когда хочется немного снять нагрузку с контроллеров домена.

Install-WindowsFeature -Name DHCP -IncludeManagementTools

# Авторизация в AD
Add-DhcpServerInDC -DnsName "DC01.corp.company.ru" -IPAddress 192.168.20.10
Add-DhcpServerInDC -DnsName "DC02.corp.company.ru" -IPAddress 192.168.20.11

# Создание области для пользовательской подсети
Add-DhcpServerv4Scope -Name "Users-VLAN10" `
  -StartRange 192.168.10.50 `
  -EndRange 192.168.10.250 `
  -SubnetMask 255.255.255.0 `
  -State Active `
  -LeaseDuration 8.00:00:00

Set-DhcpServerv4OptionValue -ScopeId 192.168.10.0 `
  -DnsServer 192.168.20.10,192.168.20.11 `
  -DnsDomain "corp.company.ru" `
  -Router 192.168.10.1

# Failover Hot-Standby между DC01 и DC02
Add-DhcpServerv4Failover -ComputerName "DC01.corp.company.ru" `
  -PartnerServer "DC02.corp.company.ru" `
  -Name "DHCP-Failover-Users" `
  -ScopeId 192.168.10.0 `
  -SharedSecret "ОченьДлинныйСекретДляФейловера2026!" `
  -Mode HotStandby `
  -ServerRole Active `
  -ReservePercent 20

Этап 9. Базовые групповые политики (GPO)

Из коробки в AD создаются две дефолтные политики: Default Domain Policy и Default Domain Controllers Policy. Их я не трогаю — это плохая практика. Создаю отдельные GPO под конкретные задачи:

  1. GPO «Password Policy». Привязана к корню домена. Минимальная длина пароля — 12, сложность включена, история — 12, срок действия 180 дней, блокировка после 10 неудач на 15 минут.
  2. GPO «Workstation Baseline». Привязана к OU=Workstations. Запрет автозапуска USB, отключение SMBv1, включение SmartScreen, блокировка PowerShell для обычных пользователей через Constrained Language Mode, отключение LLMNR, включение SMB Signing.
  3. GPO «Server Baseline». Привязана к OU=Servers. RDP только из административной подсети, обязательный аудит, отключение неиспользуемых служб (Print Spooler на серверах БД и AD), запрет интерактивного логона для сервисных аккаунтов.
  4. GPO «Mapped Drives». Привязана к OU=Sotrudniki. Через Group Policy Preferences монтирую сетевые диски: O:\ — общий обмен (DL_Share_Common_Modify), B:\ — бухгалтерия (только для GG_Buhgalteria через Item-Level Targeting).
  5. GPO «Printers». Раздача принтеров по подразделениям через GPP Item-Level Targeting (фильтр по группе безопасности).
  6. GPO «BGInfo». Информация о компьютере на рабочем столе для удобной службы поддержки — имя ПК, IP, залогиненный пользователь.

Все GPO создаются и тестируются на одной тестовой OU перед привязкой к боевой:

New-GPO -Name "Workstation Baseline" -Comment "ITfresh, базовый hardening рабочих станций"
New-GPLink -Name "Workstation Baseline" -Target "OU=Workstations,DC=corp,DC=company,DC=ru" -LinkEnabled Yes

# Применить немедленно для теста
Invoke-GPUpdate -Computer "PC-TEST-01" -RandomDelayInMinutes 0 -Force

Этап 10. Ввод компьютеров в домен

Этот этап я планирую на вечер пятницы и субботу: чтобы в понедельник утром люди уже логинились в домен. На каждом компьютере выполняется одна команда:

$Cred = Get-Credential -Message "Доменная учётка с правом ввода"
Add-Computer -DomainName "corp.company.ru" `
  -Credential $Cred `
  -OUPath "OU=Buhgalteria,OU=Workstations,DC=corp,DC=company,DC=ru" `
  -Restart

Заранее я создаю для службы поддержки специальную группу SG_JoinComputers с делегированными правами создавать computer-объекты в нужных OU — чтобы инженеры не использовали Domain Admin для рутинной операции.

После перезагрузки на каждый ПК автоматом подкатываются GPO, монтируются сетевые диски, настраиваются принтеры. Я всегда очень тщательно проверяю, что профиль пользователя создаётся правильно, что все закладки браузера и почтовые настройки переехали без проблем. Это, на мой взгляд, ключевой UX-момент, ведь именно от него зависит, будут ли пользователи ворчать на новый домен или, наоборот, примут его с восторгом.

Этап 11. Что обязательно сделать в первый месяц после внедрения

Инженер свою работу закончил, домен прекрасно функционирует, пользователи вроде бы в восторге — но проект на этом ещё не закрыт. В течение первого месяца я обязательно выполняю следующие шаги:

На третий месяц я планирую первый плановый перезапуск наших DC по очереди, чтобы применить все накопившиеся CU. В дальнейшем этот регламент мы повторяем ежеквартально.

Типичные ошибки, которые я вижу у других подрядчиков

За 15 лет на подхвате после других интеграторов я насмотрелся на одни и те же грабли:

Все эти ошибки, конечно, можно исправить за пару дней, но вот когда домен уже целый год эксплуатируется, миграция и все эти переименования обойдутся клиенту гораздо дороже, чем весь изначальный проект.

FAQ

Часто спрашивают: нужны ли два контроллера домена для офиса на 30 человек? Мой ответ: да, обязательно! Один контроллер — это, по сути, единая точка отказа. Представьте: умрёт сервер или диск, и весь офис просто не сможет ни залогиниться, ни открыть общие папки, ни распечатать что-либо. А вот второй DC даёт нам ту самую отказоустойчивость, и для виртуальной среды это стоит сущие копейки — это же просто ещё одна VM на 4 GB RAM. Мы в ITfresh ставим минимум два DC даже для офисов, где работает всего 10-15 человек.

А какую версию Windows Server выбрать, скажем, в 2026 году? Я бы сказал так: Windows Server 2022 — это основной выбор для всех новых проектов. Он проверен временем, его поддержка продлится до 2031 года, и он стабильно работает с любым гипервизором. Windows Server 2025 стоит рассматривать, если заказчик очень хочет максимально свежий стек технологий или планирует использовать SMB over QUIC. А вот Windows Server 2019 я лично ставлю только в тех случаях, когда у клиента есть жёсткие требования по совместимости со старым программным обеспечением.

Можно ли совместить AD DS, DNS и DHCP на одном сервере? Что касается DNS — да, это штатная конфигурация, и без локального DNS Active Directory, по сути, не работает. DHCP технически совместить, конечно, можно. Но на практике мы предпочитаем выносить его либо на отдельную VM, либо на роутер MikroTik с failover между двумя устройствами. Это помогает снять нагрузку с DC и значительно упрощает обновление контроллеров домена без необходимости перезагружать всю сеть.

Как же назвать домен, чтобы потом не схватить проблем? Вот мой главный совет: никогда, слышите, никогда не называйте домен реальным внешним доменом вашей компании (например, company.ru). Иначе получите split-brain DNS и кучу головной боли с почтой! Всегда используйте поддомен внешнего домена: например, corp.company.ru или ad.company.ru. И ни в коем случае не используйте .local — этот суффикс зарезервирован для mDNS (Bonjour) и может сломать работу некоторых приложений. А NetBIOS-имя пишите латиницей, до 15 символов и без всяких дефисов.

Сколько же времени и денег займёт развёртывание AD под ключ? Для офиса на 30 человек это обычно занимает 3-5 рабочих дней работы инженера. Сюда мы включаем всё: проектирование, развёртывание двух DC, настройку DNS/DHCP, миграцию всех учёток из рабочих групп, базовые GPO, заведение пользователей, ввод компьютеров в домен и, конечно же, обучение администратора заказчика. У нас в ITfresh такая разовая работа по тарифу обойдётся в 60-100 тысяч рублей — конечная цена зависит от того, есть ли у вас уже серверное железо.

Развернём Active Directory под ключ за рабочую неделю

Семёнов Е.С. и вся команда ITfresh готовы помочь вам с проектированием, развёртыванием двух контроллеров на Windows Server 2022, настройкой OU и GPO, миграцией учёток и обучением вашего администратора. Выбирайте, что вам удобнее: разовая работа или полный аутсорсинг!

Похожие статьи

Подпишитесь на рассылку ITfresh

Раз в неделю — практические гайды для руководителя IT и сисадмина: безопасность, 1С, миграции, резервные копии, лайфхаки из реальных проектов.

Реквизиты оператора персональных данных

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.