你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
了解如何在 Azure NetApp 文件中使用 LDAP
轻型目录访问协议 (LDAP) 是由名为 Internet 工程任务组 (IETF) 的国际委员会开发的标准目录访问协议。 LDAP 旨在提供通用的、基于网络的目录服务，可以使用它来跨异构平台查找网络对象。
LDAP 模型定义如何与 LDAP 目录存储通信、如何在目录中查找对象、如何描述存储中的对象以及用于访问目录的安全性。 LDAP 允许自定义和扩展存储中描述的对象。 因此，可以使用 LDAP 存储来存储多种类型的信息。 许多初始 LDAP 部署注重使用 LDAP 作为电子邮件和 Web 应用程序等应用程序的目录存储以及存储员工信息。 许多公司正在或已经使用 LDAP 取代网络信息服务 (NIS) 作为网络目录存储。
LDAP 服务器提供用于 NAS 卷的 UNIX 用户和组标识。 在 Azure NetApp 文件中，Active Directory 是当前唯一可用的受支持 LDAP 服务器。 此支持包括 Active Directory 域服务 (AD DS) 和 Microsoft Entra 域服务。
LDAP 请求分为两个主要操作。
- LDAP 绑定是从 LDAP 客户端登录到 LDAP 服务器。 绑定用于使用只读访问权限向 LDAP 服务器进行身份验证，以执行 LDAP 查找。 Azure NetApp 文件充当 LDAP 客户端。
- LDAP 查找用于查询目录中的用户和组信息，例如名称、数字 ID、主目录路径、登录 shell 路径、组成员资格等。
LDAP 可以存储双重协议 NAS 访问中使用的以下信息：
- 用户名
- 组名
- 数字用户 ID (UID) 和组 ID (GID)
- 主目录
- 登录 shell
- 网络组、DNS 名称和 IP 地址
- 组成员身份
目前，Azure NetApp 文件仅使用 LDAP 来获取用户和组信息 - 不获取网络组或主机信息。
LDAP 作为标识源为 UNIX 用户和组提供了各种优势。
- LDAP 面向未来。
随着越来越多的 NFS 客户端添加对 NFSv4.x 的支持，需要包含可从客户端和存储访问的最新用户和组列表的 NFSv4.x ID 域，以确保在定义访问权限时获得最佳安全性和保证访问成功。 拥有一个为 SMB 和 NFS 用户提供一对一名称映射的标识管理服务器，可以大大减轻存储管理员的工作量，不仅是现在，而且是未来的几年。 - LDAP 可缩放。
LDAP 服务器可以包含数百万个用户和组对象，并且借助 Microsoft Active Directory，可以使用多台服务器跨多个站点进行复制，以确保性能和弹性缩放。 - LDAP 非常安全。
LDAP 使存储系统能够安全地连接到 LDAP 服务器来请求用户信息。 LDAP 服务器提供以下绑定级别：- 匿名（Microsoft Active Directory 中默认会禁用；Azure NetApp 文件中不受支持）
- 简单密码（纯文本密码；在 Azure NetApp 文件中不受支持）
- 简单身份验证和安全层 (SASL) – 加密的绑定方法，包括 TLS、SSL、Kerberos 等。 Azure NetApp 文件支持 LDAP over TLS、LDAP 签名（使用 Kerberos）、LDAP over SSL。
- LDAP 非常可靠。
NIS、NIS+ 和本地文件提供基本信息，例如 UID、GID、密码、主目录等。 但是，LDAP 除了提供这些属性之外，还提供其他许多属性。 LDAP 使用的附加属性使双重协议管理与 LDAP 和 NIS 的集成度更高。 仅支持将 LDAP 作为使用 Azure NetApp 文件进行标识管理的外部名称服务。 - Microsoft Active Directory 基于 LDAP。
默认情况下，Microsoft Active Directory 使用 LDAP 后端来存储其用户和组条目。 但是，此 LDAP 数据库不包含 UNIX 样式属性。 通过 UNIX 标识管理（Windows 2003R2 及更高版本）、UNIX 服务（Windows 2003 及更低版本）或第三方 LDAP 工具（例如 Centrify）扩展 LDAP 架构时，会添加这些属性。 由于 Microsoft 使用 LDAP 作为后端，因此 LDAP 成为选择利用 Azure NetApp 文件中的双重协议卷的环境的完美解决方案。注意
Azure NetApp 文件目前仅支持用于 LDAP 服务的本机 Microsoft Active Directory。
Azure NetApp 文件中的 LDAP 基础知识
以下部分讨论与 Azure NetApp 文件相关的 LDAP 基础知识。
LDAP 信息存储在 LDAP 服务器中的平面文件中，并通过 LDAP 模式进行组织。 应该以某种方式配置 LDAP 客户端，使其请求和查找与 LDAP 服务器上的架构相协调。
LDAP 客户端通过 LDAP 绑定发起查询，这本质上是使用具有 LDAP 架构读取权限的帐户登录到 LDAP 服务器。 客户端上的 LDAP 绑定配置使用 LDAP 服务器定义的安全机制。 有时，它们是纯文本（简单）形式的用户名和密码交换。 在其他情况下，绑定通过简单身份验证和安全层方法 (
sasl)（例如 Kerberos 或 LDAP over TLS）进行保护。 Azure NetApp 文件使用 SMB 计算机帐户通过 SASL 身份验证进行绑定，以实现最佳安全性。客户端可以使用 RFC 2307 中定义的标准 LDAP 搜索请求来查询存储在 LDAP 中的用户和组信息。 此外，RFC 2307bis 等较新机制可实现更简化的用户和组查找。 Azure NetApp 文件使用 RFC 2307bis 的一种形式在 Windows Active Directory 中进行架构查找。
LDAP 服务器可以存储用户和组信息以及网络组。 但是，Azure NetApp 文件目前无法在 Windows Active Directory 上的 LDAP 中使用网络组功能。
Azure NetApp 文件中的 LDAP 在端口 389 上运行。 目前无法修改此端口以使用自定义端口，例如端口 636 (LDAP over SSL) 或端口 3268（Active Directory 全局目录搜索）。
可以使用 LDAP over TLS（通过端口 389 运行）或 LDAP 签名来实现加密的 LDAP 通信，这两者都可以在 Active Directory 连接上进行配置。
Azure NetApp 文件支持不超过 3 秒即可完成的 LDAP 查询。 如果 LDAP 服务器有许多对象，则可能会超出该超时，并且身份验证请求可能会失败。 在这种情况下，请考虑指定 LDAP 搜索范围来筛选查询，以获得更好的性能。
Azure NetApp 文件还支持指定首选 LDAP 服务器以帮助加快请求速度。 如果你希望确保使用最靠近 Azure NetApp 文件区域的 LDAP 服务器，请使用此设置。
如果未设置首选 LDAP 服务器，则会在 DNS 中查询 Active Directory 域名来获取 LDAP 服务记录，以填充位于该 SRV 记录中所在区域可用的 LDAP 服务器列表。 可以使用
nslookup或dig命令从客户端手动查询 DNS 中的 LDAP 服务记录。例如：
C:\>nslookup Default Server: localhost Address: ::1 > set type=SRV > _ldap._tcp.contoso.com. Server: localhost Address: ::1 _ldap._tcp.contoso.com SRV service location: priority = 0 weight = 0 port = 389 svr hostname = oneway.contoso.com _ldap._tcp.contoso.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = ONEWAY.Contoso.com _ldap._tcp.contoso.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = oneway.contoso.com _ldap._tcp.contoso.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = parisi-2019dc.contoso.com _ldap._tcp.contoso.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = contoso.com oneway.contoso.com internet address = x.x.x.x ONEWAY.Contoso.com internet address = x.x.x.x oneway.contoso.com internet address = x.x.x.x parisi-2019dc.contoso.com internet address = y.y.y.y contoso.com internet address = x.x.x.x contoso.com internet address = y.y.y.yLDAP 服务器还可用于为用户执行自定义名称映射。 有关详细信息，请参阅使用 LDAP 进行自定义名称映射。
LDAP 查询超时
默认情况下，如果 LDAP 查询无法及时完成，则这些查询会超时。 如果 LDAP 查询由于超时而失败，则用户和/或组查找将失败，而且对 Azure NetApp 文件卷的访问可能遭到拒绝，具体由卷的权限设置决定。 请参阅创建和管理 Active Directory 连接以了解 Azure NetApp 文件LDAP 查询超时设置。
名称映射类型
名称映射规则分为两种主要类型：对称和非对称。
- 对称名称映射是使用相同用户名的 UNIX 用户和 Windows 用户之间的隐式名称映射。 例如，Windows 用户
CONTOSO\user1映射到 UNIX 用户user1。 - 非对称名称映射是使用不同用户名的 UNIX 用户和 Windows 用户之间的名称映射。 例如，Windows 用户
CONTOSO\user1映射到 UNIX 用户user2。
默认情况下，Azure NetApp 文件使用对称名称映射规则。 如果需要非对称名称映射规则，请考虑配置 LDAP 用户对象以使用此类规则。
使用 LDAP 的自定义名称映射
如果已填充 LDAP 服务器上的 LDAP 模式属性，则 LDAP 可以是名称映射资源。 例如，若要将 UNIX 用户映射到不一一匹配的相应 Windows 用户名（即不对称），可为用户对象中的 uid 指定一个与为 Windows 用户名配置的值不同的值。
在以下示例中，用户的 Windows 名称为 asymmetric，需要映射到 UNIX 标识 UNIXuser。 若要在 Azure NetApp 文件中实现此操作，请打开 Active Directory 用户和计算机 MMC 的实例。 然后，找到所需的用户并打开属性框。 （这样做需要启用属性编辑器）。 导航到“属性编辑器”选项卡并找到“UID”字段，在“UID”字段中填充所需的 UNIX 用户名 UNIXuser，单击“添加”，然后单击“确定”进行确认。
完成此操作后，Windows 用户 asymmetric 从 Windows SMB 共享写入的文件将由 NFS 端的 UNIXuser 拥有。
以下示例显示了 Windows SMB 所有者 asymmetric：
以下示例显示了 NFS 所有者 UNIXuser（使用 LDAP 从 Windows 用户 asymmetric 映射）：
root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx 2 root root 4096 Jul 3 20:09 .
drwxr-xr-x 21 root root 4096 Jul 3 20:12 ..
-rwxrwxrwx 1 UNIXuser group1 19 Jul 3 20:10 asymmetric-user-file.txt
允许使用 LDAP 的本地 NFS 用户
当用户尝试通过 NFS 访问 Azure NetApp 文件卷时，请求将采用数字 ID。 默认情况下，Azure NetApp 文件支持 NFS 用户的扩展组成员身份（超出标准的 16 组上限）。 因此，Azure NetApp 文件将尝试获取该数字 ID 并在 LDAP 中查找它，以解析用户的组成员身份，而不是在 RPC 数据包中传递组成员身份。 由于该行为，如果无法将数字 ID 解析为 LDAP 中的用户，则即使发出请求的用户有权访问卷或数据结构，查找也会失败并拒绝访问。 Active Directory 连接中“允许使用 LDAP 的本地 NFS 用户”选项旨在通过禁用扩展组功能来对这些 NFS 请求禁用 LDAP 查找。 它不提供 Azure NetApp 文件中的“本地用户创建/管理”。
启用“允许具有 LDAP 的本地 NFS 用户”选项时，数字 ID 将传递到 Azure NetApp 文件，并且不会执行 LDAP 查找。 这会为不同的方案创建不同的行为，如下所示。
具有 UNIX 安全样式卷的 NFSv3
不需要将数字 ID 转换为用户名。 “允许具有 LDAP 的本地 NFS 用户”选项不会影响对卷的访问，但可能会影响用户/组所有权（名称转换）在 NFS 客户端上的显示方式。 例如，如果 1001 的数值 ID 是 LDAP 中的 user1，但在 NFS 客户端的本地传递文件中是 user2，则当数字 ID 为 1001 时，客户端将显示“user2”作为文件的所有者。
具有 UNIX 安全样式卷的 NFSv4.1
不需要将数字 ID 转换为用户名。 默认情况下，NFSv4.1 使用名称字符串 (user@CONTOSO.COM) 进行身份验证。 但是，Azure NetApp 文件支持将数字 ID 与 NFSV4.1 配合使用，这意味着 NFSv4.1 请求将到达具有数字 ID 的 NFS 服务器。 如果本地文件或 Azure NetApp 文件卷的 LDAP 等名称服务中不存在用户名转换的数字 ID，则会将数字呈现给客户端。 如果数字 ID 转换为用户名，则将使用名称字符串。 如果名称字符串不匹配，客户端会将名称压缩到客户端 idmapd.conf 文件中指定的匿名用户。 启用“允许具有 LDAP 的本地 NFS 用户”选项不会影响 NFSv4.1 访问，因为它会回退到标准 NFSv3 行为，除非 Azure NetApp 文件可以将数字 ID 解析为其本地 NFS 用户数据库中的用户名。 Azure NetApp 文件具有一组默认的 UNIX 用户，如果域 ID 字符串不匹配，则某些客户端可能会有问题，并且会压缩到 “无人” 用户。
- 本地用户包括：root (0)、pcuser (65534)、nobody (65535)。
- 本地组包括：root (0)、daemon (1)、pcuser (65534)、nobody (65535)。
最常见的情况是，当 NFSv4.1 域 ID 配置错误时，根可能会在 NFSv4.1 客户端装载中错误地显示。 有关 NFSv4.1 ID 域的详细信息，请参阅“为 Azure NetApp 文件配置 NFSv4.1 ID 域”。
可以使用名称字符串或数字 ID 配置 NFSv4.1 ACL。 如果使用数字 ID，则无需进行名称转换。 如果使用名称字符串，则正确的 ACL 解析需要进行名称转换。 使用 NFSv4.1 ACL 时，启用“允许具有 LDAP 的本地 NFS 用户”可能会导致 NFSv4.1 ACL 行为不正确，具体取决于 ACL 配置。
采用双协议配置的 NTFS 安全样式卷的 NFS（v3 和 v4.1）
UNIX 安全样式卷利用 UNIX 样式权限（模式位和 NFSv4.1 ACL）。 对于这些类型的卷，NFS 仅利用基于数字 ID 或名称字符串的 UNIX 样式身份验证，具体取决于上面列出的场景。 但是，NTFS 安全样式卷会使用 NTFS 样式权限。 这些权限是使用 Windows 用户和组分配的。 当 NFS 用户尝试使用 NTFS 样式权限访问卷时，必须发生 UNIX 到 Windows 名称的映射以确保适当的访问控制。 在此场景中，NFS 数字 ID 仍会传递到 Azure NetApp 文件 NFS 卷，但需要将数字 ID 转换为 UNIX 用户名，以便将其映射到 Windows 用户名进行初始身份验证。 例如，如果数字 ID 1001 尝试使用允许 Windows 用户“user1”访问的 NTFS 安全样式权限访问 NFS 装载，则需要在 LDAP 中将 1001 解析为“user1”用户名以获得预期的访问权限。 如果 LDAP 中不存在数字 ID 为“1001”的用户，或者 LDAP 配置错误，则所尝试的 UNIX 到 Windows 名称映射将为 1001@contoso.com。 在大多数情况下，具有该名称的用户并不存在，因此身份验证会失败并拒绝访问。 同样，如果数字 ID 1001 解析为错误的用户名（如 user2），则 NFS 请求将映射到一个意外的 Windows 用户，并且该用户的权限将使用“user2”访问控制。
启用“允许具有 LDAP 的本地 NFS 用户”将禁用数字 ID 到用户名的所有 LDAP 转换，这将有效地破坏对 NTFS 安全型卷的访问。 因此，强烈建议不要将此选项用于 NTFS 安全样式卷。
LDAP 架构
LDAP 架构是 LDAP 服务器组织和收集信息的方式。 LDAP 服务器架构通常遵循相同的标准，但不同的 LDAP 服务器提供商在架构的呈现方式上可能有所不同。
当 Azure NetApp 文件查询 LDAP 时，架构用于帮助加快名称查找速度，因为它们允许使用特定属性来查找有关用户的信息，例如 UID。 LDAP 服务器中必须存在架构属性，Azure NetApp 文件才能找到条目。 否则，LDAP 查询可能不会返回任何数据，并且身份验证请求可能会失败。
例如，如果 Azure NetApp 文件必须查询 UID 编号（例如 root=0），则会使用架构属性 RFC 2307 uidNumber Attribute。 如果 LDAP 的 uidNumber 字段中不存在 UID 编号 0，则查找请求将会失败。
Azure NetApp 文件当前使用的架构类型是基于 RFC 2307bis 的架构形式，且无法修改。
RFC 2307bis 是 RFC 2307 的扩展，添加了对 posixGroup 的支持，用户可以使用 uniqueMember 属性（而不是使用 LDAP 架构中的 memberUid 属性）动态查找辅助组。 此属性不仅使用用户的名称，还包含 LDAP 数据库中另一个对象的完全可分辨名称 (DN)。 因此，组可以包含其他组作为成员，从而允许组嵌套。 对 RFC 2307bis 的支持也添加了对对象类 groupOfUniqueNames 的支持。
此 RFC 扩展非常适合 Microsoft Active Directory 通过常用管理工具管理用户和组的方式。 这是因为，当使用标准 Windows 管理方法将 Windows 用户添加到组（并且该组具有有效的数字 GID）时，LDAP 查找将从常用 Windows 属性中拉取所需的补充组信息并自动查找数字 GID。