Миграция на многофакторную проверку подлинности Microsoft Entra и проверку подлинности пользователей Microsoft Entra

Многофакторная проверка подлинности помогает защитить инфраструктуру и ресурсы от плохих субъектов. Сервер Многофакторной идентификации Майкрософт (сервер MFA) больше не предлагается для новых развертываний. Клиенты, использующие сервер MFA, должны перейти на многофакторную проверку подлинности Microsoft Entra (многофакторная проверка подлинности Microsoft Entra).

Существует несколько вариантов миграции с сервера MFA на идентификатор Microsoft Entra:

• Хорошо: перемещение только службы MFA в идентификатор Microsoft Entra.
• Лучше. Перемещение службы MFA и проверки подлинности пользователей в идентификатор Microsoft Entra ID, описанное в этой статье.
• Лучше всего: перемещение всех приложений, службы MFA и проверки подлинности пользователей в идентификатор Microsoft Entra. См. раздел "Перемещение приложений в идентификатор Microsoft Entra ID" этой статьи, если вы планируете переместить приложения, описанные в этой статье.

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

На следующей схеме показан процесс миграции на многофакторную проверку подлинности Microsoft Entra и облачную проверку подлинности при сохранении некоторых приложений в AD FS. Этот процесс обеспечивает итеративную миграцию пользователей с сервера MFA на многофакторную проверку подлинности Microsoft Entra на основе членства в группах.

Пояснения каждого шага приведены в следующих разделах этой статьи.

Процесс миграции на идентификатор Microsoft Entra и проверку подлинности пользователя

Подготовка групп и Условный доступ

Группы используются в трех основных возможностях для миграции MFA.

• Чтобы итеративно переместить пользователей в многофакторную проверку подлинности Microsoft Entra с помощью поэтапного развертывания.

  Используйте группу, созданную в идентификаторе Microsoft Entra, также называемой облачной группой. Группы безопасности Microsoft Entra можно использовать или Группы Microsoft 365 для перемещения пользователей в MFA и для политик условного доступа.

  Внимание

  Вложенные и динамические группы членства не поддерживаются для поэтапного развертывания. Не используйте эти типы групп.

• Политики условного доступа. Для условного доступа можно использовать идентификатор Microsoft Entra или локальные группы.

• Чтобы вызвать многофакторную проверку подлинности Microsoft Entra для приложений AD FS с правилами утверждений. Этот шаг применим, только если вы используете приложения с AD FS.

  Вы должны использовать локальную группу безопасности Active Directory. После того как многофакторная проверка подлинности Microsoft Entra является дополнительным методом проверки подлинности, вы можете назначить группы пользователей использовать этот метод для каждого доверия проверяющей стороны. Например, можно вызвать многофакторную проверку подлинности Microsoft Entra для пользователей, которые уже перенесены, и сервер MFA для пользователей, которые еще не перенесены. Такая стратегия полезна как при тестировании, так и во время переноса.

Настраивать политики условного доступа

Если вы уже используете условный доступ для определения того, когда пользователям предлагается многофакторная проверка подлинности, вам не потребуется никаких изменений в политиках. Так как пользователи переносятся в облачную проверку подлинности, они начнут использовать многофакторную проверку подлинности Microsoft Entra, как определено политиками условного доступа. Они больше не будут перенаправлены на сервер AD FS и MFA.

Если для федеративных доменов параметру federatedIdpMfaBehavior задано значение enforceMfaByFederatedIdp или для флага SupportsMfa задано $True (параметр federatedIdpMfaBehavior переопределяет SupportsMfa при настройке обоих элементов управления), скорее всего, вы принудительно выполняете MFA в AD FS с использованием правил утверждений. В этом случае необходимо проанализировать правила утверждений на основе доверия проверяющей стороны идентификатора Microsoft Entra и создать политики условного доступа, поддерживающие те же цели безопасности.

При необходимости настройте политики условного доступа перед включением поэтапного развертывания. Дополнительные сведения см. на следующих ресурсах:

• Планирование развертывания условного доступа
• Распространенные политики условного доступа

