Проверка подлинности и условный доступ для Внешних удостоверений

Когда внешний пользователь обращается к ресурсам в организации, поток проверки подлинности определяется методом совместной работы (совместная работа B2B или прямое соединение B2B), поставщиком удостоверений пользователя (внешний клиент Azure AD, поставщик удостоверений социальных сетей и т. д.), политиками условного доступа и параметрами доступа между клиентами, настроенными как в домашнем клиенте пользователя, так и в ресурсах размещения клиента.

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

Поток проверки подлинности для внешних пользователей Azure AD

На следующей схеме показан поток проверки подлинности, в рамках которого организация Azure AD использует ресурсы совместно с пользователями из других организаций Azure AD. На этой схеме показано, как параметры доступа между арендаторами работают с политиками условного доступа, такими как многофакторная проверка подлинности (MFA), чтобы определить, может ли пользователь получить доступ к ресурсам. Этот поток применяется как к совместной работе B2B, так и к прямому соединению B2B, за исключением случаев, указанных на шаге 6.

Diagram illustrating the cross-tenant authentication process

Шаг Описание
1 Пользователь из Fabrikam (домашний арендатор пользователя) инициирует вход в ресурс в Contoso (арендатор ресурсов).
2 Во время входа служба токенов безопасности (STS) Azure AD оценивает политики условного доступа Contoso. Кроме того, служба проверяет, разрешен ли доступ пользователю Fabrikam, оценивая параметры доступа между арендаторами (параметры исходящего трафика Fabrikam и входящего трафика Contoso).
3 Azure AD проверяет параметры доверия для входящего трафика Contoso, чтобы убедиться, что Contoso доверяет MFA и утверждениям устройства (соответствие устройств, состояние гибридного присоединения к Azure AD) от Fabrikam. Если это не так, перейдите к шагу 6.
4 Если Contoso доверяет MFA и утверждениям устройств от Fabrikam, Azure AD проверяет учетные данные пользователя на предмет того, прошел ли пользователь MFA. Если Contoso доверяет сведениям об устройстве Fabrikam, Azure AD использует идентификатор устройства для поиска объекта устройства в Fabrikam, чтобы определить его состояние (соответствие требованиям или гибридное присоединение к Azure AD).
5 Если MFA требуется, но не выполняется или если идентификатор устройства не указан, Azure AD выдает ошибки MFA и устройства в домашнем арендаторе пользователя по мере необходимости. Если в Fabrikam удовлетворены требования к MFA и устройствам, пользователю предоставляется доступ к ресурсу в Contoso. Если проверки пройти не удается, доступ блокируется.
6 Если параметры доверия не настроены и требуется MFA, пользователям Совместной работы B2B предлагается пройти MFA для арендатора ресурса. Доступ для пользователей с прямым соединением B2B блокируется. Если соответствие устройства требуется, но его не удается оценить, доступ блокируется для как для пользователей совместной работы B2B, так и для пользователей с прямым соединением B2B.

Дополнительные сведения см. в разделе Условный доступ для внешних пользователей.

Поток проверки подлинности для внешних пользователей, не использующих Azure AD

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

Пример 1. Поток проверки подлинности и токен для внешнего пользователя, не использующего Azure AD

На следующей схеме показан поток проверки подлинности при входе внешнего пользователя с учетной записью от поставщика удостоверений, не относящегося к Azure AD, например Google, Facebook или федеративного поставщика удостоверений SAML/WS-Fed.

image shows Authentication flow for B2B guest users from an external directory

Шаг Описание
1 Гостевой пользователь B2B запрашивает доступ к ресурсу. Ресурс перенаправляет пользователя к клиенту ресурса (доверенному IdP).
2 Клиент ресурса определяет пользователя как внешнего и перенаправляет его к IdP гостевого пользователя B2B. Пользователь выполняет первичную проверку подлинности в IdP.
3 Политики авторизации оцениваются в IdP гостевых пользователей B2B. Если пользователь соответствует этим политикам, IdP гостевого пользователя B2B выдает токен пользователю. С помощью токена пользователь перенаправляется обратно в клиент ресурса. Арендатор ресурса проверяет токен, а затем оценивает пользователя на предмет соответствия политикам условного доступа. Например, арендатор ресурса может потребовать от пользователя выполнить MFA Azure Active Directory (AD).
4 Оцениваются параметры входящего доступа между арендаторами и политики условного доступа. Если все политики условного доступа удовлетворены, арендатор ресурса выдает соответствующий токен и перенаправляет пользователя к его ресурсу.

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

На следующей схеме показан поток, при котором включена проверка подлинности по одноразовому секретному коду, а внешний пользователь не проходит проверку подлинности с помощью других средств, например Azure AD, учетной записи Майкрософт (MSA) или поставщика удостоверений социальных сетей.

image shows Authentication flow for B2B guest users with one time passcode

Шаг Описание
1 Пользователь запрашивает доступ к ресурсу в другом клиенте. Ресурс перенаправляет пользователя к клиенту ресурса (доверенному IdP).
2 Клиент ресурса идентифицирует пользователя в качестве внешнего пользователя с одноразовым секретным кодом и отправляет пользователю сообщение электронной почты с одноразовым секретным кодом.
3 Пользователь получает одноразовый секретный код и передает его. Арендатор ресурса оценивает пользователя на предмет соответствия с политикам условного доступа.
4 Если все политики условного доступа удовлетворены, арендатор ресурса выдает токен и перенаправляет пользователя к его ресурсу.

