Распространенные варианты использования и сценарии для доменных служб 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 для гибридных организаций
Многие организации выполняют гибридную инфраструктуру, которая включает как облачные, так и локальные рабочие нагрузки приложений. Устаревшие приложения, перенесенные в Azure в рамках стратегии переноса и смещения, могут использовать традиционные подключения LDAP для предоставления сведений об удостоверениях. Для поддержки этой гибридной инфраструктуры сведения об удостоверениях из локальной среды AD DS можно синхронизировать с клиентом Microsoft Entra. Доменные службы Microsoft Entra затем предоставляют эти наследуемые приложения в Azure с идентификационным источником без необходимости настройки и управления подключением приложений к локальным каталоговым службам.
Давайте рассмотрим пример для Litware Corporation, гибридной организации, которая выполняет как локальные, так и ресурсы Azure:
- Приложения и серверные рабочие нагрузки, требующие доменных служб, развертываются в виртуальной сети в Azure.
- Это может включать устаревшие приложения, перенесенные в Azure в рамках стратегии переноса и перенастройки.
- Чтобы синхронизировать сведения об удостоверениях из локального каталога с клиентом Microsoft Entra, Litware Corporation развертывает Microsoft Entra Connect.
- Сведения об удостоверениях, синхронизированные, включают учетные записи пользователей и членство в группах.
- ИТ-команда Litware включает доменные службы Microsoft Entra для своего клиента Microsoft Entra в этой или одноранговой виртуальной сети.
- Приложения и виртуальные машины, развернутые в виртуальной сети Azure, могут использовать функции доменных служб Microsoft Entra, такие как присоединение к домену, чтение LDAP, привязка LDAP, проверка подлинности NTLM и Kerberos, а также групповая политика.
Важный
Microsoft Entra Connect следует установить и настроить только для синхронизации с локальными средами AD DS. Не поддерживается установка Microsoft Entra Connect в управляемом домене для синхронизации объектов обратно с идентификатором Microsoft Entra.
Доменные службы Microsoft Entra для облачных организаций
У облачного клиента Microsoft Entra отсутствует локальный источник удостоверений. Учетные записи пользователей и членство в группах, например, создаются и управляются непосредственно в идентификаторе Microsoft Entra.
Теперь рассмотрим пример облачной компании Contoso, которая использует Microsoft Entra ID для идентификации. Все удостоверения пользователей, их учетные данные и членство в группах создаются и управляются в идентификаторе Microsoft Entra. Для синхронизации сведений о удостоверении из локального каталога не существует дополнительной конфигурации Microsoft Entra Connect.
- Приложения и серверные рабочие нагрузки, требующие доменных служб, развертываются в виртуальной сети в Azure.
- ИТ-команда Contoso включает доменные службы Microsoft Entra для своего клиента Microsoft Entra в этой или одноранговой виртуальной сети.
- Приложения и виртуальные машины, развернутые в виртуальной сети Azure, могут использовать функции доменных служб Microsoft Entra, такие как присоединение к домену, чтение LDAP, привязка LDAP, проверка подлинности NTLM и Kerberos, а также групповая политика.
Безопасное администрирование виртуальных машин Azure
Чтобы позволить использовать один набор учетных данных AD, виртуальные машины Azure можно присоединить к управляемому домену доменных служб Microsoft Entra. Этот подход снижает проблемы управления учетными данными, такие как обслуживание учетных записей локального администратора на каждой виртуальной машине или отдельных учетных записей и паролей между средами.
Виртуальные машины, присоединенные к управляемому домену, также можно администрировать и защищать с помощью групповой политики. Необходимые базовые показатели безопасности можно применять к виртуальным машинам, чтобы заблокировать их в соответствии с рекомендациями по корпоративной безопасности. Например, можно использовать возможности управления групповыми политиками, чтобы ограничить типы приложений, которые можно запустить на виртуальной машине.
Рассмотрим распространенный пример сценария. Так как серверы и другая инфраструктура достигают конца жизни, Компания Contoso хочет переместить приложения, размещенные в настоящее время в локальном облаке. Их текущий ИТ-стандарт требует, чтобы серверы, на которых размещаются корпоративные приложения, должны быть присоединены к домену и управляться с помощью групповой политики.
ИТ-администратор Contoso предпочел бы присоединить к домену виртуальные машины, развернутые в Azure, чтобы упростить администрирование, так как пользователи смогут входить, используя корпоративные учетные данные. При присоединении к домену виртуальные машины также можно настроить для соблюдения необходимых базовых показателей безопасности с помощью объектов групповой политики (ГОП). Компания Contoso предпочла бы не развертывать, отслеживать и управлять собственными контроллерами домена в Azure.
Доменные службы Microsoft Entra отлично подходят для этого варианта использования. Управляемый домен позволяет виртуальным машинам присоединиться к домену, использовать один набор учетных данных и применять групповую политику. Так как это управляемый домен, вам не нужно настраивать и обслуживать контроллеры домена самостоятельно.
Заметки о развертывании
Следующие рекомендации по развертыванию относятся к этому примеру использования:
- Управляемые домены по умолчанию используют единую плоскую структуру организационной единицы (ОЕ). Все присоединенные к домену виртуальные машины находятся в одной организационной единице. При желании можно создать пользовательские организационные единицы.
- Доменные службы Microsoft Entra используют встроенные объекты групповой политики, каждый из которых предназначен для контейнера пользователей и контейнера компьютеров. Для дополнительного контроля можно создать пользовательские объекты групповой политики (GPO) и назначить их на пользовательские подразделения.
- Доменные службы Microsoft Entra поддерживают базовую схему объекта компьютера AD. Невозможно расширить схему объекта компьютера.
Перенос локальных приложений на облако, использующих аутентификацию привязки LDAP.
В качестве примера сценария компания Contoso имеет локальное приложение, которое было приобретено из поставщика программного обеспечения много лет назад. В настоящее время приложение находится в режиме обслуживания независимым поставщиком программного обеспечения (ISV), и запрос на изменения в приложении требует чрезвычайно высоких затрат. Это приложение имеет веб-интерфейс, который собирает учетные данные пользователя с помощью веб-формы, а затем проверяет подлинность пользователей, выполняя привязку LDAP к локальной среде AD DS.
Компания Contoso хотела бы перенести это приложение в Azure. Приложение должно продолжать работать и не требовать изменений as-is. Кроме того, пользователи должны иметь возможность проходить проверку подлинности с помощью существующих корпоративных учетных данных и без дополнительного обучения. Он должен быть прозрачным для конечных пользователей, где работает приложение.
В этом сценарии доменные службы Microsoft Entra позволяют приложениям выполнять привязки LDAP в рамках процесса проверки подлинности. Традиционные локальные приложения могут переноситься в Azure и продолжать беспрепятственно проверять подлинность пользователей без каких-либо изменений в конфигурации или пользовательском опыте.
Заметки о развертывании
Следующие рекомендации по развертыванию относятся к этому примеру использования:
- Убедитесь, что приложению не нужно изменять или записывать в каталог. Доступ на запись LDAP к управляемому домену не поддерживается.
- Нельзя изменять пароли непосредственно в управляемом домене. Конечные пользователи могут изменить свой пароль либо с помощью механизма самостоятельного изменения пароля Microsoft Entra , либо через локальный каталог. Эти изменения будут автоматически синхронизированы и доступны в управляемом домене.
Локальные приложения lift-and-shift, использующие чтение LDAP для доступа к каталогу
Как и в предыдущем примере сценария, предположим, компания Contoso имеет локальное бизнес-приложение, которое было разработано почти десять лет назад. Это приложение работает с каталогами и предназначено для использования LDAP для чтения информации и атрибутов о пользователях из AD DS. Приложение не изменяет атрибуты или не записывает их в каталог.
Компания Contoso хочет перенести это приложение в Azure и удалить устаревшее локальное оборудование, в настоящее время размещающее это приложение. Приложение нельзя переписать для использования современных API каталогов, таких как API Microsoft Graph на основе REST. Требуется возможность «lift-and-shift», где приложение можно перенести для работы в облаке, не изменяя код и не переписывая приложение.
Чтобы помочь в этом сценарии, доменные службы Microsoft Entra позволяют приложениям выполнять операции чтения LDAP в управляемом домене, чтобы получить необходимые сведения о атрибутах. Приложение не нужно переписывать, поэтому перенос в Azure позволяет пользователям продолжать пользоваться им, не замечая изменения в том, где оно работает.
Заметки о развертывании
Следующие рекомендации по развертыванию относятся к этому примеру использования:
- Убедитесь, что приложению не нужно изменять или записывать в каталог. Доступ на запись LDAP к управляемому домену не поддерживается.
- Убедитесь, что приложению не нужна настраиваемая или расширенная схема Active Directory. Расширения схемы не поддерживаются в доменных службах Microsoft Entra.
Перенос локальной службы или приложения управляющей программы в Azure
Некоторые приложения включают несколько уровней, где один из уровней должен выполнять прошедшие проверку подлинности вызовы к внутреннему уровню, например базе данных. Учетные записи службы AD обычно используются в этих сценариях. При перемещении приложений в Azure доменные службы Microsoft Entra позволяют использовать учетные записи служб таким же образом. Вы можете использовать ту же учетную запись службы, которая синхронизирована из локального каталога с идентификатором Microsoft Entra ID, или создать настраиваемое подразделение и затем отдельную учетную запись службы в этом подразделении. При любом подходе приложения продолжают работать таким же образом, чтобы выполнять прошедшие проверку подлинности вызовы к другим уровням и службам.
учетная запись службы
В этом примере компания Contoso имеет пользовательское приложение хранилища программного обеспечения, включающее веб-интерфейс, сервер SQL Server и внутренний FTP-сервер. Встроенная в Windows проверка подлинности с помощью учетных записей служб выполняет проверку подлинности веб-интерфейса на FTP-сервере. Веб-интерфейс настраивается для запуска как служебная учетная запись. Сервер серверной части настроен для авторизации доступа из учетной записи службы для веб-интерфейса. Компания Contoso не хочет развертывать и управлять собственными виртуальными машинами контроллера домена в облаке, чтобы переместить это приложение в Azure.
В этом сценарии серверы, на котором размещается веб-интерфейс, SQL Server и FTP-сервер, можно перенести на виртуальные машины Azure и присоединиться к управляемому домену. Затем виртуальные машины могут использовать ту же учетную запись службы в локальном каталоге для целей проверки подлинности приложения, которая синхронизируется с помощью идентификатора Microsoft Entra Connect с помощью Microsoft Entra Connect.
Заметки о развертывании
Следующие рекомендации по развертыванию относятся к этому примеру использования:
- Убедитесь, что приложения используют имя пользователя и пароль для проверки подлинности. Проверка подлинности на основе сертификатов или смарт-карт не поддерживается доменными службами Microsoft Entra.
- Нельзя изменять пароли непосредственно в управляемом домене. Конечные пользователи могут изменить свой пароль либо с помощью механизма самостоятельного изменения пароля Microsoft Entra или локального каталога. Эти изменения будут автоматически синхронизированы и доступны в управляемом домене.
Развертывания служб удаленных рабочих столов Windows Server в Azure
Доменные службы Microsoft Entra можно использовать для предоставления управляемых доменных служб серверам удаленных рабочих столов, развернутых в Azure.
Дополнительные сведения об этом сценарии развертывания см. в разделе «Как интегрировать доменные службы Microsoft Entra с развертыванием RDS».
Присоединенные к домену кластеры HDInsight
Вы можете настроить кластер Azure HDInsight, присоединенный к управляемому домену с включенным Apache Ranger. Вы можете создавать и применять политики Hive с помощью Apache Ranger и разрешать пользователям, таким как специалисты по обработке и анализу данных, подключаться к Hive с помощью таких средств на основе ODBC, как Excel или Tableau. Мы продолжаем интегрировать в HDInsight, присоединенный к домену, такие рабочие нагрузки, как HBase, Spark и Storm.
Дополнительные сведения об этом сценарии развертывания см. в разделе о том, как настроить кластеры HDInsight, присоединенные к домену,
Дальнейшие действия
Чтобы приступить к работе, создайте и настройте управляемый домен доменных служб Microsoft Entra.