Миграция сервера MFA

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

Обзор решения

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

Видео. Использование служебной программы миграции сервера MFA

Ознакомьтесь с нашим видео, чтобы ознакомиться с общими сведениями о программе миграции сервера MFA и его работе.

Ограничения и требования

• Для служебной программы миграции сервера MFA требуется новая сборка решения сервера MFA для установки на основном сервере MFA. Сборка обновляет файл данных сервера MFA и включает новую программу миграции сервера MFA. Вам не нужно обновлять WebSDK или пользовательский портал. Установка обновления автоматически не запускает миграцию.

  Заметка

  Служебная программа миграции сервера MFA может выполняться на вторичном сервере MFA. Для получения дополнительной информации, пожалуйста, см. запуск вторичного сервера MFA (по желанию).

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

• AD FS под управлением Windows Server 2016 или более поздней версии требуется для предоставления многофакторной аутентификации (MFA) для любых доверяющих сторон AD FS, за исключением службы Microsoft Entra ID и Office 365.

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

• Поэтапное развертывание может быть нацелено на не более чем 500 000 пользователей (10 групп, каждая из которых содержит не более 50 000 пользователей).

Руководство по миграции

Фаза	Шаги
Подготовка	Идентификация зависимостей сервера многофакторной проверки подлинности Microsoft Entra
	Резервное копирование файлов данных сервера многофакторной проверки подлинности Microsoft Entra
	Установка обновления сервера MFA
	настройка служебной программы миграци и сервера MFA
Миграции	Перенос данных пользователей
	валидация и тестирование
	Поэтапное Развертывание
	обучать пользователей
	Завершение миграции пользователей
Финализировать	Миграция зависимостей сервера MFA
	Обновление настроек федерации домена
	Отключить портал пользователей на сервере MFA
	Вывод из эксплуатации сервера MFA

Миграция сервера MFA обычно включает шаги в следующем процессе:

Несколько важных моментов:

этап 1 следует повторять по мере того как добавляются тестовые пользователи.

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

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

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

Этап 3 предусматривает, что все клиенты, проходящие аутентификацию на локальном сервере MFA (VPN, менеджеры паролей и т. д.), должны быть перемещены в федерацию Microsoft Entra через SAML/OAUTH. Если современные стандарты аутентификации не поддерживаются, требуется развернуть сервер(ы) NPS с установленным расширением многофакторной аутентификации Microsoft Entra. После переноса зависимостей пользователи больше не должны использовать портал пользователя на сервере MFA, а вместо этого следует управлять методами проверки подлинности в идентификаторе Microsoft Entra (aka.ms/mfasetup). Когда пользователи начинают управлять данными проверки подлинности в идентификаторе Microsoft Entra, эти методы не синхронизируются с сервером MFA. При откате к локальному серверу MFA после того, как пользователи внесли изменения в методы проверки подлинности в идентификаторе Microsoft Entra, эти изменения будут потеряны. После завершения миграции пользователей измените настройку федерации домена federatedIdpMfaBehavior. Это изменение сообщает Идентификатору Microsoft Entra больше не выполнять MFA в локальной среде и выполнять все запросы MFA с многофакторной проверкой подлинности Microsoft Entra независимо от членства в группах.

В следующих разделах подробно описаны этапы миграции.

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

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

• методы MFA
• портал пользователя
• службы проверки подлинности

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

Методы MFA

Откройте сервер MFA, выберите параметры компании:

Сервер MFA	Многофакторная проверка подлинности Microsoft Entra
вкладка "Общие"
Раздел "Пользовательские значения по умолчанию"
Телефонный звонок (стандартный)	Никаких действий не требуется
Текстовое сообщение (OTP)*	Никаких действий не требуется
Мобильное приложение (Стандартный)	Никаких действий не требуется
Телефонный звонок (ПИН-код)*	Включить голосовую OTP
Текстовое сообщение (OTP+ PIN)**	Никаких действий не требуется
* мобильного приложения (ПИН-код)	Включить сопоставление номера с
Телефонный звонок/ текстовое сообщение, мобильное приложение/язык токена OATH	Параметры языка автоматически применяются к пользователю на основе региональных настроек в браузере.
Раздел правил по умолчанию для ПИН-кода	Неприменимо; см. обновленные методы на предыдущем снимке экрана
вкладка "Разрешение имени пользователя "	Неприменимо; Определение имени пользователя не требуется для многофакторной аутентификации Microsoft Entra
вкладка текстового сообщения	Неприменимо; Многофакторная проверка подлинности Microsoft Entra использует сообщение по умолчанию для текстовых сообщений
Вкладка "Токен OATH"	Неприменимо; Многофакторная проверка подлинности Microsoft Entra использует сообщение по умолчанию для токенов OATH
Отчеты	Отчеты о действиях методов проверки подлинности Microsoft Entra

^*Если ПИН-код используется для предоставления функциональных возможностей проверки присутствия, функциональный эквивалент предоставляется выше. ПИН-коды, которые не криптографически привязаны к устройству, недостаточно защищаются от сценариев, в которых устройство было скомпрометировано. Чтобы защититься от этих сценариев, включая атаки на смену SIM-карты, переведите пользователей на более безопасные методы аутентификации согласно передовой практике Microsoft .

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

Пользовательский портал

Откройте сервер MFA, выберите пользовательский портал:

Сервер MFA	Многофакторная проверка подлинности Microsoft Entra
вкладка параметров
URL-адрес пользовательского портала	aka.ms/mfasetup
Разрешить регистрацию пользователей	См. объединенную регистрацию сведений о безопасности
— запрос на резервный телефон	См. параметры службы MFA
— запрос на получение стороннего токена OATH	См. параметры службы MFA
Разрешить пользователям инициировать обход One-Time	См. функциональность TAP идентификатора Microsoft Entra ID
Разрешить пользователям выбирать метод	См. параметры службы MFA
- Телефонный звонок	Документацию телефонных звонков см.
-Эсэмэска	См. параметры службы MFA
— Мобильное приложение	См. параметры службы MFA
— токен OATH	См. документацию по токену OATH
Разрешить пользователям выбирать язык	Языковые настройки автоматически применяются к пользователю на основе настроек локали в его браузере.
Разрешить пользователям активировать мобильное приложение	См. параметры службы MFA
— ограничение устройства	Microsoft Entra ID ограничивает пользователей пятью совокупными устройствами (экземпляры мобильного приложения + аппаратный токен OATH + программный токен OATH) на пользователя.
Использование вопросов безопасности в качестве резервного варианта	Идентификатор Microsoft Entra позволяет пользователям выбирать резервный метод во время проверки подлинности, если выбранный метод проверки подлинности завершается ошибкой.
- Вопросы для ответа	Вопросы безопасности в Microsoft Entra ID можно использовать только для самовосстановления пароля (SSPR). Дополнительные сведения о настраиваемых вопросах безопасности Microsoft Entra
Разрешить пользователям связывать сторонний токен OATH	См. документацию по токену OATH
Использование токена OATH для резервного восстановления	См. документацию по токену OATH в разделе
Истекло время сеанса
вкладка "Вопросы о безопасности"	Вопросы безопасности на сервере MFA использовались для получения доступа к пользовательскому порталу. Многофакторная проверка подлинности Microsoft Entra поддерживает только контрольные вопросы для самостоятельного сброса пароля. См. документацию вопросов безопасности.
вкладка переданных сеансов	Все потоки регистрации методов проверки подлинности управляются идентификатором Microsoft Entra и не требуют конфигурации
Доверенные IP-адреса	Доверенные IP-адреса Microsoft Entra ID

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

Службы проверки подлинности

Сервер многофакторной проверки подлинности Microsoft Entra может предоставлять функции MFA для сторонних решений, использующих RADIUS или LDAP, выступая в качестве прокси-сервера проверки подлинности. Чтобы обнаружить зависимости RADIUS или LDAP, выберите параметры аутентификации RADIUS и аутентификации LDAP на сервере MFA. Для каждой из этих зависимостей определите, поддерживают ли эти сторонние стороны современную проверку подлинности. В этом случае рассмотрим федерацию непосредственно с идентификатором Microsoft Entra.

Для развертываний RADIUS, которые не могут быть обновлены, необходимо развернуть сервер NPS и установить расширение NPS для многофакторной аутентификации Microsoft Entra.

Для развертываний LDAP, которые не могут быть обновлены или перемещены в RADIUS, определить, можно ли использовать доменные службы Microsoft Entra. В большинстве случаев протокол LDAP был развернут для поддержки изменений паролей в строке для конечных пользователей. После миграции пользователи могут управлять своими паролями с помощью самостоятельного сброса пароля в Microsoft Entra ID.

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

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

