Windows Server 2019 — установка контроллера домена

Установим роль контроллера домена на Windows Server 2019. На контроллере домена работает служба Active Directory (AD DS). С Active Directory связано множество задач системного администрирования.

AD DS в Windows Server 2019 предоставляет службу каталогов для централизованного хранения и управления пользователями, группами, компьютерами, а также для безопасного доступ к сетевым ресурсам с проверкой подлинности и авторизацией.

Подготовительные работы

Нам понадобится компьютер с операционной системой Windows Server 2019. У меня контроллер домена будет находиться на виртуальной машине:

После установки операционной системы нужно выполнить первоначальную настройку Windows Server 2019:

Хочется отметить обязательные пункты, которые нужно выполнить.

Выполните настройку сети. Укажите статический IP адрес. DNS сервер указывать не обязательно, при установке контроллера домена вместе с ним установится служба DNS. В настройках сети DNS сменится автоматически. Отключите IPv6, сделать это можно и после установки контроллера домена.

Укажите имя сервера.

Было бы неплохо установить последние обновления, драйвера. Указать региональные настройки, время. На этом подготовка завершена.

Установка роли Active Directory Domain Services

Работаем под учётной записью локального администратора Administrator (или Администратор), данный пользователь станет администратором домена.

Дополнительно будет установлена роль DNS.

Следующий шаг — установка роли AD DS. Открываем Sever Manager. Manage > Add Roles and Features.

Запускается мастер добавления ролей.

Раздел Before You Begin нас не интересует. Next.

В разделе Installation Type выбираем Role-based or feature-based installation. Next.

В разделе Server Selection выделяем текущий сервер. Next.

В разделе Server Roles находим роль Active Directory Domain Services, отмечаем галкой.

Для роли контроллера домена нам предлагают установить дополнительные опции:

• [Tools] Group Policy Management
• Active Directory module for Windows PowerShell
• [Tools] Active Directory Administrative Center
• [Tools] AD DS Snap-Ins and Command-Line Tools

Всё это не помешает. Add Features.

Теперь роль Active Directory Domain Services отмечена галкой. Next.

В разделе Features нам не нужно отмечать дополнительные опции. Next.

У нас появился раздел AD DS. Здесь есть пара ссылок про Azure Active Directory, они нам не нужны. Next.

Раздел Confirmation. Подтверждаем установку компонентов кнопкой Install.

Начинается установка компонентов, ждём.

Configuration required. Installation succeeded on servername. Установка компонентов завершена, переходим к основной части, повышаем роль текущего сервера до контроллера домена. В разделе Results есть ссылка Promote this server to domain controller.

Она же доступна в предупреждении основного окна Server Manager. Нажимаем на эту ссылку, чтобы повысить роль сервера до контроллера домена.

Запускается мастер конфигурации AD DS — Active Directory Domain Service Configuration Wizard. В разделе Deployment Configuration нужно выбрать один из трёх вариантов:

• Add a domain controller to an existing domain
• Add a new domain to an existing forest
• Add a new forest

Первый вариант нам не подходит, у нас нет текущего домена, мы создаём новый. По той же причине второй вариант тоже не подходит. Выбираем Add a new forest. Будем создавать новый лес.

Укажем в Root domain name корневое имя домена. Я пишу ilab.local, это будет мой домен. Next.

Попадаем в раздел Doman Controller Options.

В Forest functional level и Domain functional level нужно указать минимальную версию серверной операционной системы, которая будет поддерживаться доменом.

У меня в домене планируются сервера с Windows Server 2019, Windows Server 2016 и Windows Server 2012, более ранних версий ОС не будет. Выбираю уровень совместимости Windows Server 2012.

В Domain functional level также выбираю Windows Server 2012.

Оставляю галку Domain Name System (DNS) server, она установит роль DNS сервера.

Укажем пароль для Directory Services Restore Mode (DSRM), желательно, чтобы пароль не совпадал с паролем локального администратора. Он может пригодиться для восстановления службы каталогов в случае сбоя.

Не обращаем внимание на предупреждение «A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found. «. Нам не нужно делать делегирование, у нас DNS сервер будет на контроллере домена. Next.

В разделе Additional Options нужно указать NetBIOS name для нашего домена, я указываю «ILAB». Next.

В разделе Paths можно изменить пути к базе данных AD DS, файлам журналов и папке SYSVOL. Без нужды менять их не рекомендуется. По умолчанию:

• Database folder: C:\Windows\NTDS
• Log files folder: C:\Windows\NTDS
• SYSVOL folder: C:\Windows\SYSVOL

В разделе Review Options проверяем параметры установки. Обратите внимание на кнопку View script. Если её нажать, то сгенерируется tmp файл с PowerShell скриптом для установки контроллера домена.

