Cuir in eagar

Comhroinn trí

Understand NFS group memberships and supplemental groups

  • Alt

You can use LDAP to control group membership and to return supplemental groups for NFS users. This behavior is controlled through schema attributes in the LDAP server.

Primary GID

For Azure NetApp Files to be able to authenticate a user properly, LDAP users must always have a primary GID defined. The user’s primary GID is defined by the schema gidNumber in the LDAP server.

Secondary, supplemental, and auxiliary GIDs

Secondary, supplemental, and auxiliary groups are groups that a user is a member of outside of their primary GID. In Azure NetApp Files, LDAP is implemented using Microsoft Active Directory and supplemental groups are controlled using standard Windows group membership logic.

When a user is added to a Windows group, the LDAP schema attribute Member is populated on the group with the distinguished name (DN) of the user that is a member of that group. When a user’s group membership is queried by Azure NetApp Files, an LDAP search is done for the user’s DN on all groups’ Member attribute. All groups with a UNIX gidNumber and the user’s DN are returned in the search and populated as the user’s supplemental group memberships.

The following example shows the output from Active Directory with a user’s DN populated in the Member field of a group and a subsequent LDAP search done using ldp.exe.

The following example shows the Windows group member field:

Screenshot that shows the Windows group member field.

The following example shows LDAPsearch of all groups where User1 is a member:

Screenshot that shows the search of a user named `User1`.

You can also query group memberships for a user in Azure NetApp Files by selecting LDAP Group ID List link under Support + troubleshooting on the volume menu.

Screenshot that shows the query of group memberships by using the **LDAP Group ID List** link.

Group limits in NFS

Remote Procedure Call (RPC) in NFS has a specific limitation for the maximum number of auxiliary GIDs that can be honored in a single NFS request. The maximum for AUTH_SYS/AUTH_UNIX is 16, and for AUTH_GSS (Kerberos), it's 32. This protocol limitation affects all NFS servers - not just Azure NetApp Files. However, many modern NFS servers and clients include ways to work around these limitations.

To work around this NFS limitation in Azure NetApp Files, see Enable Active Directory Domain Services (AD DS) LDAP authentication for NFS volumes.

How extending the group limitation works

The options to extend the group limitation work the same way that the manage-gids option for other NFS servers works. Basically, rather than dumping the entire list of auxiliary GIDs that a user belongs to, the option performs a lookup for the GID on the file or folder and returns that value instead.

The following example shows RPC packet with 16 GIDs.

Screenshot that shows RPC packet with 16 GIDs.

Any GID past the limit of 16 is dropped by the protocol. With extended groups in Azure NetApp Files, when a new NFS request comes in, information about the user’s group membership is requested.

Considerations for extended GIDs with Active Directory LDAP

By default, in Microsoft Active Directory LDAP servers, the MaxPageSize attribute is set to a default of 1,000. That setting means that groups beyond 1,000 would be truncated in LDAP queries. To enable full support with the 1,024 value for extended groups, the MaxPageSize attribute must be modified to reflect the 1,024 value. For information about how to change that value, see the Microsoft TechNet article How to View and Set LDAP Policy in Active Directory by Using Ntdsutil.exe and the TechNet library article MaxPageSize Is Set Too High.

Next steps