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


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

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

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

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

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

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

Примечание.

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

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

Совет

Действия, описанные в этой статье, могут немного отличаться на портале, с который вы начинаете работу.

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

  1. Войдите в Центр администрирования Microsoft Entra как минимум администратор пользователя.
  2. Найдите и выберите Microsoft Entra Connect.
  3. На странице Microsoft Entra Connect в разделе поэтапного развертывания облачной проверки подлинности нажмите кнопку "Включить поэтапное развертывание" для входа управляемого пользователя.
  4. На странице функции "Включить поэтапное развертывание" нажмите кнопку "Включить" для проверки подлинности на основе сертификатов
  5. Щелкните " Управление группами " и добавьте группы, которые вы хотите быть частью облачной проверки подлинности. Чтобы избежать истечения времени ожидания, убедитесь, что группы безопасности изначально содержат не более 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 отправит указание в качестве имени участника-пользователя Microsoft Entra UPN. Затем сертификат должен соответствовать этому пользователю с помощью одной из настроенных привязок имени пользователя в политике.

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