你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

了解适用于 Azure NetApp 文件的 Active Directory 域服务站点设计和规划准则

项目
12/27/2023

正确的 Active Directory 域服务 (AD DS) 设计和规划对于使用 Azure NetApp 文件卷的解决方案体系结构十分关键。 Azure NetApp 文件功能（如 SMB 卷、双协议卷和 NFSv4.1 Kerberos 卷）旨在与 AD DS 配合使用。

本文提供建议来帮助你为 Azure NetApp 文件开发 AD DS 部署策略。阅读本文之前，需要很好地了解 AD DS 如何在功能级别上工作。

确定 Azure NetApp 文件的 AD DS 要求

部署 Azure NetApp 文件卷之前，必须确定 Azure NetApp 文件的 AD DS 集成要求，以确保 Azure NetApp 文件与 AD DS 良好连接。与 Azure NetApp 文件的 AD DS 集成不正确或不完整可能会导致对 SMB、双协议或 Kerberos NFSv4.1 卷的客户端访问中断或发生故障。

支持的身份验证方案

Azure NetApp 文件支持使用以下方法通过 SMB 进行基于标识的身份验证。

AD DS 身份验证：已联接 AD DS 的 Windows 计算机可以通过 SMB 使用 Active Directory 凭据访问 Azure NetApp 文件共享。客户端必须可访问 AD DS。如果已在本地或 Azure 中的 VM 上设置 AD DS，并且 VM 中的设备已加入 AD DS 域，则应使用 AD DS 进行 Azure NetApp 文件共享身份验证。
Microsoft Entra 域服务身份验证：基于云的 Microsoft Entra 域服务联接的 Windows VM 可以使用 Microsoft Entra 域服务凭据访问 Azure NetApp 文件共享。在此解决方案中，Microsoft Entra 域服务代表客户运行传统的 Windows Server AD 域。
用于混合标识的 Microsoft Entra Kerberos：使用 Microsoft Entra ID 对混合用户标识进行身份验证，允许 Microsoft Entra 用户使用 Kerberos 身份验证访问 Azure NetApp 文件共享。这意味着你的最终用户可以访问 Azure NetApp 文件共享，而无需从 Microsoft Entra 混合联接和 Microsoft Entra 联接的 Windows 或 Linux 虚拟机访问域控制器。目前不支持仅限云的标识。
适用于 Linux 客户端的 AD Kerberos 身份验证：Linux 客户端可以使用 AD DS 通过 SMB 对 Azure NetApp 文件使用 Kerberos 身份验证。

网络要求

Azure NetApp 文件 SMB、双协议和 Kerberos NFSv4.1 卷需要与 AD DS 域控制器建立可靠的低延迟网络连接（小于 10 毫秒 RTT）。 Azure NetApp 文件与 AD DS 域控制器之间的网络连接不佳或网络延迟较高可能会导致客户端访问中断或客户端超时。

确保满足以下有关网络拓扑和配置的要求：

确保使用 Azure NetApp 文件支持的网络拓扑。
确保 AD DS 域控制器可从托管 Azure NetApp 文件卷的 Azure NetApp 文件委托子网建立网络连接。
- 具有 AD DS 域控制器的对等互连虚拟网络拓扑必须正确配置对等，才能支持 Azure NetApp 文件到 AD DS 域控制器的网络连接。
网络安全组 (NSG) 和 AD DS 域控制器防火墙必须适当配置了规则，以支持 Azure NetApp 文件与 AD DS 和 DNS 的连接。
确保 Azure NetApp 文件与 AD DS 域控制器之间的延迟小于 10 毫秒 RTT。

所需网络端口如下所示：

服务	端口	协议
AD Web 服务	9389	TCP
DNS*	53	TCP
DNS*	53	UDP
ICMPv4	空值	回显回复
Kerberos	464	TCP
Kerberos	464	UDP
Kerberos	88	TCP
Kerberos	88	UDP
LDAP	389	TCP
LDAP	389	UDP
LDAP	389	TLS
LDAP	3268	TCP
NetBIOS 名称	138	UDP
SAM/LSA	445	TCP
SAM/LSA	445	UDP

*在 AD DS 域控制器上运行的 DNS

DNS 要求

Azure NetApp 文件 SMB、双协议和 Kerberos NFSv4.1 卷需要可对域名系统 (DNS) 服务和最新 DNS 记录进行可靠访问。 Azure NetApp 文件与 DNS 服务器之间的网络连接不佳可能会导致客户端访问中断或客户端超时。 AD DS 或 Azure NetApp 文件的 DNS 记录不完整或不正确可能会导致客户端访问中断或客户端超时。

Azure NetApp 文件支持使用 Active Directory 集成 DNS 或独立 DNS 服务器。

确保满足以下有关 DNS 配置的要求：

如果使用独立 DNS 服务器：
- 确保 DNS 服务器可与托管 Azure NetApp 文件卷的 Azure NetApp 文件委托子网建立网络连接。
- 确保防火墙或 NSG 不会阻止网络端口 UDP 53 和 TCP 53。
确保在 DNS 服务器上创建了 AD DS 网络登录服务注册的 SRV 记录。
在与 Azure NetApp 文件配置相同的域中，确保已在 DNS 服务器上创建了 Azure NetApp 文件使用的 AD DS 域控制器的 PTR 记录。
删除卷时，Azure NetApp 文件不会自动删除与 DNS 条目关联的指针记录 (PTR)。 PTR 记录用于反向 DNS 查找，将 IP 地址映射到主机名。这些记录通常由 DNS 服务器的管理员管理。在 Azure NetApp 文件中创建卷时，可以将其与 DNS 名称相关联。但是，DNS 记录（包括 PTR 记录）的管理不在 Azure NetApp 文件的范围内。 Azure NetApp 文件提供了将卷与 DNS 名称关联的选项，以便于访问，但不管理与该名称关联的 DNS 记录。如果删除 Azure NetApp 文件中的卷，则需要管理关联的 DNS 记录（例如用于转发 DNS 查找的 A 记录）并将其从 DNS 服务器或正在使用的 DNS 服务中删除。
Azure NetApp 文件支持标准的安全动态 DNS 更新。如果需要安全动态 DNS 更新，请确保在 DNS 服务器上配置安全更新。
如果未使用动态 DNS 更新，则需要为 AD DS 组织单位（在 Azure NetApp 文件 AD 连接中指定）中创建的 AD DS 计算机帐户手动创建 A 记录和 PTR 记录，以支持 Azure NetApp 文件 LDAP 签名、基于 TLS 的 LDAP、SMB、双协议或 Kerberos NFSv4.1 卷。
对于复杂或大型 AD DS 拓扑，可能需要 DNS 策略或 DNS 子网优先级以支持已启用 LDAP 的 NFS 卷。

时间源要求

Azure NetApp 文件使用 time.windows.com 作为时间源。确保 Azure NetApp 文件使用的域控制器配置为使用 time.windows.com 或其他准确的稳定根（第 1 层）时间源。如果 Azure NetApp 文件与客户端或 AS DS 域控制器之间存在五分钟以上的偏差，则身份验证会失败；对 Azure NetApp 文件卷的访问也可能会失败。

确定要与 Azure NetApp 文件配合使用的 AD DS

Azure NetApp 文件支持使用 Active Directory 域服务 (AD DS) 和 Microsoft Entra 域服务进行 AD 连接。在创建 AD 连接之前，需要决定是使用 AD DS 还是 Microsoft Entra 域服务。

有关详细信息，请参阅比较自托管 Active Directory 域服务、Microsoft Entra ID 和托管 Microsoft Entra 域服务。

Active Directory 域服务注意事项

应在以下情形中使用 Active Directory 域服务 (AD DS)：

