Home > Storage > Unity XT > Storage Admin > Dell Unity: NAS Capabilities > Multiprotocol
When configuring a NAS server for protocol access, an administrator has several options. With respect to SMB and NFS, the NAS server can be configured in one of the following ways:
The major difference between enabling both SMB and NFS independently and enabling multiprotocol is that multiprotocol configurations allow data in a single file system to be accessed through both SMB and NFS concurrently. In contrast, a non-multiprotocol NAS server with SMB and NFS enabled individually will require separate file systems to be configured for SMB and NFS, where SMB users will not be able to access NFS file system data and NFS users cannot access SMB file system data. When a NAS server is designated as multiprotocol, all file systems on that NAS server will be multiprotocol accessible.
Due to the inherent differences between the SMB and NFS protocols, some configuration is required to support multiprotocol. For example, Windows uses security identifiers (SIDs) while UNIX uses user IDs/group IDs (UIDs/GIDs) so various services are required to translate usernames to the proper IDs. Another example is security where Windows uses access control lists (ACLs) while UNIX uses mode bits or the NFSv4 ACL. The following section provides additional details about multiprotocol configuration on Dell Unity.
To use multiprotocol, you must first configure a multiprotocol NAS server. This provides the configuration that enables the NAS server to recognize users across multiple protocols. To enable multiprotocol on a NAS server, the following requirements must be met:
An Active Directory domain-joined SMB server is required to translate SIDs to Windows names. To configure an Active Directory domain-joined SMB server, NTP must be configured on the system and DNS must be configured on the NAS server. Then, browse the NAS server Properties Sharing Protocols SMB and provide the SMB computer name, Windows domain, domain privileged username, and password.
At least one of the services below must be configured to translate UIDs to UNIX names:
To configure LDAP, browse the NAS server Properties Naming Services LDAP/NIS. Provide the LDAP servers, Base DN, Authentication method, and credentials (if necessary). On this page, you can also configure the LDAP schema, enable LDAP secure (use SSL) to encrypt LDAP traffic, and configure the Certification Authority (CA) certificate for authentication. You can configure LDAP to use anonymous, simple, or Kerberos authentication.
In OE version 4.3, the ability to run LDAP lookups from the NAS server is available. This is useful for confirming the mappings are configured properly and for troubleshooting purposes. You can look up a user, group, UID, GID, host, or netgroup. To run an LDAP lookup, run the svc_nas <NAS_Server> -ldap –lookup command.
In addition, support for dynamic LDAP domain lookups on NAS servers is added. This feature enables the ability to automatically obtain the LDAP server IP addresses and ports from DNS. Dynamic LDAP domain lookups is the default option and removes the requirement for the user to manually specify the LDAP server IP addresses and ports when configuring or editing a NAS server. This also enables the ability to update the configuration dynamically and globally without modifying each individual NAS server. For this to work, SRV (service) records for each LDAP server must exist in DNS and all servers should share the same authentication settings.
Any LDAP server IP addresses that are discovered through this method are not displayed in Unisphere. If you want to view the discovered IP addresses and settings, run the svc_nas <NAS_Server> -ldap command to display the current configuration. The system automatically refreshes the configuration every 20 minutes from DNS. You can also manually refresh the configuration at any time by running the svc_nas <NAS_Server> -ldap –refresh command.
If the system is replicating to a system that is running OE version 4.2 or earlier, the discovered IP addresses are configured as static IPs on the destination system. Also, note that this feature only resolves the LDAP server IPs and ports, and the rest of the configuration still needs to be entered by the administrator. Also, if needed, the administrator still can configure the LDAP server IP addresses manually. The dynamic LDAP domain lookups feature is displayed in the figure below.
When configuring an LDAP server manually, an IP address must be entered. In OE version 5.2 and later, a Fully Qualified Domain Name (FQDN) can also be entered in place of an IP address. When an FQDN is specified, an accessible DNS server must be configured on the NAS server. After configuring an LDAP server using an FQDN, a DNS lookup is used to determine the LDAP server’s IP address. DNS is also periodically polled to ensure that if the IP ever changes, it will automatically be updated on the NAS server. Entering the LDAP server’s FQDN rather than the IP address is suggested to reduce the operational overhead required when changing an LDAP server’s IP address.
Note: When utilizing replication, it is recommended that the source and all destination systems are running OE version 5.2 or later when replicating a NAS server that utilizes a Fully Qualified Domain Name for an LDAP server. If a replication Failover occurs and the NAS server is replicating from a pre-OE version 5.2 system to a system running OE version 5.2 or later, any changes to the LDAP server configuration will not be replicated.
The description and syntax for all the LDAP configuration settings are shown in the table below.
| Anonymous | Simple | Simple (AD LDAP or IDMU) | Kerberos |
Server | LDAP Server IPs or Fully Qualified Domain Names* (Not required when using dynamic LDAP domain lookups) | |||
Port | LDAP Server Port Number - Default: 389 / SSL: 636 (Not required when using dynamic LDAP domain lookups) | |||
Base DN | Base DN in LDAP notation format. For example, if using svt.lab.com, the Base DN would be DC=svt,DC=lab,DC=com | The Base DN is the same as the Fully Qualified Domain Name. For example, svt.lab.com | Base DN in LDAP notation format. For example, if using svt.lab.com, the Base DN would be DC=svt,DC=lab,DC=com | |
Profile DN (optional) | Profile DN for the iPlanet or OpenLDAP server |
|
| |
Distinguished name (simple only) |
| User account in LDAP notation format. For example, cn=administrator,cn=users,dc=svt,dc=lab,dc=com |
| |
Password (simple only) |
| User account password |
| |
Notes | Active Directory (AD) is not supported with Anonymous LDAP authentication |
|
| See below for Kerberos authentication options
|
Note: Entering a Fully Qualified Domain Name is supported in OE version 5.2 and later.
There are two methods for configuring Kerberos:
The LDAP configuration must adhere to either the IDMU, RFC 2307 or RFC2307bis schemas. See to the RFC for a list of what is required for each schema. You can verify the current schema configuration by using the Retrieve Current Schema link on the LDAP page to retrieve the ldap.conf file, edit it, and upload a new version. All containers specified in the ldap.conf file must point to a location that is valid and exists in Active Directory, including ones that may not be in use, such as netgroup and host. If any entries are removed from this file, the NAS server automatically sets them to a default value based on the baseDN, which may result in lookup issues. Consult with your domain administrator to get the proper values for each container. The figure below shows an example of a valid LDAP schema for IDMU.
To configure NIS, browse NAS server Properties à Naming Services à LDAP/NIS.. Then, provide the NIS domain and up to three NIS servers.
Starting with OE version 4.1, local files can also be used for resolving UNIX identities. This leverages the local passwd and group files that are uploaded to the NAS server. This can be used in addition to or instead of the UDS. If both are configured, Local Files are searched first before using the UDS. To configure Local Files, browse NAS server Properties à Naming Services à Local Files. You can download the current local files from this page, which also provides syntax and additional details. After the files are edited, upload the new files back to the NAS server. The figure below shows the syntax and an example entry in a passwd file. The comment, home directory, and shell should be empty since they are not used.
Once all these requirements are fulfilled, multiprotocol access can be enabled on the NAS server and then a multiprotocol file system can be created. It is important to note that once multiprotocol is enabled and a file system is created, it cannot be disabled. The figure below shows a NAS server that has multiprotocol enabled along with the NTXMAP and mapping diagnostics options.
Multiprotocol NAS servers can only support multiprotocol file systems. They do not have the ability to support SMB-only or NFS-only file systems. If multiprotocol is enabled on an existing NAS server, all the existing file systems are automatically converted to multiprotocol. The file system access policies are automatically updated for UNIX for the existing NFS file systems and Windows for the existing SMB file systems. The system then begins to update the mappings between the Windows and UNIX accounts.
Using a multiprotocol file system allows each SMB user to be mapped to a corresponding NFS user with common access privileges, regardless of which protocol the user is using to access their file system data. By default, users with the same name in Active Directory and the UNIX directory service will have their SMB and NFS identities mapped, allowing for multiprotocol access across each protocol. For example, if a user possesses a windows domain user account named charles and a UNIX LDAP account also named charles, he would be able to access his data with the same privileges across either protocol while being identified as the same user.
However, if his Windows domain user account name was charles but his UNIX LDAP account name was chuck, his Windows and Linux usernames would not be mapped to one another and identified as the same entity by default. If users have different Windows and UNIX usernames, NTXMAP needs to be configured so they can be identified as the same user. It is important to note that NTXMAP is an optional component since it does not provide UID to name mappings. It is a user-defined and managed file that is only used to provide a translation for users that have different names. To configure NTXMAP, browse NAS server Properties à Sharing Protocols à Multiprotocol à Show advanced mapping rules. From here, you can download the current mapping file, make the appropriate edits, and upload the new file to the NAS server. Once this has been done in our example, Charles is able to access his same data whether accessing the file system through SMB as charles or through NFS as chuck.
For multiprotocol, the NAS server needs to know the mapping between the SID, SMB Name, UNIX Name, and UID. This 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 names between the protocols, but each protocol also requires a method to map their respective names to their IDs. The components involved in user mapping are shown in the table below.
Name | Service | Description |
Name | Service | Description |
Windows resolvers (SMB) | Local group database (LGDB) or domain controller | LGDB is used for SMB-only access. DC is used to return: Windows account name for a SID SID for a Windows account name |
UNIX Directory Service (NFS) | LDAP/NIS, Local Files, or Both | Used to return: UNIX account name for a UID UID and primary GID for a UNIX account name |
Secure Mapping Cache | Secmap Cache | A local cache that maintains all the mappings used by a NAS server to ensure coherency across multiple file systems. The following mappings are tracked: SID to UID and primary GID UID to SID |
Default accounts for unmapped users allow administrators to designate a specific existing Windows and/or UNIX account to serve as the mapping destination for unmapped users wanting to access file system data over the other protocol. For example, in an environment where many users have only Windows accounts, a default UNIX user may be designated to allow these unmapped users to access the multiprotocol file system. If default users are not enabled, unmapped users are denied access when attempting to access a multiprotocol file system.
With default accounts enabled, the UID and primary GID of the default UNIX user are used if an unmapped Windows users 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. The configured default users must be valid and exist in the UDS/local files or DC/LGDB for this to work properly. Although multiple users could write to the file system as the default user, this user is still considered a single user for quota calculation purposes and the UNIX account may have ownership of files from many different Windows users.
On OE version 4.2 and earlier, the default UNIX user can be configured by specifying a username, if an entry for that username exists in the UDS/local files to resolve the UID/primary GID. Starting with OE version 4.3, the default UNIX user can be optionally configured as numerical UID/primary GID value. This enables the ability to configure a default UNIX user without setting up and creating a user in the UDS/local files. 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@. The figure bellows shows how to configure default accounts for unmapped users.
Starting with OE version 4.3, the option to enable automatic mapping for unmapped Windows accounts is available. 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. Previously, access is denied for unmapped users unless the default UNIX user is configured. Using this feature provides an advantage compared to using the default UNIX user since the unique UIDs enables user quotas to be tracked and enhances security. When using a default UNIX user, multiple users may be writing to the file system using the same default account so user quotas cannot be tracked, and the UNIX account may have ownership of files from many different Windows users. If this feature is enabled, the ability to configure the default UNIX username is disabled. This feature is designed for multiprotocol environments that consists of mostly Windows users and the actual UID is not critical.
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.
It is important to note that if the UDS/local files are updated to configure a UID after one is already assigned by this feature, the new entry in the UDS/local files is ignored. If you would like to use the entry in UDS/local files, you must delete the entry from secmap cache by running svc_cifssupport <NAS_Server> -secmap –delete –name <Name> -domain <Domain>. Alternatively, you can initiate a full remapping of the entire file system if multiple updates are required.
The figure below shows the process used to resolve a Windows user (SID) to a UNIX user (UID/primary GID). Even when multiprotocol is configured, local users on the SMB Server can still be used for SMB-only access. These users do not need a mapping to a UNIX user as they are only used for SMB access.
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 indicates that the mapping process needs to be retried the next time 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. This means these users must go through the mapping process each time they connect until they have a permanent mapping defined.
The figure below shows the process 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 is different compared to the UNIX UID that is always required, regardless of the access policy, since the UID is also used for quota management purposes.
Starting with OE version 4.3, the ability to manage secmap cache is available. This provides the ability to create, update, and delete any or all entries from secmap cache. This is in addition to the existing options to view, import, export, and generate reports for secmap cache. To manage secmap cache, run the svc_cifssupport <NAS_Server> -secmap command. There are options to list the contents of secmap cache, create entries, update entries, delete entries, import a database, export the database, or generate a report on the database health and content.
Dell Unity storage also provides the ability to view a user mapping diagnostics report. This report only displays any user mappings that have issues. This process compares the users in the secmap cache to the entries in Active Directory and UDS/local files and generates a report. Under NAS server Properties Sharing Protocols Multiprotocol, click Show mapping diagnostics and Run user mapping diagnostics. After the report is generated, select Retrieve Mapping Diagnostic Report to download the report. You can view the user mapping issues and make any changes, if necessary. After corrections are made, you can optionally re-run the user mapping diagnostics report to ensure they are no longer on the list.
In the report, each line represents a user that has a mapping issue in one of the formats described in the table below.
Format | Status | Issue |
u sid | Unknown user mapping | This is an entry for an unknown SID that cannot be resolved to a username. The SID no longer exists in the DC and may have been deleted. |
u sid username | Unknown user mapping | This is an entry that is resolved successfully to a username, but not to a UID. There is no entry in the UDS/local files for this username. |
n sid username Uid OLD UID | Known user mapping | This is entry that is resolved successfully to both a SID and UID, but the entry has changed. This means the UID returned from the UDS/local files does not match the UID in secmap cache. |
The figure below shows an example of a report with users that have an inconsistent UID and unresolved SID/UID mapping.
When creating or managing a multiprotocol NAS environment, there are additional configuration options at the NAS server and file system levels related to the mapping between SMB and NFS users accessing file system data. These options are shown in the table below.
Option | Level | Default |
Access policy | File system | Native |
UMASK (SMB) | Share | 022 |
Security is also handled differently between SMB and NFS. For NFS, the authentication credentials are provided by the client or, for secure NFS, built from the UDS. User rights are determined by the NFSv3 mode bits or NFSv4 ACLs and the UID/GIDs are used for identification purposes. There are no privileges associated with UNIX security.
For SMB, the credentials are built from the domain controller (DC) and local group database (LGDB) of the SMB server. User rights are determined by the ACL and the SID is used for identification purposes. Windows security includes privileges such as TakeOwnership, Backup, and Restore that are granted by the LGDB or group policy object (GPO).
The access policy is used to define how security is enforced on a multiprotocol file system. The default setting of Native maintains two separate sets of permissions for each file and the protocol that is used to access the file determines which set of permissions are checked. If SMB is used, the ACLs are checked but if NFS is used, the NFSv3 mode bits or NFSv4 ACL are checked. If the multiprotocol environment is heavily weighted toward users of one type or another, setting the access policy to one of the other values may be desirable. The Windows setting only checks the ACLs and completely ignores the NFSv3 mode bits and NFSv4 ACL while the UNIX policy does the opposite. The table below describes the available policies that can be configured at the file system level.
Access policy | Description |
Native (default) | Manages access for each protocol separately with its own native security Security for NFS shares use the UNIX mode bits or NFSv4 ACL Security for SMB shares use the SMB Access Control List (ACL) The two sets of permissions are independent and there is no synchronization between them NFSv3 UNIX mode bits or NFSv4 ACL permission changes are synchronized to each other, but SMB ACL is not changed SMB ACL permission changes do not change the NFSv3 UNIX mode bits or NFSv4 ACL |
Windows | Uses the SMB ACL for both protocols Upon request for NFS access, the Windows credential built from the DC/LGDB is used to check the ACL for permissions NFSv3 UNIX mode bits or NFSv4 ACLs are updated when SMB ACL permissions are changed NFSv3 UNIX mode bits or NFSv4 ACL permission changes are denied |
UNIX | Uses the NFSv3 UNIX mode bits or NFSv4 ACL for both protocols Upon request for SMB access, the UNIX credential built from the UDS/local files is used to check the NFSv3 mode bits or NFSv4 ACL for permissions SMB ACL permissions are updated when NFSv3 UNIX mode bits or NFSv4 ACLs are changed SMB ACL permission changes are allowed to avoid causing disruption, but these permissions are not maintained |
The figure below shows how to configure the access policy in Unisphere.
The UMASK is a bitmask that enables the ability to control the default UNIX permissions for newly created files and folders. This setting is only applied to new files and folders created on SMB for multiprotocol file systems. The UMASK setting determines which UNIX permissions are excluded for new files and directories. By default, new files have 666 permissions while new directories have 777 permissions. If the UMASK set to the default value of 022, this means new files have 644 permissions and new directories have 755 permissions instead. If NFSv4 ACL inheritance is present on the directory, this will take precedence over the UMASK setting.
On OE version 4.2 and earlier, the UMASK setting is not used for the Windows access policy. Instead, the NAS server performs a conversion of the Windows permissions to determine the proper UNIX permissions. Although the UNIX permissions are not used while the Windows access policy is active, these permissions are still generated. This provides the ability to change the access policy without needing to re-permission the entire file system. The way the permissions are calculated are shown in the table below.
User | Description |
Owner | The rights of the owner and the rights of everyone from the ACL are used. |
Group | A logical OR is done on the entries that are not exactly the owner in the ACL to determine the permissions. |
Other | Receives the same permissions as the primary group. |