Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
При создании и запуске управляемого домена доменных служб 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 ID. Если необходимо создать учетные записи служб для приложений, которые работают только в управляемом домене, их можно создать вручную в управляемом домене. Синхронизация выполняется только одним способом из Microsoft Entra ID, поэтому учетные записи пользователей, создаваемые в управляемом домене, не синхронизируются с Microsoft Entra ID.
Политика паролей
Доменные службы включают политику паролей по умолчанию, которая определяет параметры для таких элементов, как блокировка учетной записи, максимальный возраст пароля и сложность пароля. Такие параметры, как политика блокировки учетных записей, применяются для всех пользователей в управляемом домене независимо от способа создания пользователя, как описано в предыдущем разделе. Некоторые параметры, такие как минимальная длина пароля и сложность пароля, применяются только для пользователей, созданных непосредственно в управляемом домене.
Можно создать собственные политики паролей, чтобы переопределить политику по умолчанию в управляемом домене. Эти пользовательские политики можно затем при необходимости применять к конкретным группам пользователей.
Дополнительные сведения о различиях в применении политик паролей в зависимости от источника создания пользователей см. в статье Политики блокировки паролей и учетных записей в управляемых доменах.
Хэши паролей
Для проверки подлинности пользователей в управляемом домене доменные службы должны иметь хэши паролей в формате, подходящем для проверки подлинности NT LAN Manager (NTLM) и Kerberos. Microsoft Entra ID не создает хэши паролей или не храните их в формате, который требуется для проверки подлинности NTLM или Kerberos, пока не включите доменные службы для вашего клиента. По соображениям безопасности идентификатор Microsoft Entra также не сохраняет учетные данные паролей в виде чистотекстового текста. Таким образом, идентификатор Microsoft Entra не может автоматически создавать эти хэши паролей NTLM или Kerberos на основе существующих учетных данных пользователей.
При использовании облачных учетных записей пользователям нужно сменить пароль, чтобы получить доступ к управляемому домену. Этот процесс изменения пароля приводит к созданию и хранению хэшей паролей для проверки подлинности Kerberos и NTLM в идентификаторе Microsoft Entra. Учетная запись не синхронизируется с идентификатором Microsoft Entra с доменными службами, пока пароль не будет изменен.
Для пользователей, синхронизированных из локальной среды AD DS с помощью Microsoft Entra Connect, включите синхронизацию хэшей паролей.
Внимание
Microsoft Entra Connect синхронизирует хэши устаревших паролей только при включении доменных служб для клиента Microsoft Entra. Устаревшие хэши паролей не используются, если для синхронизации локальной среды AD DS с Microsoft Entra ID используется только Microsoft Entra Connect.
Если устаревшие приложения не используют проверку подлинности NTLM или простые привязки протокола LDAP, рекомендуется отключить синхронизацию хэша паролей NTLM для доменных служб. Более подробную информацию см. в статье Отключение слабых наборов шифров и синхронизации хэшей учетных данных NTLM.
После настройки хэши паролей в требуемом формате сохраняются в управляемом домене. Если вы удалите управляемый домен, вместе с ним будут удалены все сохраненные хэши паролей. Синхронизированные учетные данные в идентификаторе Microsoft Entra не могут использоваться повторно, если вы позже создадите другой управляемый домен, необходимо повторно настроить синхронизацию хэша паролей, чтобы сохранить хэши паролей снова. Ранее присоединенные к домену виртуальные машины или пользователи не могут немедленно пройти проверку подлинности. Идентификатор Microsoft Entra должен создавать и хранить хэши паролей в новом управляемом домене. Дополнительные сведения см. в разделе "Синхронизация хэша паролей" для доменных служб и Microsoft Entra Connect.
Внимание
Microsoft Entra Connect следует установить и настроить только для синхронизации с локальными средами AD DS. Установка Microsoft Entra Connect в управляемом домене для синхронизации с Microsoft Entra ID не поддерживается.
Леса и отношения доверия
Лес — это логическая конструкция, используемая доменными службами Active Directory (AD DS) для группирования одного или нескольких доменов. Затем домены сохраняют объекты для пользователей или групп и предоставляют службы проверки подлинности.
В доменных службах лес содержит только один домен. Локальные леса AD DS часто содержат много доменов. В крупных организациях, особенно после слияний и поглощений, у вас может быть несколько локальных лесов, каждый из которых содержит несколько доменов.
По умолчанию управляемый домен синхронизирует все объекты из идентификатора Microsoft Entra, включая все учетные записи пользователей, созданные в локальной среде AD DS. Учетные записи пользователей могут напрямую проходить проверку подлинности в управляемом домене, например для входа в виртуальную машину, присоединенную к домену. Этот подход работает, когда хэши паролей могут быть синхронизированы, и пользователи не используют эксклюзивные методы входа, такие как проверка подлинности смарт-карты.
В доменных службах можно также создать доверие между лесами с другим доменом, чтобы пользователи могли получать доступ к ресурсам. В зависимости от требований к доступу, вы можете создавать доверительные отношения в лесу в разных направлениях.
| Направление доверия | Доступ пользователей |
|---|---|
| Двусторонний | Позволяет пользователям в управляемом домене и локальном домене получать доступ к ресурсам в любом домене. |
| Односторонняя исходящая | Позволяет пользователям в локальном домене получать доступ к ресурсам в управляемом домене, но не наоборот. |
| Односторонний входящий | Позволяет пользователям в управляемом домене получать доступ к ресурсам в локальном домене. |
Номера SKU доменных служб
В доменных службах доступные функции и производительность основаны на единице хранения запасов (SKU). При создании управляемого домена вы выбираете SKU, а после создания управляемого домена можете изменить его по мере изменения требований бизнеса. В следующей таблице приведены доступные номера SKU и различия между ними.
| Артикул | Рекомендуемое число объектов | Рекомендуемый объём аутентификации | Частота резервного копирования |
|---|---|---|---|
| Стандарт | До 25 000 объектов | До 3000 аутентификаций в час | Каждые пять дней |
| Предприятие | 25 001–100 000 объектов | 3001–10 000 аутентификаций в час | Каждые три дня |
| Премиум | 100 001–500 000 объектов | 10 001–70 000 аутентификаций в час | Ежедневно; резервные копии хранятся семь дней, при этом каждая третья резервная копия сохраняется 30 дней. |
Note
Отображаемые значения являются рекомендуемыми рекомендациями по емкости, а не принудительным ограничениям. По мере увеличения уровня SKU дополнительные вычислительные ресурсы выделяются управляемому домену, что может повысить производительность, операции синхронизации и пропускную способность проверки подлинности. Выберите SKU исходя из размера рабочей нагрузки, объема аутентификации, требований к производительности и требований к восстановлению.
Перед этими номерами SKU доменных служб используется модель выставления счетов на основе количества объектов (учетных записей пользователей и компьютеров) в управляемом домене. Цены больше не зависят от количества объектов в управляемом домене.
Дополнительные сведения см. на странице цен на доменные службы.
Производительность управляемого домена
Производительность домена зависит от способа реализации проверки подлинности для приложения. Дополнительные вычислительные ресурсы могут помочь улучшить время отклика запроса и сократить время синхронизации. По мере увеличения уровня SKU для управляемого домена доступны дополнительные вычислительные ресурсы. Отслеживайте производительность приложений и планируйте необходимые ресурсы.
Если бизнес или приложение требуют изменения и требуется больше вычислительных ресурсов для управляемого домена, вы можете переключиться на другой номер SKU.
Частота резервного копирования
Частота резервного копирования определяет, как часто создается снимок состояния управляемого домена. Резервные копии — это автоматизированный процесс, управляемый платформой Microsoft Entra. Если возникла проблема с управляемым доменом, Microsoft Entra поддержка может помочь вам при восстановлении из резервного копирования. Поскольку синхронизация выполняется только в одном направлении — из Microsoft Entra ID, любые проблемы в управляемом домене не влияют на Microsoft Entra ID или локальные среды AD DS и их функциональность.
С увеличением уровня SKU частота создания резервных копий увеличивается. Проверьте бизнес-требования и целевую точку восстановления, чтобы определить необходимый интервал резервного копирования для управляемого домена. Если бизнес-требования или требования к приложениям изменяются и необходимо создавать резервные копии чаще, можно выбрать другой SKU.
Доменные службы предоставляют следующие рекомендации по интервалам времени восстановления для различных типов проблем:
- Цель точки восстановления (RPO) — это максимальное интервал времени, в котором существует потенциальная потеря данных или транзакций из инцидента.
- Объект времени восстановления (RTO) — это целевой интервал времени, который возникает до возвращения уровней обслуживания в эксплуатацию после инцидента.
| Проблемы | РПО | RTO |
|---|---|---|
| Проблемы, вызванные потерей данных или повреждением контроллеров домена доменных служб, зависимых служб, эксплойтом, который скомпрометировал домен или другой инцидент, требующий восстановления контроллера домена. | Пять дней до появления события | От двух часов до четырех дней в зависимости от размера арендатора |
| Проблемы, выявленные средством диагностики домена службы поддержки Microsoft. | Ноль (0 минут) | От двух часов до четырех дней в зависимости от размера арендатора |
Следующие шаги
Чтобы приступить к работе, создайте управляемый домен доменных служб.