Поделиться через


Архитектура удостоверений для Azure Stack Hub

При выборе поставщика удостоверений для использования с Azure Stack Hub следует понимать важные различия между вариантами Microsoft Entra ID и служб федерации Active Directory (AD FS).

Возможности и ограничения

Поставщик удостоверений, которого вы выберете, может ограничить ваши возможности, включая поддержку мультитенантности.

Возможность или сценарий Microsoft Entra ID AD FS
Подключено к Интернету Да Необязательный
Поддержка мультитенантности Да Нет
Предлагать товары на Маркетплейсе Да Да (требуется использование автономного средства Syndication Marketplace)
Поддержка библиотеки проверки подлинности Active Directory (ADAL) Да Да
Поддержка таких средств, как Azure CLI, Visual Studio и PowerShell Да Да
Создание служебных принципалов в портале Azure Да Нет
Создайте служебных принципалов с сертификатами Да Да
Создание служебных принципов с секретами (ключами) Да Да
Приложения могут использовать службу Graph Да Нет
Приложения могут использовать поставщиков удостоверений для входа Да Да (требуется, чтобы приложения были федеративными с локальными экземплярами AD FS)
Управляемые идентичности Нет Нет

Топологии

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

Идентификатор Microsoft Entra: топология с одним клиентом

По умолчанию при установке Azure Stack Hub и использовании идентификатора Microsoft Entra Azure Stack Hub использует топологию одного клиента.

Топология с одним клиентом полезна при следующих случаях:

  • Все пользователи являются частью одного клиента.
  • Поставщик услуг размещает экземпляр Azure Stack Hub для организации.

одноарендаторная топология Azure Stack Hub с Microsoft Entra ID

Эта топология имеет следующие характеристики:

  • Azure Stack Hub регистрирует все приложения и службы в одном каталоге клиента Microsoft Entra.
  • Azure Stack Hub проверяет подлинность только пользователей и приложений из этого каталога, включая маркеры.
  • Учётные записи для администраторов (облачных операторов) и пользователей арендатора находятся в одном арендаторе каталога.
  • Чтобы пользователь из другого каталога мог получить доступ к этой среде Azure Stack Hub, необходимо пригласить пользователя в качестве гостевого в каталог клиента.

Идентификатор Microsoft Entra ID: многопользовательская топология

Облачные операторы могут настроить Azure Stack Hub, чтобы разрешить доступ к приложениям клиентам из одной или нескольких организаций. Пользователи получают доступ к приложениям с помощью пользовательского портала Azure Stack Hub. В этой конфигурации портал администрирования (используемый оператором облака) ограничен пользователями из одного каталога.

Топология с несколькими арендаторами полезна, когда:

  • Поставщик услуг хочет разрешить пользователям из нескольких организаций доступ к Azure Stack Hub.

многотенантная топология Azure Stack Hub с Microsoft Entra ID

Эта топология имеет следующие характеристики:

  • Доступ к ресурсам должен предоставляться для каждой организации.
  • Пользователям из одной организации не удается предоставить доступ к ресурсам пользователям, которые находятся за пределами своей организации.
  • Учетные записи для администраторов (облачных операторов) могут находиться в отдельном клиенте каталога от учетных записей для пользователей. Это разделение обеспечивает изоляцию учетных записей на уровне поставщика удостоверений.

AD FS

Топология AD FS требуется, если одно из следующих условий является истинным.

  • Azure Stack Hub не подключается к Интернету.
  • Azure Stack Hub может подключаться к Интернету, но вы выбираете использовать AD FS в качестве поставщика идентификации.

топология Azure Stack Hub с использованием AD FS

Эта топология имеет следующие характеристики:

  • Чтобы обеспечить поддержку использования этой топологии в рабочей среде, необходимо интегрировать встроенный экземпляр Azure Stack Hub AD FS с существующим экземпляром AD FS, поддерживаемым Active Directory, с помощью доверия федерации.

  • Вы можете интегрировать службу Graph в Azure Stack Hub с существующим экземпляром Active Directory. Вы также можете использовать службу API Graph на основе OData, которая поддерживает API, совместимые с API Azure AD Graph.

    Для взаимодействия с экземпляром Active Directory Graph API нуждаются в учетных данных пользователя с разрешением на чтение для вашего экземпляра Active Directory и соответствующим доступом.

    • Встроенный экземпляр AD FS.
    • Экземпляры AD FS и Active Directory, которые должны работать на Windows Server 2012 или более поздней версии.

    Между экземпляром Active Directory и встроенным экземпляром AD FS взаимодействие не ограничено OpenID Connect, и они могут использовать любой взаимно поддерживаемый протокол.

    • Учетные записи пользователей создаются и управляются в локальном экземпляре Active Directory.
    • Учетные записи служб и регистрации приложений управляются во встроенном экземпляре Active Directory.

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