I am trying to implement an NFSv4 solution for a group. I believe I have everything set up correctly: I see Active Directory accounts from the linux (RedHat 5.10) side of things (idmapd is running, domains are set the same on both VNX and linux host). Also, permissions applied on the Windows side carry onto the linux side.
The problem is they have a lot of users that have over 20 groups in Active Directory. It seems if I grant access to their 17th AD group they still can't access the system in linux (although they can using Windows).
I've seen documents referencing the server_param security maxgroups and changing it from the default of 16 to something higher. We've set it to 128 but still encounter the access issue. Besides, I didn't think that limit mattered anymore with NFSv4.
Has anyone run into this before? Maybe it's specific to RedHat 5.10?
In a NFS user can belongs to many groups, when a user is authenticated a credential is created, where this information is stored. By default, VNX is supporting only 16 groups stored in the credential for authentication. I noticed you have set the parameter allows to extend the number of groups to 128. However, we need to ensure the linux clinet supports 128 group. Mark has recommended a great technical blog to explain how to deal on the 16 group ID limitation in NFS, you may refer to this blog.
Thanks, you two. I've seen the blog post before but had only skimmed it. Reading in more detail, it says to me:
1. NFSv3's AUTH_SYS standard is to use only 16 groups.
2. To get around that limitation but still use NFSv3:
a) Create your own AUTH_SYS version that allows more than 16 groups (not very feasible)
b) Use RPCSEC_GSS which basically sends the user ID to the server and then the server performs the group lookup. The caveat with this is that some version of NLM (used for byte-locking) do not support RPCSEC_GSS.
3. To get around the NLM issue, you can use NFSv4 with RPCSEC_GSS. This is because NFSv4 includes byte-locking. Caveat here is that the client may not support more than 16 groups.
4. The final (and what I thought I implemented) solution is to NFSv4 with ACLs. My understanding is that the client no longer sends all of the group IDs to the NFS server and instead uses some sort of AD credentials that the NFS server understands and compares to the ACLs on the file/folder.
Initially it seems that I'm using ACLs (I can add multiple group permissions to a file granting access and then have someone in that same group successfully access the file on the linux side. But once I test with a user in more than 16 groups and assign just that 17th group with access rights, they're denied access.
So isn't the 16-group limitation moot because I'm using NFSv4 with ACLs?
Further research seems to indicate that the NFS version really doesn't have anything to do with the limitation: Solving the NFS 16-Group Limit Problem - Postmodern Sysadmin.
The post recommends on an NFS server to run rcp.mountd using the "
--manage-gids" option. This tells the NFS server to ignore the group IDs that are sent from the client and perform a group lookup based on the user ID. I scoured the Parameters Guide for VNX for File but didn't see anything that quite matched what "
Does anyone know of an equivalent parameter or configuration change on VNX to have it ignore the GIDs from the NFS client?
So, it's been over a year: Has anyone picked this up on the Isilon/EMC side? I see from a quick Google search that for FreeBSD this is "The eternal request. This is a duplicate of about 2343242 other bugs and has been a want list item for the FreeBSD NFS server for about 15 years." So is this just not doable?