Присоединение Windows Server к домену Active Directory

Чтобы присоединить Windows Server к домену Active Directory, зайдите в свойства системы, нажмите «Изменить» в разделе имени компьютера, выберите «Домен» и введите имя домена. Понадобятся учётные данные доменного администратора и сетевая связность с контроллером домена (плюс правильно настроенный DNS).

Что нужно проверить перед присоединением к домену

Тут такое дело. Нельзя просто взять и вписать имя домена. Нужна подготовка.

Контрольный список перед вводом в домен:

• DNS-сервер в сетевых настройках указывает на контроллер домена (это самое важное, без этого ничего не заработает)
• Сервер пингует контроллер домена по имени
• Время на сервере совпадает с доменным (разница больше 5 минут и Kerberos откажется работать)
• У вас есть учётка с правами на присоединение к домену
• Имя компьютера задано правильно, потому что после ввода в домен менять его сложнее

По факту 90% проблем с вводом в домен связаны с DNS. Не с доменом, не с правами. С DNS.

Мой знакомый Виктор, администратор из Самары, как-то потратил полдня на ввод сервера в домен. Оказалось, на его Supermicro SuperServer 1029U в качестве DNS был прописан 8.8.8.8 вместо адреса контроллера домена. Поменял одну строчку и всё заработало за минуту.

Способ 1: через GUI (свойства системы)

Самый понятный способ. Короче, делаем так:

1. Нажмите Win+Pause или откройте Server Manager → Local Server
2. Кликните по имени рабочей группы (обычно WORKGROUP)
3. Нажмите «Change» (Изменить)
4. Переключите радиокнопку с «Workgroup» на «Domain»
5. Введите имя домена, например contoso.local
6. Введите логин и пароль доменного администратора
7. Перезагрузите сервер

Если честно, GUI-способ подходит когда у вас один-два сервера. Для массового ввода нужен PowerShell или автоматизация.

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

Способ 2: через PowerShell

Быстрее и скриптуемо. Вот в чём прикол: одна команда заменяет все клики.

# Присоединяем сервер к домену contoso.local
# -Credential запросит логин/пароль интерактивно
Add-Computer -DomainName "contoso.local" -Credential (Get-Credential) -Restart

