Skip to main content

NetApp_Insight_2020.png 

NetApp Knowledgebase

Understanding name-mapping in a multiprotocol environment

Views:
510
Visibility:
Public
Votes:
0
Category:
ontap-9
Specialty:
nas
Last Updated:

Applies to

  • ONTAP 9 
  • NAS

Answer

Understanding name-mapping in a multiprotocol environment
How does name-mapping work for NFS clients accessing UNIX security style resources?
  • The client will send the UID and GID(s) in the RPC header of the NFS operation.
  • The filer will grant/deny access based on the UID and GID(s) sent in the RPC header of the NFS operation.

Note: There is no user mapping that takes place during this process. ONTAP does not need to map the incoming user to a windows user in order for an NFS client to perform operations against a unix security style resource.

How does name-mapping work when NFS clients are accessing an NTFS security style resource?
  • The client will send the UID and GID(s) in the RPC header of the NFS operation.
  • The filer will attempt to resolve the UID and GID(s) to their respective names via the sources defined in the ns-switch (name-services switch) for 'passwd' and 'group'.

To find out which sources are defined in ns-switch.conf use the following command (possible values include: files/ldap/nis): 

Cluster01::> ns-switch show -vserver SVM01

  • The filer will now attempt to map the resolved name to a valid windows user in the following order:

Explicit name-mapping - filer will consult the explicit name-mapping rules defined and string compare the unix user attempting to access with all of the 'unix-windows' rules present on the filer.
To view explicit name-mapping rules:
Cluster01::> name-mapping show -vserver SVM01 -direction unix-win
If a rule is matched, the filer will attempt to lookup the mapped windows user in Active Directory and pull the credentials for that user.

Implicit name-mapping - if no explicit rules are matched, the filer will attempt to map the unix user to a windows implicitly.
Example:Filer will attempt to map unix user 'User01' to windows user 'DOMAIN\User01'.
Again, the filer will attempt to lookup the mapped windows user in Active Directory and pull the credentials for that user.

Default windows user - if both methods above fail (For example, filer cannot pull the credentials for the mapped windows user), for any reason, the filer will map the unix user to the 'default windows user' which is defined in the NFS server settings.
To view the NFS server settings:
Cluster01::> nfs show -vserver SVM01
Note: This option is blank by default

  • The filer will now grant/deny access to the unix user based on the windows credentials that were pulled from Active Directory.

Note: Access is granted/denied on the windows credentials because the resource is NTFS security style.

How does name-mapping work when CIFS clients access UNIX security style resources?
  • The user has already authenticated to the domain, the filer needs to build credentials for the user for each newly created CIFS session.
  • The filer will attempt to map the windows user to a unix user in the following order:

Explicit name-mapping - filer will consult the explicit name-mapping rules defined and string compare the windows user attempting to access with all of the 'windows-unix' rules present on the filer.
To view explicit name-mapping rules:
Cluster01::> name-mapping show -vserver SVM01 -direction win-unix
If a rule is matched, the filer will attempt to lookup the mapped unix user's UID and GID(s) via the sources defined in ns-switch as talked about previously.

Implicit name-mapping - if no explicit rules are matched, the filer will attempt to map the unix user to a windows implicitly.
Example: Filer will attempt to map windows user 'DOMAIN\USER01 to unix user 'User01'
Again, the filer will attempt to lookup the unix user's UID and GID(s) via the sources defined in ns-switch.

Default unix user - if both methods above fail (e.g. filer cannot pull the UID and GID(s) for the mapped unix user), for any reason, the filer will map the windows user to the 'default unix user' which is defined in the CIFS server options.
To view the CIFS server options:
Cluster01::> cifs options show -vserver SVM01
Note: This option is set to 'pcuser' (UID 65534) by default.

  • The filer will grant/deny access to the windows user based on the UID and GID(s) from the mapped unix user which were pulled via one of the methods above.

Note: Access is granted/denied based on the UID and GID(s) of the unix user because the resource is set to UNIX security style.

How does name-mapping work when CIFS clients access NTFS security style resources?
  • The user has already authenticated to the domain, the filer needs to build credentials for the user for each newly created CIFS session.
  • The filer will attempt to map the windows user to a unix user in the following order:

Explicit name-mapping - filer will consult the explicit name-mapping rules defined and string compare the windows user attempting to access with all of the 'windows-unix' rules present on the filer.
To view explicit name-mapping rules:

Cluster01::> name-mapping show -vserver SVM01 -direction win-unix
If a rule is matched, the filer will attempt to lookup the mapped unix user's UID and GID(s) via the sources defined in ns-switch as talked about previously.

Implicit name-mapping - if no explicit rules are matched, the filer will attempt to map the unix user to a windows implicitly.
Example: Filer will attempt to map windows user 'DOMAIN\USER01 to unix user 'User01'
Again, the filer will attempt to lookup the unix user's UID and GID(s) via the sources defined in ns-switch.

Default unix user - if both methods above fail (For example, filer cannot pull the UID and GID(s) for the mapped unix user), for any reason, the filer will map the windows user to the 'default unix user' which is defined in the CIFS server options.
To view the CIFS server options:
Cluster01::> cifs options show -vserver SVM01
Note: This option is set to 'pcuser' (UID 65534) by default.

  • The filer will grant/deny access to the windows user based on the windows credentials we pulled from the methods above.