Основные понятия управления для учетных записей пользователей, паролей и администрирования в доменных службах 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 Connect.
  • Большинство учетных записей пользователей в управляемом домене создаются с помощью процесса синхронизации из идентификатора 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 Connect, включите синхронизацию хэшей паролей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доменные службы предоставляют следующие рекомендации по интервалам времени восстановления для различных типов проблем:

• Цель точки восстановления (RPO) — это максимальный интервал времени, в котором существует потенциальная потеря данных или транзакций из инцидента.
• Объект времени восстановления (RTO) — это целевой интервал времени, который возникает до возвращения уровней обслуживания в эксплуатацию после инцидента.

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

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