Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Применяется к: 
Арендаторы рабочей области (дополнительные сведения)
Совет
Эта статья относится к совместной работе B2B и прямому подключению B2B в арендаторах рабочей силы. Сведения о внешних арендаторах см. в разделе "Безопасность и управление в External ID 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 проверяет параметры входящего доверия Contoso, чтобы узнать, доверяет ли Contoso MFA и запросам устройств (соответствие устройств, статус гибридного присоединения Microsoft Entra) из Fabrikam. Если это не так, перейдите к шагу 6. |
| 4 | Если Contoso доверяет утверждениям MFA и устройствам из Fabrikam, Microsoft Entra ID проверяет сеанс аутентификации пользователя на наличие указания на завершение многофакторной проверки подлинности. Если Contoso доверяет сведения об устройстве из Fabrikam, идентификатор Microsoft Entra ищет утверждение в сеансе проверки подлинности, указывающее состояние устройства (совместимое или гибридное присоединение к Microsoft Entra). |
| 5 | Если многофакторная аутентификация требуется, но не выполнена, или если не предоставлено утверждение устройства, Microsoft Entra ID выдает запросы многофакторной аутентификации и проверки устройства в домашнем клиенте пользователя при необходимости. Если в Fabrikam удовлетворены требования к MFA и устройствам, пользователю предоставляется доступ к ресурсу в Contoso. Если проверки пройти не удается, доступ блокируется. |
| 6 | Если параметры доверия не настроены и требуется MFA, пользователям службы совместной работы B2B будет предложено пройти аутентификацию с использованием MFA. Они должны удовлетворять требованиям многофакторной аутентификации в тенанте ресурсов. Доступ для пользователей с прямым соединением B2B блокируется. Если требуется соответствие устройства, но его не удается оценить, то доступ блокируется как для пользователей B2B-сотрудничества, так и для пользователей B2B Direct Connect. |
Дополнительные сведения см. в разделе Условный доступ для внешних пользователей.
Поток аутентификации для внешних пользователей, не использующих Microsoft Entra ID
Если организация Microsoft Entra предоставляет ресурсы внешним пользователям с поставщиком удостоверений, отличного от идентификатора Microsoft Entra, поток проверки подлинности зависит от того, выполняется ли проверка подлинности пользователя с помощью поставщика удостоверений или с проверкой подлинности однократного секретного кода электронной почты. В любом случае арендатор ресурсов определяет используемый метод проверки подлинности, а затем либо перенаправляет пользователя к своему поставщику удостоверений, либо выдает одноразовый секретный код.
Пример 1. Поток аутентификации и токен для внешнего пользователя, отличного от Microsoft Entra ID
На следующей диаграмме иллюстрируется процесс аутентификации, когда внешний пользователь входит с учетной записью от поставщика удостоверений, не связанного с Microsoft Entra ID, например, Google, Facebook или федеративного поставщика удостоверений SAML/WS-Fed.
| Этап | Описание: |
|---|---|
| 1 | Гостевой пользователь B2B запрашивает доступ к ресурсу. Ресурс перенаправляет пользователя к клиенту ресурса (доверенному IdP). |
| 2 | Арендатор ресурса идентифицирует пользователя как внешнего и перенаправляет его к IdP гостевого пользователя B2B. Пользователь выполняет первичную проверку подлинности в IdP. |
| 3 | Политики авторизации оцениваются в IdP гостевых пользователей B2B. Если пользователь соответствует этим политикам, IdP гостевого пользователя B2B выдает токен пользователю. Пользователь перенаправляется обратно к арендатору ресурса с токеном. Арендатор ресурса проверяет токен, а затем оценивает пользователя на предмет соответствия политикам условного доступа. Например, клиенту ресурсов может потребоваться выполнить многофакторную проверку подлинности Microsoft Entra. |
| 4 | Оцениваются параметры входящего доступа между арендаторами и политики условного доступа. Если все политики условного доступа удовлетворены, арендатор ресурса выдает соответствующий токен и перенаправляет пользователя к его ресурсу. |
Пример 2. Поток проверки подлинности и токен для пользователя, использующего одноразовый секретный код
На следующей схеме показан поток при включении однократной проверки подлинности секретного кода электронной почты, а внешний пользователь не проходит проверку подлинности с помощью других средств, таких как Идентификатор Microsoft Entra, учетная запись Майкрософт (MSA) или поставщик удостоверений социальных сетей.
Диаграмма, показывающая поток аутентификации для гостевых пользователей B2B с использованием одноразового пароля.
| Этап | Описание: |
|---|---|
| 1 | Пользователь запрашивает доступ к ресурсу в другом клиенте. Ресурс перенаправляет пользователя к клиенту ресурса (доверенному IdP). |
| 2 | Клиент ресурса идентифицирует пользователя в качестве внешнего пользователя с одноразовым секретным кодом и отправляет пользователю сообщение электронной почты с одноразовым секретным кодом. |
| 3 | Пользователь получает одноразовый секретный код и передает его. Арендатор ресурса оценивает пользователя на предмет соответствия с политикам условного доступа. |
| 4 | Если все политики условного доступа удовлетворены, арендатор ресурса выдает токен и перенаправляет пользователя к его ресурсу. |
Условный доступ для внешних пользователей
Организации могут применять политики условного доступа для внешних пользователей совместной работы B2B и пользователей с прямым соединением B2B таким же образом, как они используются для сотрудников с полной занятостью и членов организации. Благодаря внедрению параметров доступа между клиентами можно также доверять утверждениям MFA и устройств из внешних организаций Microsoft Entra. В этом разделе описаны важные моменты, касающиеся применения условного доступа к пользователям за пределами организации.
Примечание.
Пользовательские управления с условным доступом не поддерживаются для доверительных отношений между арендаторами.
Назначение политик условного доступа внешним типам пользователей
При настройке политики условного доступа у вас есть детальный контроль над типами внешних пользователей, к которым вы хотите применить политику. Внешние пользователи классифицируются на основе того, как они проходят проверку подлинности (внутренне или вне) и их отношения с вашей организацией (гостем или участником).
- Гостевые пользователи службы совместной работы B2B — большинство пользователей, которые обычно считаются гостями, попадают в эту категорию. У пользователя B2B взаимодействия есть учетная запись либо во внешней организации Microsoft Entra, либо у внешнего поставщика удостоверений (например, у социального провайдера удостоверений), и у него есть разрешения на уровне гостя в вашей организации. Объект пользователя, созданный в каталоге Microsoft Entra, имеет тип пользователя - Гость. Эта категория включает пользователей совместной работы B2B, которые были приглашены и использовали самостоятельную регистрацию.
- Пользователи с доступом на уровне участника для B2B-сотрудничества. Этот пользователь B2B-сотрудничества имеет учетную запись во внешней организации Microsoft Entra или у внешнего поставщика удостоверений (например, социальная учетная запись) и обладает доступом уровня участника к ресурсам вашей организации. Этот сценарий распространен в организациях, включающих несколько арендаторов, где пользователи считаются частью более крупной организации и нуждаются в доступе на уровне участника к ресурсам в других арендаторах организации. Объект пользователя, созданный в каталоге Microsoft Entra, имеет тип пользователя Member.
- Пользователи прямого подключения B2B — внешние пользователи, которые могут получить доступ к вашим ресурсам через прямое подключение B2B, которое является двусторонним подключением к другой организации Microsoft Entra, позволяющим однократную аутентификацию в определенные приложения Microsoft (в настоящее время Microsoft Teams Connect для общих каналов). Пользователи прямого подключения B2B не имеют учетной записи в организации Microsoft Entra, но они управляются через приложение (например, владельцем общего канала Teams).
- Локальные гостевые пользователи — локальные гостевые пользователи имеют учетные данные, управляемые в каталоге. Прежде чем служба совместной работы Microsoft Entra B2B стала доступна, для взаимодействия с дистрибьюторами, поставщиками, вендорами и другими пользователями настраивались внутренние учетные данные и обозначался тип пользователя как «Гость» путем установки для объекта UserType значения Guest.
- Пользователи поставщика услуг — организации, которые служат поставщиками облачных служб для вашей организации (свойство isServiceProvider в конфигурации партнера Microsoft Graph имеет значение true).
- Другие внешние пользователи — применяется к любым пользователям, которые не попадают в эти категории, но не считаются внутренними членами вашей организации, то есть они не проходят проверку подлинности внутри пользователя с помощью идентификатора Microsoft Entra, а объект пользователя, созданный в каталоге Microsoft Entra, не имеет userType of Member.
Примечание.
Выбор "Все гостевые и внешние пользователи" теперь заменен на "Гостевые и внешние пользователи" и все его подтипы. Для клиентов, у которых ранее была политика условного доступа с выбранным параметром "Все гостевые и внешние пользователи", теперь будут отображаться "Гостевые и внешние пользователи" вместе со всеми подтипами. Это изменение в пользовательском интерфейсе не влияет на то, как политика оценивается в системе Conditional Access backend. Новый выбор предоставляет клиентам необходимую степень детализации для выбора определенных типов гостевых и внешних пользователей для включения и исключения из области пользователя при создании политики условного доступа.
Дополнительные сведения о назначениях пользователей условного доступа.
Сравните политики условного доступа для внешнего ID
В следующей таблице приведено подробное сравнение политики безопасности и параметров соответствия в Microsoft Entra External ID. Политика безопасности и соответствие управляются хост-организацией в рамках политик условного доступа.
| Политика | Пользователи службы совместной работы 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 для внешних пользователей, не связанных с Microsoft Entra ID.)
Пользователи прямого подключения B2B: если организация, управляющая ресурсами, не включает доверие к многофакторной аутентификации (MFA) с домашним арендатором пользователя, то пользователю блокируется доступ к ресурсам. Если вы хотите разрешить прямое соединение B2B с внешней организацией и политики условного доступа требуют MFA, необходимо настроить параметры входящего доверия таким образом, чтобы принимались утверждения MFA из организации.
См. дополнительные сведения о том, как настроить параметры доверия MFA для входящего трафика.
MFA для внешних пользователей, не использующих Microsoft Entra ID
Для внешних пользователей, отличных от Microsoft Entra ID, клиент ресурсов всегда отвечает за 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. См. модель выставления счетов для Внешнего идентификатора Microsoft Entra для получения информации о лицензировании B2B.
Примечание.
MFA выполняется на уровне арендатора ресурсов для обеспечения прогнозируемости. Когда гостевой пользователь входит в систему, он видит страницу входа клиента ресурса, отображаемую в фоновом режиме, собственную страницу входа в систему домашнего клиента и логотип компании на переднем плане.
Сброс подтверждения данных многофакторной аутентификации Microsoft Entra для пользователей совместной работы B2B
Для подтверждения или запрашивания регистрации MFA у пользователей Совместной работы B2B доступны следующие командлеты PowerShell.
Подключитесь к идентификатору Microsoft Entra:
Connect-Entra -Scopes 'User.Read.All'Получение сведений о методах подтверждения для всех пользователей:
Get-EntraUser | where { $_.StrongAuthenticationMethods} | select userPrincipalName, @{n="Methods";e={($_.StrongAuthenticationMethods).MethodType}}Сбросьте метод многофакторной аутентификации Microsoft Entra для конкретного пользователя, чтобы пользователь снова настроил методы аутентификации, например:
Connect-Entra -Scopes 'UserAuthenticationMethod.ReadWrite.All' Reset-EntraStrongAuthenticationMethodByUpn -UserPrincipalName jmorgan_fabrikam.com#EXT#@woodgrovebank.onmicrosoft.com
Политики надежности проверки подлинности для внешних пользователей
Уровень проверки подлинности — это элемент управления условным доступом, который позволяет задать конкретное сочетание многофакторных методов проверки, которое внешний пользователь должен пройти, чтобы получить доступ к вашим ресурсам. Этот элемент управления особенно полезен для ограничения внешнего доступа к конфиденциальным приложениям в организации, так как вы можете применять определенные методы проверки подлинности, такие как фишинговый метод, устойчивый к фишингу, для внешних пользователей.
Вы также можете применить силу проверки подлинности к различным типам гостевых или внешних пользователей, с которыми вы работаете или подключаетесь. Это означает, что вы можете применять требования к надежности проверки подлинности, уникальные для совместной работы B2B, прямого подключения B2B и других сценариев внешнего доступа.
Идентификатор Microsoft Entra предоставляет три встроенных преимущества проверки подлинности:
- Надежность многофакторной проверки подлинности
- Надёжность многофакторной аутентификации без паролей
- Устойчивость MFA против фишинга
Вы можете использовать одну из этих встроенных сильных сторон или создать настраиваемую политику надежности проверки подлинности на основе методов проверки подлинности, которые требуется требовать.
Примечание.
В настоящее время можно применять только политики надежности проверки подлинности для внешних пользователей, прошедших проверку подлинности с помощью идентификатора Microsoft Entra. Для пользователей, получающих однократные коды по электронной почте, а также для SAML/WS-Fed и Google федерации, используйте контроль доступа MFA, чтобы требовать многофакторную аутентификацию.
При применении политики уровня надежности аутентификации к внешним пользователям Microsoft Entra, политика работает вместе с параметрами доверия MFA в настройках доступа между клиентами, чтобы определить, где и как внешний пользователь должен выполнять многофакторную проверку подлинности (MFA). Пользователь Microsoft Entra сначала проходит проверку подлинности с помощью собственной учетной записи в своем домашнем клиенте Microsoft Entra. Затем, когда этот пользователь пытается получить доступ к вашему ресурсу, Microsoft Entra ID применяет политику условного доступа с учетом усиления проверки подлинности и проверяет, включено ли доверие MFA (Многофакторной Аутентификации).
В сценариях внешнего пользователя методы аутентификации, которые можно использовать для достижения требуемого уровня безопасности аутентификации, зависят от того, выполняет ли пользователь многофакторную аутентификацию в своем домашнем клиенте или клиенте ресурса. В следующей таблице указаны допустимые методы в каждом тенанте. Если клиент ресурсов решит доверять утверждениям из внешних организаций Microsoft Entra, то только те утверждения, перечисленные в столбце "Домашний клиент", принимаются клиентом ресурсов для выполнения MFA. Если клиент ресурсов отключил доверие MFA, внешний пользователь должен завершить MFA в клиенте ресурса с помощью одного из методов, перечисленных в столбце "Клиент ресурса".
Таблица 1. Методы многофакторной аутентификации по уровню надежности для внешних пользователей
| Метод аутентификации | Домашний арендатор | Арендатор ресурсов |
|---|---|---|
| SMS в качестве второго фактора | ✅ | ✅ |
| Голосовой звонок | ✅ | ✅ |
| Приложение Microsoft Authenticator — push-уведомление | ✅ | ✅ |
| Вход с использованием Microsoft Authenticator на телефоне | ✅ | |
| Программный маркер OATH | ✅ | ✅ |
| Токен оборудования OATH | ✅ | |
| Ключ безопасности FIDO2 | ✅ | |
| Windows Hello для бизнеса | ✅ | |
| Проверка подлинности на основе сертификатов | ✅ |
Сведения о настройке политики условного доступа, которая применяет требования к надежности проверки подлинности внешним пользователям или гостям, см. в статье "Условный доступ: требуется проверка подлинности для внешних пользователей".
Взаимодействие с пользователем для внешних пользователей Microsoft Entra
Политики надежности проверки подлинности работают вместе с параметрами доверия MFA в параметрах доступа между клиентами, чтобы определить, где и как внешний пользователь должен выполнять MFA.
Во-первых, пользователь Microsoft Entra проходит проверку подлинности с помощью собственной учетной записи в своем домашнем клиенте. Затем, когда этот пользователь пытается получить доступ к вашему ресурсу, Microsoft Entra ID применяет политику условного доступа по силе проверки подлинности и проверяет, включен ли доверенный доступ MFA.
- Если включено доверие к MFA, Microsoft Entra ID проверяет сеанс аутентификации пользователя на наличие утверждения, что многофакторная аутентификация (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 ID и управления рисками пользователей.
Защита идентификации Microsoft Entra обнаруживает скомпрометированные учетные данные для пользователей Microsoft Entra и помечает учетные записи пользователей, которые могут быть скомпрометированы как "подверженные риску". В качестве клиента ресурсов можно применять политики риска пользователей к внешним пользователям, чтобы заблокировать рискованные входы. Для внешнего пользователя риск пользователя оценивается в домашнем каталоге. Риск входа в реальном времени для этих пользователей оценивается в каталоге ресурсов при попытке доступа к ресурсу. Но так как идентификация внешнего пользователя существует в его домашнем каталоге, существуют следующие ограничения:
- Если внешний пользователь инициирует политику управления рисками защиты ID для принудительного сброса пароля, они блокируются из-за того, что не могут сбросить свой пароль в ресурсной организации.
- Отчет о рискованных пользователях организации ресурсов не отражает внешних пользователей, так как оценка рисков происходит в домашнем каталоге внешнего пользователя.
- Администраторы в организации, предоставляющей ресурсы, не могут отклонить доступ или выполнить исправление для внешнего пользователя, совершающего рискованные действия, так как у них нет доступа к домашнему каталогу пользователя B2B.
Политики на основе рисков можно запретить внешним пользователям, создав группу в идентификаторе Microsoft Entra, которая содержит всех внешних пользователей вашей организации. Затем добавьте эту группу в качестве исключения для политик условного доступа, основанных на рисках пользователя и рисках входа.
Дополнительные сведения см. в разделе Защита идентификации Microsoft Entra и пользователей B2B.
Следующие шаги
Дополнительные сведения см. в следующих статьях: