实现和配置 Microsoft Entra 域服务
使用仅限云的 Microsoft Entra ID 的组织可以为 Azure VNet 启用 Microsoft Entra 域服务，然后获取新的托管域。 Microsoft Entra ID 中的用户和组在新创建的域中可用，这提供了与本地 AD DS 类似的目录服务，包括组策略、Kerberos 协议和 LDAP 支持。
可以将运行 Windows 的 Azure VM 加入新创建的域，并使用基本组策略设置对其进行管理。 通过启用 Microsoft Entra 域服务，NTLM 和 Kerberos 身份验证所需的凭据哈希存储在 Microsoft Entra ID 中。
由于 Contoso 是一个混合组织，因此他们可以通过使用 Microsoft Entra Connect 将本地 AD DS 中的标识与 Microsoft Entra 域服务集成。 在本地基础结构中访问基于域的资源时，或者通过在集成了 Microsoft Entra 域服务的 Azure 虚拟网络中运行的 VM 访问资源时，混合组织中的用户可以获得相同的体验。
实现 Microsoft Entra 域服务
要实现、配置和使用 Microsoft Entra 域服务，必须在 Microsoft Entra 订阅中创建 Microsoft Entra 租户。 此外，要使用 Microsoft Entra 域服务，必须使用 Microsoft Entra Connect 部署密码哈希同步。 这是必要的操作，因为 Microsoft Entra 域服务可提供 NTLM 和 Kerberos 身份验证，因此需要用户的凭据。
在为租户启用 Microsoft Entra 域服务时，必须选择将用于此服务的 DNS 域名。 还需要选择要与本地环境同步的域。
注意
不应使用现有的 Azure 或本地 DNS 域名空间。
下表描述了可用的 DNS 域名选项。
| 选项 | 描述 |
|---|---|
| 内置域名 | 默认情况下，将使用目录的内置域名（.onmicrosoft.com 后缀）。 若要实现通过 Internet 对托管域进行安全的 LDAP 访问，则不能创建数字证书来保护与此默认域建立的连接。 Microsoft 拥有 .onmicrosoft.com 域，因此，证书颁发机构 (CA) 不会颁发证书。 |
| 自定义域名 | 最常见的方法是指定自定义域名，通常是你已拥有且可路由的域名。 使用可路由的自定义域时，流量可根据需要正确传送，以支持你的应用程序。 |
| 不可路由的域后缀 | 一般情况下，我们建议避免使用不可路由的域名后缀，例如 contoso.local。 .local 后缀不可路由，并可能会导致 DNS 解析出现问题。 |
提示
你可能需要为环境中的其他服务或环境中现有 DNS 命名空间之间的条件 DNS 转发器创建其他 DNS 记录。
在实现过程中，还需要选择要预配的林类型。 林是 AD DS 用来对一个或多个域进行分组的逻辑构造。 有两种林类型，如下表中所述。
| 林类型 | 说明 |
|---|---|
| 用户 | 此类林可同步 Microsoft Entra ID 中的所有对象，包括在本地 AD DS 环境中创建的所有用户帐户。 |
| 资源 | 此类型的林将仅同步在 Microsoft Entra ID 中直接创建的用户和组。 |
接下来，需要选择要在其中创建托管域的 Azure 位置。 如果选择支持可用性区域的区域，则 Microsoft Entra 域服务资源会跨区域分布，以实现额外的冗余。
注意
无需将 Microsoft Entra 域服务配置为跨区域分布。 Azure 平台会自动管理资源的区域分布。
还需要选择要将此服务连接到的 VNet。 由于 Microsoft Entra 域服务为本地资源提供功能，因此必须在本地和 Azure 环境之间建立 VNet。
在预配过程中，Microsoft Entra 域服务会在 Microsoft Entra 租户中创建两个企业应用程序。 需要这些应用程序来为托管域服务，因此不应删除这些应用程序。 企业应用程序包括：
- 域控制器服务。
- AzureActiveDirectoryDomainControllerServices.
部署 Microsoft Entra 域服务实例之后，必须配置 VNet 以支持其他连接的 VM 和应用程序使用托管域。 要提供此连接，必须更新 VNet 的 DNS 服务器设置，以指向与 Microsoft Entra 域服务实例关联的 IP 地址。
要对托管域上的用户进行身份验证，Microsoft Entra 域服务需要格式适用于 NTLM 和 Kerberos 身份验证的密码哈希。 除非为租户启用了 Microsoft Entra 域服务，否则 Microsoft Entra ID 不会以 NTLM 或 Kerberos 身份验证所需的格式生成或存储密码哈希。 出于安全考虑，Microsoft Entra ID 也不以明文形式存储任何密码凭据。 因此，Microsoft Entra ID 无法基于用户的现有凭据自动生成这些 NTLM 或 Kerberos 密码哈希。 配置可用的密码哈希后，它们将存储在 Microsoft Entra 域服务托管域中。
注意
如果删除 Microsoft Entra 域服务托管域，则还会删除此时存储的任何密码哈希。
如果稍后创建 Microsoft Entra 域服务托管域，则无法重用 Microsoft Entra ID 中已同步的凭据信息 - 必须重新配置密码哈希同步，才能再次存储密码哈希。 以前加入域的 VM 或用户无法立即进行身份验证，这是因为 Microsoft Entra ID 需要在新的 Microsoft Entra 域服务托管域中生成和存储密码哈希。
对于在 Microsoft Entra ID 中创建的仅限云的用户帐户而言，生成和存储这些密码哈希的步骤不同于使用 Microsoft Entra Connect 从本地目录同步的用户帐户。 纯云用户帐户是使用 Azure 门户或 Microsoft Graph PowerShell cmdlet 在 Microsoft Entra 目录中创建的帐户。 这些用户帐户不是从本地目录同步的。
对于仅限云的用户帐户，用户必须先更改其密码，然后才能使用 Microsoft Entra 域服务。 此密码更改过程会导致在 Microsoft Entra ID 中生成并存储用于 Kerberos 身份验证和 NTLM 身份验证的密码哈希。 在更改密码之前，该帐户不会从 Microsoft Entra ID 同步到 Microsoft Entra 域服务。 对于租户中所有需要使用 Microsoft Entra 域服务的云用户，可以使其密码过期，以强制他们在下次登录时更改密码，也可以指示他们手动更改密码。
提示
必须先配置 Microsoft Entra 租户以实现自助式密码重置，然后用户才能重置其密码。
附加阅读材料
若要了解详细信息，请查看以下文档。