 Изучение ценности мультитенантных организаций Microsoft 365

 microsoft 365, migration, мультитенантная организация, синхронизация учетных записей

НаписаноТони Редмонд

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

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

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

Основы мультитенантной организации

Во-первых, давайте подготовим почву, рассмотрев основы мультитенантной организации:

• Мультитенантная организация может включать до пяти арендаторов. Один из них является владельцем (главным или основным). Остальные арендаторы являются членами.
• В мультитенантной организации арендаторы синхронизируют выбранные пользовательские объекты (до 100 000) с другими арендаторами. У клиента есть отдельные конфигурации синхронизации для каждого из других клиентов в многоарендной организации.
• Синхронизация обрабатывает только пользовательские объекты. Все остальное игнорируется (группы Microsoft 365, группы безопасности, списки рассылки, почтовые контакты и т. д.).
• Механизм межклиентской синхронизации Entra ID обрабатывает обновления между арендаторами.
• Обновления, примененные к учетным записям пользователей в их домашних арендаторах, синхронизируются с другими арендаторами и перезаписывают любые изменения, внесенные в этих арендаторах. Например, если вы обновляете отображаемое имя для учетной записи пользователя, синхронизированной с другим клиентом, и этот клиент меняет исходную учетную запись, последующий цикл синхронизации перезаписывает отображаемое имя.

В двух словах, мультитенантная организация — это конструкция Microsoft 365, построенная на возможностях межклиентской синхронизации Entra ID для создания каталога известных пользовательских объектов.

Конфигурации мультитенантной организации

Вы можете управлять некоторыми аспектами синхронизации, используя конфигурацию, созданную мультитенантной организацией для клиента. Эти конфигурации доступны в разделе «Внешние удостоверения» центра администрирования Entra ID при межклиентской синхронизации. Например, вы можете изменить частоту синхронизации или обрабатываемые атрибуты, отредактировав конфигурацию целевого клиента. На рис. 1 показан набор атрибутов по умолчанию, обрабатываемых синхронизацией MTO.

Рисунок 1. Атрибуты, обрабатываемые в конфигурации межклиентской синхронизации.

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

Рисунок 2. Предоставление данных журнала для синхронизированной учетной записи пользователя.

Пользовательские объекты, синхронизированные в многопользовательских организациях

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

• Имеют имена основных пользователей, аналогичные гостевым учетным записям (например, Ben.James_Office365itpros.com#EXT#@o365maestro.onmicrosoft.com ), но являются учетными записями участников.
• Видны спискам адресов (в отличие от настройки по умолчанию для гостевых учетных записей) и поэтому отображаются в глобальном списке адресов Outlook. Объекты имеют действительный адрес электронной почты (в клиенте своего хоста) и могут быть адресованы для электронной почты. На рис. 3 показаны свойства учетной записи пользователя, просматриваемые через глобальный список адресов Outlook. Это та же учетная запись, которая указана в деталях журнала подготовки, показанных на рисунке 2.
• Учетные записи MTO включены, имеют сгенерированный системой пароль и альтернативный адрес электронной почты.
  

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

Учетные записи MTO не заблокированы от изменений. При желании вы можете обновить свойства учетной записи, но следует избегать свойств, участвующих в синхронизации. Например, арендатор хоста может обновить фотографию для учетной записи MTO (что я и сделал для учетной записи, показанной на рис. 3). Вы также можете назначать лицензии синхронизированным объектам пользователей и изменять их пароли. Фотографии пользователей, лицензии и пароли не включаются в сопоставление атрибутов синхронизации, поэтому они сохраняются в течение циклов синхронизации, исходящих от домашнего клиента.

Если вы обновите пароль учетной записи, вы сможете войти в синхронизированную учетную запись пользователя и использовать ее как обычно. Владельцы команд могут добавлять учетные записи MTO к членству в команде, и если вы затем войдете в систему с учетной записью MTO, имеющей лицензию на использование Teams, вы сможете использовать эту учетную запись для чата, участия в беседах по каналам и работы над общими документами в библиотеке документов команды. . Однако календарь учетной записи недоступен, поскольку Exchange Online пытается подключиться к календарю в почтовом ящике домашнего клиента. Viva Engage и Planner тоже не работают. Кроме того, вход в Teams с использованием исходной учетной записи для учетной записи MTO не позволит этой учетной записи взаимодействовать с командой, поскольку эта учетная запись не входит в число участников. Если вы хотите, чтобы в команде участвовал кто-то из другой организации, добавьте его в качестве гостевой учетной записи.
Я заметил, что процесс Teams Aad Sync добавляет учетные записи MTO, синхронизированные с другими арендаторами, в любые общеорганизационные команды , существующие в организации. Общеорганизационные группы поддерживаются только в организациях с менее чем 10 000 учетных записей. Добавление учетных записей MTO — это пример ошибки, которую, я уверен, Microsoft исправит до того, как многопользовательские организации станут общедоступными.

Все сводится к приложениям

Все это доказывает, что синхронизация учетных записей между арендаторами вполне возможна, но приложения Microsoft 365 должны понимать, как справляться с синхронизированными учетными записями. Новый клиент Teams 2.1 первым сделал этот шаг. В сообщении в блоге от 28 августа Microsoft объясняет, что клиент Teams 2.1 может определять, принадлежит ли внешняя учетная запись к общей мультитенантной организации (путем поиска в локальном каталоге, чтобы узнать, существует ли учетная запись участника для внешнего пользователя). Когда это происходит, Teams обеспечивает более широкое сотрудничество (например, общий доступ к файлам), поскольку по определению внешняя учетная запись существует благодаря взаимному доверию между двумя арендаторами.

Сравните ситуацию с обычными гостевыми учетными записями и внешним федеративным чатом. Если это не запрещено политикой сотрудничества Entra ID B2B , владельцы групп могут пригласить любого стать гостем. Эта учетная запись гостя сохраняется в принимающей организации, пока она не будет удалена. Здесь может помочь новая функция спонсорства для внешних учетных записей, но в большинстве случаев очистка гостевых учетных записей по-прежнему выполняется вручную, например поиск гостевых учетных записей с неиспользованными приглашениями , отчеты или удаление старых гостевых учетных записей. Дело в том, что помимо доверия, оказываемого гостевой учетной записи человеком, ее создавшим, рядовой пользователь не может воспринимать наличие гостевой учетной записи у своего арендатора как какой-либо показатель ее надежности.

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

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

Приложения являются ограничивающим фактором. Хорошо, что Teams лидируют, но теперь другим основным приложениям нужно выяснить, как они могут использовать учетные записи MTO. Например, Exchange Online может отказаться от внешней маркировки электронной почты из учетных записей MTO. Microsoft Information Protection может добавить специальное разрешение доступа для учетных записей MTO, чтобы эти учетные записи получали те же права, что и члены арендатора, на контент, защищенный метками конфиденциальности. Политики предотвращения потери данных (DLP) могут изменить свое определение того, когда контент передается за пределы клиента, чтобы учетные записи MTO считались внутренними, а не внешними. Информационные барьеры и политика соответствия коммуникациям также могут по-разному относиться к учетным записям MTO и так далее.

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

Вопрос миграции от арендатора к арендатору

Некоторые задавались вопросом, устраняют ли организации с несколькими арендаторами необходимость миграции между арендаторами (T2T) . Я так не думаю. По своей природе проекты T2T:

• Синхронизация каталогов охватывает гораздо больше, чем учетные записи пользователей: группы Microsoft 365, группы безопасности, списки рассылки, контакты (и, возможно, общие папки) и т. д. включаются в информацию, которой обмениваются арендаторы.
• Возможно участие более пяти арендаторов.
• Перемещайте учетные записи пользователей и другие объекты из одного клиента в другой, включая личные данные, такие как почтовые ящики, чаты Teams и учетные записи OneDrive для бизнеса.
• Перемещайте данные в общих репозиториях, таких как сайты SharePoint Online и Teams, из одного клиента в другой.
• Снимите защиту (метки конфиденциальности) с передаваемых данных.
• Можно передавать другую интеллектуальную собственность, например сценарии, программы и модули автоматизации.

Короче говоря, текущая предварительная версия многоарендной организации заботится об ограниченной синхронизации каталогов для небольшого набора арендаторов. Он не пытается взять на себя сложность, часто присущую проектам T2T. Я думаю, что организации с несколькими арендаторами представляют реальную ценность, особенно потому, что Microsoft создает функции приложений, которые используют преимущества надежности учетной записи, но это скорее игра синхронизации каталогов (например, классический инструмент GALsync), а не замена миграции T2T или даже кратчайший путь к миграции T2T.

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

Об Авторе