Условный доступ для внешних пользователей

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

Параметры доверия между арендаторами в Azure AD для MFA и утверждений устройств

В сценарии доступа между арендаторами Azure AD организация, содержащая ресурсы, может создавать политики условного доступа, требующие MFA или соответствия устройств для всех гостевых и внешних пользователей. Обычно внешнему пользователю, который обращается к ресурсу, следует настроить Azure AD MFA с арендатором ресурса. Но теперь Azure AD предоставляет возможность доверять MFA, утверждениям соответствующих устройств и утверждениям устройств с гибридным присоединением к Azure AD из внешних организаций Azure AD, упрощая процесс входа для внешнего пользователя. Для арендатора ресурса можно использовать параметры доступа между арендаторами, позволяющие доверять MFA и утверждениям устройств из внешних арендаторов Azure AD. Параметры доверия могут применяться ко всем организациям Azure AD или только к определенным организациям Azure AD.

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

Дополнительные сведения см. в статье Настройка параметров доступа между арендаторами для Совместной работы B2B. Если параметры доверия не настроены, последовательность аналогична потоку MFA для внешних пользователей, не использующих Azure AD.

MFA для внешних пользователей, не использующих Azure AD

Для внешних пользователей, не использующих Azure AD, за MFA всегда отвечает арендатор ресурсов. Ниже приведен пример типичного потока MFA. Этот сценарий работает для любого удостоверения, включая учетную запись Майкрософт (MSA) или идентификатор социальных сетей. Кроме того, этот поток применяется для внешних пользователей Azure AD, если вы не настроили параметры доверия в своей домашней организации Azure AD.

  1. Администратор или информационный работник компании Fabrikam приглашает пользователя из другой компании Contoso для использования приложения Fabrikam.

  2. В приложении Fabrikam настроено требование использовать при доступе Azure AD MFA.

  3. Когда пользователь Совместной работы B2B компании Contoso пытается получить доступ к приложению Fabrikam, ему предлагается пройти Azure AD MFA.

  4. После этого гостевой пользователь может настроить Azure AD MFA в Fabrikam и выбрать ее параметры.

Компания Fabrikam должна иметь достаточное количество лицензий Azure AD Premium с поддержкой Azure AD MFA. Затем пользователь из компании Contoso использует эту лицензию из Fabrikam. Сведения о лицензировании B2B см. в статье Модель выставления счетов для внешних удостоверений Azure.

Примечание

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

Сброс Azure AD MFA (подтверждение) для пользователей Совместной работы B2B

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

  1. Подключение к Azure AD:

    $cred = Get-Credential
    Connect-MsolService -Credential $cred
    
  2. Получение сведений о методах подтверждения для всех пользователей:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    

    Например:

    Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}
    
  3. Сброс метода Azure AD MFA для определенного пользователя, после которого пользователь должен заново задать методы проверки, например:

    Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
    

Условный доступ на основе информации об устройстве

Условный доступ предусматривает возможность требовать, чтобы устройство пользователя соответствовало требованиям или имело гибридное присоединение к Azure AD. Так как устройствами может управлять только домашний арендатор, для внешних пользователей следует учесть дополнительные факторы. Для арендатора ресурса вы можете использовать параметры доступа между арендаторами, позволяющие доверять утверждениям устройств (соответствующих требованиям устройств и устройств с гибридным присоединением к Azure AD).

Важно!

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

Политики управления мобильными приложениями

Для таких элементов управления предоставлением прав условного доступа, как требование доступа из утвержденных клиентских приложений и требование применения политик защиты приложений, требуется, чтобы устройство было зарегистрировано в арендаторе ресурса. Эти элементы управления можно применять только к устройствам iOS и Android. Но ни один из этих элементов управления нельзя применить к гостевым пользователям B2B, так как устройством пользователя может управлять только его домашний арендатор.

Примечание

Не рекомендуем устанавливать требование политики защиты приложений для внешних пользователей.

Условный доступ на основе расположения

Политика на основе расположения, основанная на диапазонах IP-адресов, может быть применена, если приглашающая организации может создать диапазон доверенных IP-адресов, определяющий партнерские организации.

Политики также можно применять на основе географических расположений.

Условный доступ на основе рисков

Политика рисков при входе применяется, если гостевой пользователь B2B удовлетворяет требования к предоставлению управления. Например, организация может потребовать многофакторную проверку подлинности Azure AD для пользователей со средним или высоким уровнем риска при входе. Однако если пользователь ранее не зарегистрировался для выполнения многофакторной проверки подлинности Azure AD в клиенте ресурса, он будет заблокирован. Это делается для того, чтобы злоумышленники не могли регистрировать свои учетные данные для выполнения многофакторной проверки подлинности Azure AD в случае нарушения безопасности пароля полномочного пользователя.

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

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

Условия клиентских приложений работают для гостевых пользователей B2B так же, как и для любого другого типа пользователей. Например, можно предотвратить использование устаревших протоколов проверки подлинности гостевыми пользователями.

Элементы управления сеансом условного доступа

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

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

Дополнительные сведения см. в следующих статьях о службе совместной работы Azure AD B2B.