Варианты инфраструктуры параллельной и объединенной идентификационной структуры

Корпорация Майкрософт предоставляет ряд технологий и решений для интеграции между различными локальными и облачными компонентами инфраструктуры удостоверений. Часто клиенты неясны, какие технологии наиболее правы и могут неправильно думать, что "последний выпуск охватывает все сценарии предыдущих технологических выпусков".

В этой статье рассматриваются ситуации, когда ваша компания сталкивается со сложным процессом, описанным ниже, и стремится объединить информацию об идентификации. В идеале организация с одним источником кадров, одним лесом Active Directory и одним клиентом Microsoft Entra, все интегрированные с теми же людьми в каждом из них, будут иметь лучший интерфейс идентификации для своих веб-служб Microsoft Online Services. Однако на практике корпоративный клиент может не всегда находиться в ситуации, когда это возможно. Например, клиент может пройти слияние или иметь потребность в изоляции для некоторых пользователей или приложений. Клиент, имеющий несколько HR-систем, несколько AD или несколько клиентов Microsoft Entra, должен решить, следует ли объединить их в меньшее количество экземпляров или сохранить их в параллельном режиме.

На основе наших отзывов клиентов ниже приведены некоторые распространенные сценарии и требования.

Сценарии, которые возникают для многооблачных и многоорганизационных удостоверений

• Слияние и приобретение (M&A) — относится к ситуации, когда, как правило, компания A покупает компанию B.
• Rebranding — изменение имени компании или фирменной символики и обычно изменение доменного имени электронной почты.
• Microsoft Entra ID или консолидация арендаторов Office 365, Компании с несколькими арендаторами Office 365 могут захотеть объединить их из-за требований соответствия или исторических причин.
• Консолидация домена или леса Active Directory — компании, рассматривающие возможность выполнения консолидации домена или леса Active Directory.
• Дивституры — где подразделение или бизнес-группа компании продается или становится независимым.
• Конфиденциальность сведений о пользователях — где компании должны обеспечивать сохранение определенных данных (атрибутов) в скрытом от общественности виде, и только делегированные группы или пользователи, имеющие право, могут читать, изменять и обновлять их.

Требования, которые связаны с этими сценариями

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

Сценарии, не описанные в этой статье

• Частичное слияние и поглощение. Например, организация покупает часть другой организации.
• Дивестиция или разделение организаций
• Переименование организаций.
• Совместные предприятия или временные партнеры

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

Варианты консолидации для гипотетического сценария M&A

В следующих разделах рассматриваются четыре основных сценария для гипотетического сценария M&A:

Предположим, Contoso является корпоративным клиентом, а их IT имеет одну (локальную) систему кадров, один лес Active Directory, один клиент Microsoft Entra ID для своих приложений, которые работают как ожидается. Пользователи перенаправляются из системы управления персоналом в Active Directory, затем проецируются в Microsoft Entra ID и оттуда — в приложения SaaS. Этот сценарий показан на приведенной ниже схеме, где стрелки указывают на поток информации об идентификационных данных. Та же модель применима и к клиентам с облачной системой управления персоналом, такой как Workday или SuccessFactors, которые управляют Active Directory, а не только к клиентам, использующим Microsoft Identity Manager (MIM).

Затем компания Contoso начала сливаться с Litware, которая ранее управляла своим собственным ИТ самостоятельно. ИТ-отдел Contoso будет заниматься процессом слияния и ожидает, что приложения Contoso останутся без изменений. Однако они хотят, чтобы пользователи Litware могли получать доступ к этим приложениям и сотрудничать в них. Для приложений Майкрософт, сторонних приложений SaaS и пользовательских приложений конечным состоянием должно быть то, что пользователи Contoso и Litware концептуально имеют доступ к тем же данным.

Первое решение ит-специалистов заключается в том, сколько они хотят объединить инфраструктуру. Они могли бы не полагаться на идентификационную инфраструктуру Litware. Или они могли бы рассмотреть возможность использования инфраструктуры Litware и со временем интегрироваться, минимизируя нарушения в среде Litware. В некоторых случаях клиент может сохранить существующую инфраструктуру удостоверений Litware независимой от нее, а не конвергентировать ее, а также использовать ее для предоставления сотрудникам Litware доступа к приложениям Contoso.

Если клиент решит сохранить некоторые или все компоненты инфраструктуры удостоверений Litware, то существуют компромиссы в том, насколько используется Active Directory Domain Services Litware или Microsoft Entra ID для предоставления пользователям Litware доступа к ресурсам Contoso. В этом разделе рассматриваются доступные варианты на основе того, что Компания Contoso будет использовать для пользователей Litware:

• Сценарий A. Не используйте никакую часть инфраструктуры удостоверений Litware.
• Сценарий B - Использование лесов Active Directory компании Litware, но не Microsoft Entra ID (если он у них есть)
• Сценарий C. Используйте идентификатор Microsoft Entra в Litware.
• Сценарий D - Используйте инфраструктуру удостоверений Litware, не связанную с Microsoft (если Litware не использует Active Directory / Microsoft Entra ID)

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

Соображения	A1: один HR, один IAM и арендатор.	A2: отдельная кадровая служба, единый IAM и арендатор	B3: доверие леса Active Directory, один Microsoft Entra Connect	B4: Microsoft Entra подключите их Active Directory к одному арендатору	B5: Microsoft Entra Connect синхронизирует их облачную Active Directory	C6: параллельное обеспечение нескольких арендаторов в приложениях	C7: чтение данных из их аренды и приглашение пользователей B2B	C8: отдельные пользователи IAM и B2B по мере необходимости	D9: DF с их поставщиком удостоверений, отличным от Azure AD
Усилия по миграции	Высоко	Среднее усилие	Меньшие усилия	Низкий уровень сложности	Низкий уровень сложности	Отсутствует	Отсутствует	Отсутствует	Отсутствует
Усилия по развертыванию	Меньше усилий	Среднее усилие	Среднее усилие	Среднее усилие	Низкий уровень	Низкий уровень	Высоко	Высоко	Очень высокий
Влияние конечных пользователей во время миграции	Высоко	Высоко	Средний	Средний	Средний	Отсутствует	Отсутствует	Отсутствует	Отсутствует
Операционные усилия	Низкая стоимость	Низкая стоимость	Низкая стоимость	Низкая стоимость	Низкая стоимость	Высоко	Высоко	Высоко	Очень высокий
Возможности конфиденциальности и данных (границы географического расположения и данных)	Нет (серьезная преграда для сценариев геолокации)	Ограниченная изоляция, хотя и сложная	Ограниченная изоляция локально, но не в облаке	Ограниченная изоляция локально, но не в облаке	Ограниченная изоляция локально, но не в облаке	Хорошая изоляция как в локальной среде, так и в облаке	Ограниченная изоляция как в локальной среде, так и в облаке	Ограниченная изоляция как в локальной среде, так и в облаке	Изоляция как в локальной среде, так и в облаке
Изоляция (раздельное делегирование и настройка различных моделей управления) Примечание: как определено в исходной системе (HR)	Невозможно	Возможно	Возможно	Возможно	Возможно	Высокая вероятность	Высокая вероятность	Высокая вероятность	Возможно
Возможности совместной работы	Отлично	Отлично	Отлично	Отлично	Отлично	Плохо	Среднее значение	Среднее значение	Плохо
Поддерживаемая МОДЕЛЬ ИТ-администратора (централизованная и разделенная)	Централизовано	Централизовано	Централизовано	Централизовано	Централизовано	Децентрализовано	Децентрализовано	Децентрализовано	Активно децентрализованный
Ограничения	Отсутствие изоляции	Ограниченная изоляция	Ограниченная изоляция	Ограниченная изоляция	Ограниченная изоляция. Нет возможностей обратной записи	Не будет работать для приложений Microsoft Online Services. Высокая зависимость от возможностей приложения	Требуется, чтобы приложения были осведомлены о B2B	Требуется, чтобы приложения были осведомлены о B2B	Требовать, чтобы приложения учитывали особенности B2B. Неопределенность в том, как все это работает вместе

Детали таблицы

• Сотрудник пытается предсказать необходимый опыт и дополнительную работу, необходимые для реализации решения в организации.
• Деятельность по эксплуатации пытается спрогнозировать затраты и усилия, необходимые для поддержания работы решения.
• Возможности конфиденциальности и данных показывают, разрешает ли решение поддержку географических расположений и границ данных.
• Изоляция показывает, предоставляет ли это решение возможность разделения или делегирования моделей администрирования.
• Возможности совместной работы показывают уровень совместной работы, поддерживаемый решением, а более интегрированные решения предоставляют более высокую точность командной работы.
• Модель ИТ-администратора показывает, требуется ли централизованная или может быть децентрализована модель администрирования.
• Ограничения: любые проблемы, которые стоит перечислить.

