Строим высоко-доступную Windows-инфраструктуру в командной строке. AD DS. Часть 1-я — Установка

Вступление

По сей день, Active Directory Domain Services (AD DS) остаются ядром Windows-инфраструктуры. С каждым релизом Windows Server, AD DS получает новые возможности , сохраняя превосзходную обратную совместимость. Windows Server 2016 привносит следующие улучшения в AD DS:

В этой статье мы заложим краеугольный камень нашей будущей инфраструктуры: высоко-доступный экземпляр AD DS из двух контроллеров домена. Схема будет простейшей: два обычных контроллера домена в одном сайте.



Переменные, используемые в посте:
$DomainFQDN = 'lab.exchange12rocks.net'
$DomainNBName = 'LAB'
$DC1Name = 'DC1'
$DC2Name = 'DC2'
$DC1IPAddress = '192.0.2.3'
$DC2IPAddress = '192.0.2.4'
$DefaultGWIPAddress = '192.0.2.1'
$SubNetPrefixLen = 24
$NICName = 'Ethernet'
$TempDirectoryName = 'Temp'
$TempDirectoryPath = $env:SystemDrive
$SSUFileName = 'windows10.0-kb3211320-x64_2abc94fceb4d1cdd908b3bdba473e28e0c061a3d.msu'
$CUFileName = 'windows10.0-kb4010672-x64_e12a6da8744518197757d978764b6275f9508692.msu'

Замечание

Даже если вся остальная ваша инфраструктура не отказоустойчива, рекомендуется всегда устанавливать как минимум 2 контроллера домена для записи, т.к. здоровье AD DS чрезвычайно критично для инфраструктуры. В случае единственного контроллера домена, его обслуживание прервёт предоставление практически всех сервисов в домене. Больше об этом вы можете прочитать тут: https://technet.microsoft.com/en-us/library/dd378865(v=ws.10).aspx

 

Контроллеры домена я буду устанавливать вручную, без использования средств автоматического развёртывания. Скорее всего, мы поговорим об автоматизации установки в будущих постах.

Установка первого КД

Установка ОС

Загрузите машину, которая будет нашим первым DC с новейшего ISO-образа Windows Server 2016. Выбирая редакцию для установки, не выберите, случайно, ту, на которой написано «Desktop Experience»:

После прохождения стандартного, хорошо знакомого вам мастера установки, появится текстовый экран входа в систему:

Установите пароль пользователя Administrator:

Сохраните этот пароль в надёжном месте — посже он станет паролем встроенного пользователя “Administrator” в AD DS — вам он потребуется ещё как минимум один раз.

Важно

Всегда устанавливайте сложные пароли для привилегированных учётных записей. Используйте случайно сгенерированные пароли, длиной не меньше 15 символов (чтобы предотвратить создание хешей LM). Такой пароль, конечно, невозможно запомнить, и тут нам на помощь приходят менеджеры паролей, такие как KeePass или CyberArk Enterprise Password Vault. Больше по теме вы можете найти здесь и здесь.
Другим хорошим подходом будет использование парольных фраз. Пример — в нашем любимом XKCD: https://xkcd.com/936/.

 

Каждый раз, при логоне в Server Core вас встречает экземпляр cmd.exe. Запустите PowerShell внутри этого окна cmd.exe, введя простейшую команду powershell. Я буду начинать каждую сессию входа с этой команды и больше не буду её упоминать, подразумевая по умолчанию.

Первым делом, нужно выбрать имя нашего первого КД. Как вы видите из блока с переменными выше, я выбрал «DC1» в качестве такового, но вам следует самостоятельно определиться.
Давайте переименуем DC1 и, т.к. переименование требует перезагрузки, немедленно перезагрузим машину:
Rename-Computer $DC1Name; Restart-Computer

После перезагрузки, мы снова видим текстовое окно входа в систему: входите и сразу запускайте powershell, помните?

Конфигурация сети

Чтобы сервер стал доступен через сеть, надо сконфигурировать его сетевой интерфейс. Для того, чтобы определить, какие интерфейсы есть на DC1, запустим командлет Get-NetAdapter:

Обычно, виртуальные машины Hyper-V имеют только один сетевой интерфейс, называющийся ‘Ethernet’. Сконфигурируйте его IP-адрес согласно настройкам вашей подсети:

Давайте проверим настройки. Выполните следующее с любой Windows-машины в той же подсети:

Скорее всего командлет вернёт «False» в свойстве «PingSucceeded». Если вы уверены, что сконфигурировали сетевой интерфейс корректно, обычно это означает, что Windows Firewall включён, что, разумеется, хорошо, но требует от нас корректной настройки исключений.

Внимание

Никогда не отключайте Windows Firewall — настраивайте исключения. ОТключая его, вы не только делаете хост уязвимым к атакам по сети, но и переводите систему в неподдерживаемое состояние: Microsoft тестирует свои продукты с включённым Windows Firewall.

 

Для того, чтобы разрешить входяшие ICMP-пакеты («пинги»), выполните следующее:
Set-NetFirewallRule -Name 'FPS-ICMP4-ERQ-In' -Enabled True

После этого запустите тест ещё раз — всё должно пройти корректно:

Включаем удалённое управление

До этого момента мы работали на сервере локально, что довольно неудобно. По умолчанию удалённое управление через Remote Desktop отключено — мы должны явно его включить. Во-первых, давайте убедимся, что оно выключено:

