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

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

  • Статья

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

В этой статье предполагается, что у вас есть гибридная среда, в которой выполняются следующие условия:

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

В зависимости от цели может быть реализовано несколько конечных состояний миграции.


 Цель: ТОЛЬКО вывод из эксплуатации Сервера MFA Цель. Вывод сервера MFA и переход на проверку подлинности Microsoft Entra Цель: вывод из эксплуатации Сервера MFA и AD FS
Поставщик MFA Измените поставщик MFA с сервера MFA на многофакторную проверку подлинности Microsoft Entra. Измените поставщик MFA с сервера MFA на многофакторную проверку подлинности Microsoft Entra. Измените поставщик MFA с сервера MFA на многофакторную проверку подлинности Microsoft Entra.
Проверка подлинности пользователя Продолжайте использовать федерацию для проверки подлинности Microsoft Entra. Перейдите к идентификатору Microsoft Entra с синхронизацией хэша паролей (предпочтительно) или сквозной проверкой подлинности и простым единым входом (SSO). Перейдите к идентификатору Microsoft Entra с синхронизацией хэша паролей (предпочтительно) или сквозной проверкой подлинности и единым входом.
Проверка подлинности приложения Продолжение использования проверки подлинности AD FS для приложений. Продолжение использования проверки подлинности AD FS для приложений. Перед переносом приложений на идентификатор Microsoft Entra перед миграцией на многофакторную проверку подлинности Microsoft Entra.

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

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

Необходимые компоненты

  • Среда AD FS (требуется, если вы не переносите все приложения в Microsoft Entra перед переносом сервера MFA)
    • Примените обновление до AD FS для Windows Server 2019, поведение уровня фермы (FBL) 4. Это позволит выбрать поставщика проверки подлинности на основе членства в группе для более плавного перехода пользователей. Несмотря на возможность миграции на AD FS для Windows Server 2016 FBL 3, такой переход менее удобен для пользователей. Во время миграции пользователям предлагается выбрать поставщика проверки подлинности (сервер MFA или многофакторную проверку подлинности Microsoft Entra) до завершения миграции.
  • Разрешения
    • Роль администратора предприятия в Active Directory для настройки фермы AD FS для многофакторной проверки подлинности Microsoft Entra
    • Роль глобального администратора в идентификаторе Microsoft Entra для настройки идентификатора Microsoft Entra с помощью PowerShell

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

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

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

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

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

Чтобы пользователям было проще отличить только что добавленную учетную запись от старой, связанной с Сервером MFA, имена этих двух учетных записей для мобильного приложения на Сервере MFA должны отличаться. Например, имя учетной записи, отображаемое в поле "Мобильное приложение" на сервере MFA, было изменено на Локальный сервер MFA. Имя учетной записи в приложении Microsoft Authenticator изменится при следующей отправке push-уведомления пользователю.

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

Перенос аппаратных ключей безопасности

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

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

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

Пакет SDK веб-службы сервера MFA можно использовать для экспорта серийного номера для всех токенов OATH, назначенных данному пользователю. Эти сведения можно использовать вместе с начальным файлом для импорта маркеров в идентификатор Microsoft Entra и назначения токена OATH указанному пользователю на основе серийного номера. Во время импорта необходимо связаться с пользователем, чтобы он предоставил данные OTP с устройства для завершения регистрации. См. раздел файла справки GetUserInfo>userSettings>OathTokenSerialNumber в разделе "Сервер Многофакторной проверки подлинности" на сервере MFA.

Другие миграции

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

  • Ваша готовность использовать проверку подлинности Microsoft Entra для пользователей
  • Ваша готовность переместить приложения в идентификатор Microsoft Entra

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

Наши рекомендации:

  • Используйте идентификатор Microsoft Entra для проверки подлинности, так как он обеспечивает более надежную безопасность и управление
  • При возможности переместите приложения в идентификатор Microsoft Entra

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

Проверка подлинности без пароля

В рамках регистрации пользователей для использования Microsoft Authenticator в качестве второго фактора мы рекомендуем включить в процессе регистрации вход с телефона без пароля. Дополнительные сведения, включая другие методы без пароля, такие как ключи безопасности FIDO2 и Windows Hello для бизнеса, см. в разделе "Планирование развертывания без пароля с помощью идентификатора Microsoft Entra".

Самостоятельный сброс пароля в Microsoft Identity Manager

