Гибридная идентификация: связываем локальный AD с Entra ID

Пишет Семёнов Евгений Сергеевич, директор АйТи Фреш. На практике синхронизацию с Azure AD (теперь Entra ID) просят внедрить почти все клиенты, которые подсели на Microsoft 365. Кто-то хочет один логин для Teams и файловой шары, кто-то — подтягивать групповые политики в Intune, кто-то устал вручную создавать одинаковые учётки в двух каталогах. У нас на балансе сейчас восемь инфраструктур с Entra Connect, и я расскажу, как его разворачивать аккуратно, без классических граблей.

Три способа скрестить локальный AD с облаком

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

• Password Hash Sync (PHS). Хеш пароля (точнее, SHA-256 от MD4) летит в Entra ID по TLS. Аутентификация проходит прямо в облаке. Самый простой и живучий вариант — офис упал, а в Teams люди всё равно заходят.
• Pass-through Authentication. В Entra уходит только факт существования учётки, проверка пароля остаётся локальной — агент PTA туннелирует запросы через шифрованный канал. Любят параноики.
• Federation (AD FS). Полноценная ферма ADFS + WAP в DMZ. Сложно, дорого и с кучей точек отказа. Сейчас имеет смысл разве что под какие-то legacy-SAML-сервисы.

В большинстве случаев беру PHS плюс Seamless SSO — закрывает 95% запросов по цене одного дополнительного виртуального сервера. Дальше весь разбор построен вокруг этой связки.

Что надо проверить в AD до установки

Половина провалов происходит не на этапе установки Connect, а из-за мусора в доменных атрибутах. Перед запуском мастера всегда прогоняю несколько команд и утилиту IdFix.

# Режим леса и домена — минимум 2003, лучше 2016
Get-ADForest | Select ForestMode
Get-ADDomain | Select DomainMode

# Смотрим альтернативные UPN-суффиксы
Get-ADForest | Select -ExpandProperty UPNSuffixes

# Если контора живёт в .local — добавляем публичный суффикс
Set-ADForest -Identity corp.local -UPNSuffixes @{Add="itfresh.ru"}

# Раскатываем новый UPN на пользователей
Get-ADUser -Filter * -SearchBase "OU=Staff,DC=corp,DC=local" | ForEach-Object {
    Set-ADUser -Identity $_ -UserPrincipalName ($_.SamAccountName + "@itfresh.ru")
}

Дальше скачиваю IdFix с microsoft.github.io/idfix и запускаю от Enterprise Admin. Утилита вылавливает дубли proxyAddresses, неразрешённые символы в displayName, кривые mailNickname. Всё помеченное надо починить до первого цикла синхронизации, иначе в облако полетят ошибки InvalidSoftMatch — каждая из них требует ручной правки в Entra.

Сервер под Entra Connect: железо и требования

Ставить Connect на контроллер домена — плохая идея, хоть и технически возможно. Всегда выдаю отдельную виртуалку. На моей инфраструктуре это делается на одном из восьми серверов Dell Xeon Platinum 8280 в дата-центре МТС, и уровня ESXi-хоста хватает с запасом — сам Connect ест немного.

Сетевой доступ: к контроллерам домена по LDAP/LDAPS и Kerberos, наружу — только 443 до login.microsoftonline.com и pkcs.azureedge.net. Открывать исходящий 80 порт не нужно, вопреки старым гайдам.