Создайте резервную копию файла данных сервера MFA, расположенного в %programfiles%\Multi-Factor Authentication Server\Data\PhoneFactor.pfdata (расположение по умолчанию) на основном сервере MFA. Убедитесь, что у вас есть копия установщика для текущей установленной версии на случай, если вам потребуется сделать откат. Если у вас больше нет копии, обратитесь в службу поддержки клиентов.

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

Установка обновления сервера MFA

Запустите новый установщик на основном сервере MFA. Перед обновлением сервера удалите его из балансировки нагрузки или обмена трафиком с другими серверами MFA. Перед запуском установщика не нужно удалять текущий сервер MFA. Установщик выполняет обновление на месте с помощью текущего пути установки (например, C:\Program Files\Multi-Factor Authentication Server). Если вам будет предложено установить распространяемый пакет обновления Microsoft Visual C++ 2015, примите запрос. Устанавливаются версии пакета x86 и x64. Не требуется устанавливать обновления для пользовательского портала, веб-пакета SDK или адаптера AD FS.

Заметка

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

Настройка программы миграции сервера MFA

После установки обновления сервера MFA откройте командную строку PowerShell с повышенными привилегиями: наведите указатель мыши на значок PowerShell, щелкните правой кнопкой мыши и выберите Запустить от имени администратора. Запустите .\Configure-MultiFactorAuthMigrationUtility.ps1 скрипт, найденный в каталоге установки сервера MFA (по умолчанию C:\Program Files\Multi-Factor Authentication Server).

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

Для клиентов облака для государственных организаций, которые хотят выполнить миграцию, замените записи ".com" в скрипте на ".us". Этот скрипт записывает записи реестра HKLM:\SOFTWARE\WOW6432Node\Positive Networks\PhoneFactor\ StsUrl и GraphUrl и указывает программе миграции использовать соответствующие конечные точки GRAPH.

Вам также потребуется доступ к следующим URL-адресам:

• https://graph.microsoft.com/* (или https://graph.microsoft.us/* для клиентов облака для государственных организаций)
• https://login.microsoftonline.com/* (или https://login.microsoftonline.us/* для клиентов облака для государственных организаций)

Скрипт предписывает предоставить администратору согласие только что созданному приложению. Перейдите по URL-адресу или в Центре администрирования Microsoft Entra выберите регистрацию приложений, найдите и выберите приложение Утилита миграции сервера MFA, выберите разрешения API и предоставьте соответствующие разрешения.

После завершения перейдите в папку сервера Многофакторной идентификации и откройте приложение MultiFactorAuthMigrationUtilityUI. Вы увидите следующий экран:

Вы успешно установили утилиту миграции.

Заметка

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

Запуск дополнительного сервера MFA (необязательно)

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

Скрипт Configure-MultiFactorAuthMigrationUtility.ps1 должен выполняться на вторичном сервере, чтобы зарегистрировать сертификат через регистрацию приложения утилиты миграции сервера MFA. Сертификат используется для проверки подлинности в Microsoft Graph. Запуск служб служебной программы миграции и синхронизации на вторичном сервере MFA должен повысить производительность как ручной, так и автоматической миграции пользователей.

Перенос данных пользователя

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

Утилита миграции сервера MFA нацелена на одну группу Microsoft Entra для всех действий по миграции. Вы можете добавить пользователей непосредственно в эту группу или добавить другие группы. Их также можно добавить поэтапно во время миграции.

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

Чтобы просмотреть данные атрибутов для пользователя, выделите пользователя и выберите Просмотреть:

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

Параметр настроек позволяет изменить параметры процесса миграции:

• Миграция — существует три варианта переноса метода проверки подлинности пользователя по умолчанию:

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

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

• Совпадение пользователей — позволяет указать другой локальный атрибут Active Directory для сопоставления UPN Microsoft Entra вместо значения по умолчанию userPrincipalName.

  • Служебная программа миграции пытается напрямую сопоставить имя пользователя перед использованием атрибута локально размещённого Active Directory.
  • Если совпадение не найдено, он вызывает API Windows, чтобы найти UPN Microsoft Entra и получить идентификатор безопасности, который он использует для поиска в списке пользователей сервера MFA.
  • Если API Windows не находит пользователя или идентификатор безопасности не найден на сервере MFA, то он использует настроенный атрибут Active Directory для поиска пользователя в локальной среде Active Directory, а затем используйте идентификатор безопасности для поиска в списке пользователей сервера MFA.

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

