Архитектура подготовки удостоверений локальных приложений Azure AD (предварительная версия)

Обзор

На нижеприведенной схеме показано, как работает подготовка локальных приложений.

Схема, на которой показана архитектура подготовки локальных приложений.

Подготовка пользователей к работе с локальным приложением состоит из трех основных компонентов.

  • Агент подготовки обеспечивает связь между Azure Active Directory (Azure AD) и вашей локальной средой.
  • Узел ECMA преобразует запросы на подготовку из Azure AD в запросы к целевому приложению. Он служит шлюзом между Azure AD и вашим приложением. С его помощью можно импортировать существующие соединители ECMA2, используемые с Microsoft Identity Manager. Если вы создали приложение SCIM или шлюз SCIM, то узел ECMA не требуется.
  • Служба подготовки Azure AD служит в качестве механизма синхронизации.

Примечание

Синхронизация Microsoft Identity Manager не требуется. Однако вы можете использовать ее для создания и тестирования соединителя ECMA перед его импортом на узел ECMA.

Требования к брандмауэру

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

Архитектура узла соединителя ECMA

Узел соединителя ECMA имеет несколько областей, которые он использует для локальной подготовки. Схема ниже представляет собой концептуальный рисунок с этими отдельными областями. В таблице ниже приводится более подробное описание каждой из них.

Узел соединителя ECMA

Область Описание
Конечные точки Отвечают за обмен данными и передачу данных с помощью службы подготовки Azure AD.
Кэш в памяти Используется для хранения данных, импортированных из локального источника данных.
Автосинхронизация Обеспечивает асинхронную синхронизацию данных между узлом соединителя ECMA и локальным источником данных.
Бизнес-логика Используется для координации всех действий узла соединителя ECMA. Время автосинхронизации можно настроить на узле ECMA. Это выполняется на странице свойств.

Сведения об атрибутах привязки и различающихся именах

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

Атрибут привязки является уникальным атрибутом типа объекта, который не изменяется, и представляет этот объект в кэше в памяти узла соединителя ECMA.

Различающееся имя (DN) — это имя, которое однозначно идентифицирует объект, указывая его текущее расположение в иерархии каталогов или, в случае SQL, в секции. Имя формируется путем добавления атрибута привязки к корню раздела каталога.

Различающиеся имена в традиционном формате, например для Active Directory или LDAP, обычно выглядят примерно так:

CN=Lola Jacobson,CN=Users,DC=contoso,DC=com

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

Это можно обеспечить путем установки флажка Создается автоматически при настройке соединителя genericSQL. Если выбрать автоматическое создание различающегося имени, узел ECMA сгенерирует это имя в формате LDAP: CN=<anchorvalue>,OBJECT=<type>. Это также предполагает, что флажок "Различающееся имя является привязкой" на странице "Подключение" будет снят.

Флажок DN is Anchor (DN является привязкой) снят

Соединитель genericSQL ожидает, что DN будет заполнено с использованием формата LDAP. Соединитель Generic SQL использует стиль LDAP с именем компонента "OBJECT=". Это позволяет применять секции (каждый тип объекта является секцией).

Поскольку узел соединителя ECMA сейчас поддерживает только тип объекта USER, OBJECT=<тип> будет OBJECT=USER. DN для пользователя, параметр anchorvalue которого равен ljacobson, будет выглядеть так:

CN=ljacobson,OBJECT=USER

Рабочий процесс создания пользователя

  1. Служба подготовки Azure AD отправляет узлу соединителя ECMA запрос, чтобы узнать, существует ли пользователь. Она использует в качестве фильтра атрибут сопоставления. Этот атрибут определен на портале Azure AD в разделе "Корпоративные приложения" –> On-premises provisioning (Локальная подготовка) –> Provisioning (Подготовка) –> Attribute matching (Сопоставление атрибутов). Он отмечается значением 1 для приоритета сопоставления. Можно определить один или несколько атрибутов сопоставления и задать для них приоритеты. Если вы хотите изменить атрибут сопоставления, такая возможность также предусмотрена. Атрибут сопоставления

  2. Узел соединителя ECMA получает запрос GET и выполняет запрос к внутреннему кэшу, чтобы узнать, существует ли и импортирован ли пользователь. Для этого используются сопоставляемые атрибуты, указанные выше. При определении нескольких сопоставляемых атрибутов служба подготовки Azure AD отправит запрос GET для каждого атрибута, а узел ECMA проверит свой кеш на соответствие, пока не найдет его.

  3. Если пользователь не существует, Azure AD выполнит запрос POST для создания пользователя. Узел соединителя ECMA ответит Azure AD сообщением HTTP 201 и предоставит идентификатор для пользователя. Этот идентификатор является производным от значения привязки, определенного на странице типов объектов. Эта привязка будет использоваться Azure AD для будущих и последующих запросов к узлу соединителя ECMA.

  4. Если изменятся данные пользователя в Azure AD, то Azure AD выполнит запрос GET для получения данных пользователя с помощью привязки из предыдущего шага, а не атрибута сопоставления на шаге 1. Это позволяет, например, изменить имя участника-пользователя, не нарушая связь между пользователем в Azure AD и в приложении.

