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。 |
| SAM帐户名 | Microsoft Entra 租户中的或自动生成的用户的“mailNickname”属性 | SAMAccountName 属性源自 Microsoft Entra 租户中的 mailNickname 属性。 如果多个用户帐户具有相同 mailNickname 属性，则自动生成 SAMAccountName 。 如果用户的邮件Nickname 或 UPN 前缀长度超过 20 个字符，则自动生成 SAMAccountName 以满足 SAMAccountName 属性的 20 个字符限制。 |
| 密码 | Microsoft Entra 租户中的用户密码 | 用于 NTLM 或 Kerberos 身份验证必需的旧版密码哈希将从 Microsoft Entra 租户中同步。 如果 Microsoft Entra 租户配置为使用 Microsoft Entra Connect 进行混合同步，则这些密码哈希源自本地 AD DS 环境。 |
| 主要用户/组 SID | 自动生成 | 用户/组帐户的主要 SID 在域服务中自动生成。 此属性与本地 AD DS 环境中对象的主要用户/组 SID 不匹配。 这种不匹配是因为托管域具有不同于本地 AD DS 域的 SID 命名空间。 |
| 用户和组的 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 |
| 公司名称 | 公司名称 |
| country | co |
| 部门 | 部门 |
| displayName | displayName |
| 员工编号 | 员工编号 |
| facsimileTelephoneNumber | facsimileTelephoneNumber |
| givenName | givenName |
| 职位名称 | title |
| 邮件 | 邮件 |
| mailNickname | msDS-AzureADMailNickname |
| mailNickname | SAMAccountName （有时可能自动生成） |
| 管理员 | 管理员 |
| 移动 | 移动 |
| objectid | msDS-aadObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| 密码策略 | userAccountControl（设置或清除 DONT_EXPIRE_PASSWORD 位） |
| 物理递送办公室名称 | 物理递送办公室名称 |
| 邮政编码 | 邮政编码 |
| 首选语言 | 首选语言 |
| 代理地址 | 代理地址 |
| 状态 | st |
| streetAddress | streetAddress |
| 姓 | sn |
| 电话号码 | 电话号码 |
| userPrincipalName | userPrincipalName |
组的属性映射
下表说明了如何将 Microsoft Entra ID 中的组对象的特定属性同步到域服务中的相应属性。
| Microsoft Entra ID 中的组属性 | 域服务中的组属性 |
|---|---|
| displayName | displayName |
| displayName | SAMAccountName （有时可能自动生成） |
| 邮件 | 邮件 |
| mailNickname | msDS-AzureADMailNickname |
| objectid | msDS-AzureADObjectId |
| onPremiseSecurityIdentifier | sidHistory |
| 代理地址 | 代理地址 |
| 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 冲突。 托管域使用平面 OU 结构，类似于 Microsoft Entra ID。 即使你在本地配置了分层 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 租户都是唯一的。 这些哈希经过加密，以便只有域服务有权访问解密密钥。 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 配合使用。
若要开始使用域服务， 请创建托管域。