在本地 AD DS 域中托管需要访问 Azure NetApp 文件资源的 AD DS 用户。
使需要访问 Azure NetApp 文件资源的应用程序部分在本地，部分在 Azure 中进行托管。
不需要将 Microsoft Entra 域服务与订阅中的 Microsoft Entra 租户集成，或者 Microsoft Entra 域服务与技术需求不兼容。

注意

Azure NetApp 文件不支持使用 AD DS 只读域控制器 (RODC)。

如果选择将 AD DS 与 Azure NetApp 文件配合使用，请按照将 AD DS 扩展到 Azure 体系结构指南中的指导进行操作，并确保满足 AD DS 的 Azure NetApp 文件网络和 DNS 要求。

Microsoft Entra 域服务注意事项

Microsoft Entra 域服务是与 Microsoft Entra 租户同步的托管 AD DS 域。使用 Microsoft Entra 域服务的主要优势如下：

Microsoft Entra 域服务是一个独立的域。因此，无需在本地与 Azure 之间设置网络连接。
提供简化部署和管理体验。

应在以下情形中使用 Microsoft Entra 域服务：

无需将 AD DS 从本地扩展到 Azure 以提供对 Azure NetApp 文件资源的访问权限。
安全策略不允许将本地 AD DS 扩展到 Azure。
你不是很了解 AD DS。 Microsoft Entra 域服务可以提高使用 Azure NetApp 文件获得良好结果的可能性。

如果选择将 Microsoft Entra 域服务与 Azure NetApp 文件配合使用，请参阅 Microsoft Entra 域服务文档，了解体系结构、部署和管理指导。确保也满足 Azure NetApp 文件网络和 DNS 要求。

设计 AD DS 站点拓扑以便与 Azure NetApp 文件配合使用

AD DS 站点拓扑的正确设计对于涉及 Azure NetApp 文件 SMB、双协议或 NFSv4.1 Kerberos 卷的任何解决方案体系结构都至关重要。

AD DS 站点拓扑或配置不正确可能会导致以下行为：

无法创建 Azure NetApp 文件 SMB、双协议或 NFSv4.1 Kerberos 卷
无法修改 ANF AD 连接配置
LDAP 客户端查询性能不佳
身份验证问题

Azure NetApp 文件的 AD DS 站点拓扑是 Azure NetApp 文件网络的逻辑表示形式。为 Azure NetApp 文件设计 AD DS 站点拓扑涉及规划域控制器放置、设计站点、DNS 基础结构和网络子网以确保在 Azure NetApp 文件服务、Azure NetApp 文件存储客户端和 AD DS 域控制器间建立良好连接。

除了分配到 Azure NetApp 文件 AD 站点名称中配置的 AD DS 站点的多个域控制器之外，还可为 Azure NetApp 文件 AD DS 站点分配一个或多个子网。

注意

分配到 Azure NetApp 文件 AD DS 站点的所有域控制器和子网必须连接正常（RTT 延迟小于 10 毫秒），并且可由 Azure NetApp 文件卷使用的网络接口访问。

如果使用标准网络功能，则应确保任何用户定义的路由 (UDR) 或网络安全组 (NSG) 规则不会阻止 Azure NetApp 文件与分配到 Azure NetApp 文件 AD DS 站点的 AD DS 域控制器进行网络通信。

如果使用网络虚拟设备或防火墙（例如 Palo Alto Networks 或 Fortinet 防火墙），则必须将其配置为不阻止 Azure NetApp 文件与分配到 Azure NetApp 文件 AD DS 站点的 AD DS 域控制器和子网之间的网络流量。

Azure NetApp 文件如何使用 AD DS 站点信息

Azure NetApp 文件使用 Active Directory 连接中配置的“AD 站点名称”发现存在哪些域控制器来支持身份验证、域加入、LDAP 查询和 Kerberos 票证操作。

AD DS 域控制器发现

