NFS/Authsys extended groups not working for Linux client [ Edited ]

[#1]

Hi,

I am trying to enable more than the default 16 groups for NFS connection via SYS_AUTH to a NetApp filer, but not having any success.  Can anyone shed some light?

The issue is present in our production environment, but to get to the bottom of it I have created a virtual appliance with 'NetApp Release 8.1.4 7-Mode', which matches Production.  The appliance is set-up to use our Active Directory domain and on the appliance I can use 'wcc' to successfully query users and groups.  I have set 'nfs.authsys.extended_groups_ns.enable on' and 'nfs.max_num_aux_groups  256'.

My NFS client is running recently patched RH Enterprise Linux 6.6 and I am testing with my own user account that is a member of more than 16 groups.  To test the functionality I create one file for each of the groups I belong to and set the permissions so that write is only possible by a group (not user or other).  Writing to each file is there by dependent on a different group.  As I can use chrgp successfully to setup each of these files I think it proves that AD, the Linux Client and the NetApp are all in step regarding groups.  However, when I try to write to each of these groups in turn I am successful only with the first 16, which is the same behaviour as if 'nfs.authsys.extended_groups_ns.enable' was set to 'off'.  I have tried using NFS 3 and 4 without success.

To prove there is no issue on the Linux Client I used another Linux server to create an NFS export and set the '--manage-gids' option on rpc.mountd.  After mounting that export on the client machine I repeated the test of creating the files, setting their permissions and attempting to write to each in turn.  I could write to all the files, which proves that if the NFS server is configured to use '--manage-gids' correctly the client can support it.

If I understand correctly then by enabling 'nfs.authsys.extended_groups_ns.enable' group enumeration is shifted from the client request (the groups of which are ignored) to the NetApp, which picks up the additional task of going to AD to find out what groups the requesting account is a member of.  Therefore it seems likely the netapp is not capable of enumerating an accounts groups, but when I check with wcc it seems that it is.  I get data back that looks like this (names changed to protect the innocent):

wcc -u fred.bloggs

(NT - UNIX) account name(s):  (MYDOMAIN\fred.bloggs - fred.bloggs)

                ***************

                UNIX uid = 10225

                user is a member of group MYGROUP (10042)

                NT membership

                                MYDOMAIN\fred.bloggs

<snipped lots of other groups from here>

                                BUILTIN\Users

                User is also a member of Everyone, Network Users,

                Authenticated Users

                ***************

So, after all that the questions I have are:

1. Is anyone using a NetApp with 'nfs.authsys.extended_groups_ns.enable on' successfully with a RHEL5, 6 or 7 client?
2. Does anyone know of a required configuration setting I have may not have set?
3. Am I correct in assuming that the output of wcc is a good way of verifying the appliance's ability to enumerate a user's groups?
4. Are there any logs on the netapp that could provide a clue as to what is going wrong (there is nothing in the logs exposed through theWebUI)?
5. Am I correct in my assumption that 'nfs.authsys.extended_groups_ns.enable on' works in the same way as '--manage-gids' does for rpc.mountd?

Thanks in advance for any assistance.

Regards,

David

PS, appologies if this is a repeat post - I thought I asked this question on Friday, but I cannot find the original post.

[#2]

If I read it correctly, you expect UNIX group information to come from AD. That cannot work. Filer does not map Windows groups to UNIX GIDs so it has no way to actually check permissions. Chown would work as group is resolved on client side to numerical value. I do not know why first 16 groups work, but I suspect that they are taken from NFS packet.

This (filer) option would work your client and filer used common LDAP backend to store UID/GID. This can come from AD, but not via user mapping, so your checking with wcc is pretty much irrelevant here, sorry.

[#3]

Hi,

Thanks for the reply.

I didn't know that the filer cannot map groups, but I see that you are right. I had assumed that because it can map users that it must map groups too (I had also assumed that I simply couldn't find the command for inspecting group mappings rather than it didn't exist).

It makes me wonder how people who successfully use 'nfs.authsys.extended_groups_ns.enable' make it work? I know that NFS/AUTH_SYS by definition can (should?) only pass the details of 16 groups; perhaps they are using a patched NFS client that supports more, but it is strange that it is never mentioned in the discussions of this problem.

I am intruigued by your comment 'This can come from AD, but not via user mapping'. Does that mean there is a way to get 'nfs.authsys.extended_groups_ns.enable' working without a patched NFS client? How can I do that? We use AD with rfc2307bis schema so all the data is there if I can find a way to use it.

Regards,
David

[#4]

---

It makes me wonder how people who successfully use 'nfs.authsys.extended_groups_ns.enable' make it work?

---

In several of those cases I am aware of NIS or LDAP were used.

---

I am intruigued by your comment 'This can come from AD, but not via user mapping'. Does that mean there is a way to get 'nfs.authsys.extended_groups_ns.enable' working without a patched NFS client? How can I do that? We use AD with rfc2307bis schema so all the data is there if I can find a way to use it.

---

You need to configure filer to use LDAP for UNIX name-to-id mapping. You can look at TR-3458 as starting point.

[#5]

Hi,

Sorry for the delay replying to this.

I believe that this issue is resolved in my environment and that the following is a complete list of factors involved in the solution:

1. NFSv4 cannot make use of 'nfs.authsys.extended_groups_ns.enable' - it is limited to 16 groups if you are using auth_sys. To make use of auth_sys extended groups you must use NFSv3.
2. For 'nfs.authsys.extended_groups_ns.enable' Unix group enumeration needs to be working. This is not the same thing as user mapping or group mapping (which, as Aborzenkov mentioned, is not done by the NetApp anyway).
3. The output of 'wcc -u user.name' includes a list of groups an account is a member of from a Unix perspective as well as an NT (AD/LDAP) perspective. A more concise command for testing Unix group enumeration, which is what 'nfs.authsys.extended_groups_ns.enable' depends on, is 'getXXbyYY getgrlist user.name'. You should see the GID of every group.
4. If when using 'getXXbyYY getgrlist' you do not see a full list of groups you can experiment with options on the NetApp to get it working. To get it working in my environment I had to 'set ldap.rfc2307bis.enable' to 'off' and populate the 'memberuid' field of the group. That was surprising to me as our AD schema is rfc2307biz and I expected group membership to come from other fields.

Thanks again to Aborzenkov for the help resolving this.

Regards,
David