# Если нужно сразу поместить в конкретный OU
# Без этого сервер попадёт в контейнер Computers по умолчанию
Add-Computer -DomainName "contoso.local" `
    -OUPath "OU=Servers,DC=contoso,DC=local" `
    -Credential (Get-Credential) `
    -Restart

Обратите внимание на параметр -OUPath. На самом деле это очень полезная штука. Если у вас настроены групповые политики на определённый OU, сервер сразу получит нужные настройки.

Способ 3: через Server Manager (sconfig)

На Server Core нет графического интерфейса. Но есть sconfig.

# Запускаем конфигуратор Server Core
sconfig

# Выбираем пункт 1 - Domain/Workgroup
# Выбираем D - Domain
# Вводим имя домена
# Вводим учётные данные
# Перезагружаемся

Кстати, sconfig работает и на полной версии Windows Server с GUI. Иногда так быстрее, чем лезть в свойства системы.

Проблемы при вводе в домен и их решения

Знаете что, давайте пройдёмся по типичным ошибкам. Их немного, но они встречаются постоянно.

Ошибка «The specified domain either does not exist or could not be contacted»

Самая частая. Причины:

• DNS настроен неправильно (указывает не на контроллер домена)
• Файрвол блокирует порты (нужны 53, 88, 135, 389, 445, 636, 3268, 49152-65535)
• Нет сетевой связности с контроллером домена

# Проверяем DNS-резолвинг домена
# Должен вернуть IP контроллера домена
nslookup contoso.local

# Проверяем SRV-записи, без них домен не найдётся
# Это самая полезная диагностическая команда
nslookup -type=srv _ldap._tcp.dc._msdcs.contoso.local

# Проверяем связность с контроллером домена
Test-NetConnection -ComputerName dc01.contoso.local -Port 389

Ошибка «The specified account already exists»

Это когда компьютер с таким именем уже есть в AD. Либо вы раньше уже вводили этот сервер в домен, либо кто-то создал объект с таким именем.

Решение: удалите старый объект компьютера из AD или переименуйте сервер.

Ошибка «Access is denied»

Не хватает прав. По умолчанию обычный доменный пользователь может ввести в домен до 10 компьютеров (атрибут ms-DS-MachineAccountQuota). Но лучше использовать учётку с правами Domain Admin или делегированными правами на OU.

Грубо говоря, если видите «Access is denied» и точно вводите правильный пароль, проблема в правах.

Настройка после присоединения к домену

Ввели в домен. Что дальше?

Проверьте GPO. Откройте gpresult /r и убедитесь, что нужные политики применились. Если сервер в неправильном OU, политики будут не те.

Добавьте доменные группы в локальные. Например, группу серверных администраторов в локальную группу Administrators.

# Добавляем доменную группу в локальные админы сервера
# Теперь все из этой группы смогут управлять сервером
Add-LocalGroupMember -Group "Administrators" -Member "CONTOSOServerAdmins"

Настройте удалённое управление. Enable-PSRemoting, если ещё не включено.

А ещё не забудьте про Windows Firewall. После ввода в домен должен примениться доменный профиль брандмауэра. Проверьте, что он настроен правильно.

Автоматизация ввода серверов в домен

Когда серверов много, ручной ввод не вариант. Есть несколько подходов.

Djoin (offline domain join). Позволяет присоединить сервер к домену без сетевого подключения к контроллеру. Полезно для серверов в DMZ или при развёртывании через шаблоны.

# На контроллере домена создаём blob-файл
# Этот файл потом скопируем на целевой сервер
djoin /provision /domain contoso.local /machine SRV-WEB01 /savefile C:djoin-blob.txt

# На целевом сервере применяем blob
# Сервер войдёт в домен после перезагрузки
djoin /requestODJ /loadfile C:djoin-blob.txt /windowspath %SystemRoot% /localos

Мой коллега Алексей использовал djoin при развёртывании 15 серверов в новом филиале. Сеть между филиалами ещё не была настроена, а серверы надо было подготовить. Прогнал djoin на своём ноутбуке Lenovo ThinkPad T14s, скопировал файлы на флешку, и все серверы были готовы к работе в домене ещё до настройки VPN-канала.

Вывод сервера из домена

Иногда нужно сделать обратное. Вывести сервер из домена.

# Выводим сервер из домена, возвращаем в рабочую группу
Remove-Computer -UNJoinDomainCredential (Get-Credential) -WorkgroupName "WORKGROUP" -Restart

# Не забудьте удалить объект компьютера из AD
# Иначе он там будет висеть мёртвым грузом

Тут такое дело: перед выводом из домена убедитесь, что на сервере есть локальная учётка с правами администратора. После выхода из домена доменные учётки работать перестанут (кэшированный вход может спасти, но лучше не рисковать).

Особенности для разных версий Windows Server

Процесс одинаковый для 2016, 2019 и 2022. Разница только в интерфейсе Server Manager. На самом деле Microsoft не менял этот функционал уже много лет.

Единственное: в Windows Server 2022 по умолчанию включён TLS 1.3 и ужесточены требования к безопасности. Если у вас старый контроллер домена на 2012 R2, могут быть проблемы с совместимостью протоколов.

Вот матрица совместимости:

* Могут потребоваться дополнительные настройки совместимости протоколов.

По факту, если ваш домен ещё на 2012 R2, пора обновляться. Поддержка 2012 R2 закончилась, и каждый новый сервер будет всё сложнее вводить в такой домен.

Лицензирование Windows Server

Для работы в домене каждому серверу нужна лицензия. Без активации сервер работает 180 дней, потом начинает перезагружаться. Купить ключик можно в keytrust24.store. Standard, Datacenter, версии 2016, 2019, 2022. Активация онлайн, ключ привязывается к железу.

Ну и не забывайте про CAL-лицензии. Каждому пользователю или устройству, подключающемуся к серверу, нужна клиентская лицензия. Это отдельная тема, но она важная.

Подготовка DNS перед вводом в домен: подробно

Раз уж DNS это причина 90% проблем, давайте разберём подробнее.

Когда сервер пытается присоединиться к домену, он делает DNS-запрос на SRV-запись _ldap._tcp.dc._msdcs.ИМЯ_ДОМЕНА. Эта запись указывает на контроллер домена. Если DNS-сервер не знает об этой записи, сервер не найдёт домен.

# Пошаговая диагностика DNS перед вводом в домен

# 1. Проверяем какой DNS настроен
Get-DnsClientServerAddress -InterfaceAlias "Ethernet" | Select ServerAddresses
# Должен показать IP контроллера домена (например, 192.168.1.10)

# 2. Если DNS указывает на роутер (192.168.1.1) или Google (8.8.8.8), меняем:
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses "192.168.1.10"

# 3. Проверяем резолвинг домена
Resolve-DnsName contoso.local
# Должен вернуть IP контроллера домена

# 4. Проверяем SRV-запись (самая важная проверка)
Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.contoso.local" -Type SRV
# Должен вернуть имя контроллера домена и порт 389

# 5. Проверяем связность с контроллером
Test-NetConnection -ComputerName dc01.contoso.local -Port 389
Test-NetConnection -ComputerName dc01.contoso.local -Port 88
# Порт 389 = LDAP, порт 88 = Kerberos
# Оба должны показать TcpTestSucceeded: True

# 6. Проверяем время (разница с DC не больше 5 минут!)
w32tm /stripchart /computer:dc01.contoso.local /samples:1
# Если разница больше 5 минут, синхронизируем:
w32tm /resync

По факту, если все 6 проверок прошли, ввод в домен сработает с первого раза. Если хоть одна не прошла, именно она и является причиной проблемы.

Безопасность при вводе в домен

Вот о чём редко думают: безопасность самого процесса ввода в домен.

Не используйте учётку Domain Admin для повседневных задач. Создайте отдельную учётку с делегированными правами на ввод компьютеров в домен. Если учётка Domain Admin утечёт (кейлоггер, перехват), злоумышленник получит полный контроль над доменом.

# Делегирование прав на ввод компьютеров в конкретный OU
# Через Active Directory Users and Computers:
# 1. Правый клик по OU "Servers" -> Delegate Control
# 2. Добавьте пользователя/группу
# 3. Выберите "Join a computer to the domain"
# 4. Готово

# Теперь этот пользователь может вводить серверы в домен
# но НЕ может менять пароли, удалять учётки и т.д.

Грубо говоря, принцип наименьших привилегий: каждая учётка должна иметь ровно столько прав, сколько нужно для работы. Не больше.

Чеклист после ввода сервера в домен

Сервер в домене. Что проверить и настроить:

1. Групповые политики: gpresult /r, убедитесь что нужные GPO применились
2. Доменные группы в локальных админах: добавьте группу серверных администраторов
3. Windows Firewall: должен переключиться на доменный профиль
4. Время: должно синхронизироваться с контроллером домена автоматически
5. DNS: сервер должен зарегистрироваться в DNS (проверьте прямую и обратную зону)
6. Антивирус: если используется корпоративный антивирус, убедитесь что сервер получил политики
7. Мониторинг: добавьте сервер в систему мониторинга (Zabbix, PRTG, etc.)
8. Бэкап: настройте резервное копирование (подробнее о бэкапах Windows Server)

Мой коллега Дмитрий (админит инфраструктуру из 20 серверов Dell PowerEdge R740 для логистической компании) составил чеклист из 15 пунктов, который проходит каждый новый сервер. Говорит: «После того как я забыл добавить новый сервер в бэкап и он через месяц упал, я стал педантичен как немецкий бухгалтер. Каждый пункт отмечаю в Confluence».

Массовый ввод серверов через Ansible/DSC

Когда серверов десятки, даже PowerShell-скрипты становятся неудобными. Для масштабной автоматизации используют DSC (Desired State Configuration) или Ansible.

# PowerShell DSC: конфигурация для ввода в домен
Configuration JoinDomain {
    param(
        [Parameter(Mandatory)]
        [PSCredential]$DomainCredential,
        [string]$DomainName = "contoso.local",
        [string]$OUPath = "OU=Servers,DC=contoso,DC=local"
    )

    Node $AllNodes.NodeName {
        Computer JoinDomain {
            Name       = $Node.NodeName
            DomainName = $DomainName
            JoinOU     = $OUPath
            Credential = $DomainCredential
        }
    }
}

# Применяем конфигурацию
$cred = Get-Credential
JoinDomain -DomainCredential $cred -ConfigurationData $configData
Start-DscConfiguration -Path .JoinDomain -Wait -Verbose

Если честно, DSC это мощный инструмент, но с крутой кривой обучения. Для 5-10 серверов проще Add-Computer. Для 50+ серверов DSC или Ansible окупают затраты на изучение.

Частые вопросы

Можно ли ввести в домен сервер с Windows Server Essentials?

Да, но Essentials обычно сам является контроллером домена. Если вам нужен рядовой сервер-член домена, используйте Standard.

Нужна ли перезагрузка после ввода в домен?

Да, обязательно. Без перезагрузки сервер не получит билет Kerberos и не сможет использовать доменные учётки.

Можно ли ввести в домен сервер через VPN?

Технически да, если VPN обеспечивает связность с контроллером домена по всем нужным портам. Но на практике бывают проблемы с латентностью и таймаутами. Лучше использовать djoin (offline domain join) для серверов за VPN.

Какие порты нужны для ввода в домен?

Вот полный список:

Если файрвол блокирует хотя бы один из этих портов, ввод в домен не сработает. Проверяйте с помощью Test-NetConnection перед тем, как жаловаться на «сломанный домен».

Что будет, если контроллер домена недоступен после ввода?

Сервер продолжит работать с кэшированными учётными данными. Последние 10-25 пользователей (настраивается через GPO) смогут входить. Но новые пользователи войти не смогут, и групповые политики не обновятся. Восстановите связь с DC как можно скорее.