Подготовка службы федерации Active Directory (AD FS)

Если у вас нет приложений в AD FS, для которых требуется MFA, вы можете пропустить этот раздел и перейти к разделу Подготовка поэтапного развертывания.

Обновление фермы серверов AD FS до версии 2019, уровень поведения фермы (FBL) 4

В AD FS версии 2019 корпорация Майкрософт добавила новые функции, которые позволяют указывать дополнительные способы проверки подлинности для проверяющей стороны, например приложения. Вы можете указать дополнительный способ проверки подлинности с помощью членства в группах для определения поставщика проверки подлинности. Указав дополнительный метод проверки подлинности, вы можете перейти на многофакторную проверку подлинности Microsoft Entra, сохраняя другую проверку подлинности без изменений во время перехода.

Дополнительные сведения см. в статье Обновление до AD FS на Windows Server 2016 с помощью базы данных WID. В статье рассматривается обновление вашей фермы до AD FS 2019 и обновление уровня поведения фермы (FBL) до 4.

Настройка правил утверждений для вызова многофакторной проверки подлинности Microsoft Entra

Теперь, когда многофакторная проверка подлинности Microsoft Entra является дополнительным методом проверки подлинности, вы можете назначить группам пользователей многофакторную проверку подлинности Microsoft Entra, настроив правила утверждений, также известные как доверия проверяющей стороны. Использование групп позволяет контролировать, какой поставщик проверки подлинности вызван, глобально или через приложение. Например, можно вызвать многофакторную проверку подлинности Microsoft Entra для пользователей, зарегистрированных для объединенной информации о безопасности или перенесенных номеров телефонов, при вызове сервера MFA для пользователей, номера телефонов которых не перенесены.

Правила резервного копирования

Перед настройкой новых правил утверждений создайте резервную копию правил. Вам потребуется восстановить правила утверждений в рамках действий по очистке.

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

Чтобы просмотреть глобальные правила, выполните следующую команду:

Get-AdfsAdditionalAuthenticationRule

Чтобы просмотреть отношения доверия проверяющей стороны, выполните следующую команду и замените RPTrustName именем правила утверждений доверия проверяющей стороны:

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules

Политики управления доступом

Для перехода от политик управления доступом к дополнительным правилам проверки подлинности, выполните эту команду для каждого своего отношения доверия с проверяющей стороной с помощью поставщика проверки подлинности сервера MFA:

Set-AdfsRelyingPartyTrust -**TargetName AppA -AccessControlPolicyName $Null**

Эта команда перенесет логику из текущей политики управления доступом в дополнительные правила проверки подлинности.

Настройка группы и поиск идентификатора безопасности

Вам потребуется определенная группа, в которой вы размещаете пользователей, для которых требуется вызвать многофакторную проверку подлинности Microsoft Entra. Для этой группы будет необходимо найти идентификатор безопасности (SID). Чтобы найти SID группы, используйте следующую команду и измените GroupName на имя вашей группы:

Get-ADGroup GroupName

Настройка правил утверждений для вызова многофакторной проверки подлинности Microsoft Entra

Следующие командлеты Microsoft Graph PowerShell вызывают многофакторную проверку подлинности Microsoft Entra для пользователей в группе, если они не в корпоративной сети. Замените "YourGroupSid" идентификатор безопасности, найденный, выполнив предыдущий командлет.

Обязательно ознакомьтесь со статьей Как выбрать поставщиков дополнительной проверки подлинности в версии 2019.

Задание глобального правила утверждений

Запустите следующую команду и замените RPTrustName на имя правила утверждения отношений доверия с проверяющей стороной:

(Get-AdfsRelyingPartyTrust -Name "RPTrustName").AdditionalAuthenticationRules

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

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

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

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == 
"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"https://schemas.microsoft.com/claims/multipleauthn" );
 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Задание правила утверждения для каждого приложения

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

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == 
"https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = 
"https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = 
"https://schemas.microsoft.com/claims/multipleauthn" );
c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == 
"YourGroupSID"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders", 
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", 
Value=="YourGroupSid"]) => issue(Type = 
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value = 
"AzureMfaServerAuthentication");'

Настройка многофакторной проверки подлинности Microsoft Entra в качестве поставщика проверки подлинности в AD FS

Чтобы настроить многофакторную проверку подлинности Microsoft Entra для AD FS, необходимо настроить каждый сервер AD FS. Если несколько серверов AD FS находятся в ферме, их можно настроить удаленно с помощью Microsoft Graph PowerShell.

Пошаговое руководство по выполнению этого процесса см. в статье Настройка параметров северов AD FS.

После настройки серверов можно добавить многофакторную проверку подлинности Microsoft Entra в качестве дополнительного метода проверки подлинности.

Подготовка поэтапного развертывания

Теперь все готово для включения поэтапного развертывания. Поэтапное развертывание помогает итеративно перемещать пользователей в PHS или PTA, а также переносить локальные параметры MFA.

• Обязательно ознакомьтесь с поддерживаемыми сценариями.
• Прежде всего, вам нужно выполнить предварительную работу для PHS или PTA. Мы рекомендуем PHS.
• Затем вам нужно выполнить предварительную работу для простого единого входа.
• Включите поэтапное развертывание облачной проверки подлинности для выбранного способа проверки подлинности.
• Добавьте группы, созданные для поэтапного развертывания. Помните, что вы добавите пользователей в группы итеративно, и что они не могут быть вложенными или динамическими группами членства.

Регистрация пользователей для многофакторной проверки подлинности Microsoft Entra

В этом разделе описывается, как пользователи могут зарегистрировать использование объединенной безопасности (MFA и самостоятельный сброса пароля) и как выполнить миграцию параметров MFA. Microsoft Authenticator можно использовать в режиме без пароля. Его также можно использовать для прохождения второго этапа многофакторной проверки подлинности с любым методом регистрации.

Реестр для регистрации, обеспечивающей объединенную безопасность (рекомендуется)

Рекомендуется обеспечить наличие собственного реестра пользователей для регистрации объединенных сведений о безопасности, который является единым местом для регистрации способов проверки подлинности и устройств как для MFA, так и для самостоятельного сброса пароля (SSPR).

Чтобы помочь своим пользователям в прохождении объединенного процесса регистрации, вы можете предоставить им шаблоны для обмена данными, разработанные корпорацией Майкрософт. К ним относятся шаблоны для электронной почты, плакаты, настольные подставки и другие ресурсы. Пользователи регистрируют свои данные по адресу https://aka.ms/mysecurityinfo, который переносит их на экран объединенной регистрации сведений о безопасности.

Рекомендуем вам защитить регистрационный процесс безопасности с помощью Условного доступа, который требует регистрации с доверенного устройства или из доверенного расположения. Сведения об отслеживании состояния регистрации см. в разделе "Действие метода проверки подлинности" для идентификатора Microsoft Entra.

Перенос параметров MFA с сервера MFA

С помощью служебной программы миграции сервера MFA можно синхронизировать зарегистрированные параметры MFA для пользователей с сервера MFA с идентификатором Microsoft Entra. Вы можете синхронизировать номера телефонов, аппаратные токены и регистрации устройств, такие как параметры приложения Microsoft Authenticator.

Добавление пользователей в соответствующие группы

• Если вы создали новые политики условного доступа, добавьте соответствующих пользователей в эти группы.
• Если вы создали локальные группы безопасности для правил утверждений, добавьте в эти группы соответствующих пользователей.
• Только после добавления пользователей в соответствующие правила условного доступа добавьте пользователей в группу, созданную для поэтапного развертывания. После завершения они начнут использовать выбранный вами метод проверки подлинности Azure (PHS или PTA) и многофакторную проверку подлинности Microsoft Entra, когда они требуются для выполнения многофакторной проверки подлинности.

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

Наблюдение

Многие книги Azure Monitor и отчеты об использовании и аналитике доступны для мониторинга развертывания. Эти отчеты можно найти в идентификаторе Microsoft Entra в области навигации в разделе "Мониторинг".

