如何在 Microsoft Entra 域服务托管域中同步对象和凭据
Microsoft Entra 域服务托管域中的对象和凭据可以在域中本地创建，也可以从 Microsoft Entra 租户同步。 首次部署域服务时，自动单向同步将进行配置，然后开始从 Microsoft Entra ID 复制对象。 此单向同步将继续在后台运行，使域服务托管域与 Microsoft Entra ID 中的任何更改保持同步。 不会从域服务往回同步到 Microsoft Entra ID。
在混合环境中，可以使用 Microsoft Entra Connect 将本地 AD DS 域中的对象和凭据同步到 Microsoft Entra ID。 一旦这些对象成功同步到 Microsoft Entra ID，自动后台同步就会将这些对象和凭据提供给使用托管域的应用程序。
下图展示了域服务、Microsoft Entra ID 和可选的本地 AD DS 环境之间的同步原理：
从 Microsoft Entra ID 到域服务的同步
用户帐户、组成员身份和凭据哈希会从 Microsoft Entra ID 单向同步到域服务。 此同步过程是自动的。 不需要配置、监视或管理此同步过程。 初始同步可能需要几个小时到几天的时间，具体取决于 Microsoft Entra 目录中的对象数。 初始同步完成后，在 Microsoft Entra ID 中进行的更改（如密码或属性更改）将自动同步到域服务。
在 Microsoft Entra ID 中创建用户时，除非他们在 Microsoft Entra ID 中更改密码，否则不会将其同步到域服务。 此密码更改过程会导致在 Microsoft Entra ID 中生成并存储用于 Kerberos 和 NTLM 身份验证的密码哈希。 需要使用密码哈希才能在域服务中成功进行用户身份验证。
同步过程采用单向设计。 不会将更改从域服务反向同步到 Microsoft Entra ID。 托管域在很大程度上是只读的，但你可以创建的自定义 OU 除外。 无法对托管域中的用户属性、用户密码或组成员身份进行更改。
限定范围的同步和组筛选器
可以将同步范围限定为仅源自云的用户帐户。 在该同步范围内，可以筛选特定组或用户。 可以在仅限云组、本地组或同时包括两组之间进行选择。 有关如何配置限定范围的同步的详细信息，请参阅配置限定范围同步。
属性同步和映射到域服务
下表列出了一些常见的属性，以及如何将它们同步到域服务。
| 域服务中的属性 | 源 | 注释 |
|---|---|---|
| UPN | Microsoft Entra 租户中用户的 UPN 属性 | Microsoft Entra 租户中的 UPN 属性按原样同步到域服务。 登录到托管域的最可靠方法是使用 UPN。 |
| SAMAccountName | Microsoft Entra 租户中的或自动生成的用户的 mailNickname 属性 | SAMAccountName 属性源自 Microsoft Entra 租户中的 mailNickname 属性。 如果多个用户帐户具有相同的“mailNickname”属性，会自动生成“SAMAccountName” 。 如果用户的“mailNickname”或“UPN”前缀长度超过 20 个字符，会自动生成“SAMAccountName”，以满足“SAMAccountName”属性不超过 20 个字符的限制 。 |
| 密码 | Microsoft Entra 租户中的用户密码 | NTLM 或 Kerberos 身份验证所需的旧密码哈希将从 Microsoft Entra 租户同步。 如果 Microsoft Entra 租户使用 Microsoft Entra Connect 配置了混合同步，则这些密码哈希源自本地 AD DS 环境。 |
| 主用户/组 SID | 自动生成 | 用户/组帐户的主 SID 是在域服务中自动生成的。 此属性与本地 AD DS 环境中对象的主用户/组 SID 不匹配。 之所以不匹配，是因为托管域的 SID 命名空间不同于本地 AD DS 域。 |
| 用户和组的 SID 历史记录 | 本地主用户和组 SID | 域服务中用户和组的“SidHistory”属性已设置为与本地 AD DS 环境中相应的主用户或组 SID 相匹配。 借助此功能可以更方便地将本地应用程序直接迁移到域服务，因为不需要重新 ACL 资源。 |
提示
“使用 UPN 格式登录到托管域”。可以针对托管域中的某些用户帐户自动生成“SAMAccountName”属性（例如 AADDSCONTOSO\driley）。 用户的自动生成的“SAMAccountName”可能不同于其 UPN 前缀，因此用它登录并不总是可靠的。
例如，如果多个用户具有相同的“mailNickname”属性或者用户具有很长的 UPN 前缀，可能会自动生成这些用户的“SAMAccountName” 。 使用 UPN 格式（例如 driley@aaddscontoso.com）可靠地登录到托管域。
用户帐户的属性映射
下表演示了 Microsoft Entra ID 中用户对象的特定属性如何同步到域服务中的相应属性。
| Microsoft Entra ID 中的用户属性 | 域服务中的用户属性 |
|---|---|
| accountEnabled | userAccountControl（设置或清除 ACCOUNT_DISABLED 位） |
| city | l |
| companyName | companyName |
| country | co |
| department | department |
| displayName | displayName |
| employeeId | employeeId |
| facsimileTelephoneNumber | facsimileTelephoneNumber |
| givenName | givenName |
| jobTitle | title |
| mailNickname | msDS-AzureADMailNickname |
| mailNickname | SAMAccountName（有时可能自动生成） |
| manager | manager |
| mobile | mobile |
| objectid | msDS-aadObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| passwordPolicies | userAccountControl（设置或清除 DONT_EXPIRE_PASSWORD 位） |
| physicalDeliveryOfficeName | physicalDeliveryOfficeName |
| postalCode | postalCode |
| preferredLanguage | preferredLanguage |
| ProxyAddresses | ProxyAddresses |
| state | st |
| streetAddress | streetAddress |
| surname | sn |
| telephoneNumber | telephoneNumber |
| userPrincipalName | userPrincipalName |
组的属性映射
下表演示了 Microsoft Entra ID 中组对象的特定属性如何同步到域服务中的相应属性。
| Microsoft Entra ID 中的组属性 | 域服务中的组属性 |
|---|---|
| displayName | displayName |
| displayName | SAMAccountName（有时可能自动生成） |
| mailNickname | msDS-AzureADMailNickname |
| objectid | msDS-AzureADObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| ProxyAddresses | ProxyAddresses |
| securityEnabled | groupType |
从本地 AD DS 同步到 Microsoft Entra ID 和域服务
Microsoft Entra Connect 用于将用户帐户、组成员身份和凭据哈希从本地 AD DS 环境同步到 Microsoft Entra ID。 将同步用户帐户的属性，例如 UPN 和本地安全标识符 (SID)。 若要使用域服务登录，则 NTLM 和 Kerberos 身份验证所需的旧凭据哈希也会同步到 Microsoft Entra ID。
重要
安装和配置的 Microsoft Entra Connect 应仅用于与本地 AD DS 环境同步。 不支持在托管域中安装 Microsoft Entra Connect 以将对象往回同步到 Microsoft Entra ID。
如果配置了写回，则会将 Microsoft Entra ID 中的更改往回同步到本地 AD DS 环境。 例如，如果用户使用 Microsoft Entra 自助式密码管理更改了密码，则更改的密码会往回更新到本地 AD DS 环境。
注意
请始终使用最新版本的 Microsoft Entra Connect，确保获得所有已知 Bug 的修补程序。
从多林本地环境同步
许多组织都拥有包含多个林的相当复杂的本地 AD DS 环境。 Microsoft Entra Connect 支持将用户、组和凭据哈希从多林环境同步到 Microsoft Entra ID。
Microsoft Entra ID 具有更简单和平面的命名空间。 为了使用户能够可靠地访问 Microsoft Entra ID 保护的应用程序，需要解决不同林中用户帐户的 UPN 冲突。 和 Microsoft Entra ID 类似，托管域使用平面 OU 结构。 即使你在本地配置了分层 OU 结构，所有用户帐户和组也都存储在“AADDC 用户”容器中，尽管它们从不同的本地域或林同步。 托管域会平展任何分层 OU 结构。
如前所述，不会从域服务往回同步到 Microsoft Entra ID。 可在域服务中创建自定义组织单位 (OU)，然后在这些自定义 OU 中创建用户、组或服务帐户。 在自定义 OU 中创建的对象都不会往回同步到 Microsoft Entra ID。 这些对象仅在托管域中可用，不能使用 Microsoft Graph PowerShell cmdlet、Microsoft Graph API 或 Microsoft Entra 管理中心来显示它们。
未同步到域服务的内容
下列对象或属性不会从本地 AD DS 环境同步到 Microsoft Entra ID 或域服务：
- 排除的属性：使用 Microsoft Entra Connect 从本地 AD DS 环境同步到 Microsoft Entra ID 时，可以选择排除某些属性。 这些排除的属性在域服务中不可用。
- 组策略：本地 AD DS 环境中配置的组策略不会同步到域服务。
- Sysvol 文件夹：本地 AD DS 环境中 Sysvol 文件夹的内容不会同步到域服务。
- 计算机对象：加入本地 AD DS 环境中的计算机，其计算机对象不会同步到域服务。 这些计算机未与托管域建立信任关系，它们仅属于本地 AD DS 环境。 在域服务中，仅显示已显式域加入该托管域的计算机的计算机对象。
- 用户和组的 SidHistory 属性：本地 AD DS 环境中的主用户和主组 SID 将同步到域服务。 但是，用户和组的现有“SidHistory”属性不会从本地 AD DS 环境同步到域服务。
- 组织单位 (OU) 结构：在本地 AD DS 环境中定义的组织单位不会同步到域服务。 域服务中有两个内置 OU - 一个用于用户，另一个用于计算机。 托管域具有平面 OU 结构。 可以选择在托管域中创建自定义 OU。
密码哈希同步和安全注意事项
在启用域服务时，需要使用旧密码哈希进行 NTLM + Kerberos 身份验证。 Microsoft Entra ID 不存储明文密码，因此不能为现有用户帐户自动生成这些哈希。 与 NTLM 和 Kerberos 兼容的密码哈希始终以加密形式存储在 Microsoft Entra ID 中。
每个 Microsoft Entra ID 租户的加密密钥是唯一的。 这些哈希会进行加密，以便只有域服务才能有权访问解密密钥。 Microsoft Entra ID 中没有其他服务或组件有权访问解密密钥。
然后，旧密码哈希将从 Microsoft Entra ID 同步到托管域的域控制器。 域服务中这些托管域控制器的磁盘会进行静态加密。 会在这些域控制器上存储并保护这些密码哈希，其方式类似于在本地 AD DS 环境中存储并保护密码。
对于仅云 Microsoft Entra 环境，用户必须重置/更改其密码，以便生成所必需的密码哈希并将其存储在 Microsoft Entra ID 中。 对于启用 Microsoft Entra 域服务后在 Microsoft Entra ID 中创建的任何云用户帐户，会生成密码哈希并采用与 NTLM 和 Kerberos 兼容的格式进行存储。 所有云用户帐户在同步到域服务之前都必须更改其密码。
对于使用 Microsoft Entra Connect 从本地 AD DS 环境同步的混合用户帐户，必须配置 Microsoft Entra Connect 以同步采用与 NTLM 和 Kerberos 兼容的格式的密码哈希。
后续步骤
有关密码哈希同步具体细节的详细信息，请参阅使用 Microsoft Entra Connect 进行密码哈希同步的工作原理。
若要开始使用域服务，请创建托管域。