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

Привет! Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. Знаете, на практике почти все наши клиенты, кто уже плотно сидит на Microsoft 365, просят нас внедрить синхронизацию с Azure AD (которая теперь Entra ID). Причины у всех разные: кому-то нужен единый логин для 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 вообще всё подряд. Но ведь часто это совсем лишнее, правда? Самый простой способ фильтрации — это через мастер, выбирая 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 сама подсветит скомпрометированные учётки.