• Сервер синхронизации— позволяет службе синхронизации миграции сервера MFA запускаться на вторичном сервере MFA, а не только на основном сервере. Чтобы настроить службу синхронизации миграции для запуска на вторичном сервере, скрипт Configure-MultiFactorAuthMigrationUtility.ps1 необходимо запустить на сервере, чтобы зарегистрировать сертификат с регистрацией приложения утилиты миграции сервера MFA. Сертификат используется для проверки подлинности в Microsoft Graph.

Процесс миграции может быть автоматическим или ручным.

Шаги ручного процесса:

1. Чтобы начать процесс миграции для пользователя или выбора нескольких пользователей, нажмите и удерживайте клавишу CTRL при выборе каждого пользователя, который вы хотите перенести.

2. После выбора нужных пользователей выберите Перенести пользователей>Выбранные пользователи>Подтвердить.

3. Чтобы перенести всех пользователей в группу, выберите Перенести пользователей>всех пользователей в группе Microsoft Entra>OK.

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

   

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

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

Метод	Логика
Телефон	Если расширения нет, обновите телефон MFA. Если есть расширение, обновите телефон Office. Исключение: если по умолчанию используется текстовое сообщение, удаление расширения и обновление телефона MFA.
телефон резервного копирования	Если расширения нет, обновите альтернативный телефон. Если есть расширение, обновите телефон Office. Исключение: если у телефона и резервного телефона есть расширение, пропустите резервный телефон.
мобильное приложение	Не более пяти устройств переносятся или только четыре, если у пользователя также есть аппаратный токен OATH. При наличии нескольких устройств с одинаковым именем переносится только последний. Устройства упорядочены от самых новых до старых. Если устройства уже существуют в Microsoft Entra ID, сопоставьте их с секретным ключом токена OATH и обновите. — Если совпадения с секретным ключом токена OATH нет, то проверяется совпадение с токеном устройства. — При обнаружении создайте программный токен OATH для устройства сервера MFA, чтобы включить использование метода токена OATH. Уведомления по-прежнему работают с помощью существующего устройства многофакторной проверки подлинности Microsoft Entra. - Если не найдено, создайте новое устройство. Если добавление нового устройства превышает ограничение на пять устройств, устройство пропускается.
токен OATH	Если устройства уже существуют в Microsoft Entra ID, совпадают с секретным ключом токена OATH и обновляют. — Если не найдено, добавьте новое устройство аппаратного токена OATH. Если добавление нового устройства превышает лимит в пять устройств, токен OATH не используется.

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

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

После завершения подтверждение сообщает вам о выполненных задачах:

Как упоминалось в сообщении подтверждения, может потребоваться несколько минут, чтобы перенесенные данные отображались на пользовательских объектах в идентификаторе Microsoft Entra. Пользователи могут просматривать перенесенные методы, перейдя к aka.ms/mfasetup.

Совет

Вы можете сократить время, необходимое для отображения групп, если вам не нужно просматривать методы Microsoft Entra MFA. Выберите Режим методов Azure AD MFA, чтобы переключить отображение столбцов AAD по умолчанию, телефон AAD, альтернативныйAAD, AAD Office, устройства AADи токена ГЛАГОВ AAD. При скрытии столбцов некоторые вызовы API Microsoft Graph пропускаются, что значительно повышает время загрузки пользователей.

Просмотр сведений о миграции

Вы можете использовать журналы аудита или Log Analytics для просмотра сведений о миграции пользователей с сервера MFA на многофакторную аутентификацию Microsoft Entra.

Использование журналов аудита

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

1. Войдите в центр администрирования Microsoft Entra как минимум в качестве Администратора проверки подлинности.

2. Перейдите к идентификации>мониторинга & работоспособности>журналам аудита. Чтобы отфильтровать журналы, выберите Добавить фильтры.

   

3. Выберите , инициировано субъектом, и выберите Применить.

   

4. Введите управление многофакторной аутентификацией Microsoft Entra и выберите Применить.

   

5. Этот фильтр отображает только журналы служебной программы миграции сервера MFA. Чтобы просмотреть сведения о миграции пользователя, выберите строку и перейдите на вкладку Измененные свойства. На этой вкладке показаны изменения зарегистрированных методов MFA и номеров телефонов.

   

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

   Код	Метод
   0	Голосовая мобильная связь
   2	Голосовой офис
   3	Альтернативный голос для мобильных устройств
   5	СМС
   6	Push-уведомление Microsoft Authenticator
   7	Аппаратный или программный токен OTP

