Skip to main content

Coming soon...New Support-Specific categorization of Knowledge Articles in the NetApp Knowledge Base site to improve navigation, searchability and your self-service journey.

NetApp Knowledge Base

Understanding name-mapping in a multiprotocol environment

Views:
10,748
Visibility:
Public
Votes:
18
Category:
ontap-9
Specialty:
nas
Last Updated:

Applies to

  • ONTAP 9 
  • NAS

Answer

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::> vserver services name-service ns-switch show -vserver SVM01
    • If using local 'files' for name-services, then you will need to create a local unix-user on the SVM for each user
      • Cluster01::> vserver services unix-user create -user tsmith -id 4219 -primary-gid 100 -full-name "Tom Smith" -vserver SVM01
  • The filer next attempts to map the resolved name to a valid Windows user in the following order:
  1. 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-win' rules present on the filer.

To view explicit name-mapping rules:
Cluster01::> vserver 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. If the Windows name is a group, this is an error that is silently ignored if a default user is configured.
  1. Implicit name-mapping - if no explicit rules are matched, the filer will attempt mapping the UNIX user to a Windows user implicitly. The filer will check for a match in local CIFS users and, if no match is found, in AD next.

Example: Filer will attempt to map UNIX user 'User01' to Windows user 'User01'.
Again, the filer will attempt to lookup the mapped Windows user in Active Directory and pull the credentials for that user.

  1. 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::> vserver nfs show -vserver SVM01 -fields default-win-user
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:
  1. 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 'win-unix' rules present on the filer.

To view explicit name-mapping rules:
Cluster01::> vserver 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.

  1. Implicit name-mapping - if no explicit rules are matched, the filer will attempt to map the UNIX user to a Windows user 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.

  1. 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::> vserver cifs options show -vserver SVM01 -fields default-unix-user
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:
  1. 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 'win-unix' rules present on the filer.

To view explicit name-mapping rules:

Cluster01::> vserver 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.

  1. Implicit name-mapping - if no explicit rules are matched, the filer will attempt to map the UNIX user to a Windows user 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.

  1. 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::> vserver cifs options show -vserver SVM01 -fields default-unix-user
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.

 

Scan to view the article on your device