Azure NetApp 文件每四小时启动一次域控制器发现。 Azure NetApp 文件查询特定于站点的 DNS 服务 (SRV) 资源记录，以确定哪些域控制器处于 Azure NetApp 文件 AD 连接的“AD 站点名称”字段中指定的 AD DS 站点中。 Azure NetApp 文件域控制器服务发现会检查域控制器上托管的服务（例如 Kerberos、LDAP、网络登录和 LSA）的状态，并选择最佳域控制器以用于身份验证请求。

在 Azure NetApp 文件 AD 连接的 AD 站点名称字段中指定的 AD DS 站点的 DNS 服务 (SRV) 资源记录必须包含 Azure NetApp 文件使用的 AD DS 域控制器的 IP 地址列表。可以使用 nslookup 实用工具检查 DNS (SRV) 资源记录的有效性。

注意

如果对 Azure NetApp 文件所使用的 AD DS 站点中的域控制器进行更改，请在部署新的 AD DS 域控制器与停用现有 AD DS 域控制器之间等待至少四小时。此等待时间使 Azure NetApp 文件能够发现新的 AD DS 域控制器。

确保从 DNS 中移除与已停用 AD DS 域控制器关联的过时 DNS 记录。这样做可确保 Azure NetApp 文件不会尝试与已停用域控制器通信。

AD DS LDAP 服务器发现

为 Azure NetApp 文件 NFS 卷启用 LDAP 时，会进行针对 AD DS LDAP 服务器的单独发现过程。在 Azure NetApp 文件上创建 LDAP 客户端时，Azure NetApp 文件会查询 AD DS 域服务 (SRV) 资源记录，以获取域中所有 AD DS LDAP 服务器的列表，而不是分配给 AD 连接中指定的 AD DS 站点的 AD DS LDAP 服务器。

在大型或复杂 AD DS 拓扑中，可能需要实现 DNS 策略或 DNS 子网优先级，以确保返回分配给 AD 连接中指定的 AD DS 站点的 AD DS LDAP 服务器。

或者，可以通过为 LDAP 客户端指定最多两个首选 AD 服务器来替代 AD DS LDAP 服务器发现过程。

重要

如果在创建 Azure NetApp 文件 LDAP 客户端期间 Azure NetApp 文件无法访问发现的 AD DS LDAP 服务器，则创建已启用 LDAP 的卷会失败。

不正确或不完整的 AD 站点名称配置的后果

AD DS 站点拓扑或配置不正确或不完整可能会导致卷创建失败、客户端查询问题、身份验证失败以及修改 Azure NetApp 文件 AD 连接失败。

重要

创建 Azure NetApp 文件 AD 连接需要“AD 站点名称”字段。定义的 AD DS 站点必须存在并已正确配置。

Azure NetApp 文件使用 AD DS 站点来发现分配给“AD 站点名称”中定义的“AD DS 站点”的域控制器和子网。分配给 AD DS 站点的所有域控制器都必须已与 ANF 使用的 Azure 虚拟网络接口建立良好的网络连接，并且可以访问。分配给 Azure NetApp 文件使用的 AD DS 站点的 AD DS 域控制器 VM 必须已从关闭 VM 的成本管理策略中排除。

如果 Azure NetApp 文件无法访问分配到 AD DS 站点的任一域控制器，则域控制器发现过程将查询 AD DS 域以获取所有域控制器的列表。从此查询返回的域控制器列表是无序列表。因此，Azure NetApp 文件可能会尝试使用不可访问的或连接不正常的域控制器，从而导致卷创建失败、客户端查询出现问题、身份验证失败以及无法修改 Azure NetApp 文件 AD 连接。

每当新域控制器部署到分配给 Azure NetApp 文件 AD 连接使用的 AD DS 站点的子网中时，都必须更新 AD DS 站点配置。确保站点的 DNS SRV 记录反映了对分配给 Azure NetApp 文件使用的 AD DS 站点的域控制器的任何更改。可以使用 nslookup 实用工具检查 DNS (SRV) 资源记录的有效性。

