你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
轻型目录访问协议 (LDAP) 架构是 LDAP 服务器组织和收集信息的方式。 LDAP 服务器架构通常遵循相同的标准，但不同的 LDAP 服务器提供商在架构的呈现方式上可能有所不同。
当 Azure NetApp 文件查询 LDAP 时，架构用于帮助加快名称查找速度，因为它们允许使用特定属性来查找有关用户的信息，例如 UID。 LDAP 服务器中必须存在架构属性，Azure NetApp 文件才能找到条目。 否则，LDAP 查询可能不会返回任何数据，并且身份验证请求可能会失败。
例如，如果 Azure NetApp 文件必须查询 UID 编号（例如 root=0），则会使用架构属性 RFC 2307 uidNumber Attribute。 如果 LDAP 的 0 字段中不存在 UID 编号 uidNumber，则查找请求将会失败。
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。
当 Azure NetApp 文件卷需要对 NFS 用户标识执行 LDAP 查找时，基于 RFC-2307bis 的 LDAP 架构定义的一系列属性。 下表显示了 LDAP 查找使用的属性，这些属性是使用 UNIX 属性时在 Microsoft Active Directory 中定义的默认属性。 为了正常运行，请确保在 LDAP 的用户和组帐户中正确填充这些属性。
| UNIX 属性 | LDAP 架构值 |
|---|---|
| UNIX 用户名 | uid* |
| UNIX 用户数字 ID | uidNumber* |
| UNIX 组名 | cn* |
| UNIX 组数字 ID | gidNumber* |
| UNIX 组成员身份 | member** |
| UNIX 用户对象类 | 用户** |
| UNIX 主目录 | unixHomeDirectory |
| UNIX 显示名称 | gecos |
| UNIX 用户密码 | unixUserPassword |
| UNIX 登录 shell | LoginShell |
| 用于名称映射的 Windows 帐户 | sAMAccountName** |
| UNIX 组对象类 | Group** |
| UNIX 成员 UID | memberUid*** |
| 唯一名称对象类的 UNIX 组 | Group** |
* LDAP 功能正常运行所需的属性
** 默认情况下在 Active Directory 中填充
*** 不需要
了解 LDAP 属性索引
Active Directory LDAP 提供了一种属性索引方法，有助于加快查找请求的处理。 这在大型目录环境中特别有用，在这些环境中，LDAP 搜索可能会超过 Azure NetApp 文件中查找的 10 秒超时值。 如果搜索超过其超时值，LDAP 查找会失败，访问将无法正常工作，因为服务无法验证请求访问的用户或组标识。
默认情况下，Microsoft Active Directory LDAP 会为由 Azure NetApp 文件用于 LDAP 查找的以下 UNIX 属性编制索引：
默认情况下，不为 uid 属性编制索引。 因此，LDAP 对 UID 的查询比对已编制索引的属性的查询花费更多时间。
例如，在具有 20,000 多个用户和组的 Active Directory 环境中的以下查询测试中，搜索属性 CN 已编制索引的用户大约需要 0.015 秒，而搜索具有 UID 属性（默认情况下未编制索引）的同一用户则需要将近 0.6 秒 - 慢了 40 倍。
在较小的环境中，这不会造成问题。 但在较大的环境（或 Active Directory 环境位于本地或有严重网络延迟的环境）中，差异可能非常大，足以导致访问 Azure NetApp 文件卷的用户出现访问问题。 因此，最佳做法是将 LDAP 中的 UID 属性配置为可供 Active Directory 编制索引。
将 UID 属性配置为可供 Active Directory 编制索引
通过属性对象的 searchFlags 值为属性编制索引，该值可通过架构命名上下文中的 ADSI 编辑器进行配置。 访问 ADSI 编辑器时应谨慎，至少需要架构管理员权限。
默认情况下，uid 属性对象的 searchFlags 设置为 0x8 (PRESERVE_ON_DELETE)。 此默认设置确保即使在 Active Directory 中的对象被删除的情况下，也仍然可以将属性值作为用户属性的历史记录存储在目录中。
相比之下，在 Active Directory 中针对 LDAP 搜索进行属性索引编制的属性的值为 0x1（或包含该值的某种组合），例如 uidNumber：
因此，uidNumber 的查询比 uid 的查询返回速度更快。 为了确保一致性和性能，可以通过将现有值 0x8 和 0x1 加在一起，将 uid 的 searchFlags 值调整为 9，即 (INDEX | PRESERVE_ON_DELETE)。 这样加在一起可以在向目录添加属性索引的同时保留默认行为。
通过索引，搜索具有 uid 的用户属性与搜索其他索引属性一样快。