Мониторинг поэтапного развертывания

В разделе книги выберите Общедоступные шаблоны. В разделе Гибридная проверка подлинности выберите книгуГруппы, пользователи и входы в систему в поэтапном развертывании.

Эта книга может использоваться для мониторинга следующих действий:

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

Мониторинг регистрации многофакторной проверки подлинности Microsoft Entra

Регистрация многофакторной проверки подлинности Microsoft Entra можно отслеживать с помощью отчета об использовании методов проверки подлинности и аналитических сведений. Этот отчет можно найти в идентификаторе Microsoft Entra. Выберите последовательно Наблюдение, затем Использование и аналитические данные.

В разделе "Использование и аналитические данные" выберите Способы проверки подлинности.

Подробные сведения о регистрации многофакторной проверки подлинности Microsoft Entra можно найти на вкладке "Регистрация". Чтобы просмотреть список зарегистрированных пользователей, щелкните гиперссылку "Пользователи", зарегистрированные для многофакторной проверки подлинности Azure.

Отслеживание работоспособности входа в приложение

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

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

Задачи по очистке

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

Преобразуйте свои домены в управляемую проверку подлинности

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

Восстановление правил утверждений на AD FS и удаление поставщика проверки подлинности сервера MFA

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

Например, удалите следующие разделы из правил:

c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value ==
"**YourGroupSID**"] => issue(Type = "https://schemas.microsoft.com/claims/authnmethodsproviders",
Value = "AzureMfaAuthentication");
not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid",
Value=="YourGroupSid"]) => issue(Type =
"https://schemas.microsoft.com/claims/authnmethodsproviders", Value =
"AzureMfaServerAuthentication");'

Отключение сервера MFA в качестве поставщика проверки подлинности в AD FS

Это изменение гарантирует, что в качестве поставщика проверки подлинности используется только многофакторная проверка подлинности Microsoft Entra.

1. Откройте Консоль управления AD FS.
2. В разделе "Службы" щелкните правой кнопкой мыши методы проверки подлинности и выберите "Изменить многофакторные методы проверки подлинности".
3. Снимите флажок Сервер Многофакторной идентификации Azure.

Вывод сервера MFA из эксплуатации

Чтобы удалить серверы MFA в вашей среде, выполните процедуру вывода вашего корпоративного сервера из эксплуатации.

Рекомендации при выводе сервера MFA из эксплуатации

• Рекомендуется проанализировать журналы сервера MFA, чтобы до удаления сервера убедиться в том, что ни пользователи, ни приложения его не используют.
• Удалите сервер Многофакторной идентификации из панели управления на сервере.
• При необходимости очистите журналы и каталоги данных, которые остались после их резервного копирования.
• Удалите пакет SDK для веб-сервера многофакторной проверки подлинности, если применимо, включая все файлы, оставленные на inetpub\wwwroot\MultiFactorAuthWebServiceSdk и/или каталоги MultiFactorAuth.
• Для версий сервера MFA версии 8.0.x также может потребоваться удалить веб-службу веб-службы приложений телефонного приложения многофакторной проверки подлинности.

Перемещение проверки подлинности приложения в идентификатор Microsoft Entra

При переносе всей проверки подлинности приложения с помощью MFA и проверки подлинности пользователей вы сможете удалить значительную часть локальной инфраструктуры, сократить затраты и риски. Если вы перенесли все проверки подлинности приложения, то можете пропустить этап Подготовка AD FS и упростить миграцию MFA.

Процесс перемещения всех проверок подлинности приложения показан на следующей схеме.

Если вы не можете переместить все приложения до переноса, перед началом процесса переместите как можно больше. Дополнительные сведения о переносе приложений в Azure см. в статье "Ресурсы" для переноса приложений в идентификатор Microsoft Entra.

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

• Миграция с сервера Microsoft MFA на многофакторную проверку подлинности Microsoft Entra (обзор)
• Перенос приложений из Windows Active Directory в идентификатор Microsoft Entra
• Планирование стратегии облачной проверки подлинности