Сейчас нам этот скрипт не нужен, но он может быть полезен системным администраторам для автоматизации установки роли контроллера домена с помощью PowerShell.

Попадаем в раздел Prerequisites Check, начинаются проверки предварительных требований.

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

Для начала установки роли контроллера домена нажимаем Install.

Начинается процесс установки.

Сервер будет перезагружен, о чём нас и предупреждают. Close.

Дожидаемся загрузки сервера.

Первоначальная настройка контроллера домена

Наша учётная запись Administrator теперь стала доменной — ILAB\Administrator. Выполняем вход.

Видим, что на сервере автоматически поднялась служба DNS, добавилась и настроилась доменная зона ilab.local, созданы A-записи для контроллера домена, прописан NS сервер.

На значке сети отображается предупреждение, по сетевому адаптеру видно, что он не подключен к домену. Дело в том, что после установки роли контроллера домена DNS сервер в настройках адаптера сменился на 127.0.0.1, а данный адрес не обслуживается DNS сервисом.

Сменим 127.0.0.1 на статический IP адрес контроллера домена, у меня 192.168.1.14. OK.

Теперь сетевой адаптер правильно отображает домен, предупреждение в трее на значке сети скоро пропадёт.

Запускаем оснастку Active Directory Users and Computers. Наш контроллер домена отображается в разделе Domain Controllers. В папкe Computers будут попадать компьютеры и сервера, введённые в домен. В папке Users — учётные записи.

Правой кнопкой на корень каталога, New > Organizational Unit.

Создаём корневую папку для нашей компании. При создании можно установить галку, которая защищает от случайного удаления.

Внутри создаём структуру нашей компании. Можно создавать учётные записи и группы доступа. Создайте учётную запись для себя и добавьте её в группу Domain Admins.

Рекомендуется убедиться, что для публичного сетевого адаптера включен Firewall, а для доменной и частной сетей — отключен.

Новые возможности доменных служб Active Directory в Windows Server 2016 What’s new in Active Directory Domain Services for Windows Server 2016

Область применения. Windows Server 2016 Applies To: Windows Server 2016

Следующие новые возможности служб домен Active Directory Services (AD DS) улучшают возможности Организации в обеспечении безопасности сред Active Directory и помогают им переходить к облачным развертываниям и гибридным развертываниям, где некоторые приложения и службы размещаются в облаке, а другие — в локальной среде. The following new features in Active Directory Domain Services (AD DS) improve the ability for organizations to secure Active Directory environments and help them migrate to cloud-only deployments and hybrid deployments, where some applications and services are hosted in the cloud and others are hosted on premises. В них сочетаются все лучшие возможности веб-заданий, а также добавлены некоторые улучшения, среди которых: The improvements include:

Управление привилегированным доступом Privileged access management

Управление привилегированным доступом (PAM) помогает устранить проблемы безопасности в средах Active Directory, которые вызываются методами кражи учетных данных, такими как Pass-The-Hash, Спиар фишинг и аналогичные типы атак. Privileged access management (PAM) helps mitigate security concerns for Active Directory environments that are caused by credential theft techniques such pass-the-hash, spear phishing, and similar types of attacks. Он предоставляет новое решение для административного доступа, настроенное с помощью Microsoft Identity Manager (MIM). It provides a new administrative access solution that is configured by using Microsoft Identity Manager (MIM). PAM предоставляет следующие сведения: PAM introduces:

Новый лес Active Directory бастиона, который подготавливается MIM. A new bastion Active Directory forest, which is provisioned by MIM. Лес бастиона имеет особое отношение доверия PAM с существующим лесом. The bastion forest has a special PAM trust with an existing forest. Она предоставляет новую Active Directory среду, которая может быть свободна от вредоносных действий, и изоляция из существующего леса для использования привилегированных учетных записей. It provides a new Active Directory environment that is known to be free of any malicious activity, and isolation from an existing forest for the use of privileged accounts.

Новые процессы в MIM позволяют запрашивать административные привилегии, а также новые рабочие процессы на основе утверждения запросов. New processes in MIM to request administrative privileges, along with new workflows based on the approval of requests.

Новые участники безопасности теневой копии (группы), подготовленные в лесу бастиона, с помощью MIM в ответ на запросы прав администратора. New shadow security principals (groups) that are provisioned in the bastion forest by MIM in response to administrative privilege requests. Субъекты безопасности с тенью имеют атрибут, который ссылается на идентификатор безопасности группы администраторов в существующем лесу. The shadow security principals have an attribute that references the SID of an administrative group in an existing forest. Это позволяет теневой группе получать доступ к ресурсам в существующем лесу, не изменяя списки управления доступом (ACL). This allows the shadow group to access resources in an existing forest without changing any access control lists (ACLs).

