Entra Connect Sync 2026: гайд по ошибкам

Обновлено: 22 августа 2026

Ошибка синхронизации Microsoft Entra Connect Sync, это сбой в передаче объектов Active Directory в облачный каталог Microsoft Entra ID, из-за которого новые учётные записи не появляются в Microsoft 365, смена пароля не доходит до облака, а Conditional Access выносит решения по устаревшим данным. В 2026 году я вижу три доминирующих класса таких ошибок в тикетах моей команды: дубликаты атрибутов (AttributeValueMustBeUnique), soft/hard-match конфликты (включая новый обязательный InvalidHardMatch-контроль с 1 июля 2026) и export-сбои уровня коннектора. Эта статья, по сути, рабочая инструкция, которая закрывает 90% таких инцидентов за 15–30 минут и снижает MTTR по идентити-тикетам вдвое.

С 1 июля 2026 Microsoft автоматически включила защиту InvalidHardMatch: hard-match блокируется, если у целевой облачной учётной записи задан onPremisesObjectIdentifier или назначена привилегированная роль Entra.
Все серверы Entra Connect Sync должны быть на версии 2.5.79.0 или выше к 30 сентября 2026, иначе синхронизация останавливается принудительно.
90% ошибок в моих логах, это три категории: дубликаты UserPrincipalName/proxyAddresses, soft-match конфликты и dn-attributes-failure при экспорте.
Быстрая диагностика: Get-ADSyncConnectorRunStatus плюс Get-ADSyncCSObject … Where-Object ErrorName -ne "" покрывают 80% первичной триажной задачи.
С июля 2026 Microsoft начала волны миграции на Entra Cloud Sync, оцените совместимость сейчас, а не когда придёт уведомление в M365 Message Center.
MTTR по идентити-инцидентам в моей команде упал с 47 минут до 21 после внедрения ежечасного скрипта-часового на базе Connect Health API.

Почему сбои Entra Connect Sync критичны для MTTR

В типичной гибридной инфраструктуре Entra Connect Sync, это узкое место с самым высоким «взрывным радиусом» на объём кода. Один процесс на одном сервере (обычно двух в staging-подписке никто не держит) отвечает за то, что пользователь, созданный в OU локального AD, увидит своё имя в Outlook и Teams. Когда синхронизация встаёт, инциденты сыплются по нескольким SLA одновременно: onboarding блокируется, MFA-регистрация валится, а Conditional Access продолжает применять политики к «замороженным» данным атрибутов и групп.

По моим замерам за 12 месяцев в двух гибридных тенантах на 8–15 тысяч пользователей, средний тикет «не могу зайти в почту» коррелирует со сбоем синхронизации в 34% случаев, но диагностируется правильно только в 11% случаев на первой линии. Именно этот разрыв убивает FCR (First Contact Resolution) и растягивает MTTR: инженер тратит 20 минут на пересброс пароля, прежде чем кто-то откроет Synchronization Service Manager. Всё, что описано ниже, это попытка закрыть разрыв автоматизацией и понятным ранбуком.

Второй мотиватор регуляторный. С 2026 года Microsoft ужесточила несколько поведений идентити-платформы одновременно: hard-match защиту привилегированных объектов, обязательный минимальный билд коннектора, старт волновой миграции на Cloud Sync. Каждое из этих изменений может сломать синхронизацию у команды, которая полгода не заходила на Entra-сервер.

Как быстро диагностировать сбой синхронизации Entra Connect

Первое, что я делаю, получая тикет «пользователь создан в AD, но не появляется в Microsoft 365», это открываю не GUI, а PowerShell на Entra Connect сервере. GUI хорош для точечной работы с одним объектом, но для первичной триажной задачи он попросту слишком медленный.

Мой стандартный триажный блок из трёх команд:

# 1. Модуль загружен?
Import-Module ADSync

# 2. Планировщик вообще включён и когда был последний цикл?
Get-ADSyncScheduler | Format-List SyncCycleEnabled, NextSyncCyclePolicyType,
    NextSyncCycleStartTimeInUTC, IsStagingModeEnabled

# 3. Что показывает последний запуск коннекторов?
Get-ADSyncConnectorRunStatus

Если SyncCycleEnabled равно False, кто-то из инженеров вручную остановил планировщик (например, для массовой правки) и забыл включить. Это уже 30% моих «сбоев». Включаем обратно:

Set-ADSyncScheduler -SyncCycleEnabled $true
Start-ADSyncSyncCycle -PolicyType Delta

Если планировщик работает, но Get-ADSyncConnectorRunStatus показывает completed-export-errors или completed-sync-errors, идём глубже и перечисляем объекты в ошибочном состоянии:

Get-ADSyncCSObject -ConnectorName "contoso.onmicrosoft.com - AAD" |
    Where-Object { $_.ErrorName -ne "" } |
    Select-Object DistinguishedName, ErrorName, ErrorDetail |
    Format-Table -AutoSize

Имя коннектора уточните через Get-ADSyncConnector | Select-Object Name. На выходе список DN с человекочитаемыми кодами ошибок: AttributeValueMustBeUnique, InvalidSoftMatch, dn-attributes-failure. Дальше диагностика ветвится по типу, и следующие разделы разбирают каждый по отдельности.

Параллельно я всегда открываю Synchronization Service Manager (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe), но только на вкладке Operations, чтобы увидеть визуально, какие профили выполнения (Import/Sync/Export) отвалились в каком коннекторе. Это экономит время, когда ошибка не в целевом коннекторе AAD, а в исходном AD-коннекторе (скажем, отвалилась учётная запись, читающая AD).

Как исправить дубликаты UPN и proxyAddresses

Так вот, ошибки вида AttributeValueMustBeUnique это самый частый класс сбоев в моей практике: примерно 40% всех идентити-тикетов, если не считать самих сбросов пароля. Появляются они, когда два объекта в on-prem AD (или в AD и облаке одновременно) имеют одинаковое значение userPrincipalName, proxyAddresses или mailNickname. Entra ID отклоняет второй объект и либо помещает его в quarantine с временным UPN формата <Prefix>+<4цифры>@<tenant>.onmicrosoft.com, либо просто не создаёт.

Поиск дубликатов в on-prem AD

Быстрый скрипт находит дубликаты UPN и proxyAddresses в лесу AD:

# Дубликаты userPrincipalName
Get-ADUser -Filter * -Properties userPrincipalName |
    Group-Object userPrincipalName |
    Where-Object { $_.Count -gt 1 } |
    Select-Object Name, Count

# Дубликаты proxyAddresses (SMTP-адреса)
Get-ADUser -Filter * -Properties proxyAddresses |
    ForEach-Object {
        foreach ($addr in $_.proxyAddresses) {
            [PSCustomObject]@{ User = $_.SamAccountName; Address = $addr }
        }
    } |
    Group-Object Address |
    Where-Object { $_.Count -gt 1 } |
    Select-Object Name, Count

Получение списка ошибок из облака

С обновлённым модулем Microsoft.Graph.Entra (в 2026 он полностью заменил AzureAD и MSOnline модули, которые ушли из-под поддержки) список ошибок доступен так:

Connect-Entra -Scopes "Directory.Read.All"

Get-EntraDirectoryObjectOnPremisesProvisioningError |
    Where-Object PropertyCausingError -eq 'UserPrincipalName'

Get-EntraDirectoryObjectOnPremisesProvisioningError |
    Where-Object PropertyCausingError -eq 'ProxyAddresses'

Правило устранения

Одно простое правило: удаляйте дублирующее значение с того объекта, где его быть не должно, в той директории, где он «родился». Если два пользователя реально существуют в компании и оба должны быть уникальны, переименовывайте UPN у нового сотрудника. Если один из объектов «мусор» (например, старая учётка ушедшего сотрудника с тем же именем), лучше удалить или дизаблить его, а не переносить конфликт в облако. После правки триггерите цикл вручную: Start-ADSyncSyncCycle -PolicyType Delta.

Для массовых чисток UPN у офболдингованных пользователей у нас в команде работает связка с развёртыванием Windows LAPS: офболдинг-скрипт одновременно чистит locally significant пароль и добавляет к UPN суффикс .deprovisioned, чтобы конфликтов не создавалось при перепереиспользовании имени.

InvalidSoftMatch и InvalidHardMatch в 2026: что изменилось

Soft match и hard match это два механизма, которыми Entra ID связывает on-prem объекты с уже существующими облачными. Soft match работает по совпадению proxyAddresses или UserPrincipalName. Hard match работает по ImmutableID (обычно это Base64-кодированный objectGUID). В 2026 году поведение обоих поменялось.

InvalidSoftMatch

Ошибка возникает, когда два объекта с разными sourceAnchor имеют одинаковый proxyAddresses или UserPrincipalName. Классический сценарий: облачный пользователь был создан вручную в Entra до включения синхронизации, а теперь on-prem-объект с тем же UPN пытается «прицепиться». Решение: либо уничтожить дублирующий облачный объект и дать создать чистый через синхронизацию, либо выполнить официальный hard-match через ImmutableID.

InvalidHardMatch (новое поведение с 1 июля 2026)

С 1 июля 2026 Microsoft автоматически включила Hard Match Security Hardening. Раньше hard match всегда «пробивал» защиту. Теперь Entra ID отказывает в hard match, если целевой облачный объект соответствует хотя бы одному из условий:

У пользователя уже задан onPremisesObjectIdentifier (то есть он уже связан с другим on-prem объектом).
Пользователю назначена привилегированная роль Entra (Global Admin, Privileged Role Admin и т.п.).
Пользователь eligible для привилегированной роли через PIM.

Практический эффект: если раньше администратор мог «случайно» перетянуть Global Admin с on-prem объекта, теперь такой sync упадёт с InvalidHardMatch. Это защита от takeover-атак, но она же ломает миграционные сценарии, где вы легитимно хотите пересвязать привилегированный аккаунт. Правильный путь такой: сначала снять привилегированные роли с целевого облачного объекта, затем выполнить hard match, затем вернуть роли. Никакого «принудительного» флага для обхода нет и, судя по всему, не появится.

Устранение export-ошибок: dn-attributes-failure и permission-issue

Export-ошибки, это класс сбоев, которые возникают на профиле Export to AAD, когда Sync-движок пытается отправить уже согласованные изменения в облако и получает отказ. По моей статистике на них приходится около 20% тикетов, и они часто самые неприятные, потому что «сам объект в порядке», а падает связка объектов.

dn-attributes-failure

Появляется, когда объект ссылается на другой объект (через member, manager, publicDelegates), а целевой объект не синхронизирован или удалён. Классический пример: группа с 2000 членов, из которых 3 находятся в OU, исключённой OU-фильтром синхронизации. Группа синхронизируется, но экспорт валится.

Триажный запрос, вытащить конкретный DN и посмотреть, что именно упало:

# Замените ConnectorName на ваш AAD-коннектор
Get-ADSyncCSObject -ConnectorName "contoso.onmicrosoft.com - AAD" |
    Where-Object { $_.ErrorName -like "*dn-attributes*" } |
    Select-Object DistinguishedName, ErrorDetail |
    Format-List

Дальше либо расширить scope OU-фильтров, чтобы ссылаемые объекты синхронизировались, либо очистить ссылки в самом объекте на источнике.

permission-issue и server-down

Появляются, когда сервисной учётной записи не хватает прав в Entra ID (после смены роли или пересоздания приложения) либо сервер Entra Connect не может связаться с endpoint-ами *.msappproxy.net и login.microsoftonline.com. Быстрая проверка сетевой связности:

Test-NetConnection login.microsoftonline.com -Port 443
Test-NetConnection graph.microsoft.com -Port 443
Test-NetConnection secure.aadcdn.microsoftonline-p.com -Port 443

Если ping-endpoints недоступны, проверяйте прокси (WPAD, netsh winhttp show proxy), фаервол и TLS 1.2/1.3 на самом сервере. С 2026 года Entra Connect не поддерживает TLS 1.0/1.1, что периодически ловит легаси-серверы, живущие в изолированных сегментах.

Автоматизация мониторинга: PowerShell и Entra Connect Health

Ручной ранбук работает, но не масштабируется: вы всё равно узнаёте о поломке от пользователя, а не от системы. Я использую два уровня автоматизации, оба бесплатные.

Уровень 1: PowerShell «часовой» на самом сервере

Скрипт запускается через Task Scheduler каждые 30 минут, проверяет, что цикл синхронизации закончился без ошибок, и шлёт уведомление в Teams через webhook.

# entra-sync-watchdog.ps1
Import-Module ADSync

$connector = "contoso.onmicrosoft.com - AAD"
$errors = Get-ADSyncCSObject -ConnectorName $connector |
    Where-Object { $_.ErrorName -ne "" }

$scheduler = Get-ADSyncScheduler
if (-not $scheduler.SyncCycleEnabled -or $errors.Count -gt 0) {
    $payload = @{
        text = "Entra Connect Sync ALERT`n" +
               "Scheduler: $($scheduler.SyncCycleEnabled)`n" +
               "Error objects: $($errors.Count)"
    } | ConvertTo-Json

    Invoke-RestMethod -Uri $env:TEAMS_WEBHOOK -Method Post `
        -ContentType 'application/json' -Body $payload
}

Webhook URL храните в переменной окружения (или в Azure Key Vault + Get-AzKeyVaultSecret), не в теле скрипта. Скрипт не решает проблему, но приводит время обнаружения (MTTD) к 30 минутам вместо «когда HR-директор напишет в Slack».

Уровень 2: Entra Connect Health self-service remediation

С 2025 года Entra Connect Health предоставляет self-service диагностику для дубликатов атрибутов: сервис сам определяет проблему и предлагает готовое действие в один клик, без апгрейда коннектора и без Sync Rule Editor. Для тенантов с активной подпиской Entra ID P1/P2 это ощутимо снижает нагрузку на T2-инженеров: тикет с дубликатом закрывает T1 через портал, не открывая RDP на сервер синхронизации.

Миграция на Entra Cloud Sync: что ждёт с июля 2026

С июля 2026 Microsoft начала волновую миграцию тенантов с Entra Connect Sync на Entra Cloud Sync. Это облачный сервис, который не требует локального SQL Server и поддерживает несколько активных серверов синхронизации без ручного failover. Уведомления приходят в M365 Message Center, Entra Connect Health и на email тенант-администратора.

Кто попадает в ранние волны

Ранние волны это тенанты, у которых Cloud Sync полностью покрывает текущий сценарий: один лес, стандартные потоки атрибутов, без экзотических правил синхронизации. Сложные конфигурации (multi-forest, Group Writeback v2, PTA, тяжёлая фильтрация OU, большие каталоги на 100k+ объектов) откладываются на более поздние волны: Microsoft явно говорит, что дождётся паритета фич.

Сравнение Cloud Sync и Connect Sync

Характеристика	Entra Connect Sync	Entra Cloud Sync
Инфраструктура on-prem	Сервер + SQL (LocalDB или полный)	Легковесный агент, без SQL
Высокая доступность	Staging Mode + ручной failover	Несколько активных агентов из коробки
Multi-forest	Полная поддержка	Поддерживается (без cross-forest ссылок)
Group Writeback	v1 и v2	Group Provision to AD (частичный паритет)
Кастомные правила синхронизации	Sync Rule Editor, полный контроль	Ограниченный набор через портал
Password Hash Sync	Есть	Есть
Pass-through Authentication	Есть	Планируется, пока нет
Управление конфигурацией	Локально на сервере	В облаке (Entra portal)

Критичный дедлайн: 30 сентября 2026

Независимо от того, попали вы в волну или нет, каждый сервер Entra Connect Sync должен быть обновлён до версии 2.5.79.0 или выше к 30 сентября 2026, иначе синхронизация останавливается принудительно. Сам этот билд, в свою очередь, выходит из-под поддержки 23 октября 2026, так что план обновления надо держать в календаре. Микрософт открыто говорит, что миграция на Cloud Sync это не «если», а «когда», и лучше проходить её управляемо, а не в аварийном режиме.

Что измерять в следующем месяце

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

MTTR по идентити-тикетам. Средний срок от открытия тикета до закрытия для тикетов с тегом identity. Целевой ориентир для команды на 10 инженеров, не более 30 минут по 90-му перцентилю.
FCR по классу «не могу войти». Процент таких тикетов, закрытых T1 без эскалации. Прогресс от 55% к 80% ловим после внедрения self-service remediation в Connect Health.
Sync error count over time. Число объектов в error-состоянии в конце каждого цикла. Тренд важнее абсолюта: рост на 10+ объектов в неделю без release-активности равен приоритетному инциденту.
Sync cycle duration p95. Деградация с 30 секунд до 5 минут это ранний индикатор нагрузки на SQL или DC, а не «нормальный рост».
% пользователей с quarantined UPN. Прямой индикатор гигиены AD. Больше 0.5%, пора запускать проектную чистку данных.

Синхронизируйте эти метрики с оценкой готовности к миграции Kerberos с RC4 на AES: обе инициативы затрагивают одну и ту же плоскость идентити, и, если планировать их вместе, вы сокращаете downtime-окна вдвое.

Часто задаваемые вопросы

Как быстро запустить полный цикл синхронизации Entra Connect?

На сервере Entra Connect выполните в PowerShell от имени администратора: Import-Module ADSync, затем Start-ADSyncSyncCycle -PolicyType Initial. Полный цикл может занять от нескольких минут до нескольких часов в больших каталогах и создаёт заметную нагрузку на domain controllers, планируйте вне часов пик.

Что такое ошибка InvalidHardMatch и как её обойти?

С 1 июля 2026 Entra ID блокирует hard match объектов, если целевая облачная учётная запись имеет привилегированную роль или уже связана с другим on-prem объектом. Обойти нельзя, необходимо сначала снять привилегированные роли или удалить onPremisesObjectIdentifier с целевого объекта, выполнить hard match, а затем вернуть роли.

В чём разница между Entra Connect Sync и Entra Cloud Sync?

Entra Connect Sync это классический сервер с SQL, поддерживающий сложные сценарии (Group Writeback, PTA, кастомные правила). Cloud Sync это легковесный агент без SQL, конфигурация которого хранится в облаке. Cloud Sync поддерживает multi-active высокую доступность из коробки, но пока не покрывает всех сценариев Connect Sync; Microsoft закрывает паритет постепенно.

Почему пользователь получает UPN с суффиксом onmicrosoft.com вместо корпоративного?

Это результат работы Duplicate Attribute Resiliency: Entra ID нашёл конфликт по userPrincipalName и присвоил объекту временный UPN формата <prefix>+<4 цифры>@<tenant>.onmicrosoft.com. Найдите и уберите дубликат в on-prem AD, затем запустите delta-цикл, временный UPN сменится на корректный.

Как узнать, попал ли мой тенант в первую волну миграции на Cloud Sync?

Уведомление приходит в трёх каналах: M365 Message Center, Entra Connect Health в портале Entra и на почту billing/technical-контактов тенанта. Если ни одно уведомление не пришло, ваш тенант либо ещё не в очереди, либо использует сценарий, который Cloud Sync пока не покрывает; Microsoft явно откладывает такие тенанты на более поздние волны.