Блог Виталия Лещенко
Виталий Лещенко

Windows Server для самых маленьких. Часть 31: Как работает Entra Connect?

Все части серии «Windows Server для самых маленьких»

Тридцать частей каталог жил внутри сети: Kerberos, LDAP, SMB, групповые политики — всё это не ходит через интернет и не предназначено для него. Но почта у организации — в Microsoft 365, документы — в SharePoint, а вход туда — через Entra ID, облачный каталог Microsoft, который не знает ничего об Active Directory. Два каталога с одними и теми же людьми — это два пароля, два места, где заводят и увольняют, и гарантированное расхождение. Entra Connect связывает их: учётные записи из домена появляются в облаке, пароль один, увольнение в домене отключает и облако. Эта часть — о том, что именно едет в облако, как облако проверяет пароль, не имея контроллера домена, и что для этого нужно подготовить в каталоге.

Два каталога

Active Directory Entra ID
Где ваши контроллеры арендатор (tenant) example.onmicrosoft.com в облаке Microsoft
Протоколы Kerberos, NTLM, LDAP, SMB, RPC OAuth 2.0, OpenID Connect, SAML, WS-Federation; всё по HTTPS
Структура лес, домены, OU плоский список объектов арендатора; группы, административные единицы
Управление машинами групповые политики, вступление в домен Intune и регистрация устройств
Кто аутентифицирует контроллер домена Entra ID; для гибридных пользователей — одним из трёх способов ниже
Для чего всё внутри сети Microsoft 365, Azure, приложения с входом через Microsoft, условный доступ, MFA

Протоколы облака устроены иначе, чем Kerberos. OAuth 2.0 — протокол выдачи токенов доступа: приложение получает у Entra ID подписанный токен с правами на конкретный API и предъявляет его в заголовке HTTP. OpenID Connect — надстройка над OAuth 2.0 для входа: к токену доступа добавляется токен с именем пользователя (ID token). SAML и WS-Federation — старшие протоколы того же назначения на XML: сервер входа выдаёт подписанное утверждение о пользователе, браузер переносит его в приложение. Во всех четырёх приложение не видит пароля и не ходит к контроллеру: оно доверяет подписи Entra ID. Условный доступ — правила Entra ID, которые при входе требуют дополнительного условия (MFA, управляемое устройство, страна), а MFA — многофакторная проверка: кроме пароля, подтверждение в приложении на телефоне или ключом. Intune — облачная служба управления устройствами: политики, приложения и соответствие требованиям без групповых политик.

Гибридная идентичность — это когда учётная запись создаётся и живёт в Active Directory (источник истины), а в Entra ID существует её синхронизированная копия, которую нельзя редактировать в облаке: имя, группы, атрибуты, состояние — всё приходит из домена. Инструмент синхронизации — Entra Connect Sync (до 2023 года Azure AD Connect): приложение на сервере домена с движком синхронизации, унаследованным от Microsoft Identity Manager. Есть и облегчённый вариант, Entra Cloud Sync: агент на сервере, а логика — в облаке; он проще в установке и подходит для небольших и многолесных сред, но не умеет части функций (обратная запись устройств, сложные правила), и в серии речь о Connect.

Что синхронизируется

Объекты: пользователи, группы, контакты и, при гибридной регистрации, компьютеры. Атрибуты: имя, фамилия, отображаемое имя, UPN, mail и proxyAddresses, телефоны, должность, отдел, руководитель, extensionAttribute1…extensionAttribute15, членство в группах, userAccountControl (отключённый в домене отключается и в облаке), — всего коннектор каталога читает около полутора сотен атрибутов. Направление: из домена в облако; в обратную сторону — только то, что включено явно: пароль при самостоятельном сбросе в облаке (password writeback), устройства, группы.

Не синхронизируется: пароли в открытом виде (ниже), структура OU (в облаке её нет), политики, sIDHistory, срок действия учётной записи accountExpires (просроченная в домене учётная запись в облаке остаётся рабочей), локальные атрибуты вроде homeDirectory. SID едет как атрибут onPremisesSecurityIdentifier, но доступ в облаке по нему не проверяется. Хеш пароля синхронизируется только у объектов класса user, у inetOrgPerson — нет.

Якорь. Облаку нужно знать, что объект, который приехал сегодня, — тот же, что вчера, даже если его переименовали или перенесли. Для этого Entra Connect вычисляет для каждого объекта неизменяемый sourceAnchor, а облако хранит его как immutableId (в Microsoft Graph — onPremisesImmutableId). Источник якоря выбирается при установке; потом его можно сменить только с objectGUID на mS-DS-ConsistencyGuid (задача мастера Configure Source Anchor). По умолчанию это атрибут mS-DS-ConsistencyGuid: при первой синхронизации Entra Connect записывает в него objectGUID объекта и дальше ориентируется только на него. Ради этого атрибут и отделён от objectGUID: objectGUID при переносе в другой лес меняется, а mS-DS-ConsistencyGuid можно скопировать вместе с объектом и сохранить связь с облаком. В мастере можно выбрать и сам objectGUID — так ставили до 2017 года, и так стоят многие старые установки.

PS C:\> Get-ADUser alice -Properties mS-DS-ConsistencyGuid | Select-Object ObjectGUID, @{n='ConsistencyGuid'; e={[guid]$_.'mS-DS-ConsistencyGuid'}}, @{n='immutableId'; e={[Convert]::ToBase64String($_.'mS-DS-ConsistencyGuid')}}

ObjectGUID                           ConsistencyGuid                      immutableId
----------                           ---------------                      -----------
9c3f1a2b-7d4e-4f60-8a1b-2c3d4e5f6a7b 9c3f1a2b-7d4e-4f60-8a1b-2c3d4e5f6a7b Kxo/nE59YE+KGyw9Tl9qew==

Base64 от байтов GUID — тот самый immutableId, который видно в облаке.

Три способа входа

Пользователь вводит пароль на странице входа Microsoft. Контроллера домена у облака нет. Три варианта того, кто проверяет:

Синхронизация хешей паролей (PHS). Каждые две минуты агент на сервере синхронизации запрашивает у контроллера изменившиеся хеши паролей (атрибут unicodePwd) тем же протоколом репликации MS-DRSR, которым обмениваются контроллеры (часть 10). В unicodePwd лежит NT-хеш — MD4 от пароля в UTF-16, того же вида, что ключ RC4 в Kerberos. Контроллер отдаёт его зашифрованным ключом сеанса RPC, агент расшифровывает и в облако отправляет не сам хеш, а результат PBKDF2 — функции, которая многократно прогоняет входные данные через HMAC-SHA256, чтобы перебор стал дорогим: NT-хеш плюс десятибайтная соль пользователя, тысяча итераций. Облако хранит этот результат и при входе проделывает с введённым паролем те же шаги. Исходный NT-хеш в облако не уходит, поэтому украденное из облака значение не годится для атаки pass-the-hash в домене — входа с хешем вместо пароля. Работает, когда домен недоступен; позволяет облаку сообщать об утёкших паролях; не требует ничего на стороне сети. Рекомендуемый вариант, и дальше в части он.

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

Федерация. Облако не проверяет пароль вовсе, а перенаправляет пользователя на собственный сервер организации — AD FS (Active Directory Federation Services, роль Windows Server) или сторонний провайдер — по SAML или WS-Federation, и тот после проверки выдаёт подписанный токен. Самый гибкий (смарт-карты, собственные условия) и самый тяжёлый: ферма серверов, прокси, сертификаты, и облако недоступно, когда недоступна ферма. Microsoft последовательно переводит заказчиков с федерации на PHS с условным доступом.

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

UPN и домены

В облако пользователь входит по UPN: alice@example.com. Суффикс UPN должен быть подтверждённым доменом арендатора — тем, для которого в публичном DNS есть TXT-запись, доказывающая владение. corp.example.com подтвердить нельзя без example.com, а company.local нельзя никогда. Пользователи с неподтверждённым суффиксом получают в облаке UPN вида alice@example.onmicrosoft.com, и это создаёт путаницу на годы.

Поэтому до синхронизации: в арендаторе подтверждается example.com, в лесу добавляется такой суффикс, и всем синхронизируемым пользователям меняется UPN:

PS C:\> Set-ADForest -Identity corp.example.com -UPNSuffixes @{ Add = 'example.com' }
PS C:\> Get-ADUser -SearchBase 'OU=Departments,DC=corp,DC=example,DC=com' -Filter 'Enabled -eq $true' |
    ForEach-Object { Set-ADUser $_ -UserPrincipalName "$($_.SamAccountName)@example.com" }
PS C:\> Get-ADUser alice | Select-Object UserPrincipalName

UserPrincipalName
-----------------
alice@example.com

На вход в домен это не влияет: CORP\alice и Kerberos-принципал alice@CORP.EXAMPLE.COM остаются прежними, а alice@example.com принимается контроллером как UPN (часть 3). Идеально, когда UPN совпадает с основным адресом почты: пользователь знает одно имя.

Перед установкой каталог проверяют утилитой IdFix от Microsoft: дубликаты proxyAddresses и UPN, недопустимые символы, пустые обязательные атрибуты. Облако отвергнет такие объекты при синхронизации, а IdFix покажет их заранее.

Установка

Сервер sync1.corp.example.com: рядовой член домена с полным графическим интерфейсом (Server Core не поддерживается), Microsoft рекомендует Windows Server 2022 или 2025, с исходящим HTTPS к адресам Microsoft. На контроллер ставить можно, но тогда у контроллера появляются ещё и обязанности сервера синхронизации. Установщик AzureADConnect.msi новых версий публикуется только в центре администрирования Microsoft Entra. Мастер в режиме Customize (экспресс-режим синхронизирует весь лес, выдаёт учётной записи синхронизации права с запасом и годится для лаборатории, но не для организации):

  1. Компоненты: учётная запись службы ADSync — по умолчанию виртуальная NT SERVICE\ADSync, при установке на контроллер мастер создаёт управляемую учётную запись ADSyncMSA…, можно указать и групповую управляемую из части 13; база — SQL Server Express LocalDB (предел 10 ГБ, около 100 тысяч объектов) или полноценный SQL Server.
  2. Вход пользователей: Password Hash Synchronization, с флажком Enable single sign-on.
  3. Подключение к Entra ID: учётная запись с ролью Hybrid Identity Administrator, назначенной напрямую, а не через группу. Сама она на сервере не остаётся: мастер регистрирует в арендаторе приложение, и сервер входит в облако его сертификатом по OAuth 2.0 (client credentials). Сертификат лежит на сервере, в TPM (аппаратном модуле, из которого закрытый ключ не извлекается), если он есть, живёт 90 дней и сменяется сам. Так ставятся все новые установки начиная с версии 2.5.76; старым до 7 апреля 2027 года нужно перейти на версию не ниже 2.6.84 и на вход приложением, иначе синхронизация остановится.
  4. Подключение к каталогу: лес corp.example.com, учётная запись Enterprise Admin — только для установки; мастер создаст свою.
  5. Идентификация пользователей: «Let Azure manage the source anchor» — мастер возьмёт якорем mS-DS-ConsistencyGuid, если этот атрибут ещё ни у кого в каталоге не заполнен.
  6. Фильтрация: домены и OU — только OU=Departments и OU=Groups; служебные учётные записи, администраторов и OU=Servers в облаке не нужно.
  7. Необязательные функции: обратная запись паролей для самостоятельного сброса, расширения каталога, гибридный Exchange — по потребности.
  8. Seamless SSO: учётные данные администратора домена, чтобы создать учётную запись компьютера AZUREADSSOACC.