# Качаем установщик (ссылка Microsoft меняется, проверяйте актуальную)
Invoke-WebRequest -Uri "https://download.microsoft.com/download/B/0/0/B00291D0-5A83-4DE7-86F5-980BC00DE05A/AzureADConnect.msi" `
  -OutFile C:\install\AzureADConnect.msi
msiexec /i C:\install\AzureADConnect.msi

Express или Custom — как выбрать

Мастер предлагает два сценария. Express подходит ровно в одном случае: один лес, одна сеть, никакого фильтра OU, всё и сразу. Я такую кнопку нажимал от силы пару раз на малых офисах до 30 человек. Custom — то, что использую в 90% проектов.

Сценарии, где без Custom не обойтись:

• Несколько лесов или доверенных доменов.
• Нужно синхронизировать только продуктовые OU, без OU=TestUsers и OU=SharedMailboxes.
• Планируется Password Writeback или Group Writeback.
• Включаем Device Writeback для Hybrid Azure AD Join.
• Используется PTA вместо PHS.

Настройка PHS и Seamless SSO

На шаге User sign-in ставим две галки: Password Hash Synchronization и Enable single sign-on. Для второго пункта мастер попросит креды доменного админа — они нужны один раз, сохранять их никуда не будет.

Когда включаешь SSO, в AD автоматически создаётся компьютерная учётка AZUREADSSOACC. На ней висит SPN https://autologon.microsoftonline.com, и именно через неё браузер получает Kerberos-билет. Чтобы это работало с доменной машины, надо протолкнуть два URL в зону «Местная интрасеть» Internet Options.

# Через GPO: Computer Configuration → Policies → Administrative Templates →
#   Windows Components → Internet Explorer → Internet Control Panel →
#   Security Page → Site to Zone Assignment List
# https://autologon.microsoftonline.com  → 1
# https://aadg.windows.net.nsatc.net     → 1

# Проверка руками через реестр
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftonline.com\autologon" /v https /t REG_DWORD /d 1 /f

Ключ Kerberos у AZUREADSSOACC Microsoft рекомендует крутить раз в 30 дней. Вешаю это на Task Scheduler.

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1"
$creds = Get-Credential   # Enterprise Admin
Update-AzureADSSOForest -OnPremCredentials $creds

Реальный кейс: логистический оператор в Одинцово

Осенью 2025 заехал клиент — транспортная компания, 140 сотрудников, два офиса плюс склад. Жили на Microsoft 365 Business Premium, но пользователей заводили вручную в двух местах. Задача: поднять гибрид, подключить Intune для ноутбуков, закрыть Wi-Fi через Entra + NPS.

Подняли за четыре рабочих дня. Виртуалка Windows Server 2022 с 8 ГБ RAM, Azure AD Connect v2, PHS + Seamless SSO, фильтр по двум OU (Staff и Managers), staging-сервер на второй площадке. Плюс правило Inbound с исключением подразделения OU=Contractors — подрядчикам в M365 доступ не нужен. Стоимость внедрения — 78 000 рублей вместе с документацией и инструкцией для их штатного админа. На выходе 138 учёток поехали в облако без ошибок, 2 вернулись с InvalidSoftMatch из-за одинакового proxyAddresses, который остался с древнего Exchange 2010.

Фильтрация и правила синхронизации

По умолчанию Connect тянет из выбранных OU вообще всё. Часто это лишнее. Самый простой фильтр — по OU через мастер (Customize synchronization options → Domain and OU filtering). Более тонкий — через Synchronization Rules Editor.

# Список текущих правил по приоритету
Get-ADSyncRule | Select Name, Direction, Precedence | Sort Precedence

# Пример: не синхронизировать департамент с меткой "Excluded"
# В редакторе создаём Inbound-правило с scoping-фильтром:
#   Attribute: department
#   Operator:  NOTEQUAL
#   Value:     Excluded
# Precedence должен быть ниже (меньше числом), чем у базового правила

После любой правки фильтров обязателен полный цикл, иначе изменения в облако дойдут только через 30 минут по дельте.

Start-ADSyncSyncCycle -PolicyType Initial

Диагностика и типовые поломки

Когда работа у Connect пошла и бизнес успокоился, наступает пора мониторинга. Подписку на Connect Health держать приятно, но она требует лицензии P1. Для базовой жизни хватает PowerShell.

# Расписание — должно быть Enabled и со свежим NextSyncCycle
Get-ADSyncScheduler

# Ручной дельта-запуск
Start-ADSyncSyncCycle -PolicyType Delta

# Поиск объектов с ошибками экспорта в тенант
Get-ADSyncCSObject -ConnectorName "corp.onmicrosoft.com - AAD" |
    Where-Object { $_.HasExportError } |
    Select DN, ExportError

# Журнал событий самого агента
Get-EventLog -LogName Application -Source "ADSync" -Newest 50

Три ошибки, с которыми сталкиваюсь чаще всего:

• InvalidSoftMatch — в AD или в облаке уже есть объект с таким же proxyAddress. Решается ручным слиянием через Search-UnifiedAuditLog + New-MsolUser -ImmutableId.
• DataValidationFailed — в атрибуте буква из другого алфавита или неразрешённый символ. IdFix лечит.
• LargeObject — больше 15 значений в proxyAddresses или почти во всём multi-valued. Приходится вычищать старые SMTP-адреса, оставшиеся от ретранслятора.

Отказоустойчивость и Password Writeback

Каждому серьёзному клиенту на Microsoft 365 я ставлю второй сервер в режиме staging. Это полностью рабочий экземпляр Connect, но с выключенной экспортной схемой — он параллельно сосёт данные, но не пишет их в облако. Если основной сервер умер, Set-ADSyncAutoUpgrade + один вызов мастера переводят staging в боевой за 10 минут.

Password Writeback включается в Optional features мастера. Лицензия — Entra ID P1. После включения пользователь с SSPR-регистрацией меняет пароль через my.microsoft.com, и новый хеш летит обратно в локальный AD через тот же канал. Особенно полезно удалённым сотрудникам с корпоративных ноутбуков, которые полгода не подключались к офису.

FAQ — частые вопросы про Azure AD Connect

Можно ли гонять синхронизацию сразу из нескольких лесов?

Да, на этапе Custom Setup добавляются все леса, на выходе получаем один тенант. Главное — UPN пользователей не должны пересекаться между лесами, иначе словите SoftMatch-коллизии.

Что случится, если сервер Azure AD Connect упадёт?

Сама синхронизация встанет, но уже попавшие в облако хеши продолжат работать — люди спокойно логинятся в Microsoft 365. Новые пароли до восстановления сервиса в облако не уедут. Для HA держим второй сервер в режиме staging.

Azure AD Connect и Microsoft Entra Connect — одно и то же?

Один и тот же продукт под разными вывесками. В 2023-м Microsoft переименовала Azure AD в Entra ID, а установщик стал называться Entra Connect Sync. Архитектура, правила, PowerShell-модули остались такими же.

С какой периодичностью летит синхронизация по умолчанию?

Каждые 30 минут идёт дельта-цикл — меньше выставить нельзя. Принудительно запускается командой Start-ADSyncSyncCycle -PolicyType Delta. Изменение пароля летит отдельной шиной за одну-две минуты.

Насколько безопасно отправлять хеши в облако?

В Entra ID уходит не исходный MD4-хеш, а SHA-256 от его соли — по TLS. Восстановить пароль из этой цепочки невозможно. Зато в комплекте идёт Leaked Credentials Detection — Microsoft сама подсветит скомпрометированные учётки.