Миграция из федерации в проверку подлинности на основе сертификата Microsoft Entra (CBA)

Статья
10/03/2024

В этой статье объясняется, как выполнить миграцию с федеративных серверов, таких как службы федерации Active Directory (AD FS) (AD FS) в облачную проверку подлинности с помощью проверки подлинности на основе сертификата Microsoft Entra (CBA).

Поэтапное развертывание

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

Поэтапное развертывание для проверки подлинности на основе сертификатов (CBA) помогает клиентам переходить от выполнения CBA в федеративном поставщике удостоверений в идентификатор Microsoft Entra ID путем выборочного перемещения небольшого набора пользователей для использования CBA в идентификаторе Microsoft Entra ID (больше не перенаправляется на федеративный поставщик удостоверений) с выбранными группами пользователей, прежде чем затем преобразовать конфигурацию домена в идентификатор Microsoft Entra id из федеративной в управляемый. Поэтапное развертывание не предназначено для того, чтобы домен оставался федеративным на длительное время или для большого количества пользователей.

Просмотрите это краткое видео, демонстрирующее миграцию с проверки подлинности на основе сертификатов ADFS в Microsoft Entra CBA

Примечание.

При включении поэтапного развертывания для пользователя пользователь считается управляемым пользователем, и все проверки подлинности выполняются по идентификатору Microsoft Entra. Для федеративного клиента, если CBA включен в этапе развертывания, аутентификация паролем работает только в том случае, если PHS также включен. В противном случае проверка подлинности паролей завершается ошибкой.

Включение поэтапного развертывания для проверки подлинности на основе сертификатов в клиенте

Чтобы настроить поэтапное развертывание, выполните следующие действия.

Войдите в Центр администрирования Microsoft Entra как минимум администратор пользователя.
Найдите и выберите Microsoft Entra Connect.
На странице Microsoft Entra Connect в разделе поэтапного развертывания облачной проверки подлинности выберите Включить поэтапное развертывание для управляемого входа пользователя.
На странице компонента Enable Staged Rollout выберите On для параметра аутентификации на основе сертификатов
Выберите Управление группами и добавьте группы, которые вы хотите включить в облачную проверку подлинности. Чтобы избежать истечения времени ожидания, убедитесь, что группы безопасности изначально содержат не более 200 членов.

Дополнительные сведения см. в разделе "Поэтапное развертывание".

Использование Microsoft Entra Connect для обновления атрибута certificateUserIds

Администратор AD FS может использовать редактор правил синхронизации для создания правил синхронизации для синхронизации значений атрибутов из AD FS с пользовательскими объектами Microsoft Entra. Дополнительные сведения см. в разделе "Правила синхронизации для certificateUserIds".

Для Microsoft Entra Connect требуется специальная роль с именем "Администратор гибридных удостоверений", которая предоставляет необходимые разрешения. Эта роль необходима для разрешения на запись в новый атрибут облака.

Примечание.

Если пользователь использует синхронизированные атрибуты, например атрибут onPremisesUserPrincipalName в объекте пользователя для привязки имени пользователя, то любой пользователь, имеющий административный доступ к серверу Microsoft Entra Connect, может изменить сопоставление синхронизированных атрибутов и изменить значение синхронизированного атрибута. Пользователю не нужно быть администратором облака. Администратор AD FS должен убедиться, что административный доступ к серверу Microsoft Entra Connect должен быть ограничен, а привилегированные учетные записи должны быть облачными учетными записями.

Часто задаваемые вопросы о миграции с AD FS на идентификатор Microsoft Entra

Можно ли иметь привилегированные учетные записи с федеративным сервером AD FS?

Хотя это возможно, корпорация Майкрософт рекомендует использовать привилегированные учетные записи как облачные. Использование облачных учетных записей для ограничения привилегированного доступа в идентификаторе Microsoft Entra id из скомпрометированного локального окружения. Дополнительные сведения см. в разделе Защита Microsoft 365 от локальных атак.

Если организация является гибридной под управлением AD FS и Azure CBA, они по-прежнему уязвимы для компрометации AD FS?

Корпорация Майкрософт рекомендует использовать привилегированные учетные записи как облачные. Эта практика ограничивает воздействие идентификатора Microsoft Entra из скомпрометированного локального окружения. Обслуживание привилегированных учетных записей, доступных только для облака, является основой для этой цели.

Для синхронизированных учетных записей:

Если он находится в управляемом домене (не федеративном), нет риска от федеративного поставщика удостоверений.
Если они в федеративном домене, но подмножество учетных записей перемещается в Microsoft Entra CBA от staged Rollout, они подвергаются рискам, связанным с федеративной поставщиком удостоверений, пока федеративный домен полностью не переключится на облачную проверку подлинности.

Должны ли организации исключить федеративные серверы, такие как AD FS, чтобы предотвратить возможность сводки с AD FS в Azure?

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

Если домен федеративный в идентификаторе Microsoft Entra id, высокий уровень доверия помещается в федеративный поставщик удостоверений. AD FS является одним из примеров, но понятие имеет значение true для любого федеративного поставщика удостоверений. Многие организации развертывают федеративный поставщик удостоверений, например AD FS исключительно для проверки подлинности на основе сертификатов. Microsoft Entra CBA полностью удаляет зависимость AD FS в этом случае. С помощью Microsoft Entra CBA клиенты могут переместить свое пространство приложений в идентификатор Microsoft Entra, чтобы модернизировать инфраструктуру IAM и сократить затраты на повышение безопасности.

С точки зрения безопасности учетные данные не изменяются, включая сертификат X.509, ЦС, ПИН-коды и т. д. или используемые PKI. Владельцы PKI сохраняют полный контроль над жизненным циклом выдачи и отзыва сертификата и политикой. Проверка отзыва и проверка подлинности происходят в идентификаторе Microsoft Entra ID вместо федеративного поставщика удостоверений. Эти проверки позволяют выполнять проверку подлинности без пароля, фишинговую проверку подлинности непосредственно в идентификаторе Microsoft Entra для всех пользователей.

Как проверка подлинности работает с федеративной службой AD FS и облачной проверкой подлинности Microsoft Entra с Windows?

Microsoft Entra CBA требует от пользователя или приложения предоставить имя участника-пользователя Microsoft Entra участника-пользователя, выполнившего вход.

В примере браузера пользователь чаще всего вводит имя участника-пользователя в имени участника-пользователя Microsoft Entra UPN. Имя участника-пользователя Microsoft Entra используется для обнаружения областей и пользователей. Затем сертификат должен соответствовать этому пользователю с помощью одной из настроенных привязок имени пользователя в политике.

При входе в Windows совпадение зависит от того, присоединено ли устройство к гибридному или присоединению к Microsoft Entra. Но в обоих случаях, если указана подсказка имени пользователя, Windows отправляет её в формате UPN Microsoft Entra. Затем сертификат должен соответствовать этому пользователю с помощью одной из настроенных привязок имени пользователя в политике.

Поделиться через