1 ноября 2026, 08:13Виталий Лещенко

Windows Server для самых маленьких. Часть 32: Как сопоставляются учётные записи и где подводные камни?

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

Коротко

Объект из домена связывается с облачным жёстко — по якорю immutableId, равному Base64 от mS-DS-ConsistencyGuid или objectGUID, — или мягко, по основному адресу в proxyAddresses или по UPN; не совпало — облако создаёт второй объект, а совпадающий адрес или UPN уходит в карантин. Защищённым учётным записям с adminCount = 1 синхронизация не может записать якорь и пароль, а права через AdminSDHolder с наследованием «только для дочерних» на них самих не действуют. Перенос пользователя в OU вне области синхронизации удаляет его облачную учётную запись вместе с почтой и OneDrive.

В части 31 синхронизация создавала учётные записи в облаке с нуля. Так бывает редко. Обычно к моменту, когда в организации появляется Entra Connect, в облаке уже год живут учётные записи, заведённые руками при подключении Microsoft 365: с теми же именами, с почтой, с OneDrive, полным документов. Синхронизация должна не создать дубликаты, а связать существующее, и правила этой связи — первая половина заключительной части. Вторая — о том, что в домене синхронизация обходит стороной, и о действиях, которые выглядят безобидными, пока у объекта нет двойника в облаке.

Два вида сопоставления

Когда из домена в облако впервые приходит объект, Entra ID ищет для него пару среди своих объектов. Проверка идёт только для новых объектов: если потом поменять уже синхронизированный так, что он совпадёт с чужим, будет ошибка, а не сопоставление.

Жёсткое сопоставление (hard match) — по якорю: sourceAnchor пришедшего объекта равен immutableId облачного. Так связь восстанавливается после переустановки сервера синхронизации или после переезда в новый лес с сохранением mS-DS-ConsistencyGuid. Якорь можно задать облачной учётной записи и руками, чтобы заставить её считаться парой конкретной доменной, — Base64 от того, что служит якорем: mS-DS-ConsistencyGuid, а пока он пуст — objectGUID:

PS C:\> $guid = (Get-ADUser carol).ObjectGUID
PS C:\> $immutableId = [Convert]::ToBase64String($guid.ToByteArray())
PS C:\> Connect-MgGraph -Scopes 'User.ReadWrite.All' -NoWelcome
PS C:\> Update-MgUser -UserId carol@example.com -OnPremisesImmutableId $immutableId

Это работает только с облачной учётной записью (cloud-only), у которой якоря ещё нет, и это единственный способ связать учётные записи с разными именами и адресами. С июля 2026 года облако дополнительно не даёт жёсткому сопоставлению захватить учётную запись, которой назначена или доступна привилегированная роль Entra ID, и учётную запись, у которой уже заполнен onPremisesObjectIdentifier, то есть она когда-то была связана с другим объектом домена.

Мягкое сопоставление (soft match) — по содержимому, когда якоря у облачного объекта нет. Два признака:

По адресу: основной адрес из proxyAddresses доменного объекта (значение с префиксом SMTP: заглавными; smtp: строчными — дополнительные адреса, они не участвуют) совпадает с основным адресом облачного.
По UPN: userPrincipalName доменного совпадает с UPN облачного. Это отдельная функция арендатора SoftMatchOnUpnEnabled, в новых арендаторах она включена по умолчанию.

Совпало — облачный объект получает immutableId, становится синхронизированным, и дальше действует жёсткое сопоставление. С учётными записями, у которых есть административная роль в облаке, мягкое сопоставление не работает вовсе: Entra ID защищает их от захвата из домена.

Не совпало — облако создаёт новый объект. Если у него окажется тот же основной адрес или UPN, что у существующего, срабатывает устойчивость к дубликатам (duplicate attribute resiliency, включена во всех арендаторах): облако не отвергает объект, а убирает конфликтующее значение в карантин. UPN, без которого объект не создать, заменяется временным <префикс><четыре цифры>@<начальный домен>.onmicrosoft.com, адрес просто не добавляется. Экспорт при этом считается успешным, и сервер синхронизации ошибки не пишет: конфликт виден только в облаке, в свойстве onPremisesProvisioningErrors объекта (категория PropertyConflict, атрибут UserPrincipalName или ProxyAddresses, конфликтующее значение) и в отчёте об ошибках синхронизации, который приходит техническому контакту арендатора:

PS C:\> Connect-MgGraph -Scopes 'User.Read.All' -NoWelcome
PS C:\> Get-MgUser -All -Property UserPrincipalName, OnPremisesProvisioningErrors | Where-Object { $_.OnPremisesProvisioningErrors } |
    Select-Object UserPrincipalName, @{n='Error'; e={$_.OnPremisesProvisioningErrors.Category}}, @{n='Property'; e={$_.OnPremisesProvisioningErrors.PropertyCausingError}}, @{n='Value'; e={$_.OnPremisesProvisioningErrors.Value}}

Типичный случай: в облаке carol@example.com с почтовым ящиком, а в домене у carol UPN carol@corp.example.com (суффикс не подтверждён и в облаке станет carol@example.onmicrosoft.com) и адрес smtp:carol@example.com, вписанный строчными, то есть дополнительным. Ни UPN, ни основной адрес не совпадают, и в облаке появляется вторая Кэрол без почты, а её адрес оказывается в карантине. Лечится до синхронизации — правильным UPN и основным адресом в домене, для этого и существует IdFix, — или потом жёстким сопоставлением; лишний объект после этого удаляется в облаке.

Microsoft советует держать оба вида сопоставления выключенными, пока они не нужны: запрещающие функции арендатора BlockSoftMatchEnabled и BlockCloudObjectTakeoverThroughHardMatchEnabled держат включёнными и выключают только на время, когда облачные учётные записи действительно переводят под управление домена. Иначе тот, кто может завести объект в синхронизируемой OU, может забрать себе облачную учётную запись с тем же адресом — вместе с почтой и паролем, который после сопоставления станет доменным.

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

Кого не синхронизировать

Три категории, и у каждой своя причина.

Учётные записи аварийного доступа (break-glass): две облачные учётные записи глобального администратора с UPN в onmicrosoft.com, которые не зависят ни от домена, ни от синхронизации, ни от федерации, ни от телефона одного человека. Обязательная многофакторная проверка для порталов администрирования Microsoft касается и их, поэтому Microsoft рекомендует входить в них ключом FIDO2 (аппаратный ключ, который подписывает вход закрытым ключом и не отдаёт его) или сертификатом, хранить ключи в сейфе и отслеживать каждый вход. Если синхронизация или федерация сломаются, они — единственный вход.

Администраторы облака. Учётная запись с ролью Global Administrator, синхронизированная из домена, означает, что администратор домена (или тот, кто взломал контроллер) становится администратором арендатора — пароль-то из домена. Microsoft прямо советует не связывать доменные учётные записи с существующими административными облачными: для ролей в облаке — отдельные облачные учётные записи, в домене они не нужны.

Защищённые учётные записи домена — члены Domain Admins и других групп из части 5, у которых adminCount = 1, наследование прав отключено, а дескриптор безопасности раз в час переписывает из AdminSDHolder процесс SDProp на PDC. Синхронизировать их можно, но обращается с ними синхронизация иначе, и на этом стоит остановиться.

Учётная запись MSOL_… получила права на корне домена, и их наследуют все объекты — кроме защищённых. Читать защищённый объект ей это не мешает: коннектор читает каталог с правами репликации, а они даются на корне и не зависят от прав на объекте. А вот записать в него ей нечего: при якоре mS-DS-ConsistencyGuid Entra Connect не может вписать туда objectGUID, не проходят обратная запись пароля и обратная запись атрибутов. Каждый цикл экспорта в каталог заканчивается для такого объекта ошибкой permission-issue с INSUFF_ACCESS_RIGHTS, а сброс пароля из облака — событием 33004 «ADPermissionsError».

Если защищённые учётные записи всё же нужны в облаке с обратной записью, права выдают не на объектах (SDProp снимет их через час), а на самом AdminSDHolder, откуда SDProp разнесёт их по всем защищённым. Для этого у Entra Connect есть модуль AdSyncConfig в папке установки: он знает, какие права нужны какой функции, и у его командлетов есть ключ -IncludeAdminSdHolders:

PS C:\> Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1'
PS C:\> Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName MSOL_a1b2c3d4e5f6 -ADConnectorAccountDomain corp.example.com -IncludeAdminSdHolders
PS C:\> Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountName MSOL_a1b2c3d4e5f6 -ADConnectorAccountDomain corp.example.com -IncludeAdminSdHolders

Сама Microsoft этот ключ не рекомендует, и дело не только в осторожности. Вот что лежит в AdminSDHolder после Set-ADSyncExchangeHybridPermissions -IncludeAdminSdHolders — запись и чтение всех свойств для четырёх классов, как на корне домена:

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

      ActiveDirectoryRights InheritedObjectType                  InheritanceType
      --------------------- -------------------                  ---------------
ReadProperty, WriteProperty bf967aba-0de6-11d0-a285-00aa003049e2     Descendents
ReadProperty, WriteProperty bf967a9c-0de6-11d0-a285-00aa003049e2     Descendents
ReadProperty, WriteProperty 4828cc14-1437-45bc-9b07-ad6f015e5f28     Descendents
ReadProperty, WriteProperty 5cb41ed0-0e4c-11d0-a286-00aa003049e2     Descendents

Descendents — запись только для дочерних объектов (inherit-only): модуль ставит её так же, как на корень домена, где она и должна действовать на потомков. SDProp копирует её на защищённую учётную запись как есть, и там она остаётся записью «только для дочерних объектов пользователя», которых у пользователя нет. На самого пользователя она не действует. Сравните, как те же права выглядят у обычного пользователя, унаследовавшего их с корня, и у защищённого:

PS C:\> (Get-Acl "AD:\$((Get-ADUser bob).DistinguishedName)").Access | Where-Object IdentityReference -like '*MSOL_*' | Select-Object ActiveDirectoryRights, InheritedObjectType, InheritanceType, IsInherited

      ActiveDirectoryRights InheritedObjectType                  InheritanceType IsInherited
      --------------------- -------------------                  --------------- -----------
              ExtendedRight bf967aba-0de6-11d0-a285-00aa003049e2             All        True
              WriteProperty 5df2b673-6d41-4774-b3e8-d52e8ee9ff99     Descendents        True
               ReadProperty f0f8ffac-1191-11d0-a060-00aa006c33ed     Descendents        True
ReadProperty, WriteProperty 4828cc14-1437-45bc-9b07-ad6f015e5f28     Descendents        True
ReadProperty, WriteProperty bf967a9c-0de6-11d0-a285-00aa003049e2     Descendents        True
ReadProperty, WriteProperty bf967aba-0de6-11d0-a285-00aa003049e2             All        True
ReadProperty, WriteProperty 5cb41ed0-0e4c-11d0-a286-00aa003049e2     Descendents        True

PS C:\> (Get-Acl "AD:\$((Get-ADUser alice.admin).DistinguishedName)").Access | Where-Object IdentityReference -like '*MSOL_*' | Select-Object ActiveDirectoryRights, InheritedObjectType, InheritanceType, IsInherited

      ActiveDirectoryRights InheritedObjectType                  InheritanceType IsInherited
      --------------------- -------------------                  --------------- -----------
ReadProperty, WriteProperty bf967aba-0de6-11d0-a285-00aa003049e2     Descendents       False
ReadProperty, WriteProperty bf967a9c-0de6-11d0-a285-00aa003049e2     Descendents       False
ReadProperty, WriteProperty 4828cc14-1437-45bc-9b07-ad6f015e5f28     Descendents       False
ReadProperty, WriteProperty 5cb41ed0-0e4c-11d0-a286-00aa003049e2     Descendents       False

У bob запись для класса user (bf967aba…), пришедшая с корня, стала действующей на сам объект — All. У alice.admin та же запись — явная копия из AdminSDHolder с Descendents: права у учётной записи MSOL_… на неё нет. Чтобы запись в AdminSDHolder действовала на сами защищённые объекты, она должна относиться и к самому объекту, например так ставит dsacls по умолчанию (/I:T — объект и дочерние):

PS C:\> dsacls 'CN=AdminSDHolder,CN=System,DC=corp,DC=example,DC=com' /G 'CORP\MSOL_a1b2c3d4e5f6:RPWP;mS-DS-ConsistencyGuid'

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

Пользователь, выведенный из защищённых групп, сохраняет adminCount = 1 и отключённое наследование (часть 5) — и синхронизация обращается с ним как с защищённым, пока их не вернуть руками. Найти таких можно грубой проверкой по memberOf:

PS C:\> Get-ADUser -LDAPFilter '(adminCount=1)' -Properties MemberOf | Where-Object { -not ($_.MemberOf -match 'Domain Admins|Enterprise Admins|Schema Admins|Administrators|Account Operators|Server Operators|Backup Operators|Print Operators') } | Select-Object Name

Name
----
krbtgt

krbtgt защищена всегда, сама по себе, а не через группу, — её трогать не нужно. Проверка грубая: memberOf не показывает основную группу и вложенное членство, так что каждого найденного стоит проверить глазами. Для настоящего «бывшего администратора» возврат такой:

PS C:\> Set-ADUser tfs-build -Clear adminCount
PS C:\> $dn = (Get-ADUser tfs-build).DistinguishedName
PS C:\> $acl = Get-Acl "AD:\$dn"; $acl.SetAccessRuleProtection($false, $true); Set-Acl "AD:\$dn" -AclObject $acl

Обратная запись и защита паролей

Обратная запись паролей (password writeback) — путь, по которому облако пишет в домен пароль: пользователь сбрасывает забытый пароль на странице Microsoft (самостоятельный сброс, SSPR, нужна лицензия Entra ID P1), облако передаёт новый пароль на сервер синхронизации, и тот устанавливает его в домене правами из Set-ADSyncPasswordWritebackPermissions: Reset Password, запись lockoutTime и pwdLastSet. Действует парольная политика домена: пароль, не прошедший её, облако отвергнет с сообщением о политике организации. Входящих подключений сервер синхронизации для этого не принимает: он сам держит исходящее соединение по HTTPS с ретранслятором Azure Service Bus (*.servicebus.windows.net) и службой *.passwordreset.microsoftonline.com и получает запросы через него. Журнал — Application на сервере синхронизации, источник PasswordResetService: 31001 — запрос на сброс получен, 31002 — пароль записан, 31003 — не записан (политика, права, защищённая учётная запись); 31006, 31007, 31008 — то же для смены пароля. Отказ из-за прав на защищённой учётной записи — 33004 «ADPermissionsError».

Entra Password Protection — обратная задача: правила облака для паролей домена. На каждом контроллере ставится агент: его библиотека фильтра паролей, зарегистрированная у LSA, передаёт новый пароль службе агента, а та проверяет его по списку запрещённых — глобальному от Microsoft и своему (название компании, продукты, город) — и отвергает до того, как он попадёт в каталог. Список агенты получают из облака через прокси на любом сервере домена и хранят в SYSVOL; сами контроллеры в интернет не ходят. Фильтр срабатывает при любой смене и любом сбросе пароля на этом контроллере, включая Set-ADAccountPassword и смену по Ctrl+Alt+Del, независимо от того, синхронизирован ли пользователь, — но только там, где агент стоит, поэтому ставят его на все контроллеры. Фильтры паролей контроллера перечислены в параметре Notification Packages:

PS C:\> Invoke-Command dc1 { (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa').'Notification Packages' }
rassfm
scecli

scecli — фильтр подсистемы настройки безопасности, rassfm — фильтр службы удалённого доступа; агента Password Protection на этом контроллере нет.

Гибридная регистрация устройств

Пользователи синхронизированы; машины — ещё нет. Гибридное присоединение к Entra ID (Microsoft Entra hybrid join) регистрирует компьютер домена в облаке: он получает сертификат устройства от Entra ID, и при входе пользователя Windows берёт у облака основной токен обновления (PRT, primary refresh token), которым дальше входит во все облачные приложения без пароля и без Seamless SSO. Без регистрации устройства не работает условный доступ «только с управляемых устройств», Windows Hello for Business в гибридном варианте и единый вход в Office на уровне системы.

Что нужно. Во-первых, точка подключения службы (service connection point, SCP) в разделе конфигурации леса: объект, по которому машины узнают, к какому арендатору присоединяться. Её создаёт мастер Entra Connect, задача Configure device options, с учётными данными Enterprise Admin:

PS C:\> Get-ADObject -SearchBase 'CN=Device Registration Configuration,CN=Services,CN=Configuration,DC=corp,DC=example,DC=com' -Filter 'objectClass -eq "serviceConnectionPoint"' -Properties keywords | Select-Object Name, keywords

Name                                 keywords
----                                 --------
62a0ff2e-97b9-4513-943f-0d221bd30080 {azureADName:example.onmicrosoft.com, azureADId:3a7b1c2d-4e5f-6071-8293-a4b5c6d7e8f9}

Имя объекта постоянное, в keywords — имя и идентификатор арендатора. Во-вторых, компьютеры в области синхронизации: в управляемом домене (PHS или PTA) машина регистрируется ключом, который Entra Connect выгружает в облако вместе с объектом компьютера (атрибут userCertificate), и без объекта в облаке регистрация не завершится. В-третьих, доступ машин к enterpriseregistration.windows.net, login.microsoftonline.com, device.login.microsoftonline.com и, при Seamless SSO, autologon.microsoftazuread-sso.com — в том числе через прокси от имени SYSTEM.

Саму регистрацию выполняет задача планировщика на каждой машине:

PS C:\> Get-ScheduledTask -TaskPath '\Microsoft\Windows\Workplace Join\' | Select-Object TaskName, State

TaskName                 State
--------                 -----
Automatic-Device-Join    Ready
Device-Sync           Disabled
Recovery-Check        Disabled

Automatic-Device-Join запускается при входе в систему и читает SCP. Состояние машины показывает dsregcmd /status:

PS C:\> dsregcmd /status | Select-String 'AzureAdJoined|DomainJoined|WorkplaceJoined|AzureAdPrt |DeviceCertificateValidity|KeyProvider'

             AzureAdJoined : NO
              DomainJoined : YES
           WorkplaceJoined : YES
                AzureAdPrt : NO
 DeviceCertificateValidity : [ 2026-10-13 18:31:19.000 UTC -- 2036-10-13 19:01:19.000 UTC ]
               KeyProvider : Microsoft Platform Crypto Provider

Это машина домена без гибридной регистрации: AzureAdJoined : NO, PRT нет. WorkplaceJoined : YES — другое: пользователь, войдя в Office рабочей учётной записью, зарегистрировал устройство в облаке для себя (Entra registered), и сертификат и ключ в TPM (Platform Crypto Provider) — от этой регистрации. У машины с гибридной регистрацией AzureAdJoined и DomainJoined оба YES, а после входа пользователя — AzureAdPrt : YES.

Отказы — в журнале Microsoft-Windows-User Device Registration/Admin. Частые причины: машина не достаёт до адресов выше, объект компьютера вне области синхронизации и — менее очевидная — SCP, оставшийся от прежнего арендатора. Тогда каждый вход в систему оставляет пару ошибок:

PS C:\> $ids = 304, 420
PS C:\> Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-User Device Registration/Admin'; Id=$ids} -MaxEvents 2 | Format-List TimeCreated, Id, Message

TimeCreated : 15.10.2026 9:23:19
Id          : 304
Message     : Automatic registration failed at join phase.
              Exit code: Unknown HResult Error code: 0x801c03f3
              Server error: The device object by the given id (5f2c9a71-3e4d-4b8a-9c06-1d7e2a4b6c80) is not found.
              Tenant type: Managed
              Registration type: fallback_sync
              Debug Output:
              joinMode: Join
              drsInstance: azure
              registrationType: fallback_sync
              tenantType: Managed
              tenantId: 9d4e2f10-5a6b-4c7d-8e9f-0a1b2c3d4e5f
              configLocation: undefined
              errorPhase: join
              adalCorrelationId: 2c41e7a9-0b3d-4f58-9e6a-71d2c8b5f304
              adalLog:
              undefined
              adalResponseCode: 0x0

TimeCreated : 15.10.2026 9:23:10
Id          : 420
Message     : Automatic registration failed at authentication phase. Unable to acquire Kerberos ticket.
              Exit code: The specified target is unknown or unreachable
              Kerberos endpoint: https://login.microsoftonline.com/9d4e2f10-5a6b-4c7d-8e9f-0a1b2c3d4e5f/kerberos
              SPN: adrs/enterpriseregistration.windows.net

fallback_sync — регистрация через синхронизированный объект компьютера, и в арендаторе из SCP его нет. Сверить идентификатор из SCP с настоящим можно по открытому документу OpenID Connect арендатора, без входа:

PS C:\> (Invoke-RestMethod 'https://login.microsoftonline.com/example.com/v2.0/.well-known/openid-configuration').issuer
https://login.microsoftonline.com/3a7b1c2d-4e5f-6071-8293-a4b5c6d7e8f9/v2.0

Не совпадает с azureADId в SCP — машины домена стучатся не в тот арендатор.

Чего не делать

У объекта с двойником в облаке некоторые обычные действия имеют необычные последствия.

Переносить пользователя в OU вне области синхронизации. Для синхронизации это удаление: объект исчезает из области, облако получает «удалить», и учётная запись в облаке попадает в корзину на 30 дней, а с ней — почтовый ящик, OneDrive, Teams. Восстановить можно (Restore-MgDirectoryDeletedItem), но пользователь успеет это заметить. То же — удаление пользователя в домене, но там это ожидаемо.

Массовые операции защищены порогом: если в одном цикле экспорт в облако хочет удалить больше 500 объектов, он останавливается, пока администратор не разрешит. Порог виден в глобальных настройках сервера (часть 31), а каждый цикл экспорта сообщает его облаку вместе со счётчиками — событие 116 источника Directory Synchronization в журнале Application сервера синхронизации:

Calling UpdateDirSyncConfiguration with: [CloudDirSyncConfiguration CustomerRequestedSyncInterval=, ApplicationVersion=, ClientVersion=2.6.92.0 AnchorAttribute= [PreventAccidentalDeletion DeletionPrevention=EnabledForCount, ThresholdCount=500, ThresholdPercentage=0], [CurrentExport DirSyncObjectAdds=0, DirSyncObjectDeletes=0, DirSyncObjectUpdates=0, DirSyncClientMachineName=SYNC1, TotalConnectorSpaceObjects=5], [Writeback UnifiedGroupContainer=, UserContainer=]]

Get-ADSyncExportDeletionThreshold, Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500 и Disable-ADSyncExportDeletionThreshold (временно, чтобы пропустить ожидаемое массовое удаление) спрашивают учётную запись администратора арендатора: порог хранится и в облаке. Переезд OU, смена фильтра, отключение домена из синхронизации — всё это упрётся в порог, и это правильно.

Менять mS-DS-ConsistencyGuid. Это якорь. Исходящее правило Out to AAD - User Join сравнивает якорь с тем, что облако уже знает, и при расхождении выдаёт ошибку:

IIF(IsPresent([cloudSourceAnchor]), IIF(Word([cloudAnchor],1,"_")=[sourceObjectType],IIF([cloudSourceAnchor] = [sourceAnchor],[sourceAnchor],Error("SourceAnchor attribute has changed.")),[sourceAnchor]),[sourceAnchor])

Объект перестаёт синхронизироваться, пока старое значение не вернут в каталог.

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

Чинить облачный объект в облаке. Пока OnPremisesSyncEnabled = True, атрибуты, которые приходят из домена, в облаке не редактируются; всё — в домене.

Превращать синхронизированный объект в облачный ради переезда или увольнения с сохранением ящика. Для групп у Microsoft есть штатный перевод источника управления в облако (Group Source of Authority). Для пользователей остаются вывод из области (удаление и восстановление из корзины уже облачным) или отключение синхронизации для арендатора целиком, которое занимает до 72 часов и затрагивает всех. Оба пути неприятны, и объект лучше оставить в домене отключённым, чем выводить.

Давать одному человеку одну учётную запись для всего. Администратор домена, он же глобальный администратор облака, с одним паролем — это одна утечка на две среды. Разные учётные записи, разные пароли, многофакторная проверка в облаке — и домен не тащит облако за собой.

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

Объект в пространстве коннектора облака. Объекты коннектора облака называются не по имени, а по якорю: DN — это CN={…} с шестнадцатеричными кодами символов строки Base64. Получить его из доменного объекта можно и без метавселенной:

PS C:\> $anchor = [Convert]::ToBase64String((Get-ADUser carol).ObjectGUID.ToByteArray())
PS C:\> $dn = 'CN={' + (([Text.Encoding]::ASCII.GetBytes($anchor) | ForEach-Object { $_.ToString('X2') }) -join '') + '}'
PS C:\> Get-ADSyncCSObject -ConnectorName 'example.onmicrosoft.com - AAD' -DistinguishedName $dn | Format-List DistinguishedName, ObjectType, IsConnector, HasExportError, ExportError

DistinguishedName : CN={32522F75436B2F6C526B4B6E33764D574D6C7A467A513D3D}
ObjectType        : user
IsConnector       : True
HasExportError    : False
ExportError       :

3252…3D3D — это 2R/uCk/lRkKn3vMWMlzFzQ== по байту на символ. IsConnector: True — объект связан с метавселенной, экспорт без ошибок. У объекта, который облако не приняло, здесь будет ExportError — например, AttributeValueMustBeUnique, когда новый объект с другим якорем пытается занять SID или основной адрес существующего (такой конфликт устойчивость к дубликатам не гасит). Как видит тот же объект облако, показывает Get-MgUser с OnPremisesImmutableId, OnPremisesSyncEnabled и OnPremisesProvisioningErrors — команды выше.

Защищённые учётные записи глазами синхронизации — какие из синхронизируемых не получили mS-DS-ConsistencyGuid:

PS C:\> Get-ADUser -SearchBase 'OU=Departments,DC=corp,DC=example,DC=com' -Filter * -Properties adminCount, mS-DS-ConsistencyGuid |
    Where-Object { -not $_.'mS-DS-ConsistencyGuid' } | Select-Object Name, adminCount

Name        adminCount
----        ----------
Alice Admin          1

alice.admin — в области синхронизации, с adminCount = 1, без якоря в каталоге: записать его синхронизация не смогла, и обратная запись для неё тоже не сработает. Правильное действие — не права на AdminSDHolder, а перенос административных учётных записей в OU вне области, чтобы в облако они не попадали. Перенос — это удаление облачного двойника, о котором выше, поэтому сначала стоит убедиться, что у двойника нет ящика и лицензий.

Источники

Сопоставление и конфликты:

Configure Microsoft Entra Connect for an existing tenant — жёсткое и мягкое сопоставление, перезапись атрибутов и пароля, административные роли, защита жёсткого сопоставления с июля 2026 года;
Microsoft Entra Connect Sync service features — SoftMatchOnUpnEnabled, BlockSoftMatchEnabled, SynchronizeUpnForManagedUsersEnabled;
Identity synchronization and duplicate attribute resiliency — карантин UPN и адресов, временный UPN;
Troubleshoot errors during synchronization — AttributeValueMustBeUnique, InvalidHardMatch, ошибки прав;
Design concepts — якорь, запись objectGUID в mS-DS-ConsistencyGuid и права на неё;
Update-MgUser и user resource type — onPremisesImmutableId, onPremisesProvisioningErrors.

Защищённые учётные записи и права:

Appendix C: Protected Accounts and Groups in Active Directory — AdminSDHolder, SDProp, adminCount, krbtgt;
Configure AD DS Connector Account Permissions — модуль AdSyncConfig, права по функциям, -IncludeAdminSdHolders и почему он не рекомендуется;
ACE_HEADER — флаг INHERIT_ONLY_ACE: запись не действует на объект, к которому привязана;
dsacls — /G, /I:T, /I:S;
Manage emergency access admin accounts — учётные записи аварийного доступа.

Пароли:

How does self-service password reset writeback work — обратная запись паролей, политика домена;
Troubleshoot self-service password reset writeback — адреса Service Bus, события PasswordResetService 31001, 31002, 31003, 31006, 31007, 31008 и 33004;
Microsoft Entra Password Protection — агент на контроллерах, прокси, политика в SYSVOL;
Installing and Registering a Password Filter DLL — параметр Notification Packages.

Устройства:

Configure Microsoft Entra hybrid join — задача Configure device options, SCP, нужные адреса;
Microsoft Entra hybrid joined devices — что даёт гибридная регистрация;
Primary Refresh Token — PRT и единый вход;
Troubleshoot devices by using the dsregcmd command — поля dsregcmd /status;
Troubleshoot Microsoft Entra hybrid joined devices — события регистрации и коды ошибок.

Удаления и управление объектами:

Prevent accidental deletes — порог удаления, Enable-ADSyncExportDeletionThreshold и Disable-ADSyncExportDeletionThreshold;
Restore-MgDirectoryDeletedItem — восстановление из корзины;
Group Source of Authority — перевод групп под управление облака;
Turn off directory synchronization — отключение синхронизации для арендатора.

На этом серия закончена. Тридцать две части назад был пустой сервер; теперь — лес с четырьмя контроллерами в двух сайтах, DNS и DHCP для двух семейств адресов, доверие с партнёрским лесом, удостоверяющий центр, Wi-Fi и VPN с аутентификацией в каталоге, Linux-серверы, в которые входят по билету, и облако, куда уехали те же учётные записи. Всё это настраивалось командами, и каждую из них можно повторить — в этом и был смысл.

Что осталось за рамками серии и чему могут быть посвящены отдельные статьи: файловые службы и DFS, Hyper-V и отказоустойчивые кластеры, службы удалённых рабочих столов, Windows Server Update Services, LAPS и Windows Hello for Business в деталях, и мониторинг всего описанного. Если какая-то из этих тем нужна раньше других — напишите в комментариях.