Предоставление пользователям B2B в Azure AD доступа к локальным приложениям

Теперь организации, использующие возможности совместной работы в Azure Active Directory (AAD) B2B для приглашения гостевых пользователей из партнерских организаций в AAD, могут предоставлять таким пользователям B2B доступ к локальным приложениям. В таких локальных приложениях нужно использовать проверку подлинности на основе SAML или встроенную проверку подлинности Windows (IWA) с ограниченным делегированием Kerberos (KCD).

Доступ к приложениям SAML

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

Необходимо выполнить следующие действия:

Когда вы завершите выполнение шагов выше, ваше приложение будет настроено и запущено. Чтобы проверить доступ к Azure AD B2B, выполните следующие действия:

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

Доступ к приложениям IWA и KCD

Чтобы предоставить пользователям B2B доступ к локальным приложениям, защищенным с помощью Встроенной проверки подлинности Windows и ограниченного делегирования Kerberos, требуются следующие компоненты:

  • Аутентификация через Azure Active Directory Application Proxy. Возможность аутентификации пользователей B2B в локальном приложении. Чтобы предоставить эту возможность, локальное приложение следует опубликовать через AD Application Proxy. Дополнительные сведения см. в статье Добавление локального приложения для удаленного доступа через Application Proxy.

  • Авторизация через объект пользователя B2B в локальном каталоге. Приложение должно иметь возможность проверять права пользователей и правильно предоставлять им доступ к ресурсам. Встроенная проверка подлинности Windows и ограниченное делегирование Kerberos требуют наличия объекта пользователя в локальном каталоге Active Directory на Windows Server. Как описано в разделе Принцип работы единого входа с применением KCD, прокси приложения использует этот объект пользователя для олицетворения пользователя и получения маркера Kerberos для приложения.

    Примечание

    При настройке Application Proxy в Azure AD убедитесь, что для удостоверения делегированного входа в конфигурации единого входа для Встроенной проверки подлинности Windows (IWA) задано имя участника-пользователя (по умолчанию).

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

    • Microsoft Identity Manager (MIM) и агент управления MIM для Microsoft Graph.
    • Скрипт PowerShell. Это решение проще в реализации и не требует наличия MIM.

Ниже представлена обобщенная схема совместной работы AD Application Proxy и создания объекта пользователя B2B в локальном каталоге для предоставления пользователям B2B доступа к локальным приложениям на основе IWA и KCD. Порядок шагов описан на схеме ниже.

Diagram of MIM and B2B script solutions

  1. В клиент Contoso приглашается пользователь из партнерской организации (из клиента Fabrikam).
  2. В клиенте Contoso создается объект гостевого пользователя (например, объект пользователя с именем участника-пользователя guest_fabrikam.com#EXT#@contoso.onmicrosoft.com).
  3. Гость Fabrikam импортируется из Contoso через MIM или с помощью скрипта B2B PowerShell.
  4. В локальном каталоге Contoso.com с помощью MIM или скрипта B2B PowerShell создается представление объекта гостевого пользователя Fabrikam (Guest#EXT#).
  5. Гостевой пользователь обращается к локальному приложению app.contoso.com.
  6. Запрос на аутентификацию подтверждается через прокси приложения с применением ограниченного делегирования Kerberos.
  7. Так как гостевой пользователь существует в локальной среде, аутентификация происходит успешно.

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

Вы можете управлять локальными объектами пользователей B2B с помощью политик управления жизненным циклом. Пример:

  • Вы можете настроить для гостевого пользователя политику многофакторной проверки подлинности (MFA), чтобы она обязательно использовалась при аутентификации через прокси приложений. Дополнительные сведения см. в статье Условный доступ пользователей в службе совместной работы B2B.
  • К локальным пользователям применяются любые правила спонсорства, проверки доступа, проверки учетных записей и пр., которые определены для облачного пользователя B2B. Например, если политика управления жизненным циклом удаляет облачного пользователя, соответствующий ему локальный пользователь также удаляется службой синхронизации MIM или AAD Connect. Дополнительные сведения см. в статье Управление гостевым доступом с помощью проверок доступа Azure AD.

Создание объектов гостевых пользователей B2B через MIM

Сведения о том, как с помощью пакета обновления 1 для MIM 2016 и агента управления MIM для Microsoft Graph создавать объекты гостевых пользователей в локальном каталоге, см. в статье Совместная работа Azure Active Directory B2B с Microsoft Identity Manager (MIM) 2016 с пакетом обновления 1 (SP1) и Azure Active Directory Application Proxy.

Рекомендации по лицензированию

Убедитесь, что вы правильно настроили клиентские лицензии (CAL) для внешних гостевых пользователей, которые обращаются к локальным приложениям. Дополнительные сведения см. в разделе "Лицензии External Connector" статьи Клиентские лицензии и лицензии на управление. Конкретные требования к лицензированию вы можете обсудить с представителем Microsoft или локальным торговым посредником.

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