Microsoft Identity Manager (MIM) SSPR может использовать Сервер MFA для отправки одноразовых секретных кодов в SMS в рамках процесса сброса пароля. MIM нельзя настроить для использования многофакторной проверки подлинности Microsoft Entra. Мы рекомендуем оценить перемещение службы SSPR в Microsoft Entra SSPR. Вы можете использовать возможность регистрации пользователей для многофакторной проверки подлинности Microsoft Entra, чтобы использовать объединенный интерфейс регистрации для регистрации в Microsoft Entra SSPR.

Если вы не можете переместить службу SSPR или использовать сервер MFA для вызова запросов MFA для сценариев управления привилегированным доступом (PAM), рекомендуется обновить его до альтернативного варианта MFA стороннего поставщика.

Клиенты RADIUS и многофакторная проверка подлинности Microsoft Entra

Сервер MFA поддерживает RADIUS для вызова MFA для приложений и сетевых устройств, поддерживающих этот протокол. Если вы используете RADIUS с сервером MFA, рекомендуется переместить клиентские приложения в современные протоколы, такие как SAML, OpenID Connect или OAuth в идентификаторе Microsoft Entra. Если приложение не удается обновить, можно развернуть сервер политики сети (NPS) с расширением многофакторной проверки подлинности Microsoft Entra. Расширение сервера политики сети (NPS) выступает в качестве адаптера между приложениями на основе RADIUS и многофакторной проверкой подлинности Microsoft Entra, чтобы обеспечить второй фактор проверки подлинности. Этот "адаптер" позволяет переместить клиенты RADIUS в многофакторную проверку подлинности Microsoft Entra и вывести сервер MFA.

Важные замечания

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

  • Расширение NPS не использует политики условного доступа Microsoft Entra. Если вы продолжаете использовать RADIUS и применять расширение NPS, все запросы проверки подлинности, поступающие в NPS, будут требовать от пользователей пройти MFA.
  • Пользователи должны зарегистрировать многофакторную проверку подлинности Microsoft Entra перед использованием расширения NPS. В противном случае расширение не сможет выполнить аутентификацию пользователя, что может привести к обращениям в службу поддержки.
  • Когда расширение NPS вызывает MFA, запрос MFA отправляется в стандартный метод MFA пользователя.
    • Так как вход выполняется в сторонних (не Майкрософт) приложениях, пользователь часто не будет видеть визуальное оповещение о том, что требуется MFA и что на устройство отправлен запрос.
    • Для выполнения требования многофакторной проверки подлинности пользователь должен иметь доступ к методу проверки подлинности по умолчанию. Он не может выбрать альтернативный метод. Метод проверки подлинности по умолчанию будет использоваться, даже если он отключен в методах проверки подлинности клиента и политиках MFA.
    • Пользователи могут изменить свой стандартный метод MFA на странице "Сведения о безопасности" (aka.ms/mysecurityinfo).
  • Методы MFA, доступные клиентам RADIUS контролируются клиентскими системами, отправляющими запросы на доступ по протоколу RADIUS.
    • Методы MFA, требующие ввода данных пользователем после ввода пароля, можно использовать только с системами, поддерживающими ответы на запросы доступа с помощью RADIUS. Методы ввода могут включать OTP, аппаратные токены OATH или Microsoft Authenticator.
    • В некоторых системах доступные методы MFA могут ограничиваться push-уведомлениями в Microsoft Authenticator и телефонными вызовами.

Примечание.

На доступность методов проверки подлинности влияет алгоритм шифрования паролей, используемый между клиентом RADIUS и системой NPS, а также методы ввода, которые может использовать клиент. Дополнительные сведения см. в разделе Определение методов проверки подлинности, которые смогут использовать пользователи.

К числу наиболее распространенных интеграций клиентов RADIUS относятся такие приложения, как шлюзы удаленного рабочего стола и VPN-серверы. Другие интеграции:

  • Шлюз Citrix
    • Шлюз Citrix поддерживает интеграцию расширений RADIUS и NPS, а также интеграцию SAML.
  • Cisco VPN
    • Cisco VPN поддерживает проверку подлинности RADIUS и SAML для единого входа.
    • Переход от проверки подлинности RADIUS к SAML позволяет интегрировать Cisco VPN без развертывания расширения NPS.
  • Все виртуальные сети

Ресурсы, посвященные развертыванию NPS

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