Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 。 如果用户的邮件Nickname 或 UPN 前缀长度超过 20 个字符，则自动生成 SAMAccountName 以满足 SAMAccountName 属性的 20 个字符限制。 |
| Passwords | 来自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位） |
| 城市 | l |
| companyName | companyName |
| country | co |
| 部门 | 部门 |
| displayName | displayName |
| 员工编号 | 员工编号 |
| 传真电话号码 | 传真电话号码 |
| givenName | givenName |
| 职位名称 | title |
| 邮件 | 邮件 |
| mailNickname | msDS-AzureADMailNickname |
| mailNickname | SAMAccountName （有时可能自动生成） |
| 管理员 | 管理员 |
| 移动 | 移动 |
| objectid | msDS-aadObjectId |
| 本地安全标识符 (onPremiseSecurityIdentifier) | SID历史 (sidHistory) |
| 密码策略 | userAccountControl （设置或清除DONT_EXPIRE_PASSWORD位） |
| 实体投递办公室名称 | 实体投递办公室名称 |
| postalCode | postalCode |
| 首选语言 | 首选语言 |
| 代理地址 | 代理地址 |
| 状态 | 圣 |
| streetAddress | streetAddress |
| 姓 | 锡 |
| 电话号码 | 电话号码 |
| userPrincipalName | userPrincipalName |
组的属性映射
下表说明了如何将Microsoft Entra ID中的组对象的特定属性同步到域服务中的相应属性。
| Microsoft Entra ID中的组属性 | 域服务中的组属性 |
|---|---|
| displayName | displayName |
| displayName | SAMAccountName （有时可能自动生成） |
| 邮件 | 邮件 |
| mailNickname | msDS-AzureADMailNickname |
| objectid | msDS-AzureADObjectId |
| 本地安全标识符 (onPremiseSecurityIdentifier) | SID历史 (sidHistory) |
| 代理地址 | 代理地址 |
| 启用了安全功能 | groupType |
从本地 AD DS 同步到 Microsoft Entra ID 和 Microsoft Entra 域服务
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或域服务：
- Excluded attributes： 您可以选择使用 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。
若要开始使用域服务， 请创建托管域。