Основные понятия управления для учетных записей пользователей, паролей и администрирования в доменных службах Microsoft Entra

  • Статья

При создании и запуске управляемого домена доменных служб Microsoft Entra существуют некоторые различия в поведении по сравнению с традиционной локальной средой AD DS. Вы используете те же средства администрирования в доменных службах, что и самоуправляемый домен, но вы не можете напрямую получить доступ к контроллерам домена (DC). Кроме того, могут быть некоторые различия в поведении политик паролей и хэшей паролей в зависимости от источника создания учетной записи пользователя.

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

Управление доменами

Управляемый домен представляет собой пространство имен DNS с соответствующим каталогом. В управляемом домене контроллеры домена, которые содержат все ресурсы, такие как пользователи и группы, учетные данные и политики, являются частью управляемой службы. Для обеспечения избыточности в составе управляемого домена создаются два контроллера домена. Вы не можете входить в эти контроллеры домена для выполнения задач управления. Вместо этого создайте виртуальную машину управления, присоединенную к управляемому домену, а затем установите стандартные средства управления AD DS. Можно использовать центр администрирования Active Directory или оснастки консоли управления Microsoft (MMC), например, объекты DNS или групповой политики.

Создание учетной записи пользователя

Есть несколько способов создания учетных записей пользователей в управляемом домене. Большинство учетных записей пользователей синхронизируются из идентификатора Microsoft Entra ID, который также может включать учетную запись пользователя, синхронизированную из локальной среды AD DS. Кром того, можно вручную создавать учетные записи непосредственно в управляемом домене. Некоторые функции, такие как исходная синхронизация паролей или политика паролей, действуют по-разному в зависимости от того, как и где создаются учетные записи пользователей.

  • Учетная запись пользователя может быть синхронизирована из идентификатора Microsoft Entra. Это включает облачные учетные записи пользователей, созданные непосредственно в идентификаторе Microsoft Entra ID, и гибридные учетные записи пользователей, синхронизированные из локальной среды AD DS с помощью Microsoft Entra Подключение.
    • Большинство учетных записей пользователей в управляемом домене создаются с помощью процесса синхронизации из идентификатора Microsoft Entra.
  • Учетная запись пользователя может быть создана вручную в управляемом домене и не существует в идентификаторе Microsoft Entra.
    • Если необходимо создать учетные записи служб для приложений, которые работают только в управляемом домене, их можно создать вручную в управляемом домене. Так как синхронизация — один из идентификатора Microsoft Entra, учетные записи пользователей, созданные в управляемом домене, не синхронизируются с идентификатором Microsoft Entra.

Политика паролей

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

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

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

Синхронизация хэшей паролей

Для проверки подлинности пользователей в управляемом домене доменные службы должны иметь хэши паролей в формате, подходящем для проверки подлинности NT LAN Manager (NTLM) и Kerberos. Идентификатор Microsoft Entra не создает хэши паролей и не сохраняет хэши паролей в формате, необходимом для проверки подлинности NTLM или Kerberos, пока не включите доменные службы для вашего клиента. По соображениям безопасности идентификатор Microsoft Entra также не сохраняет учетные данные паролей в виде чистотекстового текста. Таким образом, идентификатор Microsoft Entra не может автоматически создавать эти хэши паролей NTLM или Kerberos на основе существующих учетных данных пользователей.

При использовании облачных учетных записей пользователям нужно сменить пароль, чтобы получить доступ к управляемому домену. Этот процесс изменения пароля приводит к созданию и хранению хэшей паролей для проверки подлинности Kerberos и NTLM в идентификаторе Microsoft Entra. Учетная запись не синхронизируется с идентификатором Microsoft Entra с доменными службами, пока пароль не будет изменен.

Для пользователей, синхронизированных из локальной среды AD DS с помощью Microsoft Entra Подключение, включите синхронизацию хэшей паролей.

Важно!

Microsoft Entra Подключение синхронизирует хэши устаревших паролей только при включении доменных служб для клиента Microsoft Entra. Устаревшие хэши паролей не используются, если вы используете только Microsoft Entra Подключение для синхронизации локальной среды AD DS с идентификатором Microsoft Entra.

