Перенос сервера MFA
В этом разделе описывается перенос параметров MFA для пользователей Microsoft Entra из локального сервера MFA Azure в многофакторную проверку подлинности Microsoft Entra.
Обзор решения
Служебная программа миграции сервера MFA помогает синхронизировать данные многофакторной проверки подлинности, хранящиеся на локальном сервере Azure MFA непосредственно с многофакторной проверкой подлинности Microsoft Entra. После переноса данных проверки подлинности в идентификатор Microsoft Entra пользователи могут легко выполнять многофакторную проверку подлинности на основе облака, не регистрируя повторно или подтверждая методы проверки подлинности. Администраторы могут использовать служебную программу для миграции сервера MFA для отдельных пользователей или групп пользователей для тестирования и контролируемого развертывания без внесения каких-либо изменений на уровне арендатора.
Видео. Использование служебной программы миграции сервера MFA
Ознакомьтесь с нашим видео, чтобы ознакомиться с общими сведениями о программе миграции сервера MFA и его работе.
Ограничения и требования
Для служебной программы миграции сервера MFA требуется новая сборка решения сервера MFA для установки на основном сервере MFA. Сборка вносит обновления в файл данных сервера MFA и включает новую служебную программу для миграции сервера MFA. Вам не нужно обновлять портал WebSDK или user. Установка обновления не запускает перенос автоматически.
Примечание.
Служебная программа миграции сервера MFA может выполняться на вторичном сервере MFA. Дополнительные сведения проверка запустить дополнительный сервер MFA (необязательно).
Программа миграции сервера MFA копирует данные из файла базы данных в объекты пользователя в идентификаторе Microsoft Entra. Во время миграции пользователи могут быть нацелены на многофакторную проверку подлинности Microsoft Entra для тестирования с помощью поэтапного развертывания. Поэтапный перенос позволяет выполнять тестирование без внесения изменений в параметры федерации домена. После завершения переноса необходимо финализировать этот процесс, внеся изменения в настройки федерации домена.
AD FS под управлением Windows Server 2016 или более поздней версии требуется для предоставления проверки подлинности MFA для любых проверяющих сторон AD FS, не включая идентификатор Microsoft Entra и Office 365.
Просмотрите политики управления доступом AD FS и убедитесь, что ни одна из них не требует выполнения MFA в локальной среде в рамках процесса проверки подлинности.
Поэтапное развертывание может охватывать не более 500 000 пользователей (10 групп, каждая из которых содержит не более 50 000 пользователей).
Руководство по миграции
Перенос сервера 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.
На предыдущих этапах можно удалить пользователей из папок поэтапного развертывания, чтобы удалить их из область многофакторной проверки подлинности Microsoft Entra и перенаправить их обратно на локальный сервер Azure MFA для всех запросов MFA, исходящих из идентификатора Microsoft Entra.
Этап 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 независимо от членства в группах.
В следующих разделах шаги переноса описаны более подробно.
Определение зависимостей сервера многофакторной идентификации Azure
Мы упорно работали над тем, чтобы обеспечить переход на облачное решение многофакторной проверки подлинности Microsoft Entra будет поддерживать и даже повысить уровень безопасности. Существуют три обширные категории, которые следует использовать для группировки зависимостей:
Чтобы помочь в миграции, мы соответствовали широко используемым функциям сервера MFA с функциональным эквивалентом в многофакторной проверке подлинности Microsoft Entra для каждой категории.
Способы MFA
Откройте сервер MFA и щелкните Параметры компании.
| Сервер MFA | Многофакторная проверка подлинности Microsoft Entra |
|---|---|
| Вкладка "Общие" | |
| Раздел "Параметры пользователя по умолчанию" | |
| Телефонный звонок (стандартный) | Действия не требуются |
| Текстовое сообщение (OTP)* | Действия не требуются |
| Мобильное приложение (стандартный) | Действия не требуются |
| Телефонный звонок (ПИН-код)* | Включить голосовую связь (OTP) |
| Текстовое сообщение (OTP+ПИН-код)** | Действия не требуются |
| Мобильное приложение (ПИН-код)* | Включить сопоставление номеров |
| Телефонный звонок, текстовое сообщение, мобильное приложение, язык токенов OATH | Языковые параметры будут автоматически применены к пользователю на основе параметров языкового стандарта в его браузере |
| Раздел "Правила ПИН-кода по умолчанию" | Неприменимо; см. обновленные способы на предыдущем снимке экрана |
| Вкладка "Разрешение имени пользователя" | Неприменимо; Разрешение имени пользователя не требуется для многофакторной проверки подлинности Microsoft Entra |
| Вкладка "Текстовое сообщение" | Неприменимо; Многофакторная проверка подлинности Microsoft Entra использует сообщение по умолчанию для текстовых сообщений |
| Вкладка "Токен OATH" | Неприменимо; Многофакторная проверка подлинности Microsoft Entra использует сообщение по умолчанию для токенов OATH |
| Отчеты | Отчеты о действиях методов проверки подлинности Microsoft Entra |
*Когда ПИН-код используется для обеспечения функции подтверждения присутствия, функциональный эквивалент предоставляется выше. ПИН-коды, которые не криптографически привязаны к устройству, недостаточно защищаются от сценариев, в которых устройство было скомпрометировано. Чтобы защититься от таких сценариев, включая атаки с подменой SIM-карты, настройте для пользователей более безопасные способы в соответствии с рекомендациями по проверке подлинности Майкрософт.
**Функция многофакторной проверки подлинности текста по умолчанию в Microsoft Entra многофакторной проверки подлинности отправляет пользователям код, который они должны ввести в окне входа в рамках проверки подлинности. Требование округления кода обеспечивает функциональность проверки присутствия.
Пользовательский портал
Откройте сервер MFA и щелкните Пользовательский портал.
| Сервер MFA | Многофакторная проверка подлинности Microsoft Entra |
|---|---|
| Вкладка "Параметры" | |
| URL-адрес пользовательского портала | aka.ms/mfasetup |
| Разрешить регистрацию пользователей | См. статью Объединенная регистрация сведений о безопасностиэ |
| — Запросить резервный номер телефона | См. статью Параметры службы MFA. |
| — Запросить сторонний токен OATH | См. статью Параметры службы MFA. |
| Разрешить пользователям инициировать одноразовый обход проверки | См . функции TAP идентификатора записи Майкрософт |
| Разрешить пользователям выбирать способ связи | См. статью Параметры службы MFA. |
| — Телефонный вызов | См. документацию по телефонным вызовам. |
| — Текстовое сообщение | См. статью Параметры службы MFA. |
| — Мобильное приложение | См. статью Параметры службы MFA. |
| — Токен OATH | См. документацию по токену OATH. |
| Разрешить пользователям выбирать язык | Языковые параметры будут автоматически применены к пользователю на основе параметров языкового стандарта в его браузере |
| Разрешить пользователям активировать мобильное приложение | См. статью Параметры службы MFA. |
| — Ограничение устройства | Идентификатор Microsoft Entra id ограничивает пользователей пятью накопительными устройствами (экземпляры мобильных приложений + аппаратный токен OATH + маркер software OATH) для каждого пользователя |
| Использовать секретные вопросы для резервного входа | Идентификатор Microsoft Entra позволяет пользователям выбирать резервный метод во время проверки подлинности, если выбранный метод проверки подлинности завершается ошибкой. |
| — Ответы на вопросы | Вопросы безопасности в идентификаторе Microsoft Entra можно использовать только для SSPR. Дополнительные сведения о пользовательских вопросых безопасности Microsoft Entra |
| Разрешить пользователям привязывать OATH-токены сторонних производителей | См. документацию по токену OATH. |
| Использовать OATH-токен для резервного входа | См. документацию по токену OATH. |
| Время ожидания сеанса | |
| Вкладка "Вопросы безопасности" | Контрольные вопросы на сервере MFA использовались для получения доступа к пользовательскому порталу. Многофакторная проверка подлинности Microsoft Entra поддерживает только вопросы безопасности для самостоятельного сброса пароля. См. документацию по контрольным вопросам. |
| Вкладка "Переданные сеансы" | Все потоки регистрации методов проверки подлинности управляются идентификатором Microsoft Entra и не требуют конфигурации |
| Надежные IP-адреса | Доверенные IP-адреса идентификатора Microsoft Entra |
Все методы MFA, доступные на сервере MFA, должны быть включены в многофакторной проверке подлинности Microsoft Entra с помощью параметров службы MFA. Пользователи не смогут опробовать свои недавно перенесенные способы MFA, если они не включены.
Службы аутентификации
Сервер Azure MFA может предоставлять функции MFA для сторонних решений, использующих RADIUS или LDAP, выступая в качестве прокси-сервера проверки подлинности. Чтобы обнаружить зависимости RADIUS или LDAP, щелкните Проверка подлинности RADIUS и Проверка подлинности LDAP на сервере MFA. Для каждой из этих зависимостей определите, поддерживают ли эти третьи стороны современные способы проверки подлинности. В этом случае рассмотрим федерацию непосредственно с идентификатором Microsoft Entra.
Для развертываний RADIUS, которые не могут быть обновлены, необходимо развернуть сервер NPS и установить расширение NPS для многофакторной проверки подлинности Microsoft Entra.
Для развертываний LDAP, которые не могут быть обновлены или перемещены в RADIUS, определите, можно ли использовать доменные службы Microsoft Entra. В большинстве случаев LDAP развертывается для поддержки оперативного изменения пароля для пользователей. После миграции конечные пользователи могут управлять своими паролями с помощью самостоятельного сброса пароля в идентификаторе Microsoft Entra.
Если вы включили поставщик проверки подлинности сервера MFA в AD FS 2.0 для любой проверяющей стороны, за исключением доверия проверяющей стороны Office 365, вам потребуется обновить до AD FS 3.0 или федеративные те проверяющие стороны непосредственно до идентификатора Microsoft Entra, если они поддерживают современные методы проверки подлинности. Определите оптимальный план действий для каждой из зависимостей.
Резервное копирование файла данных сервера многофакторной идентификации Azure
Создайте резервную копию файла данных сервера 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 по умолчанию).
Этот скрипт потребует предоставить учетные данные для приложения Администратор istrator в клиенте 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
- Установите для наиболее безопасного метода, если он еще не установлен в идентификаторе Microsoft Entra
Эти параметры обеспечивают гибкость при переносе метода по умолчанию. Кроме того, политика методов проверки подлинности проверка во время миграции. Если перенос метода по умолчанию не разрешен политикой, вместо этого он установлен на самый безопасный метод.
Сопоставление пользователей— позволяет указать другой атрибут локальная служба Active Directory для сопоставления имени участника-пользователя Microsoft Entra вместо значения по умолчанию userPrincipalName:
- Служебная программа миграции пытается напрямую сопоставить имя участника-пользователя перед использованием атрибута локальная служба Active Directory.
- Если совпадение не найдено, он вызывает API Windows, чтобы найти имя участника-пользователя Microsoft Entra и получить идентификатор безопасности, который он использует для поиска списка пользователей сервера MFA.
- Если API Windows не находит пользователя или идентификатор безопасности не найден на сервере MFA, то он будет использовать настроенный атрибут Active Directory для поиска пользователя в локальная служба Active Directory, а затем используйте идентификатор безопасности для поиска списка пользователей сервера MFA.
Автоматическая синхронизация — запускает фоновую службу, которая будет постоянно отслеживать любые изменения метода проверки подлинности для пользователей на локальном сервере MFA и записывать их в идентификатор Microsoft Entra в указанный интервал времени.
Сервер синхронизации— позволяет службе синхронизации миграции сервера MFA запускаться на вторичном сервере MFA, а не только на основном сервере. Чтобы настроить службу синхронизации миграции для запуска на дополнительном сервере, скрипт должен быть запущен на сервере,
Configure-MultiFactorAuthMigrationUtility.ps1чтобы зарегистрировать сертификат с регистрацией приложения программы миграции сервера MFA. Сертификат используется для проверки подлинности в Microsoft Graph.
Процесс миграции может быть автоматическим или ручным.
Шаги процесса, выполняемого вручную:
Чтобы начать перенос для пользователя или выбрать несколько пользователей, нажмите и удерживайте клавишу CTRL, выбирая каждого из пользователей, которых вы хотите перенести.
Указав нужных пользователей, выберите Перенести пользователей>Выбранные пользователи>ОК.
Чтобы перенести всех пользователей в группу, нажмите кнопку "Перенести>всех пользователей" в группе>Microsoft Entra OK.
Вы можете перенести пользователей, даже если они не изменились. По умолчанию программа имеет значение "Перенос только пользователей, которые изменились". Нажмите кнопку "Миграция всех пользователей", чтобы повторно перенести ранее перенесенных пользователей , которые не изменились. Миграция без изменений пользователей может оказаться полезной во время тестирования, если администратору нужно сбросить параметры Azure MFA и повторно перенести их.
Для автоматического процесса щелкните "Автоматическая синхронизация" в Параметры, а затем выберите, нужно ли синхронизировать всех пользователей или только членов определенной группы Microsoft Entra.
В следующей таблице приведена логика синхронизации для разных способов.
| Способ | Логика |
|---|---|
| Для телефонов | Если расширения нет, обновите номер телефона для MFA. Если расширение есть, обновите рабочий номер телефона. Исключение: если способом по умолчанию является текстовое сообщение, удалите расширение и обновите номер телефона для MFA. |
| Резервное копирование Телефон | Если расширения нет, обновите альтернативный номер телефона. Если расширение есть, обновите рабочий номер телефона. Исключение: если для номера телефона и резервного номера телефона есть расширение, пропустите резервный номер телефона. |
| Мобильное приложение | Будет перенесено максимум пять устройств или только четыре, если у пользователя также есть аппаратный токен OATH. При наличии нескольких устройств с одинаковым именем переносится только последнее. Устройства будут упорядочены от самых новых до самых старых. Если устройства уже существуют в идентификаторе Microsoft Entra, сопоставляйте с секретным ключом токена OATH и обновлением. — Если совпадений с секретным ключом токена OATH нет, сопоставьте маркер устройства. — Если найдено, создайте программный токен OATH для устройства сервера MFA, чтобы разрешить работу способа с использованием токена OATH. Уведомления по-прежнему будут работать с помощью существующего устройства многофакторной проверки подлинности Microsoft Entra. — Если не найдено, создайте новое устройство. Если добавление нового устройства превысит ограничение в пять устройств, такое устройство будет пропущено. |
| Токен OATH | Если устройства уже существуют в идентификаторе Microsoft Entra, сопоставляйте с секретным ключом токена 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 Default, AAD Телефон, AAD Alternate, AAD Office, AAD Devices и AAD OATH Token. При скрытии столбцов некоторые вызовы API Microsoft Graph пропускаются, что значительно повышает время загрузки пользователей.
Просмотр сведений о миграции
Журналы аудита или Log Analytics можно использовать для просмотра сведений о миграции сервера MFA в Azure MFA.
Использование журналов аудита
Чтобы получить доступ к журналам аудита в Центре администрирования Microsoft Entra, чтобы просмотреть сведения о миграции сервера MFA в Azure MFA, выполните следующие действия.
Войдите в Центр администрирования Microsoft Entra как минимум Администратор istrator проверки подлинности.
Перейдите к журналам мониторинга удостоверений и аудита работоспособности>>. Чтобы отфильтровать журналы, нажмите кнопку "Добавить фильтры".
Выберите "Инициировано" (субъект) и нажмите кнопку "Применить".
Введите azure MFA Management и нажмите кнопку "Применить".
Этот фильтр отображает только журналы служебной программы миграции сервера MFA. Чтобы просмотреть сведения о миграции пользователя, щелкните строку и перейдите на вкладку "Измененные свойства ". На этой вкладке показаны изменения зарегистрированных методов MFA и номеров телефонов.
В следующей таблице перечислены метод проверки подлинности для каждого кода.
Код Способ 0 Голосовая связь 2 Голосовой офис 3 Альтернативный голос для мобильных устройств 5 SMS 6 Приложение Microsoft Authenticator — push-уведомление 7 Аппаратный или программный токен OTP Если были перенесены какие-либо пользовательские устройства, существует отдельная запись журнала.
Использование Log Analytics
Сведения о миграции сервера MFA в Azure MFA также можно запрашивать с помощью Log Analytics.
AuditLogs
| where ActivityDateTime > ago(7d)
| extend InitiatedBy = tostring(InitiatedBy["app"]["displayName"])
| where InitiatedBy == "Azure MFA 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 == "Azure MFA Management"
| extend UserObjectId = tostring(TargetResources[0]["id"])
| summarize UsersMigrated = dcount(UserObjectId) by InitiatedBy, bin(ActivityDateTime, 1d)
Проверка и тестирование
После успешного переноса пользовательских данных вы можете проверить взаимодействие с пользователем с помощью поэтапного развертывания, прежде чем вносить глобальное изменение арендатора. В следующем процессе вы сможете нацелиться на определенные группы Microsoft Entra для поэтапного развертывания для MFA. Поэтапное развертывание сообщает идентификатору Microsoft Entra для выполнения MFA с помощью многофакторной проверки подлинности Microsoft Entra для пользователей в целевых группах, а не отправляет их локально для выполнения многофакторной проверки подлинности. Вы можете проверить и проверить— мы рекомендуем использовать Центр администрирования Microsoft Entra, но если вы предпочитаете, вы также можете использовать Microsoft Graph.
Включение поэтапного развертывания
Перейдите по следующему URL-адресу: Включение функций поэтапного развертывания — Microsoft Azure.
Измените многофакторную проверку подлинности Azure на "Вкл." и нажмите кнопку "Управление группами".
Щелкните Добавить группы и добавьте группы, содержащие пользователей, которые вы хотите включить для Azure MFA. Выбранные группы появятся в отображаемом списке.
Примечание.
Любые группы, которые вы настроите с помощью описанного ниже способа с использованием Microsoft Graph, также появятся в этом списке.
Включение поэтапного развертывания с помощью Microsoft Graph
Создание featureRolloutPolicy
Перейдите по адресу aka.ms/ge и войдите в Graph Explorer, используя учетную запись администратора гибридной идентификации в арендаторе, который вы хотите настроить для поэтапного развертывания.
Убедитесь, для следующей конечной точки используется POST:
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies.Текст запроса должен иметь следующее содержимое (измените параметр Политика развертывания MFA на имя и описание для своей организации):
{ "displayName": "MFA rollout policy", "description": "MFA rollout policy", "feature": "multiFactorAuthentication", "isEnabled": true, "isAppliedToOrganization": false }
Выполните запрос GET с той же конечной точкой и запишите значение идентификатора (зачеркнуто на следующем изображении):
Нацеливать группы Microsoft Entra, содержащие пользователей, которые вы хотите протестировать
Создайте запрос POST со следующей конечной точкой (измените {ID of policy} на значение идентификатора, скопированное на шаге 1d):
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{ID of policy}/appliesTo/$refТекст запроса должен содержать следующий текст (измените {ID of group} на идентификатор объекта группы, для которой вы хотите выполнить настройку для поэтапного развертывания):
{ "@odata.id": "https://graph.microsoft.com/v1.0/directoryObjects/{ID of group}" }Повторите шаги a и b для любых других групп, для которых вы хотите выполнить настройку для поэтапного развертывания.
Текущую политику можно просмотреть, выполнив запрос GET по следующему URL-адресу:
https://graph.microsoft.com/v1.0/policies/featureRolloutPolicies/{policyID}?$expand=appliesToВ предыдущем процессе используется ресурс featureRolloutPolicy. Общедоступная документация еще не была обновлена с использованием новой функции multifactorAuthentication, но она содержит подробную информацию о том, как взаимодействовать с API.
Подтвердите, что пользователь использует MFA. Вот несколько моментов, которые следует проверить.
- Видят ли пользователи свои способы по адресу aka.ms/mfasetup?
- Приходят ли пользователям телефонные вызовы или текстовые сообщения?
- Могут ли они успешно пройти проверку подлинности с помощью описанных выше способов?
- Успешно ли пользователи получают уведомления Authenticator? Могут ли они утвердить эти уведомления? Успешно ли выполняется проверка подлинности?
- Могут ли пользователи успешно выполнить проверку подлинности с помощью аппаратных токенов OATH?
Обучение пользователей
Убедитесь, что пользователи знают, чего ожидать при перемещении в Azure MFA, включая новые потоки проверки подлинности. Вы также можете указать пользователям использовать объединенный портал регистрации идентификатора Microsoft Entra ID (aka.ms/mfasetup) для управления методами проверки подлинности, а не на пользовательском портале после завершения миграции. Любые изменения, внесенные в методы проверки подлинности в идентификаторе Microsoft Entra, не будут распространяться обратно в локальную среду. В ситуации, когда вам пришлось откатить сервер MFA, все изменения, внесенные пользователей в идентификаторе Microsoft Entra, не будут доступны на портале пользователя сервера MFA.
Если вы используете сторонние решения, зависящие от сервера Azure MFA для проверки подлинности (см . службы проверки подлинности), пользователи будут продолжать вносить изменения в методы MFA на портале пользователя. Эти изменения будут синхронизированы с идентификатором Microsoft Entra ID автоматически. После переноса этих сторонних решений вы можете переместить пользователей на страницу объединенной регистрации идентификатора Microsoft Entra.
Завершение переноса пользователей
Повторите шаги переноса, описанные в разделах Перенос пользовательских данных и Проверка и тестирование, пока не будут перенесены все пользовательские данные.
Перенос зависимостей сервера MFA
Используя точки данных, собранные в службах проверки подлинности, начните выполнять необходимые процессы переноса. После этого рассмотрите возможность настройки того, чтобы пользователи управляли своими способами проверки подлинности на комбинированном портале регистрации, а не на пользовательском портале на сервере MFA.
Обновление параметров федерации домена
После завершения миграции пользователей и перемещении всех служб проверки подлинности из сервера MFA пришло время обновить параметры федерации домена. После обновления Microsoft Entra больше не отправляет запрос MFA на локальный сервер федерации.
Чтобы настроить идентификатор Microsoft Entra, чтобы игнорировать запросы MFA на локальный сервер федерации, установите пакет SDK PowerShell Microsoft Graph и установите для федеративного ИдентификатораIdpMfaBehavior значение rejectMfaByFederatedIdp, как показано в следующем примере.
Запросить
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc
Content-Type: application/json
{
"federatedIdpMfaBehavior": "rejectMfaByFederatedIdp"
}
Response
Примечание: Объект ответа, показанный здесь, может быть сокращен для удобства.
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
Если сервер Azure MFA вам больше не нужен, следуйте обычным рекомендациям по отмене поддержки сервера. Никаких специальных действий в идентификаторе Microsoft Entra не требуется, чтобы указать прекращение использования сервера MFA.
План отката
Если при обновлении возникли проблемы, выполните следующие действия, чтобы выполнить откат:
Удалите сервер MFA 8.1.
Измените PhoneFactor.pfdata на резервную копию, созданную перед обновлением.
Примечание.
Все изменения, внесенные с момента создания резервной копии будут потеряны, но они должны быть минимальными, если резервная копия была создана непосредственно перед обновлением, а обновление не удалось.
Запустите установщик для предыдущей версии (например, 8.0.x.x.x).
Настройте идентификатор Microsoft Entra, чтобы принять запросы MFA на локальный сервер федерации. Используйте Graph PowerShell, чтобы задать для federatedIdpMfaBehavior значение
enforceMfaByFederatedIdp, как показано в следующем примере.Запросить
PATCH https://graph.microsoft.com/beta/domains/contoso.com/federationConfiguration/6601d14b-d113-8f64-fda2-9b5ddda18ecc Content-Type: application/json { "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp" }Следующий объект ответа сокращен для удобочитаемости.
Response
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" }
Установите для параметра Поэтапное развертывание для Azure MFA значение Выкл. Пользователи снова будут перенаправляться на локальный сервер федерации для MFA.
Следующие шаги
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по