Значение “1” в ключе реестра fDenyTSConnections означает, что сервер будет отвергать попытки подключения по Remote Desktop Protocol. Для включения Remote Desktop, исправим реестр напрямую (это поддерживаемый способ):
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\' -Name 'fDenyTSConnections' -Value 0

Не забудьте настроить исключения в Windows Firewall (позже мы это автоматизируем при помощи групповых политик):

Обновления

Отлично, мы получили удалённый доступ. Пора устанавливать роли и службы? Нет: Сперва надо установить все доступные обновления.
Загрузите последний CU для Windows Server 2016, используя эту статью. Перед тем, как вы установите CU, рекомендуется загрузить и установить последнее обновление для Servicing Stack: Не существует статьи с историей таких обновлений, но вы можете попробовать определить новей шее при помощи Google. На момент написания статьи, последнее – это KB3211320.

Внимание

Всегда устанавливайте последние доступные обновления, когда разворачиваете новый экземпляр ПО:

  1. Это сразу же защищает вас от известных уязвимостей.
  2. Иногда ПО содержит ошибки, возникающие на этапе установки/настройки.

 

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

  1. На DC1 настройте исключение в МСЭ:
    Set-NetFirewallRule -Name 'FPS-SMB-In-TCP' -Enabled True
  2. Далее, создайте временную директорию, в которую буду помещены файлы обновлений:
    $TempDirectory = New-Item -Type Directory -Name $TempDirectoryName -Path (Join-Path -Path $TempDirectoryPath -ChildPath '\')
  3. Скопируйте обновления, используя любой удобный для вас инструмент.
  4. И установите их[:
    Start-Process -FilePath 'wusa' -ArgumentList "$(Join-Path -Path ($TempDirectory.FullName) -ChildPath $SSUFileName) /quiet" -Wait;Start-Process -FilePath 'wusa' -ArgumentList "$(Join-Path -Path ($TempDirectory.FullName) -ChildPath $CUFileName) /quiet" -Wait

Система будет перезагружена автоматически. После загрузки, вы можете смело удалить файлы обновлений.

Обработка напильником

После перезагрузки, установите часовой пояс.
Используйте команду Get-TimeZone -ListAvailable, чтобы посмотреть доступные, потом установите нужный командлетом Set-TimeZone:
Set-TimeZone -Id 'Russian Standard Time'

Убедитесь, что дата и время корректны, используя командлет Get-Date.

Наконец, вы можете удалить некоторые лишние компоненты:
Remove-WindowsFeature FS-SMB1, WoW64-Support; Restart-Computer

Почему рекомендуется удалять SMB1, читайте здесь.
Что же до подсистемы WoW64 — , т.к. мы не планируем запускать никаких 32-битных приложения на КД, она нам не нужна.

Установка AD DS

Наконец-то мы готовы приступить к установке Domain Services!

После того, как файлы роли установлены, мы можем создать новый лес AD DS и повысить сервер до контроллера домена:

SafeModeAdministratorPassword — это пароль, который будет использоваться для получения доступа к машине, если AD DS, по каким-то причинам, окажутся недоступны. Тоже запишите его в надёжном месте.

Важно

Используйте те же принципы генерации пароля, как мы обсудили ранее. Не используйте тот же пароль, что вы вводили на этапе установки ОС — тот пароль теперь будет паролем встроенного пользователя Administrator.

 

Установка второго КД

Повторите все шаги до момента установки файлов роли, включительно, но используя переменные $DC2IPAddress и $DC2Name вместо $DC1IPAddress и $DC1Name соответственно.

Установка AD DS

Для того, чтобы добавить компьютер, в т.ч. контроллер, в домен Active Direcotry, этот компьютер должен быть способен разрешить имя домена (FQDN). Для этого сконфигурируем сетевой интерфейс следующим образом:
Set-DnsClientServerAddress -InterfaceAlias $NICName -ServerAddresses $DC1IPAddress

Далее повысим DC2 до контроллера домена. Система опять перезагрузится автоматически:
Install-ADDSDomainController -DomainName $DomainFQDN -Credential (Get-Credential) -Confirm:$false

Внимание

Имя пользователя на этом шаге указывайте обязательно с доменом: Если вы забудете домен, процесс зависнет. Что делать в такой ситуации, рассказывается здесь.

 

Финальные настройки DNS

Наконец, мы должны корректно сконфигурировать DNS-серверы на сетевых интерфейсах наших КД: DC1 будет использовать DC2 как первичный DNS-сервер и наоборот.
На DC1 выполните:
Set-DnsClientServerAddress -InterfaceAlias $NICName -ServerAddresses @($DC2IPAddress,'127.0.0.1')

На DC2 выполните:
Set-DnsClientServerAddress -InterfaceAlias $NICName -ServerAddresses @($DC1IPAddress,'127.0.0.1')

Замечание

Зачем добавлять 127.0.0.1? Читайте наилучшие практики по конфигурации адресов NS на сетевых интерфейсах контроллеров здесь!

 

Voilà! Теперь у нас есть 2 полноценных контроллера в домене AD DS и мы развернули их используя только PowerShell и ничего более. Следующие серии уже скоро, подписывайтесь!

Leave a Reply

Your email address will not be published. Required fields are marked *