Переход на многофакторную аутентификацию Microsoft Entra через федерацию

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

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

На следующей схеме показан процесс миграции.

Блок-схема процесса миграции. Области процесса и заголовки в этом документе расположены в том же порядке

Создание групп миграции

Чтобы создать новые политики условного доступа, необходимо назначить эти политики группам. Для этого можно использовать группы безопасности Microsoft Entra или Группы Microsoft 365. Можно также создать или синхронизировать новые объекты.

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

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

Подготовка AD FS

Обновление фермы серверов AD FS до версии 2019, FBL 4

В AD FS 2019 можно указать дополнительные методы проверки подлинности для проверяющей стороны, например приложение. Для определения поставщика проверки подлинности используется членство в группе. Указав дополнительный метод проверки подлинности, вы можете перейти на Microsoft Entra многофакторную проверку подлинности, сохраняя другую проверку подлинности без изменений во время перехода. Дополнительные сведения см. в статье Переход на AD FS в Windows Server 2016 с использованием базы данных WID. В статье рассматривается обновление фермы до AD FS 2019 и обновление уровня поведения фермы (FBL) до версии 4.

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

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

Примечание.

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

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

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

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

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

Get-AdfsAdditionalAuthenticationRule

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

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

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

Примечание.

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

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

Set-AdfsRelyingPartyTrust -TargetName AppA -AccessControlPolicyName $Null

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

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

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

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

Get-ADGroup "GroupName"

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

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

Убедитесь, что вы просмотрите инструкции по выбору дополнительных поставщиков проверки подлинности в 2019 году.

Внимание

Резервное копирование правил претензий

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

Запустите следующий командлет PowerShell:

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

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

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

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

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

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

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

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

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

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

Пошаговые инструкции по этому процессу см. в разделе Настройка серверов AD FS в статье Настройка многофакторной аутентификации Microsoft Entra в качестве поставщика аутентификации с AD FS.

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

Снимок экрана, показывающий экран

Подготовка Microsoft Entra ID и реализация миграции

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

Задайте значение параметра federatedIdpMfaBehavior на enforceMfaByFederatedIdp

Для федеративных доменов многофакторная аутентификация (MFA) может применяться с помощью Условный доступ Microsoft Entra или локальным поставщиком федерации. Каждый федеративный домен имеет параметр безопасности PowerShell Microsoft Graph с именем federatedIdpMfaBehavior. Вы можете задать значение federatedIdpMfaBehavior как enforceMfaByFederatedIdp, чтобы Microsoft Entra ID принимала MFA, выполняемую федеративным поставщиком удостоверений. Если федеративный поставщик удостоверений не выполнил MFA, Microsoft Entra ID перенаправляет запрос этому поставщику для выполнения MFA. Дополнительные сведения см. в federatedIdpMfaBehavior.

Примечание.

Параметр federatedIdpMfaBehavior — это новая версия свойства SupportsMfa командлета New-MgDomainFederationConfiguration.

Для доменов, которые задают свойство SupportsMfa , эти правила определяют, как федеративныйIdpMfaBehavior и SupportsMfa работают вместе:

  • Переключение между федеративной idpMfaBehavior и SupportsMfa не поддерживается.
  • После установки свойства federatedIdpMfaBehavior Microsoft Entra ID пропускает параметр SupportsMfa.
  • Если свойство federatedIdpMfaBehavior никогда не задано, Microsoft Entra ID будет продолжать учитывать параметр SupportsMfa.
  • Если federatedIdpMfaBehavior или SupportsMfa не заданы, по умолчанию в Microsoft Entra ID будет применяться поведение acceptIfMfaDoneByFederatedIdp.

Состояние federatedIdpMfaBehavior можно проверить, используя Get-MgDomainFederationConfiguration.

Get-MgDomainFederationConfiguration –DomainID contoso.com

Вы также можете проверить состояние флага SupportsMfa, используя команду Get-MgDomainFederationConfiguration:

Get-MgDomainFederationConfiguration –DomainName contoso.com

В следующем примере показано, как настроить федеративныйIdpMfaBehaviorenforceMfaByFederatedIdp с помощью Graph PowerShell.

Запрос

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"
}

Настройте политики условного доступа при необходимости

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

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

После создания политик условного доступа для обеспечения таких же элементов управления, как в AD FS, можно создать резервную копию и удалить настройки правил утверждений на доверяющейся стороне Microsoft Entra ID.

Дополнительные сведения см. на следующих ресурсах:

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

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

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

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

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

Примечание.

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

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

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

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

  • Если вы создали новые политики условного доступа, добавьте соответствующих пользователей в эти группы.

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

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

Наблюдение

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

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

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

Изображение экрана действия методов проверки подлинности с регистрацией пользователей в MFA

Этап очистки

После завершения миграции на многофакторную аутентификацию Microsoft Entra и готовности к выводу из эксплуатации сервера MFA выполните следующие три действия:

  1. Восстановите правила утверждений в AD FS до состояния перед миграцией и удалите поставщика проверки подлинности сервера MFA.

  2. Отключите сервер MFA в качестве поставщика проверки подлинности в AD FS. Это гарантирует, что все пользователи используют многофакторную проверку подлинности Microsoft Entra, так как это будет единственным дополнительным методом проверки подлинности.

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

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

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

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

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

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

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

  1. Откройте консоль управления AD FS.

  2. В разделе "Службы" щелкните правой кнопкой мыши методы проверки подлинности и выберите "Изменить многофакторные методы проверки подлинности".

  3. Снимите флажок рядом с сервером многофакторной аутентификации Azure.

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

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

Возможные соображения при выводе серверов MFA из эксплуатации:

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

  • Удаление сервера многофакторной идентификации с панель управления на сервере

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

  • Удалите пакет SDK для веб-сервера многофакторной проверки подлинности, если это применимо, включая любые файлы, оставшиеся в inetpub\wwwroot\MultiFactorAuthWebServiceSdk и/или каталоги MultiFactorAuth.

  • Для версий сервера MFA до версии 8.0 также может потребоваться удалить веб-службу телефонного приложения для многофакторной аутентификации

Дальнейшие шаги