Функция ссылок с истекшим сроком действия, которая обеспечивает членство, связанное с временем, в теневой группе. An expiring links feature, which enables time-bound membership in a shadow group. Пользователь может быть добавлен в группу только в течение достаточного времени, необходимого для выполнения административной задачи. A user can be added to the group for just enough time required to perform an administrative task. Членство, привязанное к времени, выражается значением срока жизни, которое распространяется на время существования билета Kerberos. The time-bound membership is expressed by a time-to-live (TTL) value that is propagated to a Kerberos ticket lifetime.

Ссылки с истекающим сроком действия доступны для всех связанных атрибутов. Expiring links are available on all linked attributes. Но единственным примером является связь атрибутов Member/memberOf между группой и пользователем, когда полное решение, например PAM, предварительно настроено для использования срока действия ссылок. But the member/memberOf linked attribute relationship between a group and a user is the only example where a complete solution such as PAM is preconfigured to use the expiring links feature.

Расширения центра распространения ключей встроены в Active Directory контроллеры домена, чтобы ограничить время жизни билета Kerberos минимальным значением срока жизни (TTL) в случаях, когда в административных группах есть несколько членов с ограниченным временем существования. KDC enhancements are built in to Active Directory domain controllers to restrict Kerberos ticket lifetime to the lowest possible time-to-live (TTL) value in cases where a user has multiple time-bound memberships in administrative groups. Например, если вы добавляете к группе A с ограниченным временем жизни, то при входе в систему время существования билета TGT (Ticket-Grant ticket) будет равно времени, оставшегося в группе A. Если вы также являетесь членом другой группы B, которая имеет меньшее значение TTL, чем группа A, то время жизни TGT равно времени, оставшееся в группе б. For example, if you are added to a time-bound group A, then when you log on, the Kerberos ticket-granting ticket (TGT) lifetime is equal to the time you have remaining in group A. If you are also a member of another time-bound group B, which has a lower TTL than group A, then the TGT lifetime is equal to the time you have remaining in group B.

Новые возможности мониторинга, позволяющие легко определить, кто запросил доступ, какой доступ был предоставлен и какие действия были выполнены. New monitoring capabilities to help you easily identify who requested access, what access was granted, and what activities were performed.

Требования к управлению привилегированным доступом Requirements for Privileged access management

Диспетчер удостоверений (Майкрософт) Microsoft Identity Manager

Функциональный уровень леса Active Directory Windows Server 2012 R2 или более поздней версии. Active Directory forest functional level of Windows Server 2012 R2 or higher.

Присоединение к Azure AD Azure AD Join

Azure Active Directory Присоединяйтесь к расширению возможностей идентификации для корпоративных, коммерческих и образовательных клиентов с улучшенными возможностями для корпоративных и персональных устройств. Azure Active Directory Join enhances identity experiences for enterprise, business and EDU customers- with improved capabilities for corporate and personal devices.

Доступность современных параметров на устройствах Windows, принадлежащих Corp. Availability of Modern Settings on corp-owned Windows devices. Службам кислорода больше не требуется личная учетная запись Майкрософт: теперь они работают с существующими рабочими учетными записями пользователей, чтобы обеспечить соответствие. Oxygen Services no longer require a personal Microsoft account: they now run off users’ existing work accounts to ensure compliance. Службы кислорода будут работать на компьютерах, которые присоединены к локальному домену Windows, а компьютеры и устройства, присоединенные к вашему клиенту Azure AD («Облачный домен»). Oxygen Services will work on PCs that are joined to an on-premises Windows domain, and PCs and devices that are «joined» to your Azure AD tenant («cloud domain»). Эти параметры приведены ниже: These settings include:

• Роуминг или Персонализация, параметры специальных возможностей и учетные данные Roaming or personalization, accessibility settings and credentials
• Резервное копирование и восстановление Backup and Restore
• Доступ к Microsoft Store с рабочей учетной записью Access to Microsoft Store with work account
• Динамические плитки и уведомления Live tiles and notifications

Доступ к организационным ресурсам на мобильных устройствах (телефонах, планшетах), которые не могут быть присоединены к домену Windows, будь то Корпоративная или BYOD. Access organizational resources on mobile devices (phones, tablets) that can’t be joined to a Windows Domain, whether they are corp-owned or BYOD.

Единый вход в Office 365 и другие приложения организации, веб-сайты и ресурсы. Single-Sign On to Office 365 and other organizational apps, websites and resources.

На устройствах BYOD добавьте рабочую учетную запись (из локального домена или Azure AD) на персональное устройство и используйте единый вход для работы с ресурсами через приложения и в Интернете, чтобы обеспечить соответствие новым возможностям, таким как условный контроль учетных записей и аттестация работоспособность устройств. On BYOD devices, add a work account (from an on-premises domain or Azure AD) to a personally-owned device and enjoy SSO to work resources, via apps and on the web, in a way that helps ensure compliance with new capabilities such as Conditional Account Control and Device Health attestation.