6. Если были перенесены какие-либо пользовательские устройства, существует отдельная запись журнала.

   

Используйте Log Analytics

Сведения о миграции пользователей сервера многофакторной аутентификации (MFA) на многофакторную аутентификацию Microsoft Entra также можно запрашивать с помощью Log Analytics.

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Microsoft Entra multifactor authentication Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| extend Upn = tostring(TargetResources[0]["userPrincipalName"])
| extend ModifiedProperties = TargetResources[0]["modifiedProperties"]
| project ActivityDateTime, InitiatedBy, UserObjectId, Upn, ModifiedProperties
| order by ActivityDateTime asc

На этом снимке экрана показаны изменения для миграции пользователей.

На этом снимку экрана показаны изменения для миграции устройств:

Log Analytics также можно использовать для суммирование действий миграции пользователей.

AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Microsoft Entra multifactor authentication Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)

Проверка и тестирование

После успешного переноса данных пользователей можно проверить пользовательский опыт с помощью поэтапного развертывания (Staged Rollout) перед изменением глобального арендатора. Этот процесс позволяет целенаправленно использовать конкретные группы Microsoft Entra для поэтапного развертывания MFA. Поэтапное развертывание указывает Microsoft Entra ID выполнять MFA, используя многофакторную аутентификацию Microsoft Entra для пользователей в целевых группах, вместо того чтобы направлять их на локальное выполнение многофакторной аутентификации. Вы можете валидировать и тестировать — мы рекомендуем использовать Центр администрирования Microsoft Entra, но если вы предпочитаете, вы также можете использовать Microsoft Graph.

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

1. Перейдите по следующему URL-адресу: Включить функции поэтапного развертывания — Microsoft Azure.

2. Измените многофакторную проверку подлинности Azure на On, а затем выберите Управление группами.

   

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

   Заметка

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

   

Включение поэтапного развертывания с помощью Microsoft Graph

1. Создание компонентаRolloutPolicy

   1. Перейдите к aka.ms/ge и войдите в Graph Explorer с помощью учетной записи администратора гибридной идентификации в клиенте, который вы хотите настроить для постепенного развертывания.

   2. Убедитесь, что функция POST выбрана для следующей конечной точки: https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies

   3. Текст запроса должен содержать следующее (измените политику развертывания MFA на имя и описание вашей организации):

      {
           "displayName": "MFA rollout policy",
           "description": "MFA rollout policy",
           "feature": "multiFactorAuthentication",
           "isEnabled": true,
           "isAppliedToOrganization": false
      }
      

      

   4. Выполните GET с той же конечной точкой и запишите значение идентификатора (), вычеркнутое на следующем рисунке.

      

2. Нацеливать группы Microsoft Entra, содержащие пользователей, которые вы хотите протестировать

   1. Создайте POST-запрос со следующим конечным пунктом (замените {идентификатор политик} на значение ID , которое вы скопировали на шаге 1d):

      https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$ref

   2. Текст запроса должен содержать следующий текст (замените {ID группы} идентификатором объекта группы, которую вы хотите использовать для поэтапного развертывания):

      {
      "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}"
      }
      

   3. Повторите шаги a и b для любых других групп, которые вы хотите нацелить с помощью поэтапного развертывания.

   4. Текущую политику можно просмотреть, выполнив команду GET по следующему URL-адресу:

      https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesTo

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

3. Убедитесь в том, что опыт использования MFA для конечных пользователей. Ниже приведены некоторые действия, которые необходимо проверить.

   1. Пользователи видят свои методы в aka.ms/mfasetup?
   2. Получают ли пользователи телефонные звонки или текстовые сообщения?
   3. Могут ли они успешно пройти проверку подлинности с помощью приведенных выше методов?
   4. Успешно ли пользователи получают уведомления Authenticator? Могут ли они утвердить эти уведомления? Успешно ли выполнена проверка подлинности?
   5. Могут ли пользователи успешно пройти проверку подлинности с помощью аппаратных токенов OATH?

Обучение пользователей

Убедитесь, что пользователи знают, что ожидать при перемещении в многофакторную проверку подлинности Microsoft Entra, включая новые потоки проверки подлинности. Вы также можете порекомендовать пользователям использовать портал объединенной регистрации Microsoft Entra ID (aka.ms/mfasetup) для управления методами проверки подлинности, а не пользовательский портал после завершения миграции. Любые изменения, внесенные в методы проверки подлинности в идентификаторе Microsoft Entra, не будут распространяться обратно в локальную среду. В ситуации, когда вам пришлось откатиться к серверу MFA, все изменения, внесенные пользователями в Microsoft Entra ID, не будут доступны на портале пользователей сервера MFA.

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

Завершение миграции пользователей

Повторите шаги миграции, описанные в разделах Миграция данных пользователей и Проверка и тестирование до тех пор, пока все пользовательские данные не будут перенесены.

Перенос зависимостей сервера MFA

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

Обновление параметров федерации домена

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

Чтобы настроить службу Microsoft Entra ID так, чтобы она игнорировала запросы MFA к вашему локальному серверу федерации, установите Microsoft Graph PowerShell SDK и задайте federatedIdpMfaBehaviorrejectMfaByFederatedIdp, как показано в следующем примере.

Просьба

PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
  "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

Ответ

Заметка

Объект ответа, показанный здесь, может быть сокращен для удобства чтения.

HTTP/1.1 200 OK
Content-Type: application/json
{
  "@odata.type": "#microsoft.graph.internalDomainFederation",
  "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
   "issuerUri": "http://contoso.com/adfs/services/trust",
   "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
   "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
   "preferredAuthenticationProtocol": "wsFed",
   "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
   "signOutUri": "https://sts.contoso.com/adfs/ls",
   "promptLoginBehavior": "nativeSupport",
   "isSignedAuthenticationRequestRequired": true,
   "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}

Пользователи больше не перенаправляются на локальный сервер федерации для MFA, независимо от того, используют они инструмент поэтапного развертывания или нет. Обратите внимание, что это может занять до 24 часов, чтобы ввести в силу.

Заметка

Обновление параметра федерации домена может занять до 24 часов.

Необязательно. Отключение пользовательского портала сервера MFA

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

• Перенаправление URL-адреса пользовательского портала сервера MFA на aka.ms/mfasetup
• Снимите флажок Разрешить пользователям входить в систему на вкладке "Параметры " в разделе "Портал пользователей" сервера MFA, чтобы предотвратить вход пользователей на портал.

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

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

План отката

Если при обновлении возникли проблемы, выполните следующие действия, чтобы вернуть изменения:

1. Удалите MFA Server 8.1.

2. Замените PhoneFactor.pfdata резервной копией, сделанной до обновления.

   Заметка

   Любые изменения, внесенные после создания резервной копии, будут утеряны, но это должно быть минимально, если резервное копирование было выполнено непосредственно перед обновлением, и обновление оказалось неуспешным.

3. Запустите установщик для предыдущей версии (например, 8.0.x.x.x).

4. Настройте идентификатор Microsoft Entra, чтобы принять запросы MFA на локальный сервер федерации. Используйте Graph PowerShell, чтобы задать федеративный IdpMfaBehavior на enforceMfaByFederatedIdp, как показано в следующем примере.

   запрос

   PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
   Content-Type: application/json
   {
     "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
   }
   

   Следующий объект ответа сокращен для удобства чтения.

   Ответ

   HTTP/1.1 200 OK
   Content-Type: application/json
   {
     "@odata.type": "#microsoft.graph.internalDomainFederation",
     "id": "6601d14b-d113-8f64-fda2-9b5ddda18ecc",
      "issuerUri": "http://contoso.com/adfs/services/trust",
      "metadataExchangeUri": "https://sts.contoso.com/adfs/services/trust/mex",
      "signingCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "passiveSignInUri": "https://sts.contoso.com/adfs/ls",
      "preferredAuthenticationProtocol": "wsFed",
      "activeSignInUri": "https://sts.contoso.com/adfs/services/trust/2005/usernamemixed",
      "signOutUri": "https://sts.contoso.com/adfs/ls",
      "promptLoginBehavior": "nativeSupport",
      "isSignedAuthenticationRequestRequired": true,
      "nextSigningCertificate": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
      "signingCertificateUpdateStatus": {
           "certificateUpdateResult": "Success",
           "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
       },
      "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
   }
   

Установите для поэтапного развертывания многофакторной аутентификации Microsoft Entra состояние Выключено. Пользователи снова перенаправляются на локальный сервер федерации для MFA.

Дальнейшие действия

• Обзор миграции с сервера MFA на многофакторную проверку подлинности Microsoft Entra
• Миграция на облачную проверку подлинности с помощью поэтапного развертывания