Если устаревшие приложения не используют проверку подлинности NTLM или простые привязки LDAP, рекомендуется отключить синхронизацию хэша паролей NTLM для доменных служб. Дополнительные сведения см. в статье Отключение слабых комплектов шрифтов и синхронизации хэшей учетных данных NTLM.

После настройки хэши паролей в требуемом формате сохраняются в управляемом домене. Если вы удалите управляемый домен, вместе с ним будут удалены все сохраненные хэши паролей. Синхронизированные учетные данные в идентификаторе Microsoft Entra не могут использоваться повторно, если вы позже создадите другой управляемый домен, необходимо повторно настроить синхронизацию хэша паролей, чтобы сохранить хэши паролей снова. Ранее присоединенные к домену виртуальные машины или пользователи не смогут немедленно пройти проверку подлинности. Идентификатор Microsoft Entra должен создавать и хранить хэши паролей в новом управляемом домене. Дополнительные сведения см. в разделе "Процесс синхронизации хэша паролей" для доменных служб и Подключение Microsoft Entra.

Важно!

Microsoft Entra Подключение следует установить и настроить только для синхронизации с локальными средами AD DS. Не поддерживается установка Microsoft Entra Подключение в управляемом домене для синхронизации объектов с идентификатором Microsoft Entra.

Леса и отношения доверия

Лес — это логическая конструкция, используемая доменными службами Active Directory (AD DS) для группирования одного или нескольких доменов. Затем домены сохраняют объекты для пользователей или групп и предоставляют службы проверки подлинности.

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

По умолчанию управляемый домен синхронизирует все объекты из идентификатора Microsoft Entra, включая все учетные записи пользователей, созданные в локальной среде AD DS. Учетные записи пользователей могут напрямую проходить проверку подлинности в управляемом домене, например для входа в виртуальную машину, присоединенную к домену. Этот подход работает, когда хэши паролей могут быть синхронизированы, и пользователи не используют эксклюзивные методы входа, такие как смарт-карта аутентификация.

В доменных службах можно также создать односторонное доверие леса, чтобы пользователи могли входить из локальной службы AD DS. При таком подходе пользовательские объекты и хэши паролей не синхронизируются с доменными службами. Пользовательские объекты и учетные данные существуют только в локальных AD DS. Такой подход позволяет предприятиям размещать в Azure ресурсы и платформы приложений, которым требуется классическая проверка подлинности, например LDAPS, Kerberos или NTLM, при этом устраняются проблемы проверки подлинности.

Номера SKU доменных служб

В доменных службах доступные функции и производительность основаны на номере SKU. Номер SKU выбирается при создании управляемого домена. После развертывания управляемого домена можно выбрать другие номера SKU по мере изменения бизнес-требований. В следующей таблице приведены доступные номера SKU и различия между ними.

Номер SKU Максимальное число объектов Частота резервного копирования
Standard Не ограничено Раз в 5 дней
Функции корпоративного уровня Не ограничено Раз в 3 дня
Premium Не ограничено Ежедневно

Перед этими номерами SKU доменных служб используется модель выставления счетов на основе количества объектов (учетных записей пользователей и компьютеров) в управляемом домене. Переменное ценообразование с учетом количества объектов в управляемом домене больше не используется.

Дополнительные сведения см. на странице цен на доменные службы.

Производительность управляемого домена

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

Если бизнес-требования или требования к приложениям изменяются, а для управляемого домена требуется дополнительная вычислительная мощность, можно выбрать другой SKU.

Частота резервного копирования

Интервал резервного копирования указывает, насколько часто создается моментальный снимок управляемого домена. Создание резервных копий — это автоматизированный процесс, управляемый платформой Azure. Если возникла проблема с управляемым доменом, служба поддержки Azure может помочь вам восстановить его из резервной копии. Так как синхронизация происходит только один из идентификатора Microsoft Entra, любые проблемы в управляемом домене не влияют на идентификатор Microsoft Entra или локальные среды и функциональные возможности AD DS.

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

Следующие шаги

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