Что мастер оставил в каталоге:

PS C:\> Get-ADUser -Filter 'Name -like "MSOL_*"' -Properties Description | Format-List Name, Description

Name        : MSOL_a1b2c3d4e5f6
Description : Account created by Microsoft Azure Active Directory Connect with installation identifier a1b2c3d4e5f64c7d8e9fa0b1c2d3e4f5 running on computer SYNC1 configured to synchronize to tenant example.onmicrosoft.com. This account must have directory replication permissions in the local Active Directory and write permission on certain attributes to enable Hybrid Deployment.

PS C:\> (Get-Acl 'AD:\DC=corp,DC=example,DC=com').Access | Where-Object IdentityReference -like '*MSOL_*' | Select-Object ActiveDirectoryRights, ObjectType, InheritedObjectType, InheritanceType

      ActiveDirectoryRights ObjectType                           InheritedObjectType                  InheritanceType
      --------------------- ----------                           -------------------                  ---------------
               ReadProperty 00000000-0000-0000-0000-000000000000 f0f8ffac-1191-11d0-a060-00aa006c33ed     Descendents
ReadProperty, WriteProperty 00000000-0000-0000-0000-000000000000 4828cc14-1437-45bc-9b07-ad6f015e5f28     Descendents
ReadProperty, WriteProperty 00000000-0000-0000-0000-000000000000 bf967a9c-0de6-11d0-a285-00aa003049e2     Descendents
              ExtendedRight 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 00000000-0000-0000-0000-000000000000            None
ReadProperty, WriteProperty 00000000-0000-0000-0000-000000000000 bf967aba-0de6-11d0-a285-00aa003049e2     Descendents
              ExtendedRight 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 00000000-0000-0000-0000-000000000000            None
ReadProperty, WriteProperty 00000000-0000-0000-0000-000000000000 5cb41ed0-0e4c-11d0-a286-00aa003049e2     Descendents
              WriteProperty 5b47d60f-6090-40b2-9f37-2a4de88f3063 5df2b673-6d41-4774-b3e8-d52e8ee9ff99     Descendents
              ExtendedRight 00299570-246d-11d0-a768-00aa006e0529 bf967aba-0de6-11d0-a285-00aa003049e2     Descendents

GUID в ObjectType — право или атрибут, в InheritedObjectType — класс объектов, на которые запись действует. Это права учётной записи, которую мастер создал в экспресс-режиме, со всеми функциями, что включались хоть раз:

Запись Что даёт Для чего
1131f6aa… и 1131f6ad… на корне домена Replicating Directory Changes и Replicating Directory Changes All чтение изменений и хешей паролей по репликации (PHS)
чтение и запись всех свойств user (bf967aba…), inetOrgPerson (4828cc14…), group (bf967a9c…), contact (5cb41ed0…) любые атрибуты этих объектов обратная запись гибридного Exchange
00299570… для user Reset Password обратная запись паролей
запись msDS-KeyCredentialLink (5b47d60f…) для msDS-Device (5df2b673…) ключи устройств обратная запись ключей Windows Hello
чтение всех свойств publicFolder (f0f8ffac…) общие папки Exchange синхронизация почтовых общих папок

Два права на корне домена — ровно то, что нужно контроллеру, чтобы реплицировать каталог вместе с паролями. Запись всех свойств пользователей — больше, чем нужно любой одной функции: с ней можно переписать servicePrincipalName или msDS-KeyCredentialLink любого незащищённого пользователя и войти от его имени. Мастер права выдаёт, но не отбирает, когда функцию выключают. Поэтому в организации учётную запись коннектора создают сами и дают ей только права включённых функций — модулем AdSyncConfig из папки установки (о нём подробнее в части 32).

Учётная запись MSOL_… с такими правами и сертификат приложения, которым сервер входит в арендатор, делают sync1 сервером уровня 0 из части 15: кто управляет им, тот управляет и доменом, и облаком. Microsoft прямо требует обращаться с ним как с компонентом уровня 0. Доступ на него — как на контроллер.

Синхронизация

Движок работает циклами: раз в 30 минут — дельта (изменения с прошлого раза), хеши паролей — каждые две минуты отдельным потоком. Модуль ADSync на сервере синхронизации:

