Skip to main content
NetApp Knowledge Base

Understanding name-mapping in a multiprotocol environment

  1. Last updated
  2. Save as PDF
Views:
19,011
Visibility:
Public
Votes:
25
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.

Additional Information

  • How to create and understand vserver name-mapping rules
  • The following is an example scenario:
    • UID 1057 is sent to ONTAP by a client.
    • ONTAP resolves UID 1057 to Unix user “bob”
    • ONTAP checks the name mapping entries.
      • If ONTAP finds a Unix to Windows name mapping entry for the pattern “bob” (say that it found “bob==DOMAIN\robert”) then the UID and the AD account are linked during the connection, so when the NFS connection is used by the UID 1057, File level access to NTFS security locations is determined based on the AD account that the that is linked.
      • If ONTAP doesn’t find an entry in the name mapping table for pattern “bob” then it will assume that “bob==DOMAIN\bob” and check AD for an account named bob.
      • If the account is found, then UID 1057 would be granted access based on the AD account “DOMAIN\bob”
      • If there is no explicit name mapping found, and implicit name mapping fails as well, there is an option in the NFS Server settings for “default windows user” which would be a final attempt to link the UID that was resolved as bob to a fallback AD account, like “DOMAIN\guest”, however this setting is normally left blank since it is not required by ONTAP for NFS access.
    • This process also happens when a CIFS/SMB connection is made, and access is attempted to a Unix security style location.
      • The only difference is that there is a requirement for the CIFS Server option for “default unix user” be populated to a Unix account that ONTAP can lookup, either locally or in NIS/LDAP.
      • This requirement is related to the fact that ONTAP runs on Unix and requires that all connections be based/tracked via a Unix UID, even if we don’t use the name mapped unix account to determine file level access.

 

NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.