Сценарии многотенантного управления пользователями

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

• Введение в многотенантное управление пользователями является первым в серии статей, которые предоставляют рекомендации по настройке и управлению жизненным циклом пользователей в мультитенантных средах Microsoft Entra.
• Общие рекомендации по управлению мультитенантными пользователями содержат рекомендации по следующим вопросам: синхронизация между клиентами, объект каталога, условный доступ Microsoft Entra, дополнительный контроль доступа и Office 365.
• Распространенные решения для мультитенантного управления пользователями, если единый клиент не работает для вашего сценария, в этой статье приводятся рекомендации по этим проблемам: автоматическое управление жизненным циклом пользователей и распределение ресурсов между клиентами, совместное использование локальных приложений между клиентами.

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

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

• Инициированный пользователем
• Скрипты
• Автоматизированный

Сценарий, инициированный пользователем

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

Например, глобальная фирма профессиональных услуг сотрудничает с субподрядчиками по проектам. Субподрядчики (внешние пользователи) требуют доступа к приложениям и документам фирмы. Администраторы фирмы могут делегировать своим конечным пользователям возможность приглашать субподрядчиков или настраивать самообслуживание для доступа к ресурсам субподрядчика.

Учетные записи подготовки

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

• Приглашения на основе приложений. Приложения Майкрософт (например, Teams и SharePoint) могут включать приглашения внешних пользователей. Настройте параметры приглашения B2B как в Microsoft Entra B2B, так и в соответствующих приложениях.
• MyApps. Пользователи могут приглашать и назначать внешних пользователей приложениям с помощью MyApps. В учетной записи пользователя должны быть разрешения утверждающего для самостоятельной регистрации приложений. Владельцы групп могут приглашать внешних пользователей в свои группы.
• Управление правами. Разрешить администраторам или владельцам ресурсов создавать пакеты доступа с ресурсами, разрешенными внешними организациями, истечением срока действия внешних пользователей и политиками доступа. Опубликуйте пакеты доступа, чтобы включить самостоятельную регистрацию внешних пользователей для доступа к ресурсам.
• портал Azure. Конечные пользователи с ролью гостевого приглашения могут войти в портал Azure и пригласить внешних пользователей из меню "Пользователи" в идентификаторе Microsoft Entra.
• Программное (PowerShell, API Graph). Конечные пользователи с ролью гостевого пригласителя могут использовать PowerShell или API Graph для приглашения внешних пользователей.

Активация приглашений

При подготовке учетных записей для доступа к ресурсу приглашения по электронной почте отправляются по адресу электронной почты приглашенного пользователя.

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

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

• У приглашенного пользователя уже есть идентификатор Microsoft Entra или учетная запись Майкрософт или учетная запись Майкрософт.
• Администраторы включили одноразовые секретные коды электронной почты.

Во время активации JIT могут применяться следующие рекомендации.

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

Дополнительные сведения см. в статье Microsoft Entra B2B для активации приглашения на совместную работу.

Включение однократной проверки подлинности секретного кода

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

• Идентификатор Microsoft Entra.
• Учетную запись Майкрософт.
• Учетная запись Gmail через Google Federation.
• Учетная запись из языка разметки утверждений безопасности (SAML)/WS-Fed IDP через прямую федерацию.

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

Управление организациями

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

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

• HiddenFromAddressListsEnabled [ShowInAddressList]
• FirstName [GivenName]
• Фамилия [SurName]
• Заголовок
• Отдел
• Номер телефона

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

По умолчанию gal скрывает приглашенных внешних пользователей. Задайте атрибуты внешних пользователей, чтобы включить их в единую глобальную запись. В разделе "Общие рекомендации по управлению мультитенантными пользователями" в разделе Microsoft Exchange Online описывается, как можно уменьшить ограничения, создавая внешних пользователей-участников вместо внешних гостевых пользователей.

Отмена подготовки учетных записей

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

При приглашении пользователей за пределами управления правами необходимо создать отдельный процесс для просмотра и управления доступом. Например, если вы напрямую пригласите внешнего пользователя через SharePoint в Microsoft 365, он не входит в процесс управления правами.

Сценарий по скрипту

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

Например, компания приобретает конкурента. У каждой компании есть один клиент Microsoft Entra. Они хотят, чтобы следующие сценарии первого дня работали без необходимости выполнять какие-либо действия по приглашению или активации. Все пользователи должны иметь возможность:

• Используйте единый вход ко всем подготовленным ресурсам.
• Найдите друг друга и ресурсы в единой глобальной сети.
• Определите присутствие друг друга и инициируйте чат.
• Доступ к приложениям на основе динамических групп членства.

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

Учетные записи подготовки

С помощью Delta Query администраторы клиентов могут развернуть скриптовый процесс извлечения для автоматизации обнаружения и подготовки удостоверений для поддержки доступа к ресурсам. Этот процесс проверяет домашний клиент для новых пользователей. В нем используются API Graph B2B для подготовки новых пользователей в качестве внешних пользователей в клиенте ресурсов, как показано на следующей многотенантной схеме топологии.

Заголовок схемы многотенантной топологии. Слева поле с меткой "Компания A" содержит внутренних пользователей и внешних пользователей. Справа поле с меткой "Компания B" содержит внутренних пользователей и внешних пользователей. Между компанией A и Company B взаимодействие переходит от компании A к компании B с меткой, скрипт для извлечения пользователей в B. Другое взаимодействие происходит из компании B в компанию A с меткой, скрипт для извлечения пользователей B в A.

• Администраторы клиента предварительно упорядочены учетные данные и согласие на чтение каждого клиента.
• Администраторы клиентов автоматизируют перечисление и извлекает пользователей с областью действия в клиент ресурсов.
• Используйте API Microsoft Graph с разрешениями на чтение и подготовку пользователей с помощью API приглашения.
• Начальная подготовка может считывать исходные атрибуты и применять их к целевому объекту пользователя.

Управление организациями

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

Отмена подготовки учетных записей

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

Если вы приглашаете пользователей за пределами управления правами, создайте отдельный процесс для просмотра и управления доступом внешних пользователей. Например, если вы пригласите внешнего пользователя непосредственно через SharePoint в Microsoft 365, он не входит в процесс управления правами.

Автоматизированный сценарий

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

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

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

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

В расширенном межоблачном сценарии подрядчик оборонной промышленной базы (DIB) имеет дочернюю компанию на основе обороны и коммерческой компании. Их нормативные требования вступают в противоречие:

• Бизнес обороны США находится в клиенте национального облака США, например Microsoft 365 US Government GCC High и Azure для государственных организаций.
• Коммерческий бизнес находится в отдельном клиенте Microsoft Entra в коммерческой организации, например в среде Microsoft Entra, работающей в глобальном облаке Azure.

Чтобы действовать как одна компания, развернутая в межоблачной архитектуре, все пользователи синхронизируются с обоими клиентами. Этот подход обеспечивает единую доступность GAL для обоих клиентов и может обеспечить автоматическую синхронизацию пользователей с обоими клиентами, включая права и ограничения приложений и содержимого. Ниже приведены примеры требований:

• Сотрудники США могут иметь вездесущий доступ к обоим клиентам.
• Сотрудники, отличные от США, отображаются в единой системе GAL обоих клиентов, но не имеют доступа к защищенному содержимому в клиенте GCC High.

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

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

Учетные записи подготовки

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

Метод 1. Использование встроенной возможности синхронизации между клиентами в идентификаторе Microsoft Entra

Этот подход работает только в том случае, если все клиенты, которые необходимо синхронизировать, находятся в одном и том же облачном экземпляре (например, коммерческой и коммерческой).

Метод 2. Подготовка учетных записей с помощью Microsoft Identity Manager

Используйте внешнее решение управления удостоверениями и доступом (IAM), например Microsoft Identity Manager (MIM) в качестве подсистемы синхронизации.

Это расширенное развертывание использует MIM в качестве подсистемы синхронизации. MIM вызывает API Microsoft Graph и Exchange Online PowerShell. Альтернативные реализации могут включать управляемую облачную службу синхронизации Active Directory (ADSS) из microsoft Industry Solutions. Существуют предложения, отличные от Майкрософт, которые можно создавать с нуля с другими предложениями IAM (например, SailPoint, Omada и OKTA).

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

Заголовок схемы: синхронизация удостоверений облака в облако. Слева поле с меткой "Компания A" содержит внутренних пользователей и внешних пользователей. Справа поле с меткой "Компания B" содержит внутренних пользователей и внешних пользователей. Между компанией A и Company B взаимодействие подсистем синхронизации переходит от компании A к компании B и от компании B к компании A.

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

Метод 3. Подготовка учетных записей с помощью Microsoft Entra Connect

Этот метод применяется только для сложных организаций, которые управляют всеми удостоверениями в традиционных службах домен Active Directory windows Server (AD DS). Этот подход использует Microsoft Entra Connect в качестве обработчика синхронизации, как показано на следующей схеме.

Название схемы: подготовка учетных записей с помощью Microsoft Entra Connect. На схеме показаны четыре основных компонента. Поле слева представляет клиента. Справа облачная фигура представляет преобразование B2B. В верхнем центре поле, содержащее облачную фигуру, представляет коммерческое облако Майкрософт. В нижнем центре поле, содержащее облачную фигуру, представляет microsoft US Government Sovereign Cloud. В поле "Клиент" значок Windows Server Active Directory подключается к двум полям, каждый из которых содержит метку Microsoft Entra Connect. Подключения дефисируются красными линиями со стрелками в обоих концах и значком обновления. Внутри фигуры Коммерческого облака Майкрософт — это другая облачная форма, представляющая коммерческую службу Microsoft Azure. Внутри — другая облачная фигура, представляющая идентификатор Microsoft Entra. Справа от формы коммерческого облака Microsoft Azure является поле, представляющее Office 365 с меткой общедоступной мультитенантной. Сплошная красная линия со стрелками в обоих концах подключает поле Office 365 с фигурой коммерческого облака Microsoft Azure и меткой гибридных рабочих нагрузок. Две дефишированные линии подключаются из поля Office 365 к облачной фигуре Microsoft Entra. Один имеет стрелку в конце, который подключается к идентификатору Microsoft Entra. Другой имеет стрелки на обоих концах. Тиреная линия со стрелками на обоих концах подключает облачную фигуру Microsoft Entra к верхней строке Microsoft Entra Connect. Тиреная линия со стрелками на обоих концах подключает фигуру Microsoft Commercial Cloud к облачной форме преобразования B2B. В поле "Microsoft US Government Sovereign Cloud" находится другая облачная форма, представляющая microsoft Azure для государственных организаций. Внутри — другая облачная фигура, представляющая идентификатор Microsoft Entra. Справа от формы коммерческого облака Microsoft Azure является поле, представляющее Office 365 с меткой, US Gov GCC-High L4. Сплошная красная линия со стрелками в обоих концах подключает поле Office 365 с фигурой облака Microsoft Azure для государственных организаций и меткой гибридных рабочих нагрузок. Две дефишированные линии подключаются из поля Office 365 к облачной фигуре Microsoft Entra. Один имеет стрелку в конце, который подключается к идентификатору Microsoft Entra. Другой имеет стрелки на обоих концах. Тиреная линия со стрелками на обоих концах подключает облачную фигуру Microsoft Entra к нижнему краю Microsoft Entra Connect. Тиреная линия со стрелками на обоих концах подключает фигуру Microsoft Commercial Cloud к облачной форме преобразования B2B.

В отличие от метода MIM, все источники удостоверений (пользователи, контакты и группы) приходят из традиционных служб домен Active Directory Windows Server (AD DS). Каталог AD DS обычно является локальным развертыванием для сложной организации, которая управляет удостоверением для нескольких клиентов. Удостоверений, доступных только для облака, не распространяется на этот метод. Все удостоверения должны находиться в AD DS, чтобы включить их в область синхронизации.

Концептуально этот метод синхронизирует пользователя с домашним клиентом в качестве внутреннего пользователя (поведение по умолчанию). Кроме того, он может синхронизировать пользователя с клиентом ресурсов как внешний пользователь (настраиваемое поведение).

Корпорация Майкрософт поддерживает этот метод двойной синхронизации с тщательным вниманием к изменениям конфигурации Microsoft Entra Connect. Например, если вы вносите изменения в конфигурацию настройки на основе мастера, необходимо задокументировать изменения, если необходимо перестроить конфигурацию во время инцидента поддержки.

Вне поля Microsoft Entra Connect не может синхронизировать внешнего пользователя. Его необходимо расширить с помощью внешнего процесса (например, скрипта PowerShell), чтобы преобразовать пользователей из внутренних в внешние учетные записи.

Преимущества этого метода включают синхронизацию удостоверения Microsoft Entra Connect с атрибутами, хранящимися в AD DS. Синхронизация может включать атрибуты адресной книги, атрибуты диспетчера, членство в группах и другие атрибуты гибридного удостоверения во всех клиентах в пределах области. Он отменяет идентификацию в соответствии с AD DS. Для управления облачным удостоверением для этой конкретной задачи не требуется более сложное решение IAM.

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

Выбор правильной топологии

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

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

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

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

Фактор	Топология сетки	Один арендатор ресурсов
Каждая компания имеет отдельный клиент Microsoft Entra с пользователями и ресурсами	Да	Да
Расположение ресурсов и совместная работа
Общие приложения и другие ресурсы остаются в текущем домашнем арендаторе	Да	№ Вы можете предоставлять общий доступ только к приложениям и другим ресурсам в клиенте ресурсов. Вы не можете предоставлять общий доступ к приложениям и другим ресурсам, оставшимся в других клиентах.
Все доступные для просмотра в gals отдельных компаний (unified GAL)	Да	Нет
Доступ к ресурсам и их администрирование
Вы можете совместно использовать все приложения, подключенные к идентификатору Microsoft Entra, среди всех компаний.	Да	№ Совместно используются только приложения в клиенте ресурсов. Вы не можете совместно использовать приложения, оставшиеся в других клиентах.
Глобальное администрирование ресурсов	Продолжайте работу на уровне клиента.	Консолидировано в клиенте ресурсов.
Лицензирование: Office 365 SharePoint в Microsoft 365, унифицированный GAL, Teams обращается ко всем гостям поддержки; Однако другие сценарии Exchange Online не делают.	Продолжается на уровне клиента.	Продолжается на уровне клиента.
Лицензирование: Идентификатор Microsoft Entra (премиум)	Первые 50 тыс. активных пользователей за месяц — бесплатно (на арендатора).	Первые 50 тыс. активных пользователей за месяц — бесплатно.
Лицензирование: программное обеспечение как услуга (SaaS)	Остаться в отдельных клиентах могут потребоваться лицензии для каждого пользователя на каждого клиента.	Все общие ресурсы находятся в одном арендаторе ресурсов. В случае необходимости можно исследовать консолидацию лицензий для одного арендатора.

Топология сетки

На следующей схеме показана топология сетки.

Заголовок схемы: топология сетки. В левом верхнем углу поле с меткой "Компания A" содержит внутренних пользователей и внешних пользователей. В правом верхнем углу поле "Компания B" содержит внутренних пользователей и внешних пользователей. В левом нижнем углу поле с меткой "Компания C" содержит внутренних пользователей и внешних пользователей. В правом нижнем углу поле с меткой "Компания D" содержит внутренних пользователей и внешних пользователей. Между компанией A и Company B и между Company C и Company D взаимодействие подсистем синхронизации происходит между компаниями слева и компаниями справа.

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

• Вы можете предоставить общий доступ к любому ресурсу в клиенте внешним пользователям.
• Каждая организация может видеть всех пользователей в конгломерате. На приведенной выше схеме существует четыре объединенных общедоступных url-адресов, каждый из которых содержит домашних пользователей и внешних пользователей из других трех клиентов.

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

Топология сетки для межоблачной топологии

Топологию сетки можно использовать как только в двух клиентах, таких как в сценарии для оборонного подрядчика DIB, привязанного к кросс-суверенному облачному решению. Как и в топологии сетки, каждый пользователь в каждом домашнем клиенте синхронизируется с другим клиентом, который становится клиентом ресурсов. На схеме раздела "Метод 3" внутренний пользователь общедоступного коммерческого клиента синхронизируется с национальным клиентом GCC High в США в качестве внешней учетной записи пользователя. В то же время внутренний пользователь GCC High синхронизируется с коммерческой как внешней учетной записью пользователя.

На схеме также показаны расположения хранилища данных. Классификация и соответствие данным находятся вне области этой статьи, но вы можете включить права и ограничения для приложений и содержимого. Содержимое может включать расположения, в которых находятся данные внутреннего пользователя (например, данные, хранящиеся в почтовом ящике Exchange Online или OneDrive). Содержимое может находиться в домашнем клиенте, а не в клиенте ресурсов. Общие данные могут находиться в любом арендаторе. Доступ к содержимому можно ограничить с помощью политик управления доступом и условного доступа.

Топология одного арендатора ресурсов

На следующей схеме показана топология одного клиента ресурсов.

Название схемы: топология одного клиента ресурса. В верхней части окна, представляющего компанию A, содержит три поля. Слева поле представляет все общие ресурсы. В середине поле представляет внутренних пользователей. Справа поле представляет внешних пользователей. Под полем "Компания A" находится поле, представляющее подсистему синхронизации. Три стрелки подключают подсистему синхронизации к компании A. Под полем подсистемы синхронизации в нижней части схемы находятся три поля, представляющие компанию B, Company C и Company D. Стрелка подключает каждую из них к окне подсистемы синхронизации. В каждом нижнем поле компании находится метка, API Microsoft Graph Exchange Online PowerShell и значки, представляющие внутренних пользователей.

В топологии одного клиента ресурсов пользователи и их атрибуты синхронизируются с клиентом ресурсов (Компания A на приведенной выше схеме).

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

Управление организациями

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

Отмена подготовки учетных записей

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

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

Следующие шаги

• Введение в многотенантное управление пользователями является первым в серии статей, которые предоставляют рекомендации по настройке и управлению жизненным циклом пользователей в мультитенантных средах Microsoft Entra.
• Общие рекомендации по управлению мультитенантными пользователями содержат рекомендации по следующим вопросам: синхронизация между клиентами, объект каталога, условный доступ Microsoft Entra, дополнительный контроль доступа и Office 365.
• Распространенные решения для мультитенантного управления пользователями, если единый клиент не работает для вашего сценария, в этой статье приводятся рекомендации по этим проблемам: автоматическое управление жизненным циклом пользователей и распределение ресурсов между клиентами, совместное использование локальных приложений между клиентами.