PS C:\> Get-ADSyncScheduler

AllowedSyncCycleInterval            : 00:30:00
CurrentlyEffectiveSyncCycleInterval : 00:30:00
CustomizedSyncCycleInterval         :
NextSyncCyclePolicyType             : Delta
NextSyncCycleStartTimeInUTC         : 15.10.2026 15:00:12
PurgeRunHistoryInterval             : 7.00:00:00
SyncCycleEnabled                    : True
MaintenanceEnabled                  : True
StagingModeEnabled                  : False
SchedulerSuspended                  : False
SyncCycleInProgress                 : False

PS C:\> Get-ADSyncConnector | Select-Object Name, Type

Name                          Type
----                          ----
example.onmicrosoft.com - AAD Extensible2
corp.example.com              AD

Два коннектора — к каталогу и к облаку, — и между ними метавселенная (metaverse): собственная база, куда объекты импортируются из обоих источников, объединяются по правилам и из которой экспортируются. Один цикл — шесть шагов, по три на каждый коннектор: импорт изменений, синхронизация (применение правил к метавселенной) и экспорт. История запусков хранится семь дней (PurgeRunHistoryInterval):

PS C:\> Get-ADSyncRunProfileResult -NumberRequested 6 | Select-Object ConnectorName, RunProfileName, Result, StartDate

ConnectorName                 RunProfileName        Result  StartDate
-------------                 --------------        ------  ---------
corp.example.com              Export                success 15.10.2026 15:00:43
example.onmicrosoft.com - AAD Export                success 15.10.2026 15:00:36
example.onmicrosoft.com - AAD Delta Synchronization success 15.10.2026 15:00:35
corp.example.com              Delta Synchronization success 15.10.2026 15:00:34
example.onmicrosoft.com - AAD Delta Import          success 15.10.2026 15:00:29
corp.example.com              Delta Import          success 15.10.2026 15:00:28

Внеочередной цикл запускают так, а -PolicyType Initial вместо Delta даёт полный цикл, который заново прогоняет все объекты через правила:

PS C:\> Start-ADSyncSyncCycle -PolicyType Delta

Result
------
Success

Success здесь значит только «цикл поставлен в очередь»; результат — в истории запусков. Пока цикл идёт, Get-ADSyncConnectorRunStatus показывает работающий коннектор и шаг, а между циклами не выводит ничего.

Не всё в модуле ADSync работает издалека. Get-ADSyncScheduler, Get-ADSyncConnector, Get-ADSyncPartitionPasswordSyncState отвечают и через Invoke-Command (часть 14), а история запусков, правила, глобальные настройки и объекты пространства коннектора — только в сеансе, открытом на самом сервере. Из удалённого сеанса, по WinRM или SSH, они отвечают одинаково:

Get-ADSyncRunProfileResult: There was no endpoint listening at net.pipe://localhost/ADSyncManagement that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Правила. Объекты из коннекторов в метавселенную и обратно переводят правила синхронизации: входящие — из каталога и облака в метавселенную, исходящие — из метавселенной в облако и в каталог; у каждого приоритет (меньше число — главнее) и выражения для атрибутов. Встроенных правил несколько десятков:

PS C:\> Get-ADSyncRule | Group-Object Direction | Select-Object Name, Count

Name     Count
----     -----
Inbound     23
Outbound    30

Свои правила добавляют в редакторе Synchronization Rules Editor, когда нужно, например, положить в облачный department значение из extensionAttribute3. Встроенные не правят, а перекрывают своими с меньшим приоритетом: обновление Entra Connect встроенные перезаписывает. Консоль Synchronization Service Manager (miisclient.exe) показывает каждый цикл: сколько объектов добавлено, изменено, какие ошибки — она же первое место для разбора «пользователь не появился».

Какой якорь выбран и что ещё включено при установке — в глобальных настройках сервера:

PS C:\> (Get-ADSyncGlobalSettings).Parameters | Where-Object Name -in 'Microsoft.SynchronizationOption.AnchorAttribute', 'Microsoft.UserSignIn.SignOnMethod', 'Microsoft.UserSignIn.DesktopSsoEnabled', 'Microsoft.OptionalFeature.ExportDeletionThreshold', 'Microsoft.OptionalFeature.ExportDeletionThresholdValue', 'Microsoft.Synchronize.ServerConfigurationVersion' | Select-Object Name, Value

Name                                                   Value
----                                                   -----
Microsoft.UserSignIn.DesktopSsoEnabled                 True
Microsoft.OptionalFeature.ExportDeletionThresholdValue 500
Microsoft.SynchronizationOption.AnchorAttribute        objectGUID
Microsoft.Synchronize.ServerConfigurationVersion       2.6.92.0
Microsoft.OptionalFeature.ExportDeletionThreshold      True
Microsoft.UserSignIn.SignOnMethod                      PasswordHashSync

