当你创建并运行 Microsoft Entra 域服务托管域时，与传统的本地 AD DS 环境相比，行为存在一些差异。 在域服务中使用的管理工具与自托管域中的相同，但你无法直接访问域控制器 (DC)。 密码策略和密码哈希的行为也存在一些差异，具体取决于创建用户帐户的源。
这篇概念性文章详细介绍了如何管理托管域，以及用户帐户的不同行为（具体取决于创建方式）。
域管理
托管域是一个 DNS 命名空间和匹配目录。 在托管域中，包含所有资源（例如用户和组、凭据和策略）的域控制器 (DC) 是托管服务的一部分。 为实现冗余，将创建两个 DC 作为托管域的一部分。 你无法登录到这些 DC 来执行管理任务， 而是创建已加入托管域的管理虚拟机（VM），然后安装常规 AD DS 管理工具。 例如，你可以使用 Active Directory 管理中心或 Microsoft 管理控制台 (MMC) 管理单元（例如 DNS 或组策略对象）。
创建用户帐户
可以通过多种方式在托管域中创建用户帐户。 大多数用户帐户是从 Microsoft Entra ID 同步进来的，而后者可能也包括从本地 AD DS 环境同步的用户帐户。 你还可以直接在托管域中手动创建帐户。 某些功能（例如初始密码同步或密码策略）的行为方式不同，具体取决于创建用户帐户的方式和位置。
- 可以从 Microsoft Entra ID 同步用户帐户。 可以使用 Microsoft Entra Connect 直接在从本地 AD DS 环境同步的Microsoft Entra ID中创建它。
- 可以在托管域中手动创建用户帐户，Microsoft Entra ID中不存在。 如果需要为仅在托管域中运行的应用程序创建服务帐户，你可以在托管域中手动创建它们。 同步仅与Microsoft Entra ID单向同步，因此在托管域中创建的用户帐户不会同步回Microsoft Entra ID。
密码策略
域服务包括一个默认的密码策略，该策略定义了帐户锁定、最长密码期限和密码复杂性等内容的设置。 帐户锁定策略等设置应用于托管域中的所有用户，与上一部分中概述的用户创建方式无关。 一些设置（例如最小密码长度和密码复杂性）仅应用于直接在托管域中创建的用户。
你可以创建自己的自定义密码策略来替代托管域中的默认策略。 然后，可以根据需要将这些自定义策略应用于特定的用户组。
若要详细了解如何根据创建用户的源以不同的方式应用密码策略，请参阅托管域中的密码和帐户锁定策略。
密码哈希
若要对托管域上的用户进行身份验证，域服务需要密码哈希，其格式适用于 NT LAN Manager (NTLM) 和 Kerberos 身份验证。 Microsoft Entra ID在为租户启用域服务之前，不会生成或存储 NTLM 或 Kerberos 身份验证所需的格式的密码哈希。 出于安全考虑，Microsoft Entra ID 也不以明文形式存储任何密码凭据。 因此，Microsoft Entra ID 无法基于用户的现有凭据自动生成这些 NTLM 或 Kerberos 密码哈希。
对于纯云用户帐户，用户必须更改其密码才能使用托管域。 此密码更改过程会导致在 Microsoft Entra ID 中生成并存储用于 Kerberos 和 NTLM 身份验证的密码哈希。 在更改密码之前，该帐户不会从 Microsoft Entra ID 同步到域服务。
对于使用 Microsoft Entra Connect 从本地 AD DS 环境同步的用户，请启用密码哈希同步。
重要
为 Microsoft Entra 租户启用域服务时，Microsoft Entra Connect 仅同步旧密码哈希。 如果仅使用 Microsoft Entra Connect 将本地 AD DS 环境与 Microsoft Entra ID 同步，则不会使用旧式密码哈希。
如果旧版应用程序不使用 NTLM 身份验证或轻型目录访问协议 （LDAP） 简单绑定，建议禁用域服务的 NTLM 密码哈希同步。 有关详细信息，请参阅禁用弱密码套件和 NTLM 凭据哈希同步。
经过适当的配置后，可用的密码哈希将存储在托管域中。 删除托管域也会删除其中存储的所有密码哈希。 如果以后创建其他托管域，则 Microsoft Entra ID 中已同步的凭据信息不可重复使用 - 必须重新配置密码哈希同步，以再次存储密码哈希。 以前已加入域的 VM 或用户无法立即进行身份验证 - Microsoft Entra ID 需要在新的托管域中生成和存储密码哈希。 有关详细信息，请参阅 域服务和 Microsoft Entra Connect 的密码哈希同步过程。
重要
安装和配置的 Microsoft Entra Connect 应仅用于与本地 AD DS 环境同步。 不支持在托管域中安装 Microsoft Entra Connect 以与 Microsoft Entra ID 同步。
林和信任
林是 Active Directory 域服务 (AD DS) 用于对一个或多个 域 进行分组的逻辑结构。 域随后会存储用户或组的对象，并提供身份验证服务。
在域服务中，林仅包含一个域。 本地部署的 AD DS 林通常包含多个域。 在大型组织中，特别是在合并和收购之后，最终可能会得到多个本地林，每个林又包含多个域。
默认情况下，托管域会同步 Microsoft Entra ID 中的所有对象，包括在本地 AD DS 环境中创建的任何用户帐户。 用户帐户可以直接针对托管域进行身份验证，例如登录已加入域的 VM。 当可以同步密码哈希，并且用户不使用独占登录方法（如智能卡身份验证）时，此方法可发挥作用。
在域服务中，还可以与另一个域创建林信任关系，让用户能够访问资源。 您可以根据访问需求，以不同方向创建林信任。
| 信任方向 | 用户访问权限 |
|---|---|
| 双向 | 允许托管域和本地域中的用户访问任一域中的资源。 |
| 单向传出 | 允许本地域域中的用户访问托管域中的资源，但反之则不然。 |
| 单向传入 | 允许托管域中的用户访问本地域内的资源。 |
“域服务”SKU
在域服务中，可用的性能和功能基于库存单位（SKU）。 创建托管域时，可以选择 SKU，并且可以在创建托管域后更改业务要求时切换 SKU。 下表概述了可用的 SKU 以及它们之间的差异：
| SKU | 建议的对象数量 | 建议的身份验证量 | 备份频率 |
|---|---|---|---|
| 标准 | 最多 25,000 个对象 | 最多 3,000 个身份验证/小时 | 每五天 |
| Enterprise | 25,001-100,000 个对象 | 3,001-10,000 个身份验证/小时 | 每三天 |
| 高级 | 100,001-500,000 个对象 | 10,001-70,000 个身份验证/小时 | 日常;备份保留七天，第三次备份保留 30 天 |
注释
显示的值为建议的容量指南，而不是强制实施的限制。 随着 SKU 级别的增加，将更多的计算资源分配给托管域，从而提高性能、同步操作和身份验证吞吐量。 根据工作负载规模、身份验证量、性能要求和恢复目标选择 SKU。
在这些域服务 SKU 之前，使用的是基于托管域中的对象（用户和计算机帐户）数量的计费模型。 不再根据托管域中的对象数来改变定价。
有关详细信息，请参阅域服务定价页。
托管域名性能
域性能因应用程序的身份验证实现方式而异。 更多计算资源可能有助于改善查询响应时间并减少同步时间。 随着 SKU 级别的增加，托管域可以使用更多的计算资源。 监视应用程序的性能并规划所需的资源。
如果业务或应用程序需要更改，并且托管域需要更多的计算能力，则可以切换到其他 SKU。
备份频率
备份频率决定了托管域快照的创建频率。 备份是由 Microsoft Entra 平台管理的自动化过程。 如果托管域出现问题，Microsoft Entra支持人员可以帮助你从备份还原。 由于同步仅以单向方式从 Microsoft Entra ID 进行，因此托管域中的任何问题都不会影响 Microsoft Entra ID 或本地 AD DS 环境及其功能。
随着 SKU 级别的提高，这些备份快照的频率也会提高。 请查看你的业务需求和恢复点目标 (RPO)，以确定托管域所需的备份频率。 如果你的业务或应用程序需求发生变化，并且你需要更频繁的备份，则可以切换到其他 SKU。
域服务针对不同类型的问题提供以下恢复时间跨度指南：
- 恢复点目标（RPO）是指在发生故障时，数据或事务可能丢失的最长时间段。
- 恢复时间对象 (RTO) 是事件发生后服务级别返回到操作之前的目标时间跨度。
| 问题 | RPO | RTO |
|---|---|---|
| 由于域服务域控制器、依赖项服务的数据丢失或损坏、泄露域的漏洞或需要还原域控制器的其他事件而导致的问题。 | 事件发生前五天 | 两小时到四天，具体取决于租户大小 |
| 由 Microsoft 支持部门 域诊断识别的问题。 | 零（0 分钟） | 两小时到四天，具体取决于租户大小 |
后续步骤
若要开始，请创建一个域服务托管域。