В данной статье сравниваются варианты интеграции локальной среды Active Directory (AD) с сетью Azure. Для каждого варианта доступна подробная эталонная архитектура.
Во многих организациях доменные службы Active Directory (AD DS) используются для проверки подлинности удостоверений, связанных с пользователями, компьютерами, приложениями или другими ресурсами, включенными в периметр безопасности. Как правило, службы каталогов и удостоверений размещаются в локальной среде, но если приложение размещено частично локально и частично в Azure, при отправке запросов на аутентификацию от Azure в локальную среду может возникнуть задержка. Внедрение службы каталогов и удостоверений в Azure может сократить ее.
В Azure предусмотрено два решения для внедрения служб каталогов и удостоверений:
Используйте идентификатор Microsoft Entra, чтобы создать домен Active Directory в облаке и подключить его к вашему локальная служба Active Directory домену. Microsoft Entra Подключение интегрирует локальные каталоги с идентификатором Microsoft Entra.
Расширьте существующую инфраструктуру локальной среды Active Directory в Azure, развернув виртуальную машину, на которой выполняются AD DS, как контроллер домена. Эта архитектура чаще используется при подключении к локальной и виртуальной сети Azure по VPN или ExpressRoute. Существует несколько вариантов этой архитектуры:
- Создайте домен в Azure и присоедините его к своему локальному лесу AD.
- Создайте в локальном лесу отдельный лес в Azure, который является доверенным для доменов.
- Реплицируйте развернутые службы федерации Active Directory (AD FS) в Azure.
В следующих разделах более подробно описан каждый из этих вариантов.
Интеграция локальных доменов с идентификатором Microsoft Entra
Используйте идентификатор Microsoft Entra, чтобы создать домен в Azure и связать его с локальным доменом AD.
Каталог Microsoft Entra не является расширением локального каталога. Скорее, это копия с теми же объектами и удостоверениями. Изменения, внесенные в эти элементы, копируются в идентификатор Microsoft Entra, но изменения, внесенные в идентификатор Microsoft Entra, не реплика обратно в локальный домен.
Вы также можете использовать идентификатор Microsoft Entra без использования локального каталога. В этом случае идентификатор Microsoft Entra выступает в качестве основного источника всех удостоверений, а не содержит данные, реплика из локального каталога.
Льготы
- Отсутствие необходимости в поддержке инфраструктуры AD в облаке. Идентификатор Microsoft Entra полностью управляется и поддерживается корпорацией Майкрософт.
- Идентификатор Microsoft Entra предоставляет те же сведения об удостоверениях, которые доступны в локальной среде.
- Аутентификация выполняется в Azure. При этом внешним приложениям и пользователям не нужно использовать локальный домен.
Сложности
- Для синхронизации каталога Microsoft Entra необходимо настроить подключение к локальному домену.
- Приложения могут быть перезаписаны, чтобы включить проверку подлинности с помощью идентификатора Microsoft Entra.
- Если вы хотите пройти проверку подлинности служб и учетных записей компьютеров, необходимо также развернуть доменные службы Microsoft Entra.
Эталонная архитектура
Присоединение AD DS в Azure к локальному лесу
Разверните серверы доменных служб AD (AD DS) в Azure. Создайте домен в Azure и присоедините его к своему локальному лесу AD.
Используйте этот параметр, если необходимо использовать функции AD DS, которые в настоящее время не реализованы идентификатором Microsoft Entra.
Льготы
- Предоставление тех же сведений об идентификаторах, что и доступны локально.
- Аутентификация учетных записей пользователя, службы и компьютеров в Azure.
- Отсутствие необходимости в управлении отдельным лесом AD. Принадлежность домена в Azure к локальному лесу.
- Применение групповой политики, определяемой локальными объектами групповой политики, к домену в Azure.
Сложности
- Необходимость в самостоятельном развертывании серверов и домена AD DS в облаке и управлении ими.
- Задержка синхронизации между серверами домена в облаке и локальными серверами.
Эталонная архитектура
AD DS в Azure с отдельным лесом
Создайте лес Active Directory, отделенный от локального, при развертывании серверов доменных служб AD (AD DS) в Azure. Этот лес является доверенным для доменов в локальном лесу.
Типичные способы применения этой архитектуры включают поддержку разделения по безопасности для облачных объектов и удостоверений, а также перенос отдельных доменов из локальной среды в облако.
Льготы
- Реализация локальных удостоверений и отдельных удостоверений, предназначенных только для Azure.
- Отсутствие необходимости в репликации из локального леса AD в Azure.
Сложности
- Необходимость дополнительных сетевых переходов для локальных серверов AD при аутентификации в Azure для локальных удостоверений.
- Необходимость в развертывании собственных серверов и лесов AD DS в облаке, а также в настройке соответствующих отношений доверия между лесами.
Эталонная архитектура
Расширение AD FS в Azure
Реплицируйте развернутые службы федерации Active Directory (AD FS) в Azure для выполнения федеративной аутентификации и авторизации для компонентов, работающих в Azure.
Типичные способы использования этой архитектуры:
- Аутентификация и авторизация пользователей из партнерских организаций.
- Предоставление пользователям возможности прохождения аутентификации в веб-браузерах за пределами брандмауэра организации.
- Предоставление пользователям возможности подключения с помощью авторизованных внешних устройств, таких как мобильные устройства.
Льготы
- Использование приложений с поддержкой утверждений.
- Настройка отношений доверия с внешними партнерами при аутентификации.
- Совместимость со множеством протоколов аутентификации.
Сложности
- Необходимость в развертывании собственных прокси-серверов веб-приложения AD DS и AD FS в Azure.
- Эту архитектуру сложно настроить.
Эталонная архитектура