Записки IT специалиста
Active Directory — от теории к практике. Часть 2 — разворачиваем доменную структуру.
- Автор: Уваров А.С.
- 20.07.2012
В прошлой части нашей статьи мы разобрали тот минимум теоретического материала, который необходимо знать перед развертыванием доменных служб Active Directory. Сегодня мы начнем практическую часть цикла, в которой подробно рассмотрим создание и переход к доменной структуре сети. Начнем, как всегда, сначала — в данной статье мы расскажем как правильно развернуть контроллеры домена.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Перед тем как приступить к практическому воплощению в жизнь всех своих планов сделайте паузу и еще раз проверьте некоторые мелочи. Очень часто эти вещи ускользают от взгляда администратора, принося в дальнейшем довольно серьезные затруднения, особенно для начинающих.
- Присвойте будущему доменному контроллеру удобочитаемое имя, например SRV-DC01, а не WIN-VAGNTE3N62T.
- Установите для сетевого адаптера статический IP адрес.
- Переименуйте встроенную учетную запись администратора, используйте только латинские буквы и символы.
Убедившись, что все вышеизложенные рекомендации выполнены, можно приступать к установке роли Доменные службы Active Directory, это можно сделать через оснастку Роли в Диспетчере сервера.
Установка данной роли еще не сделает данный сервер контроллером домена, для этого необходимо запустить Мастер установки доменных служб, что и будет предложено сделать по окончании установки, также вы можете сделать это позже, запустив dcpromo.exe.
Мы не будем разбирать подробно все настройки мастера, остановившись только на ключевых, кроме того стоит отметить, что в процессе установки будет выводиться довольно большое количество справочной информации и мы рекомендуем внимательно с ней ознакомиться.
Так как это наш первый контроллер домена, то выбираем Создать новый домен в новом лесу.
Следующим шагом следует указать имя вашего домена. Не рекомендуется давать домену интернет имя внешнего домена, также не рекомендуется давать имя в несуществующих зонах первого уровня, типа .local или .test и т.д. Оптимальным вариантом для домена AD будет поддомен в пространстве имен внешнего интернет домена, например corp.example.com. Так как наш домен используется исключительно в тестовых целях в рамках лаборатории, то мы назвали его interface31.lab, хотя правильно было бы назвать его lab.interface31.ru.
Затем указываем режим работы леса, на этом вопросе мы уже останавливались в предыдущей части статьи и в подробности вдаваться не будем.
В дополнительных параметрах обязательно укажите опцию DNS-сервер. Так как Active Directory и службы DNS тесно связаны между собой, то мы рекомендуем делать каждый контроллер домена DNS сервером и не видим веских оснований разносить эти роли.
Очень важный момент — укажите и запишите в надежном месте пароль администратора режима восстановления служб каталогов, при хорошем раскладе он вам понадобиться не должен, но гораздо хуже, если вы его не можете вспомнить.
В следующем окне еще раз перепроверьте все введенные данные и можете запускать процесс настройки доменных служб. Помните, с этого момента уже ничего изменить или исправить нельзя и если вы где-то ошиблись, то придется начать все заново. А пока мастер настраивает доменные службы можете сходить налить себе чашечку кофе.
По завершении работы мастера перезагрузите сервер и, если все сделано правильно, в вашем распоряжении первый контроллер домена, который также будет исполнять роль DNS-сервера для вашей сети. Здесь возникает еще один тонкий момент, данный сервер будет содержать записи о всех объектах вашего домена, при запросе записей, относящихся к другим доменам, которые он не сможет разрешить, они будут переданы вышестоящим серверам, т.н. серверам пересылки.
По умолчанию в качестве серверов пересылки указывается адрес DNS-сервера из свойств сетевого подключения, чтобы впоследствии избежать разного рода сбоев в работе сети следует явно указать доступные сервера во внешней сети. Для этого откройте оснастку DNS в Диспетчере сервера и выберите Сервера пересылки для своего сервера. Укажите не менее двух доступных внешних серверов, это могут быть как сервера провайдера, так и публичные DNS-службы.
Также обратите внимание, что в свойствах сетевого подключения контроллера домена, который является DNS-сервером, в качестве адреса DNS должно быть указано 127.0.0.1, любые другие варианты записи являются ошибочными.
Создав первый контроллер домена, не откладывая дело в долгий ящик, приступайте к развертыванию второго, без этого ваша структура AD не может считаться полноценной и отказоустойчивой. Также убедитесь, что сервер имеет удобочитаемое имя и статический IP-адрес, в качестве DNS-сервера укажите адрес первого контроллера и введите машину в домен.
После перезагрузки войдите доменным администратором и установите роль Доменные службы Active Directory, после чего также запустите мастер. Принципиальных отличий в настройке второго контроллера нет, разве что отвечать придется на меньшее число вопросов. Прежде всего укажите, что вы добавляете новый контроллер в существующий домен.
Как мы уже говорили, рекомендуем сделать этот сервер DNS-сервером и Глобальным каталогом. Помните, что при отсутствии глобального каталога ваш домен может оказаться неработоспособным, поэтому рекомендуется иметь как минимум два глобальных каталога и дополнительно добавлять ГК в каждый новый домен или сайт AD.
Остальные настройки полностью идентичны и, проверив все еще раз, приступайте к развертыванию второго контроллера, в процессе которого будет выполнена настройка соответствующих служб и произведена репликация с первым контроллером.
Закончив установку второго контроллера можете переходить к настройкам доменных служб: создавайте пользователей, разносите их по группам и подразделениям, настраивайте групповые политики и т.д. и т.п. Делать это можно на любом контроллере домена, для этого воспользуйтесь соответствующими пунктами меню Администрирование.
Следующим шагом будет введение в домен пользовательских ПК и рядовых серверов, а также миграция пользовательского окружения на доменные учетные записи, об этом мы поговорим в следующей части.
Дополнительные материалы:
- Службы каталогов. Часть 1 — Общие понятия
- Службы каталогов. Часть 2 — Реализации служб каталогов
- Службы каталогов. Часть 3 — Структура Active Directory
- Active Directory — от теории к практике. Часть 1 — общие вопросы
- Active Directory — от теории к практике. Часть 2 — разворачиваем доменную структуру
- Active Directory — от теории к практике. Часть 3 — настройка DHCP
- Active Directory — от теории к практике. Часть 4 — перенос учетных записей в домен
- Настраиваем высокодоступный DHCP-сервер в Windows Server 2012
- Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP
- Синхронизация времени Active Directory с внешним источником
- Обновление схемы Active Directory
- Управление ролями FSMO при помощи Ntdsutil
- Управление ролями FSMO с помощью PowerShell
- Восстанавливаем доверительные отношения в домене
- Очистка метаданных контроллера домена в Active Directory
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал:
Синхронизация объектов и учетных данных в управляемом домене доменных служб Microsoft Entra
Объекты и учетные данные в управляемом домене доменных служб Microsoft Entra могут создаваться локально в домене или быть синхронизированы из арендатора Microsoft Entra. При первом развертывании доменных служб настраивается автоматическая односторонняя синхронизация и начинается реплика те объекты из идентификатора Microsoft Entra. Эта односторонняя синхронизация продолжает выполняться в фоновом режиме, чтобы обеспечить актуальность управляемого домена доменных служб с любыми изменениями из идентификатора Microsoft Entra. Синхронизация не выполняется из доменных служб обратно с идентификатором Microsoft Entra.
В гибридной среде объекты и учетные данные из локального домена AD DS можно синхронизировать с идентификатором Microsoft Entra с помощью Microsoft Entra Подключение. После успешной синхронизации этих объектов с идентификатором Microsoft Entra автоматическая фоновая синхронизация делает эти объекты и учетные данные доступными для приложений с помощью управляемого домена.
На следующей схеме показано, как работает синхронизация между доменными службами, идентификатором Microsoft Entra ID и необязательной локальной средой AD DS:
Синхронизация с идентификатором Microsoft Entra с доменными службами
Учетные записи пользователей, членство в группах и хэши учетных данных синхронизируются одним из способов с идентификатора Microsoft Entra в доменные службы. Этот процесс синхронизации выполняется автоматически. Для него не требуется настройка, отслеживание или управление. Начальная синхронизация может занять несколько часов до нескольких дней в зависимости от количества объектов в каталоге Microsoft Entra. После завершения начальной синхронизации изменения, внесенные в идентификатор Microsoft Entra, такие как изменения пароля или атрибута, автоматически синхронизируются с доменными службами.
Когда пользователь создается в идентификаторе Microsoft Entra, он не синхронизируется с доменными службами, пока не измените пароль в идентификаторе Microsoft Entra. Этот процесс изменения пароля приводит к созданию и хранению хэшей паролей для проверки подлинности Kerberos и NTLM в идентификаторе Microsoft Entra. Хэши паролей необходимы для успешной проверки подлинности пользователя в доменных службах.
Процесс синхронизации является односторонним путем разработки. Нет обратной синхронизации изменений из доменных служб обратно с идентификатором Microsoft Entra. Как правило, управляемый домен доступен только для чтения. Исключениями являются любые пользовательские подразделения, которые вы создаете. Внесение изменений в атрибуты и пароли пользователя, а также в сведения о членстве в группах недоступно в пределах управляемого домена.
Синхронизация с областью действия и фильтр групп
Вы можете область синхронизацию только с учетными записями пользователей, которые были созданы в облаке. В рамках этой область синхронизации можно фильтровать для определенных групп или пользователей. Вы можете выбрать только облачные группы, локальные группы или оба. Дополнительные сведения о настройке синхронизации область см. в разделе «Настройка область синхронизации».
Синхронизация атрибутов и сопоставление с доменными службами
В следующей таблице перечислены некоторые распространенные атрибуты и их синхронизация с доменными службами.
| Атрибут в доменных службах | Оригинал | Примечания. |
|---|---|---|
| UPN | Атрибут участника-пользователя в клиенте Microsoft Entra | Атрибут имени участника-пользователя из клиента Microsoft Entra синхронизируется как есть с доменными службами. Самый надежный способ входа в управляемый домен — с использованием UPN. |
| SAMAccountName | Атрибут mailNickname пользователя в клиенте Microsoft Entra или автоматически сформированный | Атрибут SAMAccountName создается из атрибута mailNickname в клиенте Microsoft Entra. Если несколько учетных записей пользователей имеют одинаковый атрибут mailNickname, то SAMAccountName создается автоматически. Если длина атрибута mailNickname пользователя или префикс имени участника-пользователя превышает 20 знаков, то SAMAccountName создается автоматически, чтобы не превышать ограничение в 20 знаков, установленное для атрибутов SAMAccountName. |
| Passwords | Пароль пользователя из клиента Microsoft Entra | Устаревшие хэши паролей, необходимые для проверки подлинности NTLM или Kerberos, синхронизируются из клиента Microsoft Entra. Если клиент Microsoft Entra настроен для гибридной синхронизации с помощью Microsoft Entra Подключение, эти хэши паролей создаются из локальной среды AD DS. |
| Основной идентификатор безопасности (SID) пользователя или группы | Созданный автоматически | Основной идентификатор безопасности учетных записей пользователей или групп автоматически создается в доменных службах. Этот атрибут не совпадает с основным идентификатором безопасности пользователя или группы объекта в локальной среде AD DS. Это несоответствие объясняется тем, что управляемый домен имеет пространство имен SID, отличное от локального домена AD DS. |
| Журнал идентификаторов безопасности для пользователей и групп | Локальный основной идентификатор безопасности пользователя и группы | Атрибут SidHistory для пользователей и групп в доменных службах соответствует соответствующему основному пользователю или идентификатору безопасности группы в локальной среде AD DS. Эта функция помогает упростить перемещение локальных приложений в доменные службы, так как вам не нужно повторно использовать ресурсы ACL. |
При входе в управляемый домен используйте формат имени участника-пользователя (UPN). Для некоторых учетных записей пользователей в управляемом домене атрибут SAMAccountName, например AADDSCONTOSO\driley , может создаваться автоматически. Автоматически созданный атрибут SamAccountName пользователя может отличаться от префикса имени участника-пользователя, поэтому этот способ входа в систему не всегда надежен.
Например, если несколько пользователей имеют одинаковый атрибут mailNickname или у пользователей слишком длинные префиксы имени участника-пользователя, то атрибут SAMAccountName для этих пользователей может создаваться автоматически. Используйте формат UPN, такой как driley@aaddscontoso.com , в качестве надежного способа вход на управляемый домен.
Сопоставление атрибутов для учетных записей пользователей
В следующей таблице показано, как определенные атрибуты для пользовательских объектов в идентификаторе Microsoft Entra синхронизируются с соответствующими атрибутами в доменных службах.
| Атрибут пользователя в идентификаторе Microsoft Entra | Атрибут пользователя в доменных службах |
|---|---|
| AccountEnabled | userAccountControl (задает или удаляет значение ACCOUNT_DISABLED) |
| city | l |
| companyName | companyName |
| country | co |
| department | department |
| displayName | displayName |
| employeeId | employeeId |
| facsimileTelephoneNumber | facsimileTelephoneNumber |
| givenName | givenName |
| jobTitle | title |
| mailNickname | msDS-AzureADMailNickname |
| mailNickname | SAMAccountName (в отдельных случаях создается автоматически) |
| manager | manager |
| мобильный | мобильный |
| objectid | msDS-aadObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| passwordPolicies | userAccountControl (задает или удаляет значение DONT_EXPIRE_PASSWORD) |
| physicalDeliveryOfficeName | physicalDeliveryOfficeName |
| postalCode | postalCode |
| preferredLanguage | preferredLanguage |
| proxyAddresses | proxyAddresses |
| state | st |
| streetAddress | streetAddress |
| surname; | sn |
| telephoneNumber | telephoneNumber |
| userPrincipalName | userPrincipalName |
Сопоставление атрибутов для групп
В следующей таблице показано, как определенные атрибуты для объектов группы в идентификаторе Microsoft Entra синхронизируются с соответствующими атрибутами в доменных службах.
| Атрибут группы в идентификаторе Microsoft Entra | Атрибут группы в доменных службах |
|---|---|
| displayName | displayName |
| displayName | SAMAccountName (в отдельных случаях создается автоматически) |
| mailNickname | msDS-AzureADMailNickname |
| objectid | msDS-AzureADObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| proxyAddresses | proxyAddresses |
| securityEnabled | groupType |
Синхронизация из локальной службы AD DS с идентификатором и доменными службами Майкрософт
Microsoft Entra Подключение используется для синхронизации учетных записей пользователей, членства в группах и хэшей учетных данных из локальной среды AD DS с идентификатором Microsoft Entra. Синхронизируются атрибуты учетных записей пользователей, такие как имя участника-пользователя и локальный идентификатор безопасности (SID). Для входа с помощью доменных служб устаревшие хэши паролей, необходимые для проверки подлинности NTLM и Kerberos, также синхронизируются с идентификатором Microsoft Entra.
Microsoft Entra Подключение следует установить и настроить только для синхронизации с локальными средами AD DS. Не поддерживается установка Microsoft Entra Подключение в управляемом домене для синхронизации объектов с идентификатором Microsoft Entra.
При настройке обратной записи изменения из идентификатора Microsoft Entra синхронизируются с локальной средой AD DS. Например, если пользователь изменяет пароль с помощью самостоятельного управления паролями Microsoft Entra, пароль обновляется в локальной среде AD DS.
Всегда используйте последнюю версию Microsoft Entra Подключение, чтобы гарантировать наличие исправлений для всех известных ошибок.
Синхронизация из локальной среды с несколькими лесами
Многие организации используют довольно сложную локальную среду AD DS, которая включает несколько лесов. Microsoft Entra Подключение поддерживает синхронизацию пользователей, групп и хэшей учетных данных из сред с несколькими лесами с идентификатором Microsoft Entra ID.
Идентификатор Microsoft Entra имеет гораздо более простое и плоское пространство имен. Чтобы пользователи могли надежно получать доступ к приложениям, защищенным идентификатором Microsoft Entra, разрешать конфликты имени участника-пользователя между учетными записями пользователей в разных лесах. Управляемые домены используют плоскую структуру подразделения, аналогичную идентификатору Microsoft Entra. Все учетные записи пользователей и группы хранятся в контейнере AADDC Users, хотя их синхронизация выполняется из разных локальных доменов или лесов, даже когда иерархическая структура подразделений настроена локально. Управляемый домен выполняет сведение всех иерархических структур подразделений.
Как описано ранее, синхронизация из доменных служб обратно с идентификатором Microsoft Entra не выполняется. Вы можете создать настраиваемое подразделение организации в доменных службах, а затем пользователи, группы или учетные записи служб в этих пользовательских подразделениях. Ни один из объектов, созданных в пользовательских подразделениях, не синхронизируется с идентификатором Microsoft Entra. Эти объекты доступны только в управляемом домене и не отображаются с помощью командлетов Microsoft Graph PowerShell, API Microsoft Graph или центра администрирования Microsoft Entra.
Что не синхронизировано с доменными службами
Следующие объекты или атрибуты не синхронизируются из локальной среды AD DS с идентификатором Microsoft Entra или доменными службами:
- Исключенные атрибуты. Вы можете исключить определенные атрибуты из синхронизации с идентификатором Microsoft Entra из локальной среды AD DS с помощью Microsoft Entra Подключение. Эти исключенные атрибуты затем недоступны в доменных службах.
- Групповые политики: групповые политики, настроенные в локальной среде AD DS, не синхронизируются с доменными службами.
- Папка Sysvol. Содержимое папки Sysvol в локальной среде AD DS не синхронизируется с доменными службами.
- Компьютерные объекты: компьютерные объекты для компьютеров, присоединенных к локальной среде AD DS, не синхронизируются с доменными службами. Для этих компьютеров не установлено отношение доверия с управляемым доменом, и они принадлежат только к локальной среде AD DS. В доменных службах отображаются только компьютерные объекты для компьютеров, которые явно присоединены к управляемому домену.
- Атрибуты SidHistory для пользователей и групп: основной пользователь и первичные идентификаторы безопасности группы из локальной среды AD DS синхронизируются с доменными службами. Однако существующие атрибуты SidHistory для пользователей и групп не синхронизируются из локальной среды AD DS с доменными службами.
- Структуры подразделений организации: подразделения, определенные в локальной среде AD DS, не синхронизируются с доменными службами. В доменных службах есть два встроенных подразделения — один для пользователей и один для компьютеров. По умолчанию в управляемом домене используются подразделения с плоской структурой. Можно при необходимости создавать в управляемом домене пользовательские подразделения.
Вопросы по синхронизации и безопасности хэша паролей
При включении доменных служб требуются устаревшие хэши паролей для проверки подлинности NTLM и Kerberos. Идентификатор Microsoft Entra не хранит пароли с четким текстом, поэтому эти хэши не могут быть автоматически созданы для существующих учетных записей пользователей. Хэши паролей, совместимые с NTLM и Kerberos, всегда хранятся в зашифрованном виде в идентификаторе Microsoft Entra.
Ключи шифрования уникальны для каждого клиента Microsoft Entra. Эти хэши шифруются таким образом, что только доменные службы имеют доступ к ключам расшифровки. Никакие другие службы или компоненты в идентификаторе Microsoft Entra не имеют доступа к ключам расшифровки.
После этого устаревшие хэши паролей синхронизируются с идентификатором Microsoft Entra в контроллеры домена для управляемого домена. Диски для этих управляемых контроллеров домена в доменных службах шифруются неактивных данных. Хранение и защита этих хэшей паролей выполняется в контроллерах домена (аналогично хранению и защите паролей в локальной среде AD DS).
Для облачных сред Microsoft Entra пользователи должны сбросить или изменить пароль , чтобы необходимые хэши паролей были созданы и сохранены в идентификаторе Microsoft Entra. Для любой облачной учетной записи пользователя, созданной в идентификаторе Microsoft Entra, после включения доменных служб Microsoft Entra хэши паролей создаются и хранятся в форматах, совместимых с NTLM и Kerberos. Все учетные записи пользователей облака должны изменить пароль перед синхронизацией с доменными службами.
Для гибридных учетных записей пользователей, синхронизированных из локальной среды AD DS с помощью Microsoft Entra Подключение, необходимо настроить Microsoft Entra Подключение для синхронизации хэшей паролей в совместимых форматах NTLM и Kerberos.
Следующие шаги
Дополнительные сведения о специфике синхронизации паролей см. в статье о том, как синхронизация хэша паролей работает с Microsoft Entra Подключение.
Чтобы приступить к работе с доменными службами, создайте управляемый домен.
Dns-сервер ожидает от доменных служб
DNS-сервер ожидает от доменных служб Active Directory (AD DS) сигнала о том, что первичная синхронизация каталога завершена. Службу DNS-сервера невозможно запустить до завершения первичной синхронизации, так как критические данные DNS могут быть еще не реплицированными на этот контроллер домена. Если журнал событий AD DS показывает, что имеются проблемы с разрешением DNS-имен в адреса, рассмотрите возможность добавления IP-адреса другого DNS-сервера для этого домена в список DNS-серверов в свойствах протокола IP этого компьютера. Такое событие будет записываться в журнал каждые две минуты, пока служба AD DS не сообщит об успешном завершении первичной синхронизации.
Настройка Active Directory Domain Services
Настройка Active Directory представляет из себя достаточно простой процесс и рассматривается на множестве ресурсов в интернете, включая официальные . Тем не менее на своем блоге я не могу не затронуть этот момент, поскольку большинство дальнейших статей будет так или иначе основано на окружении, настройкой которого я планирую заняться как раз сейчас.
Хочется задать вопросы или поделиться знаниями? Приходи в наш закрытый Telegram-чат.
Подготовка окружения
Разворачивать роль AD я планирую на двух виртуальных серверах (будущих контроллерах домена) по очереди.
- Первым делом нужно задать подходящие имена серверов, у меня это будут DC01 и DC02;
- Далее прописать статические настройки сети (подробно этот момент я рассмотрю ниже);
- Установите все обновления системы, особенно обновления безопасности (для КД это важно как ни для какой другой роли).
На этом этапе необходимо определиться какое имя домена у вас будет. Это крайне важно, поскольку потом смена доменного имени будет очень большой проблемой для вас, хоть и сценарий переименования официально поддерживается и внедрен достаточно давно.
Примечание: н екоторые рассуждения, а также множество ссылок на полезный материал, вы можете найти в моей статье Пара слов про именование доменов Active Directory. Рекомендую ознакомиться с ней, а также со списком использованных источников.
Поскольку у меня будут использоваться виртуализованные контроллеры домена, необходимо изменить некоторые настройки виртуальных машин, а именно отключить синхронизацию времени с гипервизором. Время в AD должно синхронизироваться исключительно с внешних источников. Включенные настройки синхронизации времени с гипервизором могут обернуться циклической синхронизацией и как следствие проблемами с работой всего домена.
Примечание: отключение синхронизации с хостом виртуализации – самый простой и быстрый вариант. Тем не менее, это не best practic. Согласно рекомендациям Microsoft, нужно отключать синхронизацию с хостом лишь частично 1 . Для понимания принципа работы читайте официальную документацию 2 3 , которая в последние годы радикально подскочила вверх по уровню изложения материала .
Вообще сам подход к администрированию виртуализованных контроллеров домена отличается в виду некоторых особенностей функционирования AD DS 4 5 :
Виртуальные среды представляют особую трудность для распределенных рабочих потоков, зависящих от логической схемы репликации по времени. Например, репликация AD DS использует равномерно увеличивающееся значение (которое называется USN, или номер последовательного обновления), назначенное транзакциям в каждом контроллере домена. Каждый экземпляр базы данных контроллера домена также получает идентификатор под названием InvocationID. InvocationID контроллера домена и его номер последовательного обновления вместе служат уникальным идентификатором, который связан с каждой транзакцией записи, выполняемой на каждом контроллере домена, и должны быть уникальны в пределах леса.
На этом основные шаги по подготовке окружения завершены, переходим к этапу установки.
Установка Active Directory
Установка производится через Server Manager и в ней нет ничего сложного, подробно все этапы установки вы можете увидеть ниже:
Сам процесс установки претерпел некоторые изменения 6 по сравнению с предыдущими версиями ОС:
Развертывание доменных служб Active Directory (AD DS) в Windows Server 2012 стало проще и быстрее по сравнению с предыдущими версиями Windows Server. Установка AD DS теперь выполняется на основе Windows PowerShell и интегрирована с диспетчером серверов. Сократилось количество шагов, необходимых для внедрения контроллеров домена в существующую среду Active Directory.
Необходимо выбрать только роль Доменные службы Active Directory, никакие дополнительные компоненты устанавливать не нужно. Процесс установки занимает незначительно время и можно сразу переходить к настройке.
Настройка Active Directory
Когда установится роль, справа вверху Server Manager вы увидите восклицательный знак – требуется провести конфигурацию после развертывания. Нажимаем Повысить роль этого сервера до контроллера домена.
Далее весь процесс будет проходить в мастере настройки.
Повышение роли сервера до контроллера домена
Этапы работы мастера подробно описаны в документации 7 . Тем не менее, пройдемся по основным шагам.
Поскольку мы разворачиваем AD с нуля, то нужно добавлять новый лес. Не забудьте надежно сохранить пароль для режима восстановления служб каталогов (DSRM). Расположение базы данных AD DS можно оставить по умолчанию (именно так и рекомендуют. Однако для разнообразия в своей тестовой среде я указал другой каталог).
После этого сервер самостоятельно перезагрузится.
Создание учетных записей администраторов домена/предприятия
Залогиниться нужно будет под учетной записью локального администратора, как и прежде. Зайдите в оснастку Active Directory – пользователи и компьютеры, создайте необходимые учетные записи – на этом этапе это администратор домена.
Сразу же рекомендую настроить и иерархию организации (только не используйте русские символы!).
Настройка DNS на единственном DC в домене
Во время установки AD также была установлена роль AD DNS, поскольку других серверов DNS у меня в инфраструктуре не было. Для правильно работы сервиса необходимо изменить некоторые настройки. Для начала нужно проверить предпочитаемые серверы DNS в настройках сетевого адаптера. Необходимо использовать только один DNS-сервер с адресом 127.0.0.1. Да, именно localhost. По умолчанию он должен прописаться самостоятельно.
Убедившись в корректности настроек, открываем оснастку DNS. Правой кнопкой нажимаем на имени сервера и открываем его свойства, переходим на вкладку “Сервер пересылки”. Адрес DNS-сервера, который был указан в настройках сети до установки роли AD DS, автоматически прописался в качестве единственного сервера пересылки:
Необходимо его удалить и создать новый и крайне желательно, чтобы это был сервер провайдера, но никак не публичный адрес типа общеизвестных 8.8.8.8 и 8.8.4.4. Для отказоустойчивости пропишите минимум два сервера. Не снимайте галочку для использования корневых ссылок, если нет доступных серверов пересылки. Корневые ссылки – это общеизвестный пул DNS-серверов высшего уровня.
Добавление второго DC в домен
Поскольку изначально я говорил о том, что у меня будет два контроллера домена, пришло время заняться настройкой второго. Проходим также мастер установки, повышаем роль до контроллера домена, только выбираем Добавить контроллер домена в существующий домен:
Обратите внимание, что в сетевых настройках этого сервера основным DNS-сервером должен быть выбран настроенный ранее первый контроллер домена! Это обязательно, иначе получите ошибку.
После необходимых настроек логиньтесь на сервер под учетной записью администратора домена, которая была создана ранее.
Настройка DNS на нескольких DC в домене
Для предупреждения проблем с репликацией нужно снова изменить настройки сети и делать это необходимо на каждом контроллере домена (и на существовавших ранее тоже) и каждый раз при добавлении нового DC:
Если у вас больше трех DC в домене, необходимо прописать DNS-серверы через дополнительные настройки именно в таком порядке. Подробнее про DNS вы можете прочитать в моей статье Шпаргалка по DNS.
Настройка времени
Этот этап нужно выполнить обязательно, особенно если вы настраиваете реальное окружение в продакшене. Как вы помните, ранее я отключил синхронизацию времени через гипервизор и теперь нужно её настроить должным образом. За распространение правильного время на весь домен отвечает контроллер с ролью FSMO PDC эмулятор (Не знаете что это такая за роль? Читайте статью PDC emulator — Эмулятор первичного контроллера домена). В моем случае это конечно же первый контроллер домена, который и является носителем всех ролей FSMO изначально.
Настраивать время на контроллерах домена будем с помощью групповых политик. Напоминаю, что учетные записи компьютеров контроллеров домена находятся в отдельном контейнере и имеют отдельную групповую политику по умолчанию. Не нужно вносить изменения в эту политику, лучше создайте новую.
Назовите её как считаете нужным и как объект будет создан, нажмите правой кнопкой – Изменить. Переходим в Конфигурация компьютера\Политики\Административные шаблоны\Система\Служба времени Windows\Поставщики времени. Активируем политики Включить NTP-клиент Windows и Включить NTP-сервер Windows, заходим в свойства политики Настроить NTP-клиент Windows и выставляем тип протокола – NTP, остальные настройки не трогаем:
Дожидаемся применения политик (у меня это заняло примерно 5-8 минут, несмотря на выполнение gpupdate /force и пару перезагрузок), после чего получаем:
Вообще надо сделать так, чтобы время с внешних источников синхронизировал только PDC эмулятор, а не все контроллеры домена под ряд, а будет именно так, поскольку групповая политика применяется ко всем объектам в контейнере. Нужно её перенацелить на конкретный объект учетной записи компьютера-владельца роли PDC-эмулятор. Делается это также через групповые политики – в консоли gpmc.msc нажимаем левой кнопкой нужную политику и справа у вас появятся её настройки. В фильтрах безопасности нужно добавить учетную запись нужного контроллера домена:
Подробнее о принципе работы и настройке службы времени читайте в официальной документации 8 .
На этом настройка времени, а вместе с ней и начальная настройка Active Directory, завершена. Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге. Также рекомендую ознакомиться с основной статье по Active Directory – Active Directory Domain Services
- Time Synchronization and Domain Controller VM’s↩
- Accurate Time for Windows Server 2016↩
- Virtualizing Domain Controllers using Hyper-V↩
- Знакомство с виртуализацией доменных служб Active Directory (уровень 100)↩
- Виртуализация доменных служб Active Directory↩
- Что нового в установке и удалении доменных служб Active Directory↩
- Описание страниц мастера установки и удаления доменных служб Active Directory↩
- How the Windows Time Service Works↩