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

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

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

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

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

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

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

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

Подготовка службы федерации Active Directory (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, их параметры можно настроить удаленно с помощью Azure AD PowerShell.

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

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

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

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

Задайте для federatedIdpMfaBehavior значение enforceMfaByFederatedIdp

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

Примечание.

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

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

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

Состояние federatedIdpMfaBehavior можно проверить с помощью Get-MgDomainFederationConfiguration.

Get-MgDomainFederationConfiguration –DomainID yourdomain.com

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

Get-MgDomainFederationConfiguration –DomainName yourdomain.com

В следующем примере показано, как задать для federatedIdpMfaBehavior значение enforceMfaByFederatedIdp с помощью Graph PowerShell.

Запросить

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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "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": "MIIE3jCCAsagAwIBAgIQQcyDaZz3MI",
   "signingCertificateUpdateStatus": {
        "certificateUpdateResult": "Success",
        "lastRunDateTime": "2021-08-25T07:44:46.2616778Z"
    },
   "federatedIdpMfaBehavior": "enforceMfaByFederatedIdp"
}

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

Наблюдение

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

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

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

Этап очистки

После завершения миграции на многофакторную проверку подлинности 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 для веб-сервера многофакторной проверки подлинности, включая все файлы, оставленные в etpub\wwwroot\MultiFactorAuthWebServiceSdk и каталоги MultiFactorAuth.

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

Next Steps

• Развертывание синхронизации хэша паролей
• Дополнительные сведения об условном доступе
• Перенос приложений в идентификатор Microsoft Entra