Secondary GID not working with ADlookup

  • Article

Recently we had a case where users from Windows 7, NFS client were unable to access the NFS share. Adlookup was set up properly. And changing the setting to fetch the information from Windows 2003, User name mapping server resolved the issue.

Note: We did not change any settings on the Unix NFS server

Current set up:

  • User name mapping configured on Windows 2003
  • NFS server configured on Windows 7/ windows 2008 R2/Windows 2003
  • AD configured and user’s UIDNumber and GIDnumber populated.
  • On Unix the parent NFS share is own by user A and group A (permission 770)
  • Inside the parent NFS share, subfolders have user and group specific permission.
  • Windows user is not mapped to user A and group A but is mapped to the users who has full permission on the subfolder.

While troubleshooting we found that the windows user was getting access to the NFS share through secondary group membership, while using
User name mapping. But the same was not happening with ADlookup.

User name mapping feature was based more on Unix style and it allowed the NFS client to pass the auxiliary GID (secondary group) information to the NFS server. Hence when we are using User name mapping (which is fetching the information from NIS); we pass on the secondary group information. So, though the user A’s primary group is X but still the user is able to get the access to the NFS share, since he is also a member of group Y.

On Windows 7\2008 R2, we have an option to fetch the mapping information from Windows 2003 (running user name mapping) and make this work.

But while using ADlookup, it will not pass the secondary group information to the NFS server and hence the access fails for a folder
which has permission ‘770’.

Suggested options given in this scenario for ADlookup:

In case of ADlookup, we need to add the RX permission for others on the parent NFS share and give the appropriate permission on the sub
folder.