Дерево решений

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

Остальная часть этого документа описывает четыре сценария A-D с различными вариантами, поддерживающими их.

Сценарий A. Если компания Contoso не хочет полагаться на существующую инфраструктуру удостоверений Litware

Для этого параметра у Litware может не быть систем идентификации личности (например, как у небольших компаний), или клиент может захотеть отключить инфраструктуру Litware. Или они хотят оставить его нетронутой, для использования сотрудниками Litware для проверки подлинности в приложениях Litware, но предоставить сотрудникам Litware новые удостоверения в рамках Contoso. Например, если Алиса Смит была сотрудником Litware, она может иметь два удостоверения - Alice@litware.com и ASmith123@contoso.com. Эти идентичности будут полностью отличаться друг от друга.

Вариант 1. Объединение в единую систему управления персоналом

Как правило, клиенты включают сотрудников Litware в систему управления персоналом Contoso. Этот параметр активирует этих сотрудников для получения учетных записей и правильного доступа к каталогам и приложениям Contoso. Затем пользователь Litware будет иметь новое удостоверение Contoso, которое можно использовать, чтобы запросить доступ к правильным приложениям Contoso.

Вариант 2. Сохранение системы управления персоналом Litware

Иногда конвергентные системы кадров могут быть недоступны, по крайней мере, не в краткосрочной перспективе. Вместо этого клиент подключит свою систему предоставления, например MIM, для чтения из обеих систем управления персоналом. В этой диаграмме верхняя часть представляет собой существующую инфраструктуру Contoso, а вторая часть — это добавление Litware к общей инфраструктуре.

Этот же сценарий также можно было бы использовать с помощью входящего трафика Microsoft Entra Workday или SuccessFactors. Компания Contoso может привести пользователей из источника кадров Litware Workday вместе с существующими сотрудниками Contoso.

Результаты консолидации всей инфраструктуры удостоверений

• Сокращена ИТ-инфраструктура, только одна система удостоверений для управления, нет требований к сетевому подключению, кроме системы управления персоналом.
• Согласованный интерфейс пользователя и администрирования

Ограничения консолидации всей инфраструктуры удостоверений

• Все данные, необходимые сотрудникам Contoso и происходящие из Litware, нужно перенести в среду Contoso.
• Все интегрированные приложения Active Directory или Microsoft Entra из Litware, необходимые для Contoso, должны быть перенастроены в среду Contoso. Эта перенастройка может потребовать изменений в конфигурации, в используемых для доступа группах или, возможно, в самих приложениях.

Сценарий B. Если компания Contoso хочет сохранить леса Active Directory Litware, но не использовать Microsoft Entra ID Litware.

Litware может иметь множество существующих приложений на основе Active Directory, на которые они полагаются, и поэтому Contoso может пожелать, чтобы сотрудники Litware сохраняли свои идентификации в своей существующей AD. Затем сотрудник Litware будет использовать существующее удостоверение для проверки подлинности существующих ресурсов и проверки подлинности ресурсов Contoso. В этом сценарии у Litware нет облачных удостоверений в Microsoft Online Services — либо Litware не являлся клиентом Microsoft Entra, облачные ресурсы Litware не были предоставлены для совместного использования с Contoso, или Contoso перенесла облачные ресурсы Litware, чтобы они стали частью арендатора Contoso.

Вариант 3. Лесной траст с приобретенным лесом

Используя доверительную связь между лесами Active Directory, Contoso и Litware могут подключать свои домены Active Directory. Это доверие позволяет пользователям Litware проходить проверку подлинности интегрированных с Active Directory приложений Contoso. Microsoft Entra Connect может получать данные из леса Active Directory Litware, чтобы пользователи Litware проходили аутентификацию в интегрированных приложениях Microsoft Entra от Contoso. Для этой топологии развертывания требуется сетевой маршрут между двумя доменами и подключением к сети TCP/IP между любым пользователем Litware и приложением, интегрированным с Contoso Active Directory. Кроме того, легко настроить двунаправленное доверие, чтобы пользователи Contoso могли получать доступ к приложениям, интегрированным с Litware AD (при наличии).

Результат настройки доверия к лесу

• Все сотрудники Litware могут проверять подлинность интегрированных приложений Contoso Active Directory или Microsoft Entra, а компания Contoso может использовать текущие средства на основе AD для управления авторизацией.

Ограничения создания доверия в лесу

• Требуется подключение TCP/IP между пользователями, присоединенными к одному лесу, и ресурсами, присоединенными к другому лесу.
• Требуется, чтобы приложения на основе Active Directory в лесу Contoso поддерживали работу в нескольких лесах.

Вариант 4. Настройка Microsoft Entra Connect к полученному лесу без доверия к лесу

Клиент также может настроить Microsoft Entra Connect для чтения из другого леса. Эта конфигурация позволяет пользователям Litware проходить проверку подлинности в интегрированных приложениях Microsoft Entra Contoso, но не предоставляет доступ к интегрированным приложениям Contoso Active Directory пользователю Litware. Эти приложения Contoso не распознают пользователей Litware. Для этой топологии развертывания требуется сетевое подключение TCP/IP между контроллерами домена Microsoft Entra Connect и Litware. Например, если Microsoft Entra Connect находится на виртуальной машине Contoso IaaS, необходимо также установить туннель в сеть Litware.

Результат использования Microsoft Entra Connect для подготовки одного клиента

• Все сотрудники Litware могут аутентифицироваться в интегрированных приложениях Microsoft Entra компании Contoso.

Ограничения использования Microsoft Entra Connect для подготовки одного клиента

• Требуется подключение TCP/IP между Microsoft Entra Connect компании Contoso и доменами Active Directory компании Litware.
• Не позволяет пользователям Litware иметь доступ к приложениям на основе Active Directory Компании Contoso

Вариант 5. Развертывание облачной синхронизации Microsoft Entra Connect в приобретенном лесу

Облачное предоставление Microsoft Entra Connect устраняет необходимость в подключении к сети, но вы можете связать только один Active Directory с Microsoft Entra ID для конкретного пользователя при облачной синхронизации. Пользователи Litware могут аутентифицироваться в интегрированных с Microsoft Entra приложениях Contoso, но не в приложениях, интегрированных с Active Directory Contoso. Эта топология не требует подключения TCP/IP между Litware и локальными средами Contoso.

Результат развертывания Microsoft Entra Connect для облачной синхронизации во вновь приобретённом лесу

• Все сотрудники Litware могут аутентифицироваться в интегрированных приложениях Microsoft Entra компании Contoso.

Ограничения использования облачной синхронизации Microsoft Entra Connect в приобретенном лесу

• Не позволяет пользователям Litware получать доступ к приложениям Contoso на основе Active Directory.

Сценарий C. Если Contoso хочет сохранить Microsoft Entra ID компании Litware

Litware может быть клиентом Microsoft Online Services или Azure или иметь одно или несколько приложений на основе Microsoft Entra ID, на которые они полагаются. Таким образом, компания Contoso может пожелать, чтобы сотрудники Litware продолжали использовать свои личные учетные данные для доступа к этим ресурсам. Затем сотрудник Litware будет использовать существующее удостоверение для проверки подлинности существующих ресурсов и проверки подлинности ресурсов Contoso.

Этот сценарий подходит в тех случаях, когда:

• Litware имеет обширные инвестиции в Azure или Microsoft Online Services, включая несколько тенантов Office 365, миграция которых в другой тенант будет дорогостоящей или требующей много времени.
• Litware может быть выделенной в будущем или же является партнёрством, которое будет работать независимо.
• Litware не имеет локальной инфраструктуры

Вариант 6. Поддержание параллельного предоставления и SSO для приложений в каждом каталоге Microsoft Entra ID

Один из вариантов — предоставить каждому идентификатору Microsoft Entra возможность независимо обеспечивать единый вход и подключать пользователей из своего каталога к целевому приложению. Например, если ИТ-отдел Contoso использует такое приложение, как Salesforce, он предоставит Litware права администратора для создания пользователей в той же подписке Salesforce.

Результат параллельной подготовки

• Пользователи могут проходить проверку подлинности приложений с помощью существующего удостоверения, не изменяя инфраструктуру Contoso.

Ограничения параллельной подготовки

• При использовании федерации требуется, чтобы приложения поддерживали несколько поставщиков федерации для одной подписки.
• Невозможно для приложений Майкрософт, таких как Office или Azure
• Contoso не имеет видимости в идентификаторе Microsoft Entra для доступа к приложениям для пользователей Litware

Вариант 7. Настройка учетных записей B2B для пользователей из приобретенного клиента

Если у Litware есть собственный арендатор, Contoso может получать данные о пользователях из этого арендатора и, используя B2B API, приглашать каждого из этих пользователей в арендатор Contoso. (Этот процесс массового приглашения можно выполнить, например, через соединитель графа MIM.) Если компания Contoso также имеет приложения на основе AD, которые они хотят сделать доступными для пользователей Litware, то MIM может создавать учетные записи пользователей в Active Directory, которые будут сопоставляться с UPN участников Microsoft Entra, чтобы прокси-сервер приложения мог выполнять KCD от имени отображения пользователя Litware в Active Directory компании Contoso.

Затем, когда сотрудник Litware хочет получить доступ к приложению Contoso, он может сделать это, выполнив проверку подлинности в собственном каталоге с назначением доступа к клиенту ресурсов.

Результат настройки учетных записей B2B для пользователей из другого клиента

• Пользователи Litware могут проходить проверку подлинности приложений Contoso, и Contoso управляет этим доступом в своем клиенте.

Ограничения настройки учетных записей B2B для пользователей из другого клиента

• Для каждого пользователя Litware, которому требуется доступ к ресурсам Contoso, требуется дубликат учетной записи.
• Требуется, чтобы приложения были способны поддерживать B2B для единого входа.

Вариант 8. Настройка B2B с общим каналом данных HR для обоих каталогов

В некоторых ситуациях после приобретения организация может перейти на единую платформу управления персоналом, но по-прежнему использовать существующие системы управления идентификацией. В этом сценарии MIM может проводить предоставление пользователей в несколько систем Active Directory в зависимости от того, к какой части организации относится пользователь. Они могут продолжать использовать B2B, чтобы пользователи прошли проверку подлинности существующего каталога и имеют унифицированный GAL.

Результат настройки гостевых пользователей B2B из общего источника данных системы управления персоналом

• Пользователи Litware могут проходить проверку подлинности в приложениях Contoso и управлять доступом в клиенте.
• Litware и Contoso имеют единый GAL.
• Никаких изменений в Active Directory или Microsoft Entra ID в компании Litware.

Ограничения на создание гостевых пользователей B2B из общего источника данных HR-системы

• Требуются изменения в процессе предоставления ресурсов компании Contoso, чтобы также направлять пользователей в Active Directory компании Litware, а также для обеспечения подключения между доменами компаний Litware и Contoso.
• Требуется, чтобы приложения были способны поддерживать B2B для единого входа.

Сценарий D. Если Litware использует инфраструктуру, отличной от Active Directory

Наконец, если Litware использует другую службу каталогов, локальную или в облаке, ИТ-специалисты Contoso по-прежнему могут настроить проверку подлинности сотрудников Litware и получить доступ к ресурсам Contoso с помощью существующего удостоверения.

Вариант 9. Использование прямой федерации B2B (общедоступная предварительная версия)

В этом сценарии предполагается, что Litware имеет следующее:

• Некоторые существующие каталоги, такие как OpenLDAP или даже база данных SQL или неструктурированный файл пользователей с их адресами электронной почты, которые они могут регулярно предоставлять компании Contoso.
• Поставщик удостоверений, поддерживающий SAML, например PingFederate или OKTA.
• Общедоступный DNS-домен, такой как Litware.com, и пользователи с адресами электронной почты в этом домене.

В этом подходе компания Contoso настраивает прямую федерацию от своего клиента к поставщику удостоверений Litware, а затем регулярно считывает обновления пользователей Litware из их каталога, чтобы пригласить пользователей Litware в Microsoft Entra ID Contoso. Это обновление можно выполнить с помощью соединителя MIM Graph. Если у компании Contoso также есть приложения на основе Active Directory, которые они хотят сделать доступными для пользователей Litware, MIM может создать пользователей в Active Directory, которые будут сопоставляться с UPN пользователей Microsoft Entra, чтобы прокси-сервер приложения мог выполнять KCD от имени пользователя Litware в Active Directory Contoso.

Результат использования прямой федерации B2B

• Пользователи Litware проходят аутентификацию в Microsoft Entra ID от Contoso с помощью своего существующего поставщика удостоверений и получают доступ к облачным и локальным веб-приложениям Contoso.

Ограничения использования прямой федерации B2B

• Требовать, чтобы приложения Contoso могли обеспечивать поддержку единого входа для пользователей B2B.

Дальнейшие шаги

• Что такое облачная синхронизация Microsoft Entra Connect
• Настройка входящего предоставления ресурсов для Microsoft Entra ID
• Настройка прямой федерации B2B
• Параметры управления пользователями в многопользовательской системе
• Что такое подготовка приложений?