Проверка подлинности и условный доступ для внешнего идентификатора
Совет
Эта статья относится к совместной работе B2B и прямому подключению B2B. Если клиент настроен для управления удостоверениями клиентов и доступом, см. статью "Безопасность и управление" в Внешняя идентификация Microsoft Entra.
Когда внешний пользователь обращается к ресурсам в организации, поток проверки подлинности определяется методом совместной работы (совместная работа B2B или прямой подключением B2B), поставщиком удостоверений пользователя (внешним клиентом Microsoft Entra, поставщиком удостоверений социальных удостоверений и т. д.), политиками условного доступа и параметрами доступа между клиентами, настроенными как в домашнем клиенте пользователя, так и в ресурсах размещения клиента.
В этой статье описан поток проверки подлинности для внешних пользователей, которые обращаются к ресурсам в организации. Организации могут применять несколько политик условного доступа для внешних пользователей. Такие политики можно установить на уровне арендатора, приложения или отдельного пользователя так же, как они применяются для сотрудников с полной занятостью и членов организации.
Поток проверки подлинности для внешних пользователей Microsoft Entra
На следующей схеме показан поток проверки подлинности, когда организация Microsoft Entra предоставляет доступ к ресурсам с пользователями из других организаций Microsoft Entra. На этой схеме показано, как параметры доступа между клиентами работают с политиками условного доступа, такими как многофакторная проверка подлинности, чтобы определить, может ли пользователь получить доступ к ресурсам. Этот поток применяется как к совместной работе B2B, так и к прямому соединению B2B, за исключением случаев, указанных на шаге 6.
| Этап | Описание: |
|---|---|
| 1 | Пользователь из Fabrikam (домашний арендатор пользователя) инициирует вход в ресурс в Contoso (арендатор ресурсов). |
| 2 | Во время входа служба маркеров безопасности Microsoft Entra (STS) оценивает политики условного доступа Contoso. Кроме того, служба проверяет, разрешен ли доступ пользователю Fabrikam, оценивая параметры доступа между арендаторами (параметры исходящего трафика Fabrikam и входящего трафика Contoso). |
| 3 | Идентификатор Microsoft Entra id проверка s параметры входящего доверия Contoso, чтобы узнать, доверяет ли Contoso многофакторную проверку подлинности и утверждения устройств (соответствие устройств, состояние гибридного соединения Microsoft Entra) из Fabrikam. Если это не так, перейдите к шагу 6. |
| 4 | Если Contoso доверяет утвержденияМ MFA и устройств из Fabrikam, идентификатор Microsoft Entra проверка сеанс проверки подлинности пользователя для указания того, что пользователь завершил MFA. Если Contoso доверяет сведения об устройстве из Fabrikam, идентификатор Microsoft Entra ищет утверждение в сеансе проверки подлинности, указывающее состояние устройства (совместимое или гибридное присоединение к Microsoft Entra). |
| 5 | Если MFA требуется, но не завершена или если утверждение устройства не предоставлено, идентификатор Microsoft Entra id выдает проблемы MFA и устройств в домашнем клиенте пользователя по мере необходимости. Если в Fabrikam удовлетворены требования к MFA и устройствам, пользователю предоставляется доступ к ресурсу в Contoso. Если проверки пройти не удается, доступ блокируется. |
| 6 | Если параметры доверия не настроены и MFA не требуются, пользователи службы совместной работы B2B запрашивают MFA. Они должны удовлетворять MFA в клиенте ресурсов. Доступ для пользователей с прямым соединением B2B блокируется. Если соответствие устройства требуется, но его не удается оценить, доступ блокируется для как для пользователей совместной работы B2B, так и для пользователей с прямым соединением B2B. |
Дополнительные сведения см. в разделе Условный доступ для внешних пользователей.
Поток проверки подлинности для внешних пользователей, не использующих Azure AD
Если организация Microsoft Entra предоставляет ресурсы внешним пользователям с поставщиком удостоверений, отличного от идентификатора Microsoft Entra, поток проверки подлинности зависит от того, выполняется ли проверка подлинности пользователя с помощью поставщика удостоверений или с проверкой подлинности однократного секретного кода электронной почты. В любом случае арендатор ресурсов определяет используемый метод проверки подлинности, а затем либо перенаправляет пользователя к своему поставщику удостоверений, либо выдает одноразовый секретный код.
Пример 1. Поток проверки подлинности и токен для внешнего пользователя, не использующего Azure AD
На следующей схеме показан поток проверки подлинности при входе внешнего пользователя с учетной записью от поставщика удостоверений, не относящегося к Azure AD, например Google, Facebook или федеративного поставщика удостоверений SAML/WS-Fed.
| Этап | Описание: |
|---|---|
| 1 | Гостевой пользователь B2B запрашивает доступ к ресурсу. Ресурс перенаправляет пользователя к клиенту ресурса (доверенному IdP). |
| 2 | Клиент ресурса определяет пользователя как внешнего и перенаправляет его к IdP гостевого пользователя B2B. Пользователь выполняет первичную проверку подлинности в IdP. |
| 3 | Политики авторизации оцениваются в IdP гостевых пользователей B2B. Если пользователь соответствует этим политикам, IdP гостевого пользователя B2B выдает токен пользователю. С помощью токена пользователь перенаправляется обратно в клиент ресурса. Арендатор ресурса проверяет токен, а затем оценивает пользователя на предмет соответствия политикам условного доступа. Например, клиенту ресурсов может потребоваться выполнить многофакторную проверку подлинности Microsoft Entra. |
| 4 | Оцениваются параметры входящего доступа между арендаторами и политики условного доступа. Если все политики условного доступа удовлетворены, арендатор ресурса выдает соответствующий токен и перенаправляет пользователя к его ресурсу. |
Пример 2. Поток проверки подлинности и токен для пользователя, использующего одноразовый секретный код
На следующей схеме показан поток при включении однократной проверки подлинности секретного кода электронной почты, а внешний пользователь не проходит проверку подлинности с помощью других средств, таких как Идентификатор Microsoft Entra, учетная запись Майкрософт (MSA) или поставщик удостоверений социальных сетей.
| Этап | Описание: |
|---|---|
| 1 | Пользователь запрашивает доступ к ресурсу в другом клиенте. Ресурс перенаправляет пользователя к клиенту ресурса (доверенному IdP). |
| 2 | Клиент ресурса идентифицирует пользователя в качестве внешнего пользователя с одноразовым секретным кодом и отправляет пользователю сообщение электронной почты с одноразовым секретным кодом. |
| 3 | Пользователь получает одноразовый секретный код и передает его. Арендатор ресурса оценивает пользователя на предмет соответствия с политикам условного доступа. |
| 4 | Если все политики условного доступа удовлетворены, арендатор ресурса выдает токен и перенаправляет пользователя к его ресурсу. |
Условный доступ для внешних пользователей
Организации могут применять политики условного доступа для внешних пользователей совместной работы B2B и пользователей с прямым соединением B2B таким же образом, как они используются для сотрудников с полной занятостью и членов организации. Благодаря внедрению параметров доступа между клиентами можно также доверять утверждениям MFA и устройств из внешних организаций Microsoft Entra. В этом разделе описаны важные моменты, касающиеся применения условного доступа к пользователям за пределами организации.
Примечание.
Пользовательские элементы управления с условным доступом не поддерживаются для доверия между клиентами.
Назначение политик условного доступа внешним типам пользователей
При настройке политики условного доступа у вас есть детальный контроль над типами внешних пользователей, к которым вы хотите применить политику. Внешние пользователи классифицируются на основе того, как они проходят проверку подлинности (внутренне или вне) и их отношения с вашей организацией (гостем или участником).
- Гостевые пользователи службы совместной работы B2B — большинство пользователей, которые обычно считаются гостями, попадают в эту категорию. У этого пользователя совместной работы B2B есть учетная запись во внешней организации Microsoft Entra или внешний поставщик удостоверений (например, социальное удостоверение), и у них есть разрешения на гостевой уровень в вашей организации. Объект пользователя, созданный в каталоге Microsoft Entra, имеет userType of Guest. Эта категория включает пользователей совместной работы B2B, которые были приглашены и использовали самостоятельную регистрацию.
- Пользователи участников совместной работы B2B. Этот пользователь службы совместной работы B2B имеет учетную запись во внешней организации Microsoft Entra или внешний поставщик удостоверений (например, социальное удостоверение) и доступ на уровне участника к ресурсам в организации. Этот сценарий распространен в организациях, включающих несколько арендаторов, где пользователи считаются частью более крупной организации и нуждаются в доступе на уровне участника к ресурсам в других арендаторах организации. Объект пользователя, созданный в каталоге Microsoft Entra, имеет userType of Member.
- Пользователи прямого подключения B2B — внешние пользователи, которые могут получить доступ к ресурсам через прямой подключение B2B, который является двусторонним подключением к другой организации Microsoft Entra, которая обеспечивает единый вход в определенные приложения Майкрософт (в настоящее время Microsoft Teams Связи общих каналов). У пользователей прямого подключения B2B нет присутствия в организации Microsoft Entra, но вместо этого управляются из приложения (например, владельцем общего канала Teams).
- Локальные гостевые пользователи — локальные гостевые пользователи имеют учетные данные, управляемые в каталоге. Прежде чем служба совместной работы Microsoft Entra B2B была доступна, для совместной работы с распространителями, поставщиками, поставщиками и другими пользователями, настроив для них внутренние учетные данные и назначив их в качестве гостей, установив для пользователя объект UserType значение Guest.
- Пользователи поставщика услуг — организации, которые служат поставщиками облачных служб для вашей организации (свойство isServiceProvider в конфигурации партнера Microsoft Graph имеет значение true).
- Другие внешние пользователи — применяется к любым пользователям, которые не попадают в эти категории, но не считаются внутренними членами вашей организации, то есть они не проходят проверку подлинности внутри пользователя с помощью идентификатора Microsoft Entra, а объект пользователя, созданный в каталоге Microsoft Entra, не имеет userType of Member.
Примечание.
Выбор "Все гостевые и внешние пользователи" теперь заменен на "Гостевые и внешние пользователи" и все его подтипы. Для клиентов, у которых ранее была политика condtional Access с выбранным параметром "Все гостевые и внешние пользователи", появится сообщение "Гостевые и внешние пользователи" вместе со всеми подтипами. Это изменение в пользовательском интерфейсе не влияет на то, как политика оценивается серверной частью условного доступа. Новый выбор предоставляет клиентам необходимую степень детализации, чтобы выбрать типы спецификаций гостевых и внешних пользователей для включения и исключения из область пользователей при создании политики условного доступа.
Дополнительные сведения о назначениях пользователей условного доступа.
Сравнение политик условного доступа внешнего идентификатора
В следующей таблице приведено подробное сравнение параметров политики безопасности и соответствия требованиям в Внешняя идентификация Microsoft Entra. Политика безопасности и соответствие управляются хост-организацией в рамках политик условного доступа.
| Политика | Пользователи службы совместной работы B2B | Пользователи прямого подключения B2B |
|---|---|---|
| Предоставление элементов управления — блокировка доступа | Поддерживается | Поддерживается |
| Предоставление элементов управления — требовать многофакторную проверку подлинности | Поддерживается | Поддерживается, требуется настройка параметров доверия для входящего трафика для принятия утверждений MFA из внешней организации. |
| Предоставление элементов управления — требуется соответствующее устройство | Поддерживается, требуется настройка параметров доверия для входящего трафика, чтобы принимать соответствующие утверждения устройства из внешней организации. | Поддерживается, требуется настройка параметров доверия для входящего трафика, чтобы принимать соответствующие утверждения устройства из внешней организации. |
| Предоставление элементов управления — требуется гибридное устройство, присоединенное к Microsoft Entra | Поддерживается, требуется настройка параметров доверия для входящих подключений для принятия утверждений гибридного устройства Microsoft Entra из внешней организации. | Поддерживается, требуется настройка параметров доверия для входящих подключений для принятия утверждений гибридного устройства Microsoft Entra из внешней организации. |
| Предоставление элементов управления. Требовать утвержденное клиентское приложение | Не поддерживается | Не поддерживается |
| Предоставление элементов управления . Требовать политику защиты приложений | Не поддерживается | Не поддерживается |
| Предоставление элементов управления . Требовать изменение пароля | Не поддерживается | Не поддерживается |
| Предоставление элементов управления — условия использования | Поддерживается | Не поддерживается |
| Элементы управления сеансами. Использование примененных приложений ограничений | Поддерживается | Не поддерживается |
| Элементы управления сеансами— использование элемента управления условным доступом | Поддерживается | Не поддерживается |
| Элементы управления сеансами — частота входа | Поддерживается | Не поддерживается |
| Элементы управления сеансами — сеанс постоянного браузера | Поддерживается | Не поддерживается |
MFA для внешних пользователей Microsoft Entra
В сценарии с несколькими клиентами Microsoft Entra организация ресурсов может создавать политики условного доступа, требующие соответствия MFA или устройств для всех гостевых и внешних пользователей. Как правило, пользователю совместной работы B2B, доступ к ресурсу, необходимо настроить многофакторную проверку подлинности Microsoft Entra с помощью клиента ресурса. Однако идентификатор Microsoft Entra теперь предоставляет возможность доверять утверждениям MFA от других клиентов Microsoft Entra. Возможность устанавливать отношения доверия к другим арендаторам в рамках MFA упрощает процесс входа для пользователей Совместной работы B2B и обеспечивает доступ для пользователей прямого соединения B2B.
Если вы настроили параметры входящего доверия для приема утверждений MFA из домашнего клиента службы совместной работы B2B или прямого подключения пользователя B2B, идентификатор Microsoft Entra ID проверка сеанс проверки подлинности пользователя. Если сеанс содержит утверждение, указывающее, что политики MFA уже выполнены в домашнем клиенте пользователя, пользователь получает простой вход в общий ресурс.
Если доверие MFA не включено, пользовательский интерфейс для пользователей Совместной работы B2B и будет отличаться от интерфейса для пользователей прямого подключения B2B:
Пользователи службы совместной работы B2B: если организация ресурсов не включает доверие MFA с домашним клиентом пользователя, пользователь может получить вызов MFA из организации ресурсов. (поток аналогичен потоку MFA для внешних пользователей, не использующих Azure AD).
Пользователи прямого подключения B2B: если организация ресурсов не включает доверие MFA с домашним клиентом пользователя, пользователь блокирует доступ к ресурсам. Если вы хотите разрешить прямое соединение B2B с внешней организацией и политики условного доступа требуют MFA, необходимо настроить параметры входящего доверия таким образом, чтобы принимались утверждения MFA из организации.
См. дополнительные сведения о том, как настроить параметры доверия MFA для входящего трафика.
MFA для внешних пользователей, не использующих Azure AD
Для внешних пользователей, не использующих Azure AD, за MFA всегда отвечает арендатор ресурсов. В следующем примере показан типичный поток MFA. Этот сценарий работает для любого удостоверения, включая учетную запись Майкрософт (MSA) или идентификатор социальных сетей. Этот поток также применяется для внешних пользователей Microsoft Entra, если вы не настраиваете параметры доверия с домашней организацией Microsoft Entra.
Администратор или информационный работник компании Fabrikam приглашает пользователя из другой компании Contoso для использования приложения Fabrikam.
Приложение Fabrikam настроено на требование многофакторной проверки подлинности Microsoft Entra при доступе.
Когда пользователь совместной работы B2B из Contoso пытается получить доступ к приложению Fabrikam, им будет предложено выполнить задачу многофакторной проверки подлинности Microsoft Entra.
Затем гостевой пользователь может настроить многофакторную проверку подлинности Microsoft Entra с помощью Fabrikam и выбрать параметры.
Fabrikam должен иметь достаточно лицензий на идентификатор Microsoft Entra уровня "Премиум", поддерживающих многофакторную проверку подлинности Microsoft Entra. Затем пользователь из компании Contoso использует эту лицензию из Fabrikam. Сведения о лицензировании B2B см. в модели выставления счетов для Внешняя идентификация Microsoft Entra.
Примечание.
MFA выполняется на уровне арендатора ресурсов для обеспечения прогнозируемости. Когда гостевой пользователь входит в систему, он видит страницу входа клиента ресурса, отображаемую в фоновом режиме, собственную страницу входа в систему домашнего клиента и логотип компании на переднем плане.
Сброс многофакторной проверки подлинности Microsoft Entra (проверка подлинности) для пользователей совместной работы B2B
Для подтверждения или запрашивания регистрации MFA у пользователей Совместной работы B2B доступны следующие командлеты PowerShell.
Примечание.
Модули Azure AD и MSOnline PowerShell устарели с 30 марта 2024 г. Дополнительные сведения см. в обновлении об отмене. После этой даты поддержка этих модулей ограничена поддержкой миграции в пакет SDK Для Microsoft Graph PowerShell и исправления безопасности. Устаревшие модули будут продолжать функционировать до 30 марта 2025 года.
Рекомендуется перенести в Microsoft Graph PowerShell для взаимодействия с идентификатором Microsoft Entra (ранее — Azure AD). Часто задаваемые вопросы о миграции см. в разделе "Вопросы и ответы о миграции". Примечание. Версии 1.0.x MSOnline могут возникнуть сбоем после 30 июня 2024 г.
Подключение идентификатор Microsoft Entra:
$cred = Get-Credential Connect-MsolService -Credential $credПолучение сведений о методах подтверждения для всех пользователей:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Например:
Get-MsolUser | where { $_.StrongAuthenticationMethods} | select UserPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Сбросите метод многофакторной проверки подлинности Microsoft Entra для конкретного пользователя, чтобы пользователь снова настроил методы проверки правописания, например:
Reset-MsolStrongAuthenticationMethodByUpn -UserPrincipalName gsamoogle_gmail.com#EXT#@ WoodGroveAzureAD.onmicrosoft.com
Политики надежности проверки подлинности для внешних пользователей
Сила проверки подлинности — это элемент управления условным доступом, который позволяет определить определенное сочетание многофакторных методов проверки подлинности, которые внешний пользователь должен завершить доступ к ресурсам. Этот элемент управления особенно полезен для ограничения внешнего доступа к конфиденциальным приложениям в организации, так как вы можете применять определенные методы проверки подлинности, такие как фишинговый метод, устойчивый к фишингу, для внешних пользователей.
Вы также можете применить силу проверки подлинности к различным типам гостевых или внешних пользователей, с которыми вы работаете или подключаетесь. Это означает, что вы можете применять требования к надежности проверки подлинности, уникальные для совместной работы B2B, прямого подключения B2B и других сценариев внешнего доступа.
Идентификатор Microsoft Entra предоставляет три встроенных преимущества проверки подлинности:
- Надежность многофакторной проверки подлинности
- Сила MFA без пароля
- Устойчивость к фишингу MFA
Вы можете использовать одну из этих встроенных сильных сторон или создать настраиваемую политику надежности проверки подлинности на основе методов проверки подлинности, которые требуется требовать.
Примечание.
В настоящее время можно применять только политики надежности проверки подлинности для внешних пользователей, прошедших проверку подлинности с помощью идентификатора Microsoft Entra. Для однократного секретного кода, SAML/WS-Fed и пользователей федерации Google используйте элемент управления предоставлением MFA, чтобы требовать многофакторную проверку подлинности.
При применении политики надежности проверки подлинности к внешним пользователям Microsoft Entra политика работает вместе с параметрами доверия MFA в параметрах доступа между клиентами, чтобы определить, где и как внешний пользователь должен выполнять многофакторную проверку подлинности. Пользователь Microsoft Entra сначала проходит проверку подлинности с помощью собственной учетной записи в своем домашнем клиенте Microsoft Entra. Затем, когда этот пользователь пытается получить доступ к ресурсу, идентификатор Microsoft Entra применяет политику условного доступа проверки подлинности и проверка, чтобы узнать, включена ли доверие MFA.
В сценариях внешнего пользователя методы проверки подлинности, приемлемые для выполнения силы проверки подлинности, зависят от того, выполняется ли пользователь MFA в своем домашнем клиенте или клиенте ресурса. В следующей таблице указаны допустимые методы в каждом клиенте. Если клиент ресурсов решит доверять утверждениям из внешних организаций Microsoft Entra, то только те утверждения, перечисленные в столбце "Домашний клиент", принимаются клиентом ресурсов для выполнения MFA. Если клиент ресурсов отключил доверие MFA, внешний пользователь должен завершить MFA в клиенте ресурса с помощью одного из методов, перечисленных в столбце "Клиент ресурса".
Таблица 1. Методы MFA для проверки подлинности для внешних пользователей
| Authentication method | Домашний клиент | Клиент ресурсов |
|---|---|---|
| SMS в качестве второго фактора | ✅ | ✅ |
| Голосовой звонок | ✅ | ✅ |
| Приложение Microsoft Authenticator — push-уведомление | ✅ | ✅ |
| Вход на телефон Microsoft Authenticator | ✅ | |
| Программный маркер OATH | ✅ | ✅ |
| Токен оборудования OATH | ✅ | |
| Ключ безопасности FIDO2 | ✅ | |
| Windows Hello для бизнеса | ✅ |
Сведения о настройке политики условного доступа, которая применяет требования к надежности проверки подлинности внешним пользователям или гостям, см. в статье "Условный доступ: требуется проверка подлинности для внешних пользователей".
Взаимодействие с пользователем для внешних пользователей Microsoft Entra
Политики надежности проверки подлинности работают вместе с параметрами доверия MFA в параметрах доступа между клиентами, чтобы определить, где и как внешний пользователь должен выполнять MFA.
Во-первых, пользователь Microsoft Entra проходит проверку подлинности с помощью собственной учетной записи в своем домашнем клиенте. Затем, когда этот пользователь пытается получить доступ к ресурсу, идентификатор Microsoft Entra применяет политику условного доступа проверки подлинности и проверка, чтобы узнать, включена ли доверие MFA.
- Если включено доверие MFA, идентификатор Microsoft Entra проверка сеанс проверки подлинности пользователя для утверждения, указывающего, что MFA выполнена в домашнем клиенте пользователя. (См. раздел Таблица 1 для методов проверки подлинности, приемлемых для выполнения MFA при завершении в домашнем клиенте внешнего пользователя.) Если сеанс содержит утверждение, указывающее, что политики MFA уже выполнены в домашнем клиенте пользователя и методы удовлетворяют требованиям к надежности проверки подлинности, пользователь может получить доступ. В противном случае идентификатор Microsoft Entra представляет пользователю задачу завершить MFA в домашнем клиенте с помощью приемлемого метода проверки подлинности. Метод MFA должен быть включен в домашнем клиенте, и пользователь должен иметь возможность зарегистрировать его.
- Если доверие MFA отключено, идентификатор Microsoft Entra представляет пользователю задачу завершить MFA в клиенте ресурса с помощью приемлемого метода проверки подлинности. (См. раздел Таблица 1 для методов проверки подлинности, приемлемых для выполнения MFA внешним пользователем.)
Если пользователь не может завершить многофакторную проверку подлинности или если политика условного доступа (например, соответствующая политика устройства) не сможет зарегистрировать его, доступ блокируется.
Соответствие устройств и политики гибридных присоединенных устройств Microsoft Entra
С помощью политик условного доступа организации могут требовать, чтобы устройствами пользователей управляла служба Microsoft Intune. Такие политики могут блокировать доступ внешних пользователей, так как внешний пользователь не может зарегистрировать свое неуправляемое устройство в организации, предоставляющей ресурсы. Устройствами может управлять только домашний арендатор пользователя.
Но с помощью параметров доверия устройств вы можете разблокировать доступ для внешних пользователей, по-прежнему требуя использования управляемых устройств. В параметрах доступа между клиентами вы можете доверять утверждениям от домашнего клиента внешнего пользователя о том, соответствует ли устройство пользователя политикам соответствия устройств или присоединено к гибридному присоединению к Microsoft Entra. Параметры доверия устройств можно задать для всех организаций Microsoft Entra или отдельных организаций.
Если параметры доверия устройств включены, идентификатор Microsoft Entra ID проверка сеанс проверки подлинности пользователя для утверждения устройства. Если сеанс содержит утверждение устройства, указывающее, что политики уже выполнены в домашнем клиенте пользователя, внешний пользователь получает простой вход в общий ресурс.
Внимание
- Если вы не хотите доверять утверждениям о соответствии устройств или гибридному присоединению Microsoft Entra от домашнего клиента внешнего пользователя, мы не рекомендуем применять политики условного доступа, требующие от внешних пользователей использовать управляемые устройства.
Фильтры устройств
При создании политик условного доступа для внешних пользователей можно оценить политику на основе атрибутов устройства зарегистрированного устройства в идентификаторе Microsoft Entra. Используя фильтр для условий устройств , вы можете нацелиться на определенные устройства с помощью поддерживаемых операторов и свойств и других доступных условий назначения в политиках условного доступа.
Фильтры устройств можно использовать вместе с параметрами доступа между арендаторами, чтобы установить политики для устройств, управляемых в других организациях. Например, предположим, что вы хотите заблокировать устройства из внешнего клиента Microsoft Entra на основе определенного атрибута устройства. Чтобы настроить политику на основе атрибутов устройства, выполните следующие действия.
- Настройте параметры доступа между арендаторами таким образом, чтобы установить доверие к утверждениям устройств из этой организации.
- В качестве атрибута устройства, который нужно использовать для фильтрации, назначьте один из поддерживаемых атрибутов расширения устройства.
- Создайте политику условного доступа с фильтром устройств, который блокирует доступ к устройствам, содержащим этот атрибут.
См. дополнительные сведения о фильтрации устройств с использованием условного доступа.
Политики управления мобильными приложениями
Не рекомендуем устанавливать требование политики защиты приложений для внешних пользователей. Для таких элементов управления предоставлением прав условного доступа, как требование доступа из утвержденных клиентских приложений и требование применения политик защиты приложений, требуется, чтобы устройство было зарегистрировано в арендаторе ресурса. Эти элементы управления можно применять только к устройствам iOS и Android. Так как устройством пользователя может управлять только его домашний арендатор, эти элементы управления нельзя применять к внешним гостевым пользователям.
Условный доступ на основе расположения
Политика на основе расположения, основанная на диапазонах IP-адресов, может быть применена, если приглашающая организации может создать диапазон доверенных IP-адресов, определяющий партнерские организации.
Политики также можно применять на основе географических расположений.
Условный доступ на основе рисков
Политика рисков при входе применяется, если внешний гостевой пользователь удовлетворяет требования к предоставлению управления. Например, организации может потребоваться многофакторная проверка подлинности Microsoft Entra для среднего или высокого риска входа. Однако если пользователь ранее не зарегистрировался для многофакторной проверки подлинности Microsoft Entra в клиенте ресурса, пользователь заблокирован. Это делается, чтобы предотвратить регистрацию собственных учетных данных многофакторной проверки подлинности Microsoft Entra в случае, если они скомпрометируют пароль законного пользователя.
Но политику риска пользователя нельзя разрешить в арендаторе ресурса. Например, если требуется изменение пароля для внешних гостевых пользователей с высоким риском, они блокируются из-за невозможности сброса паролей в каталоге ресурсов.
Условие клиентских приложений условного доступа
Условия клиентских приложений работают для гостевых пользователей B2B так же, как и для любого другого типа пользователей. Например, можно предотвратить использование устаревших протоколов проверки подлинности гостевыми пользователями.
Элементы управления сеансом условного доступа
Элементы управления сеансом работают для гостевых пользователей B2B так же, как и для любого другого типа пользователей.
Защита идентификации и политики рисков пользователей
Защита идентификации обнаруживает скомпрометированные учетные данные для пользователей Microsoft Entra и помечает учетные записи пользователей, которые могут быть скомпрометированы как "подверженные риску". В качестве клиента ресурсов можно применять политики риска пользователей к внешним пользователям, чтобы заблокировать рискованные входы. Для внешнего пользователя риск пользователя оценивается в домашнем каталоге. Риск входа в реальном времени для этих пользователей оценивается в каталоге ресурсов при попытке доступа к ресурсу. Но так как удостоверение внешнего пользователя существует в его домашнем каталоге, действуют следующие ограничения:
- Если внешний пользователь активирует политику рисков пользователей Защиты идентификации для принудительного сброса пароля, доступ для такого пользователя блокируется, так как он не может сбросить пароль в организации, предоставляющей ресурсы.
- Отчет о рискованных пользователях организации ресурсов не отражает внешних пользователей, так как оценка рисков происходит в домашнем каталоге внешнего пользователя.
- Администраторы в организации, предоставляющей ресурсы, не могут отклонить доступ или выполнить исправление для внешнего пользователя, совершающего рискованные действия, так как у них нет доступа к домашнему каталогу пользователя B2B.
Политики на основе рисков можно запретить внешним пользователям, создав группу в идентификаторе Microsoft Entra, которая содержит всех внешних пользователей вашей организации. Затем добавьте эту группу в качестве исключения для встроенных в Защиту идентификации политик рисков пользователей и политик рисков при входе, а также любых политик условного доступа, использующих риск при входе в качестве условия.
Дополнительные сведения см. на странице Защита идентификации и пользователи B2B.
Следующие шаги
Дополнительные сведения см. в следующих статьях: