To understand how multiprotocol user mapping works, it is important first to understand how single protocol user mapping works for both SMB and NFS.

• SMB

• When an SMB user connects to a share, they are identified by their SID.
• Active Directory is used to resolve their SID to a human-readable username and conversely.

Example: S-1-5-21-1553607022-1141325308-60145995-1789  DELL\Tom

• NFS

• When an NFS user connects to an export, they are identified by their UID and primary GID.
• The UNIX Directory Service (UDS) or Local Files are used to resolve their UID to a human-readable username and conversely.

Example: UID=1000  Tom

• The UNIX Directory Service (UDS) or Local Files are used to resolve their primary GID to a human-readable group name and conversely.

Example: GID=1000  Users

Ultimately, the goal of the multiprotocol-mapping process is to create a mapping between the Windows SID and the UNIX UID. Once the UID is known, it is possible to find its associated primary GID. To accomplish this task, use the usernames to bridge the two protocols together. The following shows an example of a complete multiprotocol mapping between the SID  UID and primary GID.

• Multiprotocol

• An SMB user connects to a share and is identified by their SID.
• Active Directory resolves their SID to a human-readable username.
• The Windows username is mapped to a UNIX username.
• UDS or Local Files are used to resolve the UNIX username to their UID.
• UDS or Local Files are used to resolve the UID primary GID.

Example: S-1-5-21-155360702…  DELL\Tom  Tom  UID=1000  GID=1000

In a multiprotocol configuration, the end-to-end mapping between the SID, SMB Name, UNIX Name, UID, and primary GID is crucial. Both Windows and UNIX resolvers must be available to provide their respective mappings, which are joined to create this end-to-end mapping. This mapping provides the ability for a Windows user to be matched to a UNIX user, and conversely, to enforce file security when the other protocol is used for access. This cross-protocol mapping is principally done by matching usernames between the protocols, but each protocol also requires a method to map their respective usernames to their IDs.

If the user mapping is not properly configured, users may be denied access to the file system, obtain access to files that they should not have access to, or be prevented from accessing their own files. This mapping enables the system to identify when the same user is trying to access their files, regardless of the access protocol.

Table 7 shows the components that are involved in the user-mapping process and a short description of their purpose.

Table 7.      User-mapping components

SMB mapping – domain users

In a multiprotocol configuration, it is required to join the SMB server to an Active Directory domain for resolving SIDs to and from Windows usernames. When connecting to a multiprotocol file system, domain users go through the user-mapping process to create a mapping from the Windows SID to the UNIX UID and primary GID.

SMB mapping – local users

Because local users on an SMB server are intended for SMB-only access, they are not mapped using this process. Because stand-alone SMB servers only support local users, they would not have the necessary mappings for a proper multiprotocol configuration.

If a local user connects to a multiprotocol file system over SMB, the LGDB is searched and used to resolve the SID to a Windows username. The local user is mapped to a dedicated UID range, starting with 2151678452 as the local Administrator user. The UID then increments with each additional local user.

Due to this mapping, the UID of the local user on the file system is unlikely to match the UID configured on the UNIX client. From the NAS server’s perspective, they are being tracked as two different users, which results in the same user having inconsistent permissions across different protocols. Potential workarounds include:

• Manually configure UIDs to ensure that they are consistent with the local SMB server. To manually configure the UIDs, create all the local users on an SMB server, determine the UIDs of the local users, and then configure the UNIX clients to use those UIDs.
• If security is not a concern, using open permissions could be another option. If the files are accessible to everyone, then there is no need to maintain consistent permissions across protocols.

NFS mapping

In a multiprotocol configuration, it is recommended to enable a service for resolving UID and GIDs to and from usernames. The available options are:

• UNIX Directory Service (UDS): LDAP or NIS
• Local files

Although multiprotocol can be used without any of these services, the NAS server would not be able to create the end-to-end mapping described previously. Therefore, when the same user attempts to access files using a different protocol, the user might encounter permissions issues.

For more information about how to configure local files, NIS, or LDAP, see the respective sections in this document.

Secure mapping cache

Secure mapping cache (secmap) is a cache that contains the mappings of users that have previously connected to the NAS server. This mapping includes the SID, username, and UID for each user. Since secmap is a cache, it only stores mappings that are generated by the standard mapping mechanisms. It is not a resolution service and does not generate any mappings of its own.

