你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
对于单个 NFS 请求中可以遵循的最大辅助 GID（次要组）数，NFS 具有特定的限制。 AUTH_SYS/AUTH_UNIX 的最大值为 16。 对于 AUTH_GSS (Kerberos)，最大值为 32。 这是 NFS 的已知协议限制。
Azure NetApp 文件可以将辅助组的最大数目增加到 1,024。 通过从名称服务（如 LDAP）预提取请求用户的组，避免截断 NFS 数据包中的组列表来实现这点。
工作原理
扩展组限制的选项的工作方式与其他 NFS 服务器的 -manage-gids 选项的工作方式相同。 该选项不是转储用户所属的整个辅助 GID 列表，而是在文件或文件夹上查找 GID 并返回该值。
mountd 的命令参考注释：
-g or --manage-gids
Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server.
发出访问请求时，数据包的 RPC 部分仅传递 16 个 GID。
协议会删除超出上限 16 的任何 GID。 Azure NetApp 文件中的扩展 GID 只能与外部名称服务（如 LDAP）一起使用。
潜在的性能影响
扩展组的性能损失最小，通常为比较低的个位数百分比。 较高的元数据 NFS 工作负载可能会产生更大的影响，尤其是对系统缓存。 性能也可能受到名称服务服务器的速度和工作负载的影响。 重载的名称服务服务器响应速度较慢，导致预提取 GID 时出现延迟。 为了获得最佳结果，请使用多个名称服务服务器来处理大量请求。
“允许具有 LDAP 的本地用户”选项
当用户尝试通过 NFS 访问 Azure NetApp 文件卷时，请求将采用数字 ID。 默认情况下，Azure NetApp 文件支持 NFS 用户的扩展组成员身份（超出标准的 16 组上限，最高可达 1,024 组）。 因此，Azure NetApp 文件会尝试在 LDAP 中查找数字 ID，以解析用户的组成员身份，而不是在 RPC 数据包中传递组成员身份。
由于该行为，如果无法将数字 ID 解析为 LDAP 中的用户，则即使发出请求的用户有权访问卷或数据结构，查找也会失败并拒绝访问。
Active Directory 连接中“允许使用 LDAP 的本地 NFS 用户”选项旨在通过禁用扩展组功能来对这些 NFS 请求禁用 LDAP 查找。 它不提供 Azure NetApp 文件中的本地用户创建/管理。
有关该选项的详细信息，包括它在 Azure NetApp 文件中如何采用不同的卷安全样式，请参阅了解 LDAP 在 Azure NetApp 文件中的用法。