Предоставление пользователям 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. Порядок шагов описан на схеме ниже.

Схема решений сценариев MIM и B2B.

  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 или Azure AD B2B. Дополнительные сведения см. в статье Управление гостевым доступом с помощью проверок доступа Azure AD.

Создание объектов гостевых пользователей B2B с помощью скрипта Azure AD B2B

Пример скрипта Azure AD B2B можно использовать для создания теневых учетных записей Azure AD, синхронизированных из учетных записей Azure AD B2B. Затем можно использовать теневые учетные записи для локальных приложений, использующих ограниченное делегирование Kerberos.

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

Вы можете использовать MIM 2016 с пакетом обновления 1 (SP1) и агент управления MIM для Microsoft Graph для создания объектов гостевых пользователей в локальном каталоге. Дополнительные сведения см. в статье Azure AD совместной работы B2B с Microsoft Identity Manager (MIM) 2016 с пакетом обновления 1 (SP1) с приложение Azure прокси-сервером.

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

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

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