Лучшие практики агента

  • Использование одного и того же агента для возможности локальной подготовки вместе с Workday / SuccessFactors / облачной синхронизацией Azure AD Connect в настоящее время не поддерживается. Мы активно работаем над поддержкой локальной подготовки на том же агенте, что и другие сценарии подготовки.
    • Избегайте любых форм встроенной проверки исходящей связи TLS между агентами и Azure. Этот тип встроенной проверки вызывает ухудшение коммуникационного потока.
  • Агент должен взаимодействовать как с Azure, так и с вашим приложением, поэтому размещение агента влияет на задержку этих двух подключений. Вы можете уменьшить задержку сквозного трафика, оптимизировав каждое из сетевых подключений. Каждое подключение можно оптимизировать следующим образом:
    • уменьшить расстояние между двумя конечными точками прыжка;
    • выбрать нужную сеть для прохода Например, проход по частной сети, а не через общедоступный Интернет, может выполняться быстрее ввиду выделенных каналов связи.

Вопросы по работе агента подготовки

Здесь вы найдете ответы на некоторые распространенные вопросы.

Как узнать версию моего агента подготовки?

  1. Войдите на сервер Windows, где установлен агент подготовки.
  2. Выберите Панель управления>Удаление или изменение программ.
  3. Найдите версию, соответствующую записи агента подготовки Microsoft Azure AD Connect.

Могу ли я установить агент подготовки на тот же сервер, на котором работает Azure AD Connect или Microsoft Identity Manager?

Да. Да, вы можете установить агент подготовки на том же сервере, на котором работает Azure AD Connect или Microsoft Identity Manager, но они не требуются.

Как настроить агент подготовки для использования прокси-сервера исходящих HTTP-подключений?

Агент подготовки поддерживает использование исходящего прокси-сервера. Его можно настроить, изменив файл конфигурации агента C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config. Добавьте следующие строки в конце файла непосредственно перед закрывающим тегом </configuration>. Замените переменные [proxy-server] и [proxy-port] значениями имени прокси-сервера и номера порта.

    <system.net>
        <defaultProxy enabled="true" useDefaultCredentials="true">
            <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
            />
        </defaultProxy>
    </system.net>

Как убедиться, что агент подготовки может взаимодействовать с клиентом Azure AD и никакие брандмауэры не блокируют порты, необходимые агенту?

Можно также проверить, открыты ли все необходимые порты.

Как удалить агент подготовки?

  1. Войдите на сервер Windows, где установлен агент подготовки.
  2. Выберите Панель управления>Удаление или изменение программ.
  3. Удалите следующие программы:
    • агент подготовки Microsoft Azure AD Connect;
    • Microsoft Azure AD Connect Agent Updater;
    • пакет агента подготовки Microsoft Azure AD Connect.

Журнал агента подготовки

В этой статье перечислены выпущенные версии и функции агента подготовки Azure Active Directory Connect. Команда разработчиков Azure AD регулярно добавляет в агент подготовки новые функции. Убедитесь, что вы не используете один и тот же агент для локальной подготовки и облачной синхронизации или подготовки на основе управления персоналом.

Корпорация Майкрософт предоставляет прямую поддержку для последней и предпоследней версий агента.

Вы можете скачать последнюю версию агента по этой ссылке.

1.1.892.0

20 мая 2022 г. — доступно для скачивания

Устраненные проблемы

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

1.1.846.0

11 апреля 2022 г.: выпущена версия для скачивания

Устраненные проблемы

  • Мы добавили поддержку ObjectGUID в качестве привязки для универсального соединителя LDAP при подготовке пользователей в AD LDS.

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