Активация приглашения службы совместной работы Azure Active Directory B2B
В этой статье описываются способы доступа гостевых пользователей к ресурсам и процесс согласия, c которыми они могут столкнуться. Если вы отправляете гостю электронное письмо с приглашением, то оно содержит ссылку, которую гость может активировать для получения доступа к вашему приложению или порталу. Сообщение электронной почты с приглашением — лишь один из способов получения гостями доступа к вашим ресурсам. В качестве альтернативы можно добавить гостей в каталог и предоставить им прямую ссылку на портал или приложение, к которому вы хотите предоставить общий доступ. Независимо от используемого метода, гости проходят через процесс получения первоначального согласия. Этот процесс гарантирует, что ваши гости согласны с условиями конфиденциальности и принимают все настроенные условия использования.
Когда вы добавляете гостя в свой каталог, его учетная запись имеет статус согласия (просматриваемый в PowerShell), для которого изначально установлено значение PendingAcceptance. Эта настройка сохраняется до тех пор, пока гость не примет ваше приглашение и не согласится с вашей политикой конфиденциальности и условиями использования. После этого состояние согласия изменяется на Принято и страницы согласия больше не представляются гостю.
Важно!
- Начиная с 12 июля 2021 года, если клиенты Azure AD B2B настраивают новые интеграции Google для самостоятельной регистрации в пользовательских или бизнес-приложениях, то проверка подлинности с помощью удостоверений Google будет невозможна, пока она не будет перемещена в системные веб-представления. Подробнее.
- 30 сентября 2021 года Google прекращает поддержку входа через встроенные веб-представления. Если ваши приложения проверяют подлинность пользователей с помощью встроенного веб-представления и вы используете федерацию Google с Azure AD B2C либо используете Azure AD B2B для приглашения внешних пользователей или самостоятельной регистрации, то пользователи Google Gmail не смогут пройти проверку подлинности. Подробнее.
- Функция отправки одноразового секретного кода по электронной почте теперь включена по умолчанию для всех новых арендаторов и для всех существующих арендаторов, для которых вы не отключили ее явным образом. Если эта функция отключена, в рамках резервного способа проверки подлинности будет отправляться приглашение на создание учетной записи Майкрософт.
Активация и вход через общую конечную точку
Пользователи-гости теперь смогут входить в приложения с несколькими клиентами или собственные приложения Майкрософт через общую конечную точку (URL-адрес), например https://myapps.microsoft.com
. Ранее общий URL-адрес перенаправлял пользователя-гостя на домашний клиент, а не на клиент ресурсов для проверки подлинности, и поэтому требовалась ссылка для конкретного клиента (например, https://myapps.microsoft.com/?tenantid=<tenant id>
). Теперь пользователь-гость может перейти по общему URL-адресу приложения, выбрать Параметры входа, а потом нажать Вход в организацию. Затем пользователь вводит доменное имя вашей организации.
Затем пользователь перенаправляется в конечную точку конкретного клиента, где он может войти с помощью своего адреса электронной почты или выбрать настроенный поставщик удостоверений.
Активация с помощью прямой ссылки
В качестве альтернативы электронному письму с приглашением или общему URL-адресу приложения вы можете предоставить гостю прямую ссылку на ваше приложение или портал. Сначала необходимо добавить гостевого пользователя в каталог с помощью портала Azure или PowerShell. Затем можно использовать любой из настраиваемых способов развертывания приложений для пользователей, включая ссылки для прямого входа. Когда гость использует прямую ссылку вместо приглашения по электронной почте, он все равно пройдет процедуру получения первоначального согласия.
Примечание
Прямая ссылка предназначается для определенного клиента. Другими словами, она содержит идентификатор клиента или проверенный домен, чтобы гость мог пройти проверку подлинности в клиенте, где находится общее приложение. Ниже приведены некоторые примеры прямых ссылок с контекстом клиента.
- Панель доступа к приложениям:
https://myapps.microsoft.com/?tenantid=<tenant id>
- Панель доступа к приложениям для проверенного домена:
https://myapps.microsoft.com/<;verified domain>
- Портал Azure:
https://portal.azure.com/<tenant id>
- Отдельное приложение: см. статью об использовании ссылки для прямого входа.
В некоторых случаях рекомендуется использовать приглашение по электронной почте вместо прямой ссылки. Если эти особые случаи актуальны для организации, рекомендуем приглашать пользователей с отправкой приглашения по электронной почте.
- Иногда объект приглашенного пользователя не может использовать адрес электронной почты из-за конфликта с контактным объектом (например, контактным объектом Outlook). В этом случае пользователь должен выбрать URL-адрес активации в приглашении по электронной почте.
- Пользователь может выполнить вход с псевдонимом адреса электронной почты, по которому поступило приглашение (Псевдоним — это другой адрес электронной почты, связанный с учетной записью электронной почты.) В этом случае пользователь должен выбрать URL-адрес активации в приглашении по электронной почте.
Активация с помощью приглашения по электронной почте
Когда вы добавляете гостя в свой каталог с помощью портала Azure, в этом процессе ему отправляется электронное письмо с приглашением. Вы также можете отправить приглашения по электронной почте, когда используете PowerShell, чтобы добавить гостевых пользователей в каталог. Ниже приведено описание процесса активации ссылки гостем в сообщении электронной почты.
- Гость получает приглашение, отправленное Microsoft Invitations.
- Он выбирает пункт Принять приглашение в сообщении электронной почты.
- Гость будет использовать свои собственные учетные данные для входа в ваш каталог. Если у гостя нет учетной записи, которую можно включить в федерацию с вашим каталогом, и функция одноразового секретного кода электронной почты (OTP) не включена; гость предлагает создать личный MSA. Дополнительные сведения см. в разделе о потоке активации приглашения.
- Для работы с гостевыми системами используется процедура согласия, описанная ниже.
Ограничение на активацию при конфликтующем объекте Contact
Иногда приглашенный внешний гостевой пользователь может конфликтовать с существующим объектом Contact, в результате чего гостевой пользователь создается без ProxyAddress. Это известное ограничение, которое препятствует активации гостевыми пользователями приглашения через прямую ссылку с использованием учетных записей поставщика удостоверений SAML/WS-Fed, MSA, федерации Google или отправки одноразового секретного кода по электронной почте.
Но следующие сценарии должны продолжать работать:
- Активация приглашения через ссылку для активации приглашения по электронной почте с использованием учетных записей поставщика удостоверений SAML/WS-Fed, отправки одноразового секретного кода по электронной почте и федерации Google.
- Повторный вход в приложение после активации с использованием учетных записей поставщика удостоверений SAML/WS-Fed и федерации Google.
Чтобы разблокировать пользователей, которые не могут активировать приглашение из-за конфликтующего объекта Contact, сделайте следующее:
- Удалите конфликтующий объект Contact.
- Удалите гостевого пользователя на портале Azure (свойство "Приглашение принято" пользователя должно находиться в состоянии ожидания).
- Повторное приглашение гостевого пользователя.
- Дождитесь, пока пользователь активирует приглашение.
- Добавьте контактный электронный адрес пользователя обратно в Exchange и во все списки рассылки, куда он должен входить.
Поток активации приглашения
Когда пользователь нажимает ссылку Принять приглашение в сообщении электронной почты с приглашением, Azure AD автоматически активирует приглашение на основе потока активации, как показано ниже.
Azure AD выполняет обнаружение пользователей, чтобы определить, существует ли пользователь в управляемом арендаторе Azure AD. (Неуправляемые Azure AD учетные записи больше не могут использоваться для активации.) Если имя участника-пользователя совпадает как с существующей учетной записью Azure AD, так и с личной учетной записью MSA, пользователю предлагается выбрать учетную запись, которую он хочет использовать.
Если администратор включил федерацию поставщика удостоверений SAML/WS-Fed, Azure AD проверяет, соответствует ли суффикс домена пользователя домену настроенного поставщика удостоверений SAML/WS-Fed, и перенаправляет пользователя к предварительно настроенному поставщику удостоверений.
Если администратор включил федерацию Google, Azure AD проверяет, gmail.com ли суффикс домена пользователя, или googlemail.com, и перенаправляет пользователя в Google.
Процесс активации проверяет, есть ли у пользователя личный MSA. Если у пользователя уже есть существующая MSA, он будет входить в систему с ее помощью.
После идентификации домашнего каталога пользователя он перенаправляется соответствующему поставщику удостоверений для входа в систему.
Если домашний каталог не найден и функция отправки одноразового секретного кода по электронной почте включена для гостей, секретный код отправляется пользователю на адрес электронной почты приглашенного лица. Пользователь получает и вводит этот секретный код на странице входа в Azure AD.
Если домашний каталог не найден и функция отправки одноразового секретного кода по электронной почте отключена, пользователю будет предложено создать пользовательскую учетную запись MSA с использованием адреса электронной почты приглашенного лица. Мы поддерживаем создание MSA с рабочими письмами в доменах, которые не проверены в Azure AD.
После проверки подлинности на правильного поставщика удостоверений пользователь перенаправляется в Azure AD для завершения процедуры согласия.
Условия предоставления согласия для гостей
Когда гость впервые входит в партнерскую организацию для получения доступа к ресурсам, для него отображаются следующие страницы согласия. Эти страницы согласия отображаются для гостя только после входа, они не отображаются, если пользователь уже принял их.
Гость просматривает страницу Проверка разрешений с описанием заявления о конфиденциальности в приглашенной организации. Чтобы продолжить, пользователь должен принять условия использования своих данных в соответствии с политиками конфиденциальности приглашающей организации.
Примечание
Сведения о том, как администратор клиента может создать ссылку на заявление о конфиденциальности вашей организации, см. в разделе Практическое руководство. Добавление сведений о конфиденциальности организации в Azure Active Directory.
Если условия использования настроены, гостю необходимо открыть и изучить их, а затем нажать кнопку Принять.
Вы можете настроить условия использования в разделе Внешние удостоверения>Условия использования.
Если не указано иное, гость перенаправляется на панель доступа к приложениям, в которой перечислены приложения, доступные гостю.
В вашем каталоге значение для гостя Приглашение принято изменяется на Да. Если вы создали MSA, гостевой параметр Источник будет иметь значение Учетная запись Майкрософт. Дополнительные сведения о свойствах учетной записи гостевого пользователя см. в статье Свойства пользователя службы совместной работы Azure Active Directory B2B. Если отображается сообщение об ошибке, требующее согласия администратора при доступе к приложению, см. раздел о том, как предоставить согласие администратора для приложений.
Параметр автоматического активации
Важно!
Сейчас автоматическая активация доступна в предварительной версии. Юридические условия, применимые к функциям Azure, которые находятся в состоянии бета-версии, предварительной версии или иным образом еще не выпущены в общедоступной версии, см. на странице Дополнительные условия использования предварительных версий в Microsoft Azure.
Вы можете автоматически активировать приглашения, чтобы пользователям не нужно было принимать запрос согласия при добавлении в другой клиент для совместной работы B2B. После настройки пользователю службы совместной работы B2B отправляется уведомление по электронной почте, которое не требует никаких действий от пользователя. Пользователям отправляется уведомление по электронной почте напрямую, и им не нужно сначала обращаться к клиенту, прежде чем они получат сообщение электронной почты. Ниже показан пример уведомления по электронной почте, если вы автоматически активируете приглашения в обоих клиентах.
Сведения об автоматическом активации приглашений см. в разделах Общие сведения о межтенантном доступе и Настройка параметров доступа между арендаторами для совместной работы B2B.