注意

Azure NetApp 文件不支持使用 AD DS 只读域控制器 (RODC)。若要防止 Azure NetApp 文件使用 RODC，请不要使用 RODC 配置 AD 连接的“AD 站点名称”字段。

Azure NetApp 文件的 AD DS 站点拓扑配置示例

AD DS 站点拓扑是部署 Azure NetApp 文件的网络的逻辑表示形式。在本部分中，AD DS 站点拓扑的示例配置方案旨在演示 Azure NetApp 文件的基本 AD DS 站点设计。它并不是为 Azure NetApp 文件设计网络或 AD 站点拓扑的唯一方法。

重要

对于涉及复杂 AD DS 或复杂网络拓扑的方案，应让 Microsoft Azure CSA 评审 Azure NetApp 文件网络和 AD 站点设计。

下图显示了示例网络拓扑：sample-network-topology.png

在示例网络拓扑中，本地 AD DS 域 (anf.local) 扩展到 Azure 虚拟网络中。本地网络使用 Azure ExpressRoute 线路连接到 Azure 虚拟网络。

Azure 虚拟网络有四个子网：网关子网、Azure Bastion 子网、AD DS 子网和 Azure NetApp 文件委托子网。已加入 anf.local 域的冗余 AD DS 域控制器部署到 AD DS 子网中。 AD DS 子网分配有 IP 地址范围 10.0.0.0/24。

Azure NetApp 文件只能使用一个 AD DS 站点确定哪些域控制器将用于身份验证、LDAP 查询和 Kerberos。在示例方案中，创建了两个子网对象，并将其分配给使用 Active Directory 站点和服务实用工具的名为 ANF 的站点。一个子网对象映射到 AD DS 子网 10.0.0.0/24，另一个子网对象映射到 ANF 委托子网 10.0.2.0/24。

在 Active Directory 站点和服务工具中，验证是否将部署到 AD DS 子网中的 AD DS 域控制器分配给 ANF 站点：

若要创建映射到 Azure 虚拟网络中的 AD DS 子网的子网对象，请右键单击“Active Directory 站点和服务”实用工具中的“子网”容器，然后选择“新建子网...”。在“新建对象 - 子网”对话框中，在“前缀”字段中输入 AD DS 子网的 10.0.0.0/24 IP 地址范围。选择 ANF 作为子网的站点对象。选择“确定”以创建子网对象并将它分配给 ANF 站点。

若要验证新子网对象是否已分配给正确的站点，请右键单击 10.0.0.0/24 子网对象，然后选择“属性”。 “站点”字段应显示 ANF 站点对象：

若要创建映射到 Azure 虚拟网络中的 Azure NetApp 文件委托子网的子网对象，请右键单击“Active Directory 站点和服务”实用工具中的“子网”容器，然后选择“新建子网...”。

跨区域复制注意事项

Azure NetApp 文件跨区域复制使你可以将 Azure NetApp 文件卷从一个区域复制到另一个区域，以支持业务连续性和灾难恢复 (BC/DR) 要求。

Azure NetApp 文件 SMB、双协议和 NFSv4.1 Kerberos 卷支持跨区域复制。复制这些卷需要满足以下要求：

在源区域和目标区域中创建的 NetApp 帐户。
在源区域和目标区域中创建的 NetApp 帐户中的 Azure NetApp 文件 Active Directory 连接。
AD DS 域控制器在目标区域中部署并运行。
必须在目标区域中部署正确的 Azure NetApp 文件网络、DNS 和 AD DS 站点设计，才能实现 Azure NetApp 文件与目标区域中的 AD DS 域控制器的良好网络通信。
目标区域中的 Active Directory 连接必须配置为使用目标区域中的 DNS 和 AD 站点资源。