Этот сервер поставлен с якорем objectGUID. Так бывает и без явного выбора: в режиме «Let Azure manage the source anchor» мастер берёт mS-DS-ConsistencyGuid, только если атрибут не заполнен ни у одного объекта каталога (или если прошлая установка записала свой выбор в арендатор), а если атрибут уже заполнила прошлая синхронизация, решает, что им пользуется другое приложение, и берёт objectGUID. Тогда mS-DS-ConsistencyGuid синхронизация не пишет вовсе, а якорь каждого объекта — Base64 от его objectGUID. При установке по умолчанию в AnchorAttribute стоит mS-DS-ConsistencyGuid. Остальное: вход — синхронизация хешей, Seamless SSO включён, порог удаления — 500 объектов за цикл (о нём в части 32).

Фильтрация. Список OU меняется в свойствах коннектора каталога — в мастере (задача Customize synchronization options) или в консоли — и виден в его настройках:

PS C:\> (Get-ADSyncConnector -Name 'corp.example.com').Partitions.ConnectorPartitionScope | Format-List ContainerInclusionList, ContainerExclusionList

ContainerInclusionList : {OU=Departments,DC=corp,DC=example,DC=com, OU=Groups,DC=corp,DC=example,DC=com}
ContainerExclusionList : {CN=LostAndFound,DC=corp,DC=example,DC=com, DC=corp,DC=example,DC=com}

Корень домена исключён, включены только две OU. После изменения нужен полный цикл, Start-ADSyncSyncCycle -PolicyType Initial. Фильтрация по атрибуту — правило, выставляющее в метавселенной cloudFiltered = True, отсекает объекты внутри OU — например, всех с extensionAttribute15 = NoSync. Так же работает встроенная фильтрация: правило In from AD - User Join само не пускает в облако krbtgt_…, MSOL_…, AAD_… и служебные ящики Exchange.

Второй сервер ставится в staging mode (промежуточный режим): он импортирует и вычисляет всё то же самое, но не экспортирует. При отказе основного на втором снимают этот режим в мастере (задача Configure staging mode), а основной переводят в него; командлетом режим не переключается, Get-ADSyncScheduler только показывает его в StagingModeEnabled. Два активных сервера одновременно недопустимы.

Перенос на другой сервер идёт через тот же промежуточный режим. Каждый раз, когда настройки меняют в мастере, сервер сам сохраняет их в %ProgramData%\AADConnect файлом Applied-SynchronizationPolicy-<дата>-<время>.json; изменения, сделанные через PowerShell или редактор правил, туда не попадают, их выгружают задачей мастера View or export current configuration. На новом сервере мастер в режиме Customize с флажком Import synchronization settings берёт этот файл и по умолчанию включает промежуточный режим. Учётные данные из файла не переносятся: учётную запись для каталога и вход в облако задают заново. Когда результаты нового сервера совпали с результатами старого, старый переводят в промежуточный режим, новый выводят из него, и только после этого старый удаляют.

Удаление Entra Connect со старого сервера не убирает его учётные записи:

  • в каталоге остаётся его MSOL_… — в описании указаны компьютер и идентификатор установки — вместе с правами репликации на корне домена. Если новый сервер создал свою учётную запись, старую удаляют, а её записи в списке прав корня домена после этого остаются правилами неизвестного SID, и их снимают отдельно;
  • в облаке у установок со старым способом входа остаётся учётная запись Sync_<СЕРВЕР>_<идентификатор>@example.onmicrosoft.com с ролью Directory Synchronization Accounts — своя у каждого сервера, в том числе у сервера в промежуточном режиме; таких учётных записей в арендаторе может быть не больше 20. Их список и удаление — модулем Microsoft Graph PowerShell:
PS C:\> Connect-MgGraph
PS C:\> $role = Get-MgDirectoryRole | Where-Object DisplayName -eq 'Directory Synchronization Accounts'
PS C:\> Get-MgDirectoryRoleMember -DirectoryRoleId $role.Id | Select-Object Id, @{n='UserPrincipalName'; e={$_.AdditionalProperties.userPrincipalName}}
PS C:\> Remove-MgUser -UserId <Id учётной записи старого сервера>

Сервер, который входит в облако приложением, такой учётной записи не имеет; каким способом он входит, показывает Get-ADSyncEntraConnectorCredential на нём самом:

PS C:\> Get-ADSyncEntraConnectorCredential | Select-Object ConnectorIdentityType

ConnectorIdentityType
---------------------
Application

После перевода сервера со старого способа на приложение Microsoft рекомендует удалить его прежнюю учётную запись командой Remove-ADSyncAADServiceAccount -AADCredential (Get-Credential) -Name Sync_<СЕРВЕР>_<идентификатор> — с учётными данными администратора облака. Что делать с приложением выведенного сервера, документация не говорит; найти его можно в регистрациях приложений арендатора по идентификатору, который на старом сервере показывал тот же Get-ADSyncEntraConnectorCredential, и неиспользуемое приложение с действующим сертификатом лучше удалить.

Остановить синхронизацию на время работ — Set-ADSyncScheduler -SyncCycleEnabled $false; забыть включить обратно — классическая причина, по которой «новые сотрудники не получают почту».

Seamless SSO

Пользователь на машине домена открывает Outlook в браузере и не вводит пароль. Для этого в каталоге при установке появилась учётная запись компьютера AZUREADSSOACC со SPN HTTP/autologon.microsoftazuread-sso.com, а её ключ Kerberos (пароль, который мастер задал) передан в облако:

PS C:\> Get-ADComputer AZUREADSSOACC -Properties servicePrincipalName | Select-Object -ExpandProperty servicePrincipalName
HTTP/www.tm.a.prd.aadg.akadns.net
HTTP/www.tm.a.prd.aadg.trafficmanager.net
HTTP/aadg.windows.net.nsatc.net
HTTP/autologon.prda.aadg.msidentity.com
HTTP/autologon.microsoftazuread-sso.com
RestrictedKrbHost/www.tm.a.prd.aadg.akadns.net
RestrictedKrbHost/www.tm.a.prd.aadg.trafficmanager.net
RestrictedKrbHost/aadg.windows.net.nsatc.net
RestrictedKrbHost/autologon.prda.aadg.msidentity.com
RestrictedKrbHost/autologon.microsoftazuread-sso.com

Браузер просит билет на то имя, которое видит в адресе, — autologon.microsoftazuread-sso.com; остальные SPN — внутренние имена той же службы Microsoft за балансировщиком, они нужны, чтобы билет нашёлся под любым из них.

Дальше — ровно часть 6: браузер, получив от страницы входа перенаправление на https://autologon.microsoftazuread-sso.com/… с вызовом 401 Negotiate, просит у контроллера билет на HTTP/autologon.microsoftazuread-sso.com, получает его (ключом AZUREADSSOACC), отправляет облаку, а облако, зная тот же ключ, расшифровывает билет, читает из него UPN и SID и выдаёт сеанс. Контроллер домена — обычный KDC, облако — обычная служба со своим ключом, и единственная необычность в том, что служба — за пределами сети.

Условие на клиенте — то же, что для интранет-сайта в части 30: адрес должен быть в зоне «Местная интрасеть», иначе браузер не отправит билет. Политика Site to Zone Assignment с записью https://autologon.microsoftazuread-sso.com → зона 1, через часть 24:

PS C:\> $gpo = New-GPO -Name 'Browser - Intranet zone'
PS C:\> Set-ADObject "CN={$($gpo.Id)},CN=Policies,CN=System,DC=corp,DC=example,DC=com" -Replace @{
    gPCUserExtensionNames = '[{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{D02B1F73-3407-48AE-BA88-E8213C6761F1}][{4CFB60C1-FAA6-47F1-89AA-0B18730C9FD3}{D02B1F73-3407-48AE-BA88-E8213C6761F1}]' }
PS C:\> $key = 'HKCU\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings'
PS C:\> Set-GPRegistryValue -Guid $gpo.Id -Key $key -ValueName 'ListBox_Support_ZoneMapKey' -Type DWord -Value 1
PS C:\> Set-GPRegistryValue -Guid $gpo.Id -Key "$key\ZoneMapKey" -ValueName 'https://autologon.microsoftazuread-sso.com' -Type String -Value 1
PS C:\> Set-GPRegistryValue -Guid $gpo.Id -Key "$key\ZoneMapKey" -ValueName 'https://intranet.corp.example.com' -Type String -Value 1
PS C:\> New-GPLink -Guid $gpo.Id -Target 'DC=corp,DC=example,DC=com' -LinkEnabled Yes

Каждая Set-GPRegistryValue в ответ выводит объект политики с новым временем изменения, New-GPLink — созданную привязку. Это та же политика, что для интранета была нужна в части 30: ZoneMapKey со значением 1 — зона «Местная интрасеть». Edge и Chrome берут зоны у Windows, так же как Internet Explorer. Политика пользовательская: пользователи могут лежать в разных OU, а зоны — настройка профиля пользователя.

Строка с Set-ADObject здесь не лишняя. ZoneMapKey — только хранилище списка из шаблона: сам по себе он зон не меняет. Рабочие записи вида …\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon с параметром https = 1 из него строит отдельное расширение групповой политики на клиенте (client-side extension, CSE) — «Internet Explorer Zonemapping», библиотека iedkcs32.dll, GUID {4CFB60C1-FAA6-47F1-89AA-0B18730C9FD3}. Клиент запускает для GPO только те расширения, которые перечислены в его атрибуте gPCUserExtensionNames (для компьютерной части — gPCMachineExtensionNames): пары «GUID расширения, GUID оснастки редактора». Редактор групповой политики, сохраняя «Site to Zone Assignment List», дописывает туда Zonemapping сам; Set-GPRegistryValue знает только расширение Registry {35378EAC-…}. Без исправления атрибута политика применяется, gpresult её показывает, значение в ZoneMapKey лежит в реестре, а адрес остаётся в зоне «Интернет», и браузер вместо билета показывает форму пароля. Set-ADObject стоит до Set-GPRegistryValue, чтобы следующая запись подняла версию GPO и клиенты, уже видевшие её, обработали политику заново.

Проверка на клиенте после gpupdate /target:user /force — что запись появилась там, где её читает Windows:

PS C:\> Get-ItemProperty 'HKCU:\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon' | Select-Object https

https
-----
    1

Браузер, запущенный до обновления политики, перечитает зоны только после перезапуска.

Типы шифрования. Билет зашифрован ключом AZUREADSSOACC, и облако должно иметь ключ того же типа. Если у учётной записи не задан атрибут msDS-SupportedEncryptionTypes, мастер и ротация передают в облако только ключ RC4, а контроллеры на Windows Server 2025 билетов RC4 не выдают: билет приходит в AES-256, облако расшифровать его не может и отвечает AADSTS81004: Kerberos authentication failed. Поэтому до первой ротации учётной записи разрешают только AES (24 = AES128 + AES256), а потом ротируют ключ:

PS C:\> Set-ADComputer AZUREADSSOACC -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }

Ключ AZUREADSSOACC стоит менять раз в 30 дней — как пароль любой учётной записи компьютера, но здесь автоматики нет: Update-AzureADSSOForest из модуля AzureADSSO на сервере синхронизации с учётными данными администратора домена и арендатора. Модуль из Entra Connect 2.6.92 в PowerShell 7 не работает (ему нужна WCF, Windows Communication Foundation — библиотека .NET Framework для вызова веб-служб, которой в .NET нынешних версий нет), а в Windows PowerShell 5.1 спотыкается о версию сборки Microsoft.IdentityModel.Abstractions, которую требует MSAL — библиотека Microsoft для получения токенов OAuth у Entra ID: мастер Entra Connect обходит это перенаправлением версий в своём конфиге, а консоль — нет. Перед ротацией стоит проверить, исправлено ли это в установленной версии. Учётная запись имеет те же свойства уровня 0: тот, у кого есть её ключ, выпишет билет в облако от имени любого пользователя.

Проверка без браузера. Принимает ли облако билет, видно и без страницы входа: curl.exe из Windows умеет Negotiate и сам запросит билет у контроллера.

PS C:\> klist purge
PS C:\> curl.exe --negotiate -u : -s -o NUL -w '%{http_code}' "https://autologon.microsoftazuread-sso.com/example.com/winauth/sso?client-request-id=$([guid]::NewGuid())"
200

klist purge сначала выбрасывает билеты из кеша сеанса, чтобы curl запросил новый. 200 — облако расшифровало билет; 403 с AADSTS81004 в теле ответа — ключ в облаке не совпадает с ключом в каталоге или с типом шифрования билета. После ротации облаку нужно несколько минут. curl сам отправляет билет на любой адрес и зоны не проверяет, поэтому 200 здесь при форме пароля в браузере означает, что дело в зоне на клиенте.

Чего Seamless SSO не делает. Он заменяет только ввод пароля. Если условный доступ или настройки безопасности по умолчанию требуют многофакторную проверку (MFA), запрос подтверждения на телефоне после входа по билету останется: для облака билет Kerberos — тот же первый фактор, что и пароль. И в приватных окнах — InPrivate в Edge, инкогнито в Chrome — браузеры по умолчанию не отправляют Kerberos ни на какой адрес, так что проверять вход нужно в обычном профиле.

Для Windows 10 и 11 Seamless SSO — запасной механизм: машины с гибридной регистрацией (часть 32) входят в облако токеном устройства при входе в систему, и браузеру ничего не нужно. Seamless SSO остаётся для старых Windows, для машин без гибридной регистрации и для Firefox без интеграции.

Смотрим руками

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

PS C:\> $ad = Get-ADSyncCSObject -ConnectorName 'corp.example.com' -DistinguishedName 'CN=Alice Smith,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com'
PS C:\> $mv = Get-ADSyncMVObject -Identifier $ad.ConnectedMVObjectId
PS C:\> $dn = ($mv.Lineage | Where-Object ConnectorName -like '*- AAD').ConnectedCsObjectDN
PS C:\> $cs = Get-ADSyncCSObject -ConnectorName 'example.onmicrosoft.com - AAD' -DistinguishedName $dn
PS C:\> $cs.Attributes | Where-Object Name -in 'userPrincipalName', 'sourceAnchor', 'cloudAnchor', 'cloudMastered', 'onPremisesSamAccountName', 'onPremiseSecurityIdentifier', 'onPremisesDistinguishedName', 'accountEnabled' | Select-Object Name, @{n='Value'; e={$_.Values -join ', '}}

Name                        Value
----                        -----
accountEnabled              true
cloudAnchor                 User_5d1e7c2a-3b4f-4e6a-9c8d-7f0a1b2c3d4e
cloudMastered               false
onPremiseSecurityIdentifier AQUAAAAAAAUVAAAAx/f+13x3VciUWs4BUAQAAA==
onPremisesDistinguishedName CN=Alice Smith,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com
onPremisesSamAccountName    alice
sourceAnchor                Kxo/nE59YE+KGyw9Tl9qew==
userPrincipalName           alice@example.com

sourceAnchor совпадает с Base64 от mS-DS-ConsistencyGuid; cloudAnchor — идентификатор объекта в облаке (User_ и его id в Microsoft Graph); onPremiseSecurityIdentifier — SID из части 3 в двоичном виде; cloudMastered = false — объектом владеет домен, и в облаке он не редактируется. Со стороны облака то же показывает модуль Microsoft Graph PowerShell — свойства OnPremisesSyncEnabled, OnPremisesImmutableId, OnPremisesSecurityIdentifier, OnPremisesSamAccountName, OnPremisesLastSyncDateTime у Get-MgUser; для этого нужен вход в арендатор с разрешением User.Read.All:

PS C:\> Connect-MgGraph -Scopes 'User.Read.All' -NoWelcome
PS C:\> Get-MgUser -UserId alice@example.com -Property UserPrincipalName, OnPremisesSyncEnabled, OnPremisesImmutableId, OnPremisesLastSyncDateTime, OnPremisesSamAccountName, OnPremisesSecurityIdentifier | Format-List UserPrincipalName, OnPremises*

Пока OnPremisesSyncEnabled = True, объект в облаке не редактируется: все изменения — в домене.

Синхронизация паролей. Когда агент последний раз отработал успешно:

PS C:\> Get-ADSyncPartitionPasswordSyncState | Where-Object DN -ne 'default' | Format-List DN, PasswordSyncLastSuccessfulCycleEndTimestamp, PasswordSyncLastCycleStatus

DN                                          : DC=corp,DC=example,DC=com
PasswordSyncLastSuccessfulCycleEndTimestamp : 15.10.2026 15:02:33
PasswordSyncLastCycleStatus                 : Successful

Время — UTC, и оно сдвигается каждые две минуты, даже если пароли не менялись: агент спрашивает контроллер по расписанию. Смена пароля конкретного пользователя по документации оставляет в журнале Application сервера синхронизации пару событий источника Directory Synchronization: 656 «Password Change Request» и 657 «Password Change Result» с якорем и DN пользователя:

PS C:\> Invoke-Command -ComputerName sync1 { $ids = 656, 657; Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Directory Synchronization'; Id=$ids} -MaxEvents 2 }

Массив кодов передаётся переменной: внутри Invoke-Command Windows PowerShell 5.1 с литералом Id=656, 657 событий не находит.

Синхронизация паролей глазами контроллера. Если на контроллере включён аудит Directory Service Access, каждые две минуты в журнале Security появляются три события 4662 от учётной записи MSOL_… — на сам объект домена (класс domainDNS), с правами репликации:

PS C:\> Invoke-Command -ComputerName dc1 {
    Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4662; StartTime=(Get-Date).AddMinutes(-3)} |
        Where-Object { $_.Properties[1].Value -like 'MSOL_*' } |
        Select-Object TimeCreated, @{n='Object'; e={$_.Properties[6].Value}}, @{n='Right'; e={($_.Properties[11].Value -split '\s+' | Where-Object { $_ })[1]}}
} | Format-Table TimeCreated, Object, Right

TimeCreated         Object                                  Right
-----------         ------                                  -----
15.10.2026 18:02:33 %{6b1f2e3d-4c5a-4b69-8d7e-0f1a2b3c4d5e} {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}
15.10.2026 18:02:33 %{6b1f2e3d-4c5a-4b69-8d7e-0f1a2b3c4d5e} {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2}
15.10.2026 18:02:33 %{6b1f2e3d-4c5a-4b69-8d7e-0f1a2b3c4d5e} {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}

Object — objectGUID домена ((Get-ADDomain).ObjectGUID), Right — Replicating Directory Changes All дважды и Replicating Directory Changes один раз. Ровно так в журнале выглядит атака DCSync, когда злоумышленник с этими правами вытягивает хеши как контроллер. Поэтому правила обнаружения DCSync должны знать эту учётную запись и этот сервер как исключение, а сами права — оставаться только у неё.

Билет Seamless SSO на рабочей станции после входа в Outlook в браузере:

PS C:\> klist | Select-String -Pattern 'autologon' -Context 0,2

>       Server: HTTP/autologon.microsoftazuread-sso.com @ CORP.EXAMPLE.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize

Обычный сервисный билет, выданный нашим KDC на службу, которая находится в облаке Microsoft.

Якорь в метаданных каталога. Кто и когда записал mS-DS-ConsistencyGuid, видно в метаданных репликации (часть 10):

PS C:\> repadmin /showobjmeta dc2 "CN=Alice Smith,OU=Sales,OU=Departments,DC=corp,DC=example,DC=com" | Select-String ConsistencyGuid

20481533                                Office\DC2   6118432 2026-10-15 14:58:07    1 mS-DS-ConsistencyGuid

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

Источники

Entra Connect и гибридная идентичность:

  • What is Microsoft Entra Connect? — компоненты Entra Connect, синхронизация, способы входа, Connect Health;
  • What is Microsoft Entra Cloud Sync? — облегчённый агент и сравнение с Connect;
  • Prerequisites and hardware — версии Windows Server, Server Core, LocalDB и 100 тысяч объектов, уровень 0, обязательное обновление до 7 апреля 2027 года;
  • Accounts and permissions — учётная запись коннектора MSOL_…, права экспресс-установки, учётная запись службы ADSync, учётные записи Sync_… в облаке, их предел и удаление;
  • Configure AD DS Connector Account Permissions — модуль AdSyncConfig и права по функциям;
  • Authenticate to Microsoft Entra ID by using application identity — приложение и сертификат вместо учётной записи синхронизации, 90 дней, ротация, Get-ADSyncEntraConnectorCredential и Remove-ADSyncAADServiceAccount.

Якорь и атрибуты:

Способы входа:

Синхронизация:

Seamless SSO:

Аудит и облачная сторона:

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

Дальше — часть 32: сопоставление учётных записей и подводные камни. Мягкое сопоставление по UPN и адресу и жёсткое по якорю; что делать, когда в облаке уже есть учётные записи с теми же именами; защищённые учётные записи и AdminSDHolder, на которых синхронизация спотыкается; обратная запись паролей; гибридная регистрация устройств; и чего не стоит делать с объектом, у которого есть двойник в облаке.

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

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

© 2006-2026 Виталий Лещенко