Интеграция MDM позволяет автоматически регистрировать устройства в MDM (Intune или сторонней организации). MDM integration lets you auto-enroll devices to your MDM (Intune or third-party).

Настройка режима киоска и общих устройств для нескольких пользователей в Организации. Set up «kiosk» mode and shared devices for multiple users in your organization.

Опыт разработки позволяет создавать приложения, предназначенные для корпоративных и личных контекстов с общим стеком программирования. Developer experience lets you build apps that cater to both enterprise and personal contexts with a shared programing stack.

Параметр создания образов позволяет выбрать между образами и разрешить пользователям настраивать корпоративные устройства непосредственно во время первого запуска. Imaging option lets you choose between imaging and allowing your users to configure corp-owned devices directly during the first-run experience.

Windows Hello для бизнеса Windows Hello for Business

Windows Hello для бизнеса — это проверка подлинности на основе ключей, которая используется организациями и потребителями, которая выходит за пределы паролей. Windows Hello for Business is a key-based authentication approach organizations and consumers, that goes beyond passwords. Такая форма проверки подлинности зависит от нарушений, кражи и учетных данных, которые защищены от фишинга. This form of authentication relies on breach, theft, and phish-resistant credentials.

Пользователь входит в систему на устройстве с помощью биометрического или ПИН-кода, который связан с сертификатом или парой асимметричных ключей. The user logs on to the device with a biometric or PIN log on information that is linked to a certificate or an asymmetrical key pair. Поставщики удостоверений (поставщиков удостоверений) проверяют пользователя, сопоставляя открытый ключ пользователя с Идлоккер, и предоставляет сведения для входа в систему через один раз пароль (OTP), Телефон или другой механизм уведомления. The Identity Providers (IDPs) validate the user by mapping the public key of the user to IDLocker and provides log on information through One Time Password (OTP), Phone or a different notification mechanism.

Дополнительные сведения см. в разделе Windows Hello для бизнеса . For more information see, Windows Hello for Business

Устаревшие функциональные уровни службы репликации файлов (FRS) и Windows Server 2003 Deprecation of File Replication Service (FRS) and Windows Server 2003 functional levels

Хотя служба репликации файлов (FRS) и функциональные уровни Windows Server 2003 стали устаревшими в предыдущих версиях Windows Server, она повторяет, что операционная система Windows Server 2003 больше не поддерживается. Although File Replication Service (FRS) and the Windows Server 2003 functional levels were deprecated in previous versions of Windows Server, it bears repeating that the Windows Server 2003 operating system is no longer supported. В результате все контроллеры домена, работающие под управлением Windows Server 2003, необходимо удалить из домена. As a result, any domain controller that runs Windows Server 2003 should be removed from the domain. Режим работы домена и леса должен быть повышен по крайней мере до Windows Server 2008, чтобы не допустить добавления в среду контроллера домена, на котором выполняется более ранняя версия Windows Server. The domain and forest functional level should be raised to at least Windows Server 2008 to prevent a domain controller that runs an earlier version of Windows Server from being added to the environment.

В режимах работы домена Windows Server 2008 и более новых версий для репликации содержимого папки SYSVOL между контроллерами домена используется репликация службы распределенных файловых систем (DFS). At the Windows Server 2008 and higher domain functional levels, Distributed File Service (DFS) Replication is used to replicate SYSVOL folder contents between domain controllers. Если вы создаете домен в режиме работы домена Windows Server 2008 или более новых версий, для репликации SYSVOL автоматически используется репликация DFS. If you create a new domain at the Windows Server 2008 domain functional level or higher, DFS Replication is automatically used to replicate SYSVOL. Если вы создаете домен в более низком режиме работы, необходимо перейти от репликации FRS к DFS для SYSVOL. If you created the domain at a lower functional level, you will need to migrate from using FRS to DFS replication for SYSVOL. Чтобы выполнить миграцию, выполните приведенные ниже действия или ознакомьтесь с упрощенным набором действий в блоге о хранилище файлов группы хранения. For migration steps, you can either follow these steps or you can refer to the streamlined set of steps on the Storage Team File Cabinet blog.

Функциональные уровни домена и леса Windows Server 2003 по-прежнему поддерживаются, но организации должны повысить функциональный уровень до Windows Server 2008 (или более высокий, если возможно), чтобы обеспечить совместимость репликации SYSVOL и поддержку в будущем. The Windows Server 2003 domain and forest functional levels continue to be supported, but organizations should raise the functional level to Windows Server 2008 (or higher if possible) to ensure SYSVOL replication compatibility and support in the future. Кроме того, существует множество других преимуществ и функций, доступных на более высоких функциональных уровнях выше. In addition, there are many other benefits and features available at the higher functional levels higher. Дополнительную информацию можно найти в следующих ресурсах: See the following resources for more information: