Планирование, проектирование и реализация microsoft Entra Подключение

Завершено

Microsoft Entra Подключение — это решение, которое связывает организации локальная служба Active Directory с идентификатором Microsoft Entra на основе облака. ИТ-специалисты могут синхронизировать удостоверения из локальной среды в Azure и обеспечивать согласованность удостоверений между двумя платформами. Это подключение обеспечивает такие службы, как синхронизация хэша паролей, сквозная проверка подлинности и простой единый вход.

Microsoft Entra Подключение — это средство Майкрософт, предназначенное для удовлетворения и достижения целей гибридной идентификации. Он предоставляет следующие возможности:

• Синхронизация. Отвечает за создание пользователей, групп и других объектов. Обеспечивается согласованность сведений о пользователях и группах в локальной среде и в облаке. Эта синхронизация также включает хэши паролей.
• Синхронизация хэша паролей — метод входа, который синхронизирует хэш локального пароля AD пользователя с идентификатором Microsoft Entra.
• Сквозная проверка подлинности — это метод входа, который позволяет пользователям использовать один и тот же пароль локально и в облаке, при этом не требует дополнительной инфраструктуры для федеративной среды.
• Интеграция федерации — федерация является необязательной частью Microsoft Entra Подключение и может использоваться для настройки гибридной среды с помощью локальной инфраструктуры AD FS. Федерация также предоставляет возможности управления AD FS, такие как обновление сертификата и дополнительные развертывания сервера AD FS.
• Мониторинг работоспособности. Microsoft Entra Подключение-Health обеспечивает надежный мониторинг.

Зачем использовать Подключение Microsoft Entra?

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

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

Удостоверение — это новый уровень управления ИТ-безопасности, поэтому проверка подлинности является инструментом защиты доступа организации к новому облачному миру. Организации должны определить плоскость управления удостоверениями, которая повышает безопасность и защищает облачные приложения от несанкционированного доступа. Когда решение гибридного удостоверения Microsoft Entra является новым уровнем управления, проверка подлинности является основой доступа к облаку. Выбор правильного метода проверки подлинности является важным первым решением при настройке решения гибридного удостоверения Microsoft Entra. Чтобы выбрать метод аутентификации, необходимо учитывать время, имеющуюся инфраструктуру, сложность и стоимость реализации решения. Эти факторы отличаются для каждой организации и могут изменяться с течением времени.

Облачная аутентификация

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

Синхронизация хэша паролей Microsoft Entra (PHS). Самый простой способ включить проверку подлинности для локальных объектов каталога в Microsoft Entra. Пользователи могут использовать те же имя пользователя и пароль, которые они вводят в локальной среде, без необходимости развертывать дополнительную инфраструктуру.

• Трудозатраты. Синхронизация хэша паролей требует минимальных трудозатрат для развертывания, обслуживания и обеспечения инфраструктуры. Этот уровень усилий обычно применяется к организациям, которым требуются только их пользователи для входа в Microsoft 365, приложения SaaS и другие ресурсы на основе идентификаторов Майкрософт. При включении синхронизация хэша паролей входит в процесс синхронизации Microsoft Entra Подключение и выполняется каждые две минуты.
• Взаимодействие с пользователем. Чтобы повысить удобство входа пользователей, разверните простой единый вход с синхронизацией хэша паролей. Простой единый вход исключает ненужные запросы, если пользователи вошли в систему.
• Сложные сценарии. Если организации решили использовать аналитические сведения из удостоверений с отчетами Microsoft Entra Identity Protection с помощью Microsoft Entra ID Premium P2. Например, в отчете об утечке учетных данных. Windows Hello для бизнеса включает в себя особые требования при использовании синхронизации хэша паролей. Доменные службы Microsoft Entra требуют синхронизации хэша паролей для создания пользователей с корпоративными учетными данными в управляемом домене.
• Непрерывность бизнес-процессов. Использование синхронизации хэша паролей с облачной аутентификацией обеспечивает высокий уровень доступности в качестве облачной службы, которая охватывает все центры обработки данных Майкрософт. Чтобы убедиться, что синхронизация хэша паролей не завершается в течение длительных периодов, разверните второй сервер Microsoft Entra Подключение в промежуточном режиме в резервной конфигурации.
• Рекомендации. В настоящее время синхронизация хэша паролей не обеспечивает немедленное изменение состояния локальных учетных записей. В этой ситуации пользователь имеет доступ к облачным приложениям, пока состояние учетной записи пользователя не будет синхронизировано с идентификатором Microsoft Entra. Если организации могут преодолеть это ограничение, активируя новый цикл синхронизации после того, как администраторы выполнят массовые процедуры обновления состояния локальных учетных записей пользователей. Примером может быть отключение учетных записей.

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

• Трудозатраты. Для сквозной аутентификации требуется один или несколько (рекомендуется три) упрощенных агентов, установленных на серверах. Эти агенты должны иметь доступ к вашим локальным доменным службам Active Directory, включая локальные контроллеры домена AD. Им необходим исходящий доступ к Интернету и доступ к контроллерам домена. По этой причине не поддерживается развертывание агентов в сети периметра.
• Взаимодействие с пользователем. Чтобы повысить удобство входа пользователей, разверните простой единый вход со сквозной аутентификацией. Простой единый вход исключает ненужные запросы, если пользователи уже вошли в систему.
• Сложные сценарии. Сквозная аутентификация принудительно применяет политику локальных учетных записей во время входа. Например, доступ запрещается при заблокированной или отключенной локальной учетной записи, а также после истечения срока действия пароля. Доступ также может быть запрещен, если попытка входа выполняется за пределами допустимого диапазона времени для конкретного пользователя.
• Непрерывность бизнес-процессов. Рекомендуется развернуть два дополнительных агента сквозной аутентификации. Эти дополнительные компоненты в дополнение к первому агенту на сервере Microsoft Entra Подключение. Такое развертывание обеспечивает высокий уровень доступности запросов на проверку подлинности. Если развернуты три агента, один агент все еще может выйти из строя, если другой агент отключен для обслуживания.
• Рекомендации. Синхронизацию хэша паролей можно использовать в качестве резервного метода аутентификации для сквозной аутентификации на случай, если агентам не удается проверить учетные данные пользователя из-за значительного сбоя в локальной среде. Отработка отказа на синхронизацию хэша паролей не происходит автоматически, и для переключения метода входа вручную необходимо использовать Microsoft Entra Подключение.

Федеративная аутентификация

При выборе этого метода проверки подлинности идентификатор Microsoft Entra передает процесс проверки подлинности отдельной доверенной системе проверки подлинности, например локальная служба Active Directory службам федерации (AD FS), чтобы проверить пароль пользователя. Эта система проверки подлинности может поддерживать дополнительные требования расширенной аутентификации. Примеры: аутентификация на основе смарт-карт или многофакторная проверка подлинности сторонних производителей.

• Трудозатраты. Использование системы федеративной проверки подлинности зависит от внешней доверенной системы для аутентификации пользователей. Некоторые компании хотят повторно использовать свои существующие федеративные системные инвестиции с их решением гибридного удостоверения Microsoft Entra. Обслуживание и управление федеративной системой выходит за пределы контроля идентификатора Microsoft Entra. Именно от организации, использующей федеративную систему, зависит ее безопасное развертывание и способность обрабатывать нагрузку аутентификации.

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

• Сложные сценарии. Федеративное решение проверки подлинности требуется, если у клиентов есть требование проверки подлинности, что идентификатор Microsoft Entra не поддерживается в собственном коде.

  • Аутентификация, требующая наличия смарт-карт или сертификатов.
  • Локальные серверы MFA или сторонние поставщики многофакторной проверки подлинности, которым необходим федеративный поставщик удостоверений.
  • Аутентификация с использованием решения для аутентификации стороннего производителя.
  • Для входа в систему требуется имя sAMAccountName, например «ДОМЕН\имя пользователя», а не имя участника-пользователя (UPN), например user@domain.com.

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

• Рекомендации. Федеративные системы обычно требуют более значительных инвестиций в локальную инфраструктуру. Большинство организаций выбирает этот вариант, если они уже вложили средства в локальную федерацию. И если действует строгое бизнес-требование использовать один поставщик удостоверений. Федерация более сложна с точки зрения работы и устранения неполадок по сравнению с облачными решениями аутентификации.

Схемы архитектуры

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

• Простота решения для синхронизации хеша паролей:

  

• Требования агента к сквозной аутентификации с использованием двух агентов для обеспечения избыточности:

  

• Компоненты, необходимые для федерации в сети периметра и внутренней сети организации:

  

Рекомендации

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

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

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

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

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

• Защита идентификации. Одним из лучших способов защиты пользователей в облаке является Защита идентификации Microsoft Entra с помощью Microsoft Entra Premium P2. Корпорация Майкрософт постоянно ищет в Интернете списки пользователей и паролей, которые злоумышленники продают и предоставляют на теневых веб-сайтах. Идентификатор Microsoft Entra может использовать эти сведения для проверки того, скомпрометируются ли какие-либо имена пользователей и пароли в вашей организации. Поэтому очень важно включить синхронизацию хэша паролей независимо от используемого метода аутентификации, будь то федеративная или сквозная аутентификация. Сведения об утечке учетных данных представляются в виде отчета. Эти сведения можно использовать, чтобы блокировать пользователей или вынудить их сменить пароль при попытке выполнить вход с помощью скомпрометированного пароля.

Основные понятия проектирования Microsoft Entra Подключение

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

sourceAnchor

Атрибут sourceAnchor определяется как атрибут, который остается неизменным на протяжении всего времени существования объекта. Он однозначно идентифицирует объект как один и тот же объект в локальной среде и в идентификаторе Microsoft Entra. Этот атрибут также называется immutableId. Оба этих имени взаимозаменяемы. Данный атрибут используется в следующих случаях.

• При создании нового сервера подсистемы синхронизации или перестроении после сценария аварийного восстановления этот атрибут связывает существующие объекты в идентификаторе Microsoft Entra с локальными объектами.
• При переходе из облачного удостоверения в синхронизированную модель удостоверений этот атрибут позволяет объектам "жестко сопоставлять" существующие объекты в идентификаторе Microsoft Entra с локальными объектами.
• При использовании федерации: в этом случае данный атрибут в сочетании с userPrincipalName используется в утверждении для уникальной идентификации пользователя.

Значение атрибута должно соответствовать следующим правилам:

• Его длина должна быть меньше 60 знаков.

  • Символы, отличные от a–z, A–Z или 0–9, кодируются, и каждый из них считается как три символа.

• Оно не должно содержать специальный символ \ ! # $ % & * + / = ? ^ { } | ~ > < ( ) ' ; : , [ ] " @ _.

• (оно должно быть глобально уникальным)

• Значение должно относиться к строковому, целочисленному или двоичному типу.

• Значение не должно быть основано на имени пользователя, так оно может изменяться.

• Не следует учитывать регистр и избегать значений, которые зависят от регистра.

• Значение должно присваиваться при создании объекта.

При наличии одного локального леса следует использовать атрибут objectGuid. Атрибут objectGuid можно также использовать при использовании экспресс-параметров в Microsoft Entra Подключение. А также атрибут, используемый d DirSync. Если у вас несколько лесов и вы не перемещаете пользователей между лесами и доменами, то атрибут objectGUID вполне подходит для использования. Другой вариант — выбрать существующий атрибут, который наверняка никогда не изменяется. Зачастую можно использовать атрибут employeeID. Если значение атрибута содержит буквы, исключите вероятность изменения регистра (верхний или нижний) в значении этого атрибута. Не используйте атрибуты, содержащие имя пользователя. После решения атрибута sourceAnchor мастер сохраняет сведения в клиенте Microsoft Entra. Сведения будут использоваться в будущем установке Microsoft Entra Подключение.

Вход Microsoft Entra

Параметры синхронизации интеграции локального каталога с идентификатором Microsoft Entra могут повлиять на способ проверки подлинности пользователя. Microsoft Entra использует userPrincipalName (UPN) для проверки подлинности пользователя. Однако при синхронизации пользователей необходимо тщательно выбирать атрибут, который будет использоваться в качестве значения userPrincipalName. При выборе атрибута, который будет использоваться в Azure в качестве значения UPN (имени участника-пользователя), следует убедиться в следующем.

• Значения атрибута соответствуют синтаксису имени участника-пользователя (RFC 822) в формате имя_пользователя@домен.
• Суффикс в значениях соответствует одному из проверенных пользовательских доменов в идентификаторе Microsoft Entra

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

Пользовательское состояние домена и имя субъекта-пользователя

Убедитесь, что для суффикса имени участника-пользователя (UPN) существует проверенный домен. Джон (John) является пользователем в contoso.com. Вы хотите, чтобы Джон использовал локальную имя john@contoso.com участника-пользователя для входа в Azure после синхронизации пользователей с каталогом Microsoft Entra contoso.onmicrosoft.com. Для этого необходимо добавить и проверить contoso.com в качестве личного домена в идентификаторе Microsoft Entra, прежде чем начать синхронизацию пользователей. Если суффикс имени участника-пользователя, например contoso.com, не соответствует проверенном домену в идентификаторе Microsoft Entra, средство заменяет суффикс имени участника-пользователя на contoso.onmicrosoft.com.

В некоторых организациях используются домены, не поддерживающие маршрутизацию, например contoso.local, или простые одноуровневые домены наподобие contoso. Не удается проверить неизменяемый домен. Microsoft Entra Подключение может синхронизироваться только с проверенным доменом в идентификаторе Microsoft Entra. При создании каталога Microsoft Entra создается маршрутизируемый домен, который становится доменом по умолчанию для идентификатора Microsoft Entra, например contoso.onmicrosoft.com. Поэтому в данной ситуации возникает необходимость подтвердить любой другой маршрутизируемый домен, на случай если вы не хотите синхронизироваться с доменом onmicrosoft.com по умолчанию.

Microsoft Entra Подключение обнаруживает, работает ли вы в среде домена, отличной от routable, и будете соответствующим образом предупреждать вас о том, что вы будете работать с экспресс-параметрами. Если вы работаете с доменом, который не поддерживает маршрутизацию, имена участников-пользователей, скорее всего, тоже содержат не поддерживающий маршрутизацию суффикс. Например, если вы работаете в contoso.local, Microsoft Entra Подключение предлагает использовать пользовательские параметры, а не использовать экспресс-параметры. С помощью пользовательских параметров вы можете указать атрибут, который следует использовать в качестве имени участника-пользователя для входа в Azure после синхронизации пользователей с идентификатором Microsoft Entra.

Топологии для Microsoft Entra Подключение

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

Общая топология	Description
Один лес, один клиент Microsoft Entra	Наиболее распространенной топологией является один локальный лес с одним или несколькими доменами и одним клиентом Microsoft Entra. Для проверки подлинности используется синхронизация хэша паролей. Экспресс-установка Microsoft Entra Подключение поддерживает только эту топологию.
Несколько лесов, один клиент Microsoft Entra	Во многих организациях есть среды, которые включают несколько локальных лесов Active Directory. Есть разные причины существования нескольких локальных лесов Active Directory. Типичными примерами являются проекты с лесами ресурсов учетных записей и лесами, появившимися в результате слияния или поглощения. При наличии нескольких лесов все леса должны быть доступны одним сервером синхронизации Microsoft Entra Подключение. Компьютер должен быть присоединен к домену. Если необходимо получить доступ ко всем лесам, можно разместить сервер в сети периметра (также называется DMZ и промежуточной подсетью).
Несколько лесов, один сервер синхронизации, пользователи представлены только в одном каталоге	В этой среде все локальные леса рассматриваются как отдельные сущности. В любых других лесах пользователи отсутствуют. У каждого леса есть своя организация Exchange. Синхронизация GALSync между лесами отсутствует. Такая топология может возникать в результате слияний и поглощений, а также в организации, в которой все подразделения функционируют независимо. Эти леса находятся в той же организации в идентификаторе Microsoft Entra и отображаются с унифицированным gal. На предыдущем рисунке каждый объект в каждом лесу представлен один раз в метавселенной и агрегирован в целевом клиенте.
Несколько лесов: полная сетка с дополнительным решением GALSync	Топология полной сетки позволяет пользователям и ресурсам размещаться в любом лесу. Как правило, между лесами образуются двусторонние отношения доверия. Если Exchange присутствует в нескольких лесах, может быть доступным дополнительное локальное решение GALSync. Каждый пользователь будет представлен во всех остальных лесах как контакт. GALSync часто реализуется через FIM 2010 или MIM 2016. Microsoft Entra Connect нельзя использовать в локальном решении GALSync.
Несколько лесов: лес ресурсов учетной записи	В этом сценарии один (или несколько) лес ресурсов доверяет всем лесам учетных записей. Лес ресурсов обычно имеет расширенную схему Active Directory с Exchange и Teams. Все службы Exchange и Teams, а также другие общие службы находятся в этом лесу. У пользователей есть отключенные учетные записи в этом лесу. С лесом учетных записей связан почтовый ящик.
промежуточного сервера	Microsoft Entra Подключение поддерживает установку второго сервера в промежуточном режиме. Сервер в этом режиме считывает данные из всех подключенных каталогов, но не записывает ничего в подключенные каталоги. Он использует обычный цикл синхронизации и поэтому содержит обновленную копию данных удостоверения.
Несколько клиентов Microsoft Entra	Существует связь 1:1 между сервером синхронизации Microsoft Entra Подключение и клиентом. Для каждого клиента Microsoft Entra требуется одна установка сервера синхронизации Microsoft Entra Подключение. Экземпляры клиента AD изолированы по проектированию. Это значит, что пользователям в одном клиенте недоступны пользователи в другом клиенте. Разделение пользователей является поддерживаемой конфигурацией. В противном случае следует использовать одну клиентную модель Microsoft Entra.
Каждый объект только один раз в клиенте Microsoft Entra	В этой топологии один сервер синхронизации Microsoft Entra Подключение подключен к каждому клиенту. Серверы синхронизации Microsoft Entra Подключение должны быть настроены для фильтрации, чтобы каждый из них был взаимоисключающим набором объектов для работы. Например, каждый сервер может обслуживать определенный домен или подразделение.

Факторы компонентов Microsoft Entra Подключение

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

Модуль подготовки подключается к каждому лесу Active Directory и к идентификатору Microsoft Entra. Процесс считывания информации с каждого каталога называется "импорт". Экспорт относится к обновлению каталогов из модуля подготовки. Синхронизация оценивает правила передачи объектов в модуль подготовки.

Microsoft Entra Подключение использует следующие промежуточные области, правила и процессы, чтобы разрешить синхронизацию с Active Directory с идентификатором Microsoft Entra:

• Пространство соединителя — объекты из каждого подключенного каталога, фактические каталоги, помещаются на промежуточное хранение сначала здесь, прежде чем их обработает соответствующий модуль. Идентификатор Microsoft Entra имеет собственную CS, и каждый лес, к которому вы подключаетесь, будет иметь собственную CS.
• Метавселенная (MV) — объекты, которые необходимо синхронизировать, создаются в зависимости от правил синхронизации. Объекты должны существовать в метавселенной, прежде чем они могут заполнить объекты и атрибуты в других подключенных каталогах. Есть только одна метавселенная.
• Правила синхронизации — определяют, какие объекты будут созданы (спроектированы) или подключены (присоединены) к объектам в метавселенной. Правила синхронизации также определяют, какие значения атрибутов будут скопированы или преобразованы в каталоги и из них.
• Профили выполнения — создают пакеты этапов процесса копирования объектов и значений их атрибутов в соответствии с правилами синхронизации между промежуточными областями и подключенными каталогами.

Облачная синхронизация Microsoft Entra

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

• Поддержка синхронизации с клиентом Microsoft Entra из среды леса, отключенной от нескольких лесов Active Directory: распространенные сценарии включают слияние и приобретение. Приобретенные леса AD компании изолированы от лесов AD родительской компании. Компании, которые исторически использовали несколько лесов AD.
• Упрощенная установка с помощью агентов подготовки с легким весом: агенты действуют в качестве моста от AD к идентификатору Microsoft Entra с конфигурацией синхронизации, управляемой в облаке.
• Для упрощения развертываний с высоким уровнем доступности можно использовать несколько агентов подготовки, критически важных для организаций, использующих синхронизацию хэша паролей из AD в Идентификатор Microsoft Entra.
• Поддержка больших групп с количеством членов до 50 000. При синхронизации больших групп мы рекомендуем использовать фильтр области только по подразделениям.

С помощью microsoft Entra Подключение облачной синхронизации подготовка от AD к Идентификатору Microsoft Entra выполняется в Microsoft Online Services. Организация должна развертывать только в локальной или размещенной в IaaS среде легкий агент, который выступает в качестве моста между идентификатором Microsoft Entra и AD. Конфигурация подготовки хранится и управляется в рамках службы. Помните, что синхронизация выполняется каждые 2 минуты.