有关如何使用 Microsoft Entra Connect 的大多数主题假设你从新的 Microsoft Entra 租户开始，并且那里没有用户或其他对象。 如果您最初设置了一个 Microsoft Entra 租户，并用用户和其他对象充实了它，现在希望使用 Connect，那么本主题将非常适合您。
Microsoft Entra ID 中的对象在云中或本地进行管理。 对于单个对象，不能在本地管理某些属性，也不能管理 Microsoft Entra ID 中的一些其他属性。 每个对象都有一个标志，指示对象在何处进行管理。
可以在本地管理一些用户，也可以在云中管理其他用户。 此配置的常见方案是一个组织，其中包含会计工作者和销售人员的组合。 会计工作者有一个本地 AD 帐户，但销售人员没有，但两者在 Microsoft Entra ID 中有一个帐户。 你将在本地管理一些用户，在 Microsoft Entra ID 中管理一些用户。
当你开始管理同时在 Microsoft Entra ID 和本地环境中存在的用户时，如果希望后续使用 Microsoft Entra Connect，还需要考虑一些其他注意事项。
开始与 Microsoft Entra Connect 同步时，Microsoft Entra 服务 API 会检查每个新的传入对象，并尝试查找要匹配的现有对象。 此过程使用三个属性： userPrincipalName、 proxyAddresses 和 sourceAnchor/immutableID。 userPrincipalName 或 proxyAddresses 上的匹配称为“软匹配”。sourceAnchor 上的匹配称为“硬匹配”。对于 proxyAddresses 属性，仅使用 SMTP：的值（即主电子邮件地址）用于评估。
只会针对来自本地 AD 的新对象评估匹配。 如果更改现有对象，使其与这些属性中的任何一个匹配，则会看到错误。
如果Microsoft Entra ID 找到一个对象，其中属性值与来自 Microsoft Entra Connect 的新传入对象相同，则它将接管 Microsoft Entra ID 中的对象，而以前云托管的对象将转换为本地托管对象。 Microsoft Entra ID 中的所有属性如果在本地 AD 中具有值，这些属性会被相应的本地值覆盖。
警告
由于Microsoft Entra ID 中的所有属性都将被本地值覆盖，因此请确保本地数据良好。 例如，如果您在 Microsoft 365 中仅有托管的电子邮件地址，并且没有在本地 AD DS 中保持更新，那么在 Microsoft Entra ID / Microsoft 365 中而 AD DS 中不存在的任何值都会丢失。
重要
如果使用始终在 Express 安装中启用的密码哈希同步，则 Microsoft Entra ID 中的密码哈希将被本地 AD 中的密码哈希覆盖。 如果用户习惯于管理多个不同的密码，那么你需要通知他们应使用本地 AD 密码。
在规划过程中，必须考虑上一部分的内容和警告。 如果在Microsoft Entra ID 中进行了许多更改，但未反映在本地 AD DS 中，则为了防止数据丢失，需要计划如何在将对象与 Microsoft Entra Connect 同步之前，使用Microsoft Entra ID 更新的值填充 AD DS。
如果您将对象进行软匹配，则会将 sourceAnchor 添加到 Microsoft Entra ID 中的对象，以便以后可以使用硬匹配。
重要
Microsoft 强烈建议不要将本地帐户与 Microsoft Entra ID 中已存在的管理帐户进行同步。
默认情况下，对象的 SourceAnchor 值（例如“abcdefghijklmnopqrstuv=”）是从本地 Active Directory 对象的 mS-Ds-ConsistencyGUID 属性（或 ObjectGUID）的 Base64 字符串表示形式。 此值设置为 Microsoft Entra ID 中的相应 ImmutableId。
Microsoft Entra Connect 添加新对象时，Microsoft Entra ID 服务会尝试使用与 Microsoft Entra ID 中存在对象的 ImmutableId 属性对应的 sourceAnchor 值匹配传入对象。 如果有匹配项，Microsoft Entra Connect 将接管该对象的源或授权机构 (SoA)，并在所谓的 “硬匹配” 中使用传入的本地 Active Directory 对象的属性来更新该对象。当 Microsoft Entra ID 找不到任何与 SourceAnchor 值匹配的 ImmutableId 对象时，它会尝试使用传入对象的 userPrincipalName 或主 SMTP 地址在所谓的 “软匹配” 中找到匹配项。
硬匹配和软匹配都尝试匹配Microsoft Entra ID 中已存在和管理的对象，并添加表示同一本地实体的新传入对象。 如果Microsoft Entra ID 找不到传入对象的 硬匹配 或 软匹配 ，则会在 Microsoft entra ID 目录中预配一个新对象。
如果 Microsoft Entra ID 能够根据主 SMTP 地址将新传入对象与 Microsoft Entra ID 中管理的现有对象“软匹配”，但此新对象的 sourceAnchor 值不同，则系统会尝试预配一个新对象，这通常会导致 Microsoft Entra ID 无法创建新对象的冲突。 这种冲突在以下情况下发生：
在已同步到 Entra ID 的原始本地 AD 用户中，
mS-Ds-ConsistencyGuid属性被设置了不同的 sourceAnchor 值。使用同一 UPN 和主 SMTP 地址创建了一个新的本地 AD 用户，但具有不同的 sourceAnchor 和 SID。
在这种情况下，Microsoft Entra Connect 中会引发 AttributeValueMustBeUnique 导出错误。 根据传入的用户属性，此错误可能引用以下属性冲突之一：
AttributeConflictName = OnPremiseSecurityIdentifier：新的对象具有不同的源锚定，但与 Entra ID 目录中存在的用户具有相同的 OnPremiseSecurityIdentifier（SID）和主 SMTP 地址。
AttributeConflictName = ProxyAddresses：新的传入对象具有不同的 sourceAnchor 和 SID，但与 Entra ID 目录中存在的用户具有相同的主 SMTP 地址。
注意
在一些罕见的情况下，OnPremiseSecurityIdentifier 会由于本地 AD RID 池出现问题而导致冲突（例如，从备份中恢复的域控制器），从而生成具有相同 SID 的新用户。 在这种情况下，尝试预配用户时会引发AttributeValueMustBeUnique错误，这不是因为“软匹配”尝试，而是因为OnPremiseSecurityIdentifier在Entra ID目录中必须是唯一的。
这些情况通常意味着你尝试重新配置同一用户。 若要解决冲突，应更新本地用户 mS-Ds-ConsistencyGuid 的属性，以匹配与现有云用户的 ImmutableID 相同的值。 此更改允许 Microsoft Entra ID 执行正确的“硬匹配”。
我们添加了一个配置选项，用于在 Microsoft Entra ID 中禁用硬匹配功能。 建议客户禁用硬匹配，除非他们需要它来接管仅限云的帐户。
若要禁用硬匹配，请使用 Update-MgDirectoryOnPremiseSynchronization Microsoft Graph PowerShell cmdlet：
Connect-MgGraph -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId 'YOUR_TENANT_ID' -Scopes "OnPremDirectorySynchronization.ReadWrite.All"
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.BlockCloudObjectTakeoverThroughHardMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
同样，我们添加了一个配置选项，用于在 Microsoft Entra ID 中禁用软匹配选项。 我们建议客户禁用软匹配，除非他们需要它接管仅限云的帐户。
若要禁用软匹配，请使用 Update-MgDirectoryOnPremiseSynchronization Microsoft Graph PowerShell cmdlet：
Connect-MgGraph -Environment China -ClientId 'YOUR_CLIENT_ID' -TenantId 'YOUR_TENANT_ID' -Scopes "OnPremDirectorySynchronization.ReadWrite.All"
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.BlockSoftMatchEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
注意
为租户启用时，BlockCloudObjectTakeoverThroughHardMatchEnabled 和 BlockSoftMatchEnabled 将阻止匹配所有对象。 建议客户仅在租赁需要匹配过程期间禁用这些功能。 完成任何匹配且不再需要后，此标志应再次设置为 True 。
对于启用了邮件的组和联系人，可以根据 proxyAddresses 进行软匹配。 硬匹配不适用，因为只能对用户更新 sourceAnchor/immutableID（使用 PowerShell）。 对于没有启用邮件功能的组，目前不支持软性匹配或硬性匹配。
为了防止不受信任的本地用户，Microsoft Entra ID 与具有管理员角色的云用户不匹配。 此行为默认为。 若要解决此问题，可以执行以下步骤：
从云专用用户对象中删除目录角色。
硬删除在云中创建的新隔离对象。
触发新的同步周期。
（可选）完成匹配后，将目录角色添加回云中的用户对象。
某些客户最初在 Microsoft Entra ID 中使用仅限云的解决方案，而没有构建本地 AD。 稍后，他们希望使用本地资源，并想要基于 Microsoft Entra 数据生成本地 AD。 Microsoft Entra Connect 无法帮助你实现此方案。 它不会在本地创建用户，并且无法将本地密码设置为与 Microsoft Entra ID 中的密码相同。
如果计划添加本地 AD 的唯一原因是支持 LOB（业务线应用），则也许应考虑改用 Microsoft Entra 域服务 。
详细了解如何将本地标识与 Microsoft Entra ID 集成。