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

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

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

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

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

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

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

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

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

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

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

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

  Внимание

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

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

• Чтобы вызвать многофакторную проверку подлинности 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 ID доверяющей стороны и создать политики условного доступа, поддерживающие аналогичные цели безопасности.

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

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

Подготовка 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" на идентификатор безопасности (SID), который был найден при выполнении предыдущего командлета.

Обязательно ознакомьтесь со статьей Как выбрать поставщиков дополнительной проверки подлинности в версии 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 ID.

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

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

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

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

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

Наблюдение

Многие рабочие книги Azure Monitor и отчёты Usage & insights предоставляют возможность мониторинга вашего развертывания. Эти отчеты можно найти в Microsoft Entra ID области навигации в разделе Monitoring.

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

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

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

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

Мониторинг регистрации многофакторной аутентификации Microsoft Entra

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

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

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

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

Мониторьте приложения, которые вы перенесли в Microsoft Entra ID, используя книгу работоспособности авторизации приложения или отчет об активности использования приложения.

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

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

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

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

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

Восстановление правил утверждений на 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 также может потребоваться удалить веб-службу Phone App многофакторной проверки подлинности.

Перенос аутентификации приложений в Microsoft Entra ID

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

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

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

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

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