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


Общие рекомендации по управлению мультитенантными пользователями

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

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

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

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

  • Синхронизация клиентов
  • Объект каталога
  • Условный доступ Microsoft Entra
  • Дополнительное управление доступом
  • Office 365

Синхронизация клиентов

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

Вариант использования Синхронизация между клиентами Настраиваемая разработка
Управление жизненным циклом пользователей Check mark icon Check mark icon
Доступ к файлам и доступ к приложениям Check mark icon Check mark icon
Поддержка синхронизации с и из национальных облаков Check mark icon
Управление синхронизацией из клиента ресурсов Check mark icon
Объекты группы синхронизации Check mark icon
Ссылки диспетчера синхронизации Check mark icon Check mark icon
Источник уровня атрибутов центра Check mark icon
Запись Microsoft Entra обратно в Microsoft Windows Server Active Directory Check mark icon

Рекомендации по работе с объектом каталога

Приглашение внешнего пользователя с использованием имени участника-пользователя и SMTP-адреса

Microsoft Entra B2B ожидает, что имя пользователя UserPrincipalName (UPN) является основным адресом протокола SMTP (EMAIL) для отправки приглашений. Если имя участника-пользователя совпадает с основным SMTP-адресом, B2B работает должным образом. Однако если имя участника-пользователя отличается от основного SMTP-адреса внешнего пользователя, возможно, не удается устранить, когда пользователь принимает приглашение, что может быть проблемой, если вы не знаете реального имени участника-пользователя. При отправке приглашений для B2B необходимо обнаружить и использовать имя участника-участника-участника.

В разделе Microsoft Exchange Online этой статьи объясняется, как изменить основной SMTP по умолчанию для внешних пользователей. Этот метод полезен, если вы хотите, чтобы все сообщения электронной почты и уведомления для внешнего потока поступают на реальный основной SMTP-адрес, а не имя участника-участника-участника. Это может быть требованием, если имя участника-пользователя не может маршрутизировать поток обработки почты.

Преобразование пользовательского типа внешнего пользователя

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

При преобразовании внешнего гостевого пользователя в учетную запись внешнего участника могут возникнуть проблемы с тем, как Exchange Online обрабатывает учетные записи B2B. Учетные записи, приглашенные в качестве внешних пользователей-участников, нельзя включить по почте. Чтобы включить учетную запись внешнего члена, используйте следующий оптимальный подход.

  • Пригласите пользователей между организациями в качестве внешних учетных записей гостевых пользователей.
  • Отобразите учетные записи в глобальном списке адресов.
  • Задайте для типа пользователя значение "Член".

При использовании этого подхода учетные записи отображаются как объекты MailUser в Exchange Online и в Office 365. Кроме того, обратите внимание, что существует проблема с временем. Убедитесь, что пользователь отображается в gal, проверка как свойство Microsoft Entra user ShowInAddressList соответствует свойству Exchange Online PowerShell HiddenFromAddressListsEnabledd (которые являются обратными друг от друга). В разделе Microsoft Exchange Online этой статьи содержатся дополнительные сведения об изменении видимости.

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

Проблемы с использованием объектов почтового контакта вместо внешних пользователей или членов

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

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

Примечание.

Для использования почтовых контактов требуется служба Active Directory (AD DS) или Exchange Online PowerShell. Microsoft Graph не предоставляет вызов API для управления контактами.

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

Существующее состояние Сценарий подготовки Фактический результат
нет Приглашение члена B2B Пользователь,не поддерживающий почту. См. важное примечание выше.
нет Приглашение гостя B2B Внешний пользователь с поддержкой почты.
Объект контакта почты существует Приглашение члена B2B Ошибка. Конфликт адресов прокси-сервера.
Объект контакта почты существует Приглашение гостя B2B Внешний пользователь с поддержкой "Почта" и "Не по почте". См. важное примечание выше.
Внешний гостевой пользователь с поддержкой почты Создание объекта контакта электронной почты Ошибка
Внешний пользователь с поддержкой почты существует Создание почтового контакта Ошибка

Корпорация Майкрософт рекомендует использовать совместную работу Microsoft Entra B2B (вместо традиционной синхронизации GAL) для создания:

  • Внешние пользователи, которые позволяют отображаться в gal.
  • Внешние пользователи-члены, которые отображаются в gal по умолчанию, но не включены по почте.

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

Выполните этот рекомендуемый подход для достижения цели:

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

  • Группы Office 365. Политики поддержки групп Office 365, определяющие типы пользователей, которым разрешено быть членами групп и взаимодействовать с содержимым, связанным с группами. Например, группа может не разрешить гостевым пользователям присоединиться. Эти политики не могут управлять объектами контактов почты.
  • Управление группами самообслуживания (SSGM) Microsoft Entra. Объекты контактов почты не могут быть участниками в группах с помощью функции SSGM. Вам может потребоваться больше средств для управления группами с получателями, представленными как контакты вместо объектов пользователей.
  • Управление идентификацией Microsoft Entra, проверки доступа. Вы можете использовать функцию проверки доступа для проверки и проверки членства в группе Office 365. Проверки доступа основаны на объектах пользователей. Элементы, представленные объектами контактов почты, не область для проверки доступа.
  • Управление идентификацией Microsoft Entra, управление правами (EM). При использовании EM для включения запросов на самостоятельный доступ для внешних пользователей на портале EM компании он создает объект пользователя во время запроса. Он не поддерживает объекты почтового контакта.

Рекомендации по условному доступу Microsoft Entra

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

Если разрешено, это поведение можно переопределить с помощью межтенантного доступа Параметры (CTAS), которые учитывают многофакторную проверку подлинности и соответствие устройств домашнему клиенту.

  • Требовать многофакторную проверку подлинности. Без настройки CTAS внешний пользователь должен зарегистрировать и ответить на многофакторную проверку подлинности в клиенте ресурсов (даже если многофакторная проверка подлинности была удовлетворена в домашнем клиенте), что приводит к нескольким проблемам многофакторной проверки подлинности. Если они должны сбросить свои многофакторные проверки подлинности, они могут не знать о нескольких многофакторных регистрации проверки подлинности в клиентах. При недостаточной осведомленности пользователю нужно будет связаться с администратором домашнего арендатора или арендатора ресурсов (или же с двумя администраторами).
  • Требовать, чтобы устройство было отмечено как соответствующее. Без настройки CTAS удостоверение устройства не зарегистрировано в клиенте ресурсов, поэтому внешний пользователь не может получить доступ к ресурсам, которым требуется этот элемент управления.
  • Требуется гибридное устройство, присоединенное к Microsoft Entra. Без настройки CTAS удостоверение устройства не регистрируется в клиенте ресурсов (или локальная служба Active Directory подключено к клиенту ресурсов), поэтому внешний пользователь не может получить доступ к ресурсам, которым требуется этот элемент управления.
  • Требовать утвержденное клиентское приложение или требовать политику защиты приложений. Без настройки CTAS внешние пользователи не могут применить политику управления мобильными приложениями Intune (MAM), так как для нее также требуется регистрация устройства. Политика условного доступа клиента ресурсов с помощью этого элемента управления не позволяет домашнему клиенту MAM защититься от политики. Исключите внешних пользователей из каждой политики условного доступа на основе MAM.

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

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

Защита мультитенантной среды

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

Условный доступ

Ниже приведены рекомендации по настройке управления доступом.

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

Мониторинг мультитенантной среды

  • Отслеживайте изменения политик доступа между клиентами с помощью пользовательского интерфейса журналов аудита, API или интеграции Azure Monitor (для упреждающих оповещений). События аудита используют категории CrossTenantAccess Параметры и CrossTenantIdentitySync Параметры. Отслеживая события аудита в этих категориях, вы можете определить любые изменения политики доступа между клиентами в клиенте и принять меры. При создании оповещений в Azure Monitor можно создать запрос, например следующий, чтобы определить любые изменения политики доступа между клиентами.
AuditLogs
| where Category contains "CrossTenant"
  • Мониторинг доступа к приложениям в клиенте с помощью панели мониторинга действий доступа между клиентами. Это позволяет узнать, кто обращается к ресурсам в клиенте и откуда приходят эти пользователи.

Динамические группы

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

Требовать назначение пользователей для приложений

Если у приложения требуется назначение пользователя? Свойство No, внешние пользователи могут получить доступ к приложению. Администраторы приложений должны понимать влияние управления доступом, особенно если приложение содержит конфиденциальную информацию. Ограничьте приложение Microsoft Entra набором пользователей в клиенте Microsoft Entra объясняет, как зарегистрированные приложения в клиенте Microsoft Entra по умолчанию доступны всем пользователям клиента, успешно прошедшим проверку подлинности.

Управление привилегированными пользователями

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

Единицы управления с ограниченным доступом

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

Другие рекомендации по управлению доступом

Условия

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

Рекомендации по лицензированию гостевых пользователей с помощью функций Microsoft Entra ID P1 или P2

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

Рекомендации по Office 365

Следующая информация относится к Office 365 в контексте сценариев этого документа. Подробные сведения доступны в Microsoft 365 межтенантной совместной работы 365, описывающие параметры, включающие использование центрального расположения для файлов и бесед, совместного использования календарей, обмена мгновенными сообщениями, аудио-и видеозвонков для обмена данными и защиты доступа к ресурсам и приложениям.

Microsoft Exchange Online

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

  • Вы можете назначить лицензию Exchange Online внешнему пользователю. Однако вы не можете выдавать маркер для Exchange Online. Результаты — это то, что они не могут получить доступ к ресурсу.
    • Внешние пользователи не могут использовать общие или делегированные почтовые ящики Exchange Online в клиенте ресурсов.
    • Внешний пользователь можно назначить общему почтовому ящику, но он не может получить к нему доступ.
  • Чтобы включить их в gal, необходимо развернуть внешних пользователей. По умолчанию они скрыты.
    • Скрытые внешние пользователи создаются во время приглашения. Создание не зависит от того, активировал ли пользователь свое приглашение. Таким образом, если все внешние пользователи не используются, список включает объекты пользователей внешних пользователей, которые не активировали приглашение. В зависимости от вашего сценария, вы можете или не хотите, чтобы перечисленные объекты.
    • Внешние пользователи могут быть незахвачены с помощью Exchange Online PowerShell. Можно выполнить командлет Set-MailUser PowerShell, чтобы задать для свойства HiddenFromAddressListsEnabled значение $false.

Например:

Set-MailUser [ExternalUserUPN] -HiddenFromAddressListsEnabled:\$false\

Где ExternalUserUPN — вычисляемое имя UserPrincipalName.

Например:

Set-MailUser externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -HiddenFromAddressListsEnabled:\$false

Внешние пользователи могут быть незахвачены в Центр администрирования Microsoft 365.

  • Обновления можно задать только для свойств Exchange (например, PrimarySmtpAddress, ExternalEmailAddress, EmailAddresses и MailTip) с помощью Exchange Online PowerShell. Центр Администратор Exchange Online не позволяет изменять атрибуты с помощью графического пользовательского интерфейса (GUI).

Как показано выше, вы можете использовать командлет PowerShell Set-MailUser для свойств, связанных с почтой. Существуют свойства пользователя, которые можно изменить с помощью командлета Set-User PowerShell. Вы можете изменить большинство свойств с помощью API Azure AD Graph.

Одним из наиболее полезных функций Set-MailUser является возможность управления свойством EmailAddresses . Этот многозначный атрибут может содержать несколько прокси-адресов для внешнего пользователя (например, SMTP, X500, протокола SIP). По умолчанию внешний пользователь имеет первичный SMTP-адрес, коррелируя с userPrincipalName (UPN). Если вы хотите изменить основной SMTP-адрес или добавить SMTP-адреса, можно задать это свойство. Вы не можете использовать Центр exchange Администратор; необходимо использовать Exchange Online PowerShell. Добавление или удаление адресов электронной почты для почтового ящика в Exchange Online показывает различные способы изменения многозначного свойства, например EmailAddresses.

Microsoft SharePoint в Microsoft 365

SharePoint в Microsoft 365 имеет собственные разрешения для конкретной службы в зависимости от того, является ли пользователь (внутренний или внешний) членом или гостем в клиенте Microsoft Entra. Внешний общий доступ Office 365 и совместная работа Microsoft Entra B2B описывает, как включить интеграцию с SharePoint и OneDrive для совместного использования файлов, папок, элементов списка, библиотек документов и сайтов с людьми за пределами организации, а также с помощью Azure B2B для проверки подлинности и управления.

После включения внешнего общего доступа в SharePoint в Microsoft 365 возможность поиска гостевых пользователей в SharePoint в средство выбора пользователей Microsoft 365 по умолчанию отключена. Этот параметр запрещает обнаружение гостевых пользователей, если они скрыты в глобальном списке адресов Exchange Online. Вы можете сделать гостевых пользователей видимыми двумя способами (не взаимоисключающими):

  • Вы можете включить возможность поиска гостевых пользователей следующим образом:
  • Гостевые пользователи, видимые в коллекции GAL Exchange Online, также отображаются в sharePoint в средство выбора пользователей Microsoft 365. Учетные записи видны независимо от параметра Show Люди PickerSuggestionsForGuestUsers.

Microsoft Teams

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

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

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

Рекомендации по лицензированию для гостевых пользователей в Teams

При использовании Azure B2B с рабочими нагрузками Office 365 ключевые аспекты включают экземпляры, в которых гостевые пользователи (внутренние или внешние) не имеют того же опыта, что и пользователи-члены.

  • Группы Майкрософт.Добавление гостей в группы Office 365 описывает, как гостевой доступ в Группы Microsoft 365 позволяет вам и вашей команде сотрудничать с людьми за пределами организации, предоставляя им доступ к групповым беседам, файлам, приглашениям календаря и записной книжке группы.
  • Microsoft Teams.Владелец группы, член и гостевые возможности в Teams описывают возможности гостевой учетной записи в Microsoft Teams . Вы можете включить полный интерфейс точности в Teams с помощью внешних пользователей-участников.
    • Для нескольких клиентов в нашем коммерческом облаке пользователи, лицензированные в своем домашнем клиенте, могут получить доступ к ресурсам в другом клиенте в пределах одного юридического лица. Вы можете предоставить доступ с помощью параметра внешних участников без дополнительных сборов за лицензирование. Этот параметр применяется для SharePoint, OneDrive для бизнеса, Teams и групп.
    • Для нескольких клиентов в других облаках Майкрософт и для нескольких клиентов в разных облаках проверка лицензия участника B2B еще не доступна. Использование участника B2B с Teams требует дополнительной лицензии для каждого участника B2B. Это также может повлиять на другие рабочие нагрузки, такие как Power BI.
    • Использование участника B2B для клиентов, не входящих в ту же юридическую сущность, распространяется на дополнительные требования к лицензии.
  • Функции управления удостоверениями. Для управления правами и проверки доступа могут потребоваться другие лицензии для внешних пользователей.
  • Другие продукты. Для таких продуктов, как управление отношениями с клиентами Dynamics (CRM), может потребоваться лицензирование в каждом клиенте, в котором представлен пользователь.

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

  • Введение в многотенантное управление пользователями является первым в серии статей, которые предоставляют рекомендации по настройке и управлению жизненным циклом пользователей в мультитенантных средах Microsoft Entra.
  • Многотенантные сценарии управления пользователями описывают три сценария, для которых можно использовать мультитенантные функции управления пользователями: инициированные пользователем, скрипты и автоматизированные.
  • Распространенные решения для мультитенантного управления пользователями, если единый клиент не работает для вашего сценария, в этой статье приводятся рекомендации по этим проблемам: автоматическое управление жизненным циклом пользователей и распределение ресурсов между клиентами, совместное использование локальных приложений между клиентами.
  • Microsoft Collaboration Framework для промышленной базы обороны США описывает эталонные архитектуры для идентификации для размещения мультитенантных организаций (MTO) и, в частности, тех, которые имеют развертывание в американском национальном облаке с Microsoft 365 US Government (GCC High) и Azure для государственных организаций. Он также обращается к внешней совместной работе в строго регулируемых средах, включая организации, которые размещаются в коммерческой или в американском национальном облаке.