Compartilhar via


AD primary group (primarygroupID) being sent by the NFS server in case of Kerberos Authentication instead of gidNumber

With Windows 2012, there are multiple options of mapping users and group for NFS access. This has been discussed on the blog below:

https://blogs.technet.com/b/filecab/archive/2012/10/09/nfs-identity-mapping-in-windows-server-2012.aspx

We came across the difference in behavior while we use the authentication type as Auth_sys to the authentication type Kerberos.

While using Kerberos as authentication type on the NFS share then the response from the NFS server is the uidNumber of the user and the primary group for the user in AD which is configured through the “memberof” tab. Hence in case of Kerberos the NFS server does not send the gidNumber set on the user’s properties.

In case of Auth_sys, the NFS server sends the uidNumber and the gidNumber as the GetAttr response to the NFS clients.  

I have attached Network traces for reference. Assuming the below environment, we have tested the scenario and collected the netmon traces:

Environment: Windows 2012 as NFS Server, Linux ES 6.4 as NFS client

  • On the Windows NFS server, two shares are configured. Once with “Auth_sys” as authentication type.
  • The other NFS share is configured with Kerberos an authentication type (Krb5,Krb5p, krb5i)
  • AD lookup configured for the user with uidNumber and gidNumber
  • Primary group set for the user through the memberof Tab is “DomainUsers”.

 

 

Observation:

  • When the user/NFS Client is authenticating by windows, it is being issued a Kerberos ticket which is being used in any create/access call by the UNIX, snapshot of the screenshot

 

  • The Primary group of the user in the Active Directory is set to ‘Domain Users’ which will be put in as a Primary Group in the PAC when a Kerberos ticket is given to the user. PAC also contains the SID of the users and the groups the user is member of. The primary group is defined as “ULONG PrimaryGroupId;” in the PAC structure, see https://msdn.microsoft.com/en-us/library/cc237917.aspx for more details.

 

  •  When we create a file/folder from windows side, it is always setting the GID as the primary group i.e. Domain Users since this is what it finds as the primary group from the PAC while creating the token and this is always true when creating the file/folders from windows irrespective of NFS Authentication module (Krb5 or Auth_Sys).

 

  •  When we create a file/folder from NFS Client (Linux), depending upon the authentication mechanism (krb5 or Auth_sys), the GID is being sent by windows NFS Server. If we are using Kerberos authentication, then windows will consider GID as the primary group since this is what will be in the PAC. When we use Auth_Sys, since there is no PAC involved, NFS Server sends the GIDNumber configured in the AD for the user as per RFC. Looking at the SETATTR Call, the client is sending the UID and GID in the Credential structure. NFS Server will respond with the UID and GID which is configured in the Active Directory in the NFS Application layer packet (in case of Auth_Sys)

 

  • The AUTH_SYS case differ from the Kerberos case because in the Kerberos case we get explicit information earlier in the process as a result of the Kerberos ticket and so there is no need to go further and check the gidNunber for the user.

 

                                                                                                                                           
SETATTR Call sent from the client: (Kerberos)

 

SETATTR Reply from the server: (Kerberos)

 
 

 SETATTRCall sent from the client: (Auth_Sys)

 

 

SETATTRReply from the server: (Auth_Sys)

 

 

 

Alternate solution suggested:

  • Set the Primary Group of the User from the Memberof Tab to the Unix Group (GID).
  • Use the Auth_Sys authentication in the NFS Server.  
  • Populate the gidnumber of Domain user and
    • Use the same gidnumber in the user’s attribute
    • Map domain user group to the Unix group