Распространенные варианты использования и сценарии для доменных служб Microsoft Entra

Доменные службы Microsoft Entra предоставляют управляемые доменные службы, такие как присоединение к домену, групповая политика, протокол LDAP и проверка подлинности Kerberos или NTLM. Доменные службы Microsoft Entra интегрируются с существующим клиентом Microsoft Entra, что позволяет пользователям входить с помощью имеющихся учетных данных. Эти доменные службы используются без необходимости развертывания, управления и обновления контроллеров домена в облаке, что обеспечивает более простой перенос локальных ресурсов в Azure.

В этой статье описаны некоторые распространенные бизнес-сценарии, в которых доменные службы Microsoft Entra предоставляют ценность и соответствуют этим потребностям.

Распространенные способы предоставления облачных решений для идентификации

При переносе существующих рабочих нагрузок в облако вы можете настроить LDAP для приложений, которые поддерживают доступ к каталогу, чтобы они выполняли чтение и запись в локальный каталог AD DS. Приложения, выполняемые в среде Windows Server, обычно развертываются на виртуальных машинах, присоединенных к домену. Это позволяет безопасно управлять ими с помощью групповой политики. Для аутентификации пользователей приложения могут также использовать функцию встроенной проверки подлинности Windows (например, Kerberos или NTLM).

Чтобы предоставить службу идентификации для приложений, работающих в Azure, ИТ-администраторы часто применяют одно из следующих решений:

• Настройка VPN-подключения типа "сеть — сеть" между рабочей нагрузкой в Azure и локальной средой AD DS.
  • Затем локальные контроллеры домена обеспечивают проверку подлинности через VPN-подключение.
• Создание реплик контроллеров домена с помощью виртуальных машин Azure для расширения домена или леса AD DS из локальной среды.
  • Контроллеры домена, работающие на виртуальных машинах Azure, обеспечивают проверку подлинности и реплицируют данные каталога из локальной среды AD DS.
• развертывание автономной среды AD DS в Azure на основе контроллеров домена, работающих на виртуальных машинах Azure.
  • Контроллеры домена, работающие на виртуальных машинах Azure, обеспечивают проверку подлинности, но данные каталога не реплицируются из локальной среды AD DS.

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

Доменные службы Microsoft Entra предлагают альтернативные варианты создания VPN-подключений к локальной среде AD DS или запуска виртуальных машин в Azure и управления ими для предоставления служб удостоверений. Как управляемая служба, доменные службы Microsoft Entra снижают сложность создания интегрированного решения удостоверений для гибридных и облачных сред.

Сравнение доменных служб Microsoft Entra с идентификатором Microsoft Entra и самоуправляемыми AD DS на виртуальных машинах Azure или локальной среде

Доменные службы Microsoft Entra для гибридных организаций

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

Рассмотрим пример гибридной организации Litware Corporation, которая использует одновременно локальные ресурсы и облако Azure.

• Приложения и серверные рабочие нагрузки, для которых требуются службы доменов, развертываются в виртуальной сети Azure.
  • Сюда относятся и старые приложения, перенесенные в Azure согласно стратегии lift-and-shift.
• Чтобы синхронизировать сведения об удостоверениях из локального каталога с клиентом Microsoft Entra, Litware Corporation развертывает Microsoft Entra Подключение.
  • Среди прочего синхронизируются учетные записи пользователей и сведения о членстве в группах.
• ИТ-команда Litware включает доменные службы Microsoft Entra для своего клиента Microsoft Entra в этой или одноранговой виртуальной сети.
• Приложения и виртуальные машины, развернутые в виртуальной сети Azure, могут использовать функции доменных служб Microsoft Entra, такие как присоединение к домену, чтение LDAP, привязка LDAP, проверка подлинности NTLM и Kerberos, а также групповая политика.

Важно!

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

Доменные службы Microsoft Entra для облачных организаций

У клиента Microsoft Entra только для облака нет локального источника удостоверений. Учетные записи пользователей и членство в группах, например, создаются и управляются непосредственно в идентификаторе Microsoft Entra.

Теперь рассмотрим пример компании Contoso, которая использует идентификатор Microsoft Entra для идентификации. Все удостоверения пользователей, их учетные данные и членство в группах создаются и управляются в идентификаторе Microsoft Entra. Дополнительная конфигурация Microsoft Entra Подключение для синхронизации сведений о удостоверении из локального каталога отсутствует.

• Приложения и серверные рабочие нагрузки, для которых требуются службы доменов, развертываются в виртуальной сети Azure.
• ИТ-команда Contoso включает доменные службы Microsoft Entra для своего клиента Microsoft Entra в этой или одноранговой виртуальной сети.
• Приложения и виртуальные машины, развернутые в виртуальной сети Azure, могут использовать функции доменных служб Microsoft Entra, такие как присоединение к домену, чтение LDAP, привязка LDAP, проверка подлинности NTLM и Kerberos, а также групповая политика.

Безопасное администрирование виртуальных машин Azure

Чтобы позволить использовать один набор учетных данных AD, виртуальные машины Azure можно присоединить к управляемому домену доменных служб Microsoft Entra. Такой подход позволяет сократить количество проблем с управлением учетными данными, например поддержку локальных учетных записей администраторов на каждой виртуальной машине или отдельных учетных записей и паролей между средами.

Виртуальные машины, присоединенные к управляемому домену, также можно администрировать и защищать с помощью групповой политики. К виртуальным машинам также можно применять необходимые базовые показатели системы безопасности или блокировать их в соответствии с корпоративными рекомендациями по безопасности. Например, для запрета запуска приложений определенного типа на виртуальной машине можно использовать возможности управления групповой политикой.

Рассмотрим пример типичного сценария. С истечением срока эксплуатации серверов и прочей инфраструктуры компания Contoso хочет переместить в облако множество приложений, которые в настоящее время размещены локально. Согласно текущему корпоративному стандарту использования ИТ-ресурсов серверы, на которых размещаются корпоративные приложения, должны быть присоединены к домену, а управляться они должны с помощью групповой политики.

ИТ-администратор компании Contoso предпочитает присоединить к домену виртуальные машины, развернутые в Azure, чтобы упростить администрирование, так как пользователи затем смогут выполнять вход с использованием корпоративных учетных данных. При присоединении к домену виртуальные машины также можно настроить с учетом необходимых базовых показателей безопасности с помощью объектов групповой политики (GPO). Отсутствие необходимости выполнять развертывание и мониторинг контроллеров домена в Azure — в интересах Contoso.

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

Примечания по развертыванию

Следующие рекомендации по развертыванию применимы в данном случае.

• По умолчанию управляемые домены используют единую плоскую структуру подразделений. Все виртуальные машины, присоединенные к домену, находятся в одном подразделении. При необходимости можно создать настраиваемые подразделения.
• Доменные службы Microsoft Entra используют встроенный объект групповой политики для контейнеров пользователей и компьютеров. Для дополнительного контроля можно создать настраиваемые объекты групповой политики и привязать их к настраиваемым подразделениям.
• Доменные службы Microsoft Entra поддерживают базовую схему объекта компьютера AD. Расширить схему объекта компьютера нельзя.

Локальные приложения lift-and-shift, использующие проверку подлинности привязки LDAP

В данном примере в компании Contoso используется локальное приложение, которое было приобретено у независимого поставщика ПО много лет назад. Приложение в настоящее время обслуживает этот независимый поставщик, и стоимость запроса на внесение в него изменений будет недопустимо высокой. Это приложение имеет внешний веб-интерфейс, который собирает пользовательские учетные данные с помощью веб-формы, а затем проверяет подлинность пользователей, выполняя привязку LDAP к локальной среде AD DS.

Компании Contoso нужно перенести это приложение в Azure. Приложение должно продолжать работать "как есть" без внесения изменений. Кроме того, пользователи должны иметь возможность проходить проверку подлинности с помощью существующих корпоративных учетных данных и без дополнительного обучения. Конечным пользователям должно быть понятно, где запущено приложение.

В этом сценарии доменные службы Microsoft Entra позволяют приложениям выполнять привязки LDAP в рамках процесса проверки подлинности. Устаревшие локальные приложения могут быть перенесены в Azure и продолжать проверять подлинность пользователей без каких-либо изменений в конфигурации или в пользовательском интерфейсе.

Примечания по развертыванию

Следующие рекомендации по развертыванию применимы в данном случае.

• Убедитесь, что для приложения не требуется вносить изменения или записи в каталог. Доступ на запись LDAP к управляемому домену не поддерживается.
• Пароли нельзя менять непосредственно в управляемом домене. Конечные пользователи могут изменить пароль с помощью механизма самостоятельного изменения пароля Microsoft Entra или локального каталога. Эти изменения затем автоматически синхронизируются с их последующим применением в управляемом домене.

Локальные приложения lift-and-shift, использующие операции чтения LDAP для доступа к каталогу

Как и в предыдущем примере, предположим, что у компании Contoso есть локальное бизнес-приложение, которое было разработано около десяти лет назад. Это приложение использует каталоги и предназначено для использования протокола LDAP для чтения сведений и атрибутов пользователей из AD DS. Приложение не изменяет атрибуты и ничего не записывает в каталог.

Компании Contoso необходимо перенести это приложение в Azure и вывести из эксплуатации устаревшее локальное оборудование, на котором в настоящее время это приложение размещено. Приложение нельзя переписать с использованием современных API-интерфейсов каталогов, например Microsoft Graph API на основе REST. Требуется перенести приложение для запуска в облаке без необходимости менять код или переписывать приложение.

Чтобы помочь в этом сценарии, доменные службы Microsoft Entra позволяют приложениям выполнять операции чтения LDAP в управляемом домене, чтобы получить необходимые сведения о атрибутах. Приложение не нужно перезаписывать, поэтому благодаря методу lift-and-shift в Azure можно продолжать использовать приложение, не зная, где оно выполняется.

Примечания по развертыванию

Следующие рекомендации по развертыванию применимы в данном случае.

• Убедитесь, что для приложения не требуется вносить изменения или записи в каталог. Доступ на запись LDAP к управляемому домену не поддерживается.
• Убедитесь, что приложению не требуется настраиваемая или расширенная схема Active Directory. Расширения схемы не поддерживаются в доменных службах Microsoft Entra.

Перенос локальной службы или управляющего приложения в Azure

Некоторые приложения включают в себя несколько уровней, где один из уровней должен выполнять вызовы, прошедшие проверку, на уровень сервера, например в базу данных. Обычно в таких случаях используются учетные записи служб AD. При перемещении приложений в Azure доменные службы Microsoft Entra позволяют использовать учетные записи служб таким же образом. Вы можете использовать ту же учетную запись службы, которая синхронизирована из локального каталога с идентификатором Microsoft Entra ID или создать настраиваемую подразделение, а затем создать отдельную учетную запись службы в этом подразделении. В обоих этих случаях приложения продолжают работать в одном и том же режиме и отправлять вызовы, прошедшие проверку, на другие уровни и в службы.

В данном примере в компании Contoso используется написанное по заказу приложение — хранилище, состоящее из внешнего веб-интерфейса, сервера SQL и внутреннего FTP-сервера. Для проверки внешнего веб-интерфейса на FTP-сервере применяется встроенная проверка подлинности Windows с помощью учетных записей служб. Веб-интерфейс настраивается для запуска в качестве учетной записи службы. Внутренний сервер настраивается для авторизации доступа к учетной записи службы для веб-интерфейса. Contoso не хочет развертывать и обслуживать собственные виртуальные машины контроллера домена в облаке, чтобы переместить это приложение в Azure.

В этом сценарии серверы, на которых размещается веб-интерфейс, сервер SQL и сервер FTP, можно перенести на виртуальные машины Azure и подключить к управляемому домену. Затем виртуальные машины могут использовать ту же учетную запись службы в локальном каталоге для целей проверки подлинности приложения, которая синхронизируется с помощью идентификатора Microsoft Entra с помощью Microsoft Entra Подключение.

Примечания по развертыванию

Следующие рекомендации по развертыванию применимы в данном случае.

• Убедитесь, что приложение использует имя пользователя и пароль для проверки подлинности. Проверка подлинности на основе сертификата или интеллектуального карта не поддерживается доменными службами Microsoft Entra.
• Пароли нельзя менять непосредственно в управляемом домене. Конечные пользователи могут изменить пароль с помощью механизма самостоятельного изменения пароля Microsoft Entra или локального каталога. Эти изменения затем автоматически синхронизируются с их последующим применением в управляемом домене.

Развертывание служб удаленных рабочих столов Windows в Azure

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

Дополнительные сведения об этом сценарии развертывания см . в том, как интегрировать доменные службы Microsoft Entra с развертыванием RDS.

Присоединенные к домену кластеры HDInsight

Можно настроить кластер Azure HDInsight, который присоединен к управляемому домену с поддержкой Apache Ranger. Создайте и примените политики куста с помощью Apache Ranger и разрешите пользователям (например, специалистам по обработке и анализу данных) подключаться к кусту с помощью средств на основе ODBC, например Excel, Tableau и т. д. Мы планируем в скором времени добавить другие рабочие нагрузки в присоединенный к домену кластер HDInsight, такие как HBase, Spark и Storm.

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

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

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