Once a user mapping is stored in secmap, the NAS server leverages this local cache for future mapping lookups. Only new users connecting to the NAS server must rely on external services to resolve their mappings.

Under normal circumstances, secmap is persistent and does not need to be managed. However, in specific situations, it may be necessary to edit secmap such as when a user UID changes. In this case, the cached entry in secmap is no longer accurate and can be updated or deleted using the svc_nas_cifssupport command. If the entry is deleted, the user is treated as a new user the next time they connect, so their new mapping is resolved and stored in secmap.

Ntxmap

Ntxmap is an optional local file that is used to provide name translations between protocols. The multiprotocol user-mapping workflow that is described previously assumes that users have the same usernames across both protocols. However, this consistency in usernames might not be the case in all environments. In environments where usernames are different across protocols, ntxmap is required to translate usernames from one protocol to another. For example, if a user has a Windows account that is named DELL\Tom and a UNIX account that is named Thomas, the system cannot assume that these accounts are the same user.

In addition to one-to-one mappings, ntxmap can also be used to provide advanced name translations. Ntxmap can be used to convert multiple usernames to a single username. For example, all the users in the Windows ENG domain can be mapped to a single UNIX user named enguser. Another option that is available is to provide name conversions. For example, all the UNIX users can be mapped to DELL\unix-<username>.

Ntxmap only provides username translations between protocols and does not provide any ID to username mappings. In environments where usernames are always the same and have a one-to-one mapping between protocols, ntxmap is not required.

Automatic mapping for unmapped Windows accounts

Since the PowerStore file system is UNIX-based, all data that is written must be associated with a valid UID and primary GID. NFS users have a UID and primary GID natively available. However, SMB users must have a mapping that converts their native SID to a UID and primary GID. A reverse mapping from UID to SID is not always required because it is only necessary if Windows permissions are enforced (Windows Access Policy).

This feature enables the ability to automatically generate and assign a unique UID to Windows users that do not have a UID mapping. This feature enables access to the share for unmapped users, instead of denying them access. Since each user has a unique UID, UID-based feature such as user quotas can still properly track the consumption of each individual user.

This option is enabled by default on SMB-only and multiprotocol NAS servers. If this feature is enabled, the ability to configure default accounts is disabled. Because the system automatically assigns each UID, use this feature only in environments where the  UID of these users is not critical. In environments where administrators want to control the UID assignments, disable this feature. If this feature is disabled and there are no other mapping methods available for unmapped users, the unmapped users are denied access to the share.

This feature generates 32-bit UIDs with the most significant bit set to prevent conflicts with UIDs defined by the administrator in the UDS/local files. The range of UIDs generated by this feature is between 2147483649 (0x80000001) and 2151677951 (0x803FFFFF). The automatic UID is only assigned if the user does not already have a UID configured in the UDS/local files.

If the UDS or local files are updated to configure a UID after the feature has already assigned the UID, the new entry in the UDS or local files is ignored. If you want to use the entry in UDS/local files, you must delete the entry from secmap cache.

Default accounts for unmapped users

This feature allows administrators to designate a specific Windows and/or UNIX account to serve as the mapping destination for unmapped users. This feature enables access to the share for unmapped users, instead of denying them access. For example, in an environment where many users only have Windows accounts, a default UNIX user may be designed to allow access for these unmapped users to the multiprotocol file system.

With default accounts enabled, the UID and primary GID of the default UNIX user are used if an unmapped Windows user attempts to access the file system through NFS. Similarly, the credentials of the default Windows user are used when an unmapped UNIX user attempts to access the file system through SMB.

Although multiple users could be writing to the file system as the default user, this user is still considered a single user since they share the same UID. This causes user quota calculations to be inaccurate. Also, the UNIX account may have ownership of files from many different Windows users.

The default UNIX user can be configured as a username or as a numerical UID and primary GID value. If a username is specified, the username must be resolvable to a UID and primary GID through the UDS or local files for the mapping process.

However, configuring the default UNIX user using a numerical UID and primary GID value does not require the user to have an entry in the UDS or local files. This is because all the information needed to create the mapping between the SID to UID and primary GID is available. The specified UID must be in the 32-bit range and follow this format: @uid=<UID>,gid=<GID>@. For example, if you want to configure a default UNIX user with a UID 1000 and primary GID of 2000, enter @uid=1000,gid=2000@.

This option is disabled by default on SMB-only and multiprotocol NAS servers. If this feature is enabled, the ability to enable automatic mapping is disabled. If this feature is disabled and there are no other mapping methods available for unmapped users; they are denied access to the share.

Mapping process

Figure 21 shows the process that is used to resolve a Windows user (SID) to a UNIX user (UID and primary GID). In a multiprotocol configuration, local users on the SMB Server can still be used for SMB-only access, so they are not mapped to a UNIX user.

Figure 21.    SID to UID and primary GID mapping

1. Secmap is searched for the SID. If the SID is found, the UID and primary GID mapping is resolved.

2. If the SID is not in secmap, the Windows username must be found.
   1. The local group database (LGDB) is searched for the SID to determine if it is a local user. If the SID is found, the name is SMB_SERVER\USER. Since it is a local user for SMB-only access, no UNIX mapping is required.
   2. If SID is not found in the LGDB, the DC is searched for the SID. If the SID is found in the domain, the name is DOMAIN\USER.
   3. If the SID is not resolvable, access is denied. This failed mapping added to the persistent secmap database.
3. If the default UNIX account is not used, the Windows name is translated to the UNIX name.
   1. If the Windows name is found in NTXMAP, that entry is used as the UNIX name.
   2. If the Windows name is not found in NTXMAP or if NTXMAP is disabled, the Windows name is used as the UNIX name.
4. The local files or UDS is searched for the UNIX name to find the UID and primary GID.
   1. If the UNIX name is found, the UID and primary GID mapping is resolved. This successful mapping is added to the persistent secmap database.
   2. If the UNIX name is not found, but the automatic mapping for unmapped Windows accounts feature is enabled, the UID is automatically assigned. This successful mapping is added to the persistent secmap database.
   3. If the UNIX name is not found, but a default UNIX account is configured, the UID and primary GID are mapped to that of the default UNIX account. This failed mapping added to the persistent secmap database.
   4. If the UNIX name is not resolvable, access is denied. This failed mapping is added to the persistent secmap database.

Mappings that do not result in a permanent UID are considered failed mappings – 2c, 4c, and 4d. Users with failed mappings are added to the secmap database with 4294967294 as their UID. This UID indicates that the mapping process must be retried the next time that the user connects. If a mapping is defined for these users later, they can convert in to successfully mapped users upon connecting. The secmap database is then updated accordingly with the permanent mapping. These users must go through the mapping process each time they connect until they have a permanent mapping defined.

Figure 22 shows the process that is used to resolve a UNIX user (UID) to a Windows user (SID). This process is only needed if the access policy is set to Windows. This process is different compared to the UNIX UID that is always required, regardless of the access policy, since the UID is also used for file ownership and quota management purposes.

Figure 22.    UID to SID mapping

1. Secmap is searched for the UID. If the UID is found, the SID mapping is resolved.
2. If the UID is not in secmap, the UNIX username must be found.
   1. Local files or UDS is searched for the UID. If the UID is found, the UNIX name is determined.
   2. If the UID is not found, but a default Windows account is configured, the UID is mapped to the default Windows account. If it does not exist, the default Windows user is added to the persistent secmap database.
   3. If the UID is not resolvable, access is denied.
3. If the default Windows account is not used, the UNIX name is translated to the Windows name.
   1. If the UNIX name is found in NTXMAP, that entry is used as the Windows name.
   2. If the UNIX name is not found in NTXMAP or if NTXMAP is disabled, the UNIX name is used as the Windows name.
4. The DC or LGDB is searched for the Windows name to find the SID.
   1. The Windows name is searched in the DC. If the Windows name is found, the SID mapping is resolved. This successful mapping is added to the persistent secmap database.
   2. If the Windows name contains a period (.) and the part of the name following the last period (.) matches an SMB server name, the LGDB of that SMB Server is searched. If the Windows name is found, the SID mapping is resolved. This successful mapping is added to the persistent secmap database.
   3. If the Windows name is not found, but a default Windows account is configured, the SID is mapped to that of the default Windows account. If it does not exist, the default Windows user is added to the persistent secmap database.
   4. If the Windows name is not resolvable, access is denied.