Deep dive: File system security and access in a multiprotocol environment
Security on file system objects
In a multiprotocol environment, security policy is set at the file system level, and is independent for each file system. Each file system uses its access policy to determine how to reconcile the differences between NFS and SMB access control semantics. Selecting an access policy determines which mechanism is used to enforce file security on the particular file system.
UNIX security model
When the UNIX policy is selected, any attempt to change file level security from the SMB protocol, such as changes to access control lists (ACLs), is ignored. UNIX access rights are referred to as the mode bits or NFSv4 ACL of a file system object. Mode bits are represented by a bit string. Each bit represents an access mode or privilege that is granted to the user owning the file, the group associated with the file system object, and all other users. UNIX mode bits are represented as three sets of concatenated rwx (read, write, and execute) triplets for each category of users (user, group, or other). An ACL is a list of users and groups of users by which access to, and denial of, services is controlled.
Windows security model
The Windows security model is based primarily on object rights, which involve the use of a security descriptor (SD) and its ACL. When SMB policy is selected, changes to the mode bits from NFS protocol are ignored.
Access to a file system object is based on whether permissions have been set to Allow or Deny through the use of a security descriptor. The SD describes the owner of the object and group SIDs for the object along with its ACLs. An ACL is part of the security descriptor for each object. Each ACL contains access control entries (ACEs). Each ACE in turn, contains a single SID that identifies a user, group, or computer and a list of rights that are denied or allowed for that SID.
File system access
File access is provided through NAS servers, which contain a set of file systems where data is stored. The NAS server provides access to this data for NFS and SMB file protocols by sharing file systems through SMB shares and NFS shares. The NAS server mode for multiprotocol sharing allows the sharing of the same data between SMB and NFS. Because the multiprotocol sharing mode provides simultaneous SMB and NFS access to a file system, the mapping of Windows users to Unix users and defining the security rules to use (mode bits, ACL, and user credentials) must be considered and configured properly for multiprotocol sharing.
In a multiprotocol context, a Windows user needs to be matched to a UNIX user. However, a UNIX user has to be mapped to a Windows user only when the access policy is Windows. This matching is necessary so that file system security can be enforced, even if it is not native to the protocol. The following components are involved in user mapping:
- UNIX Directory Services, local files, or both
- Windows resolvers
- Secure mapping (secmap) - a cache that contains all mappings between SIDs, and UID or GIDs used by a NAS server.
UNIX Directory Services and local files
UNIX Directory Services (UDSs) and local files are used to do the following:
- Return the corresponding UNIX account name for a particular user identifier (UID).
- Return the corresponding UID and primary group identifier (GID) for a particular UNIX account name.
The supported services are:
- Local files
- None (the only possible mapping is through the default user)
There should be one UDS enabled or local files enabled, or both local files and a UDS enabled for the NAS server when multiprotocol sharing is enabled. The Unix directory service property of the NAS server determines which is used for user mapping.
Windows resolvers are used to do the following for user mapping:
- Return the corresponding Windows account name for a particular security identifier (SID)
- Return the corresponding SID for a particular Windows account name
The Windows resolvers are:
- The domain controller (DC) of the domain
- The local group database (LGDB) of the SMB server
The function of secmap is to store all SID-to-UID and primary GID and UID-to-SID mappings to ensure coherency across all file systems of the NAS server.
ntxmap is used to associate a Windows account to a UNIX account when the name is different. For example, if there is a user who has an account that is called Gerald on Windows but the account on UNIX is called Gerry, ntxmap is used to make the correlation between the two.
SID to UID, primary GID mapping
The following sequence is the process used to resolve an SID to a UID, primary GID mapping:
- secmap is searched for the SID. If the SID is found, the UID and GID mapping is resolved.
- If the SID is not found in secmap, the Windows name related to the SID must be found.
- The local group databases of the SMB servers of the NAS are searched for the SID. If the SID is found, the related Windows name is the local user name along with the SMB server name.
- If the SID is not found in the local group database, the DC of the domain is searched. If the SID is found, the related Windows name is the user name. If the SID is not resolvable, access is denied.
- The Windows name is translated into a UNIX name. The ntxmap is used for this purpose.
- If the Windows name is found in ntxmap, the entry is used as the UNIX name.
- If the Windows name is not found in ntxmap, the Windows name is used as the UNIX name.
- The UDS (NIS server, LDAP server, or local files) is searched using the UNIX name.
- If the UNIX user name is found in the UDS, the UID and GID mapping is resolved.
- If the UNIX name is not found, but the automatic mapping for unmapped Windows accounts feature is enabled, the UID is automatically assigned.
- If the UNIX user name is not found in the UDS but there is a default UNIX account, the UID and GID mapping is resolved to that of the default UNIX account.
- If the SID is not resolvable, access is denied.
If the mapping is found, it is added in the persistent secmap database. If the mapping is not found, the failed mapping is added to the persistent secmap database.
The following diagram illustrates the process used to resolve an SID to a UID, primary GID mapping:
UID to SID mapping
The following sequence is the process used to resolve a UID to an SID mapping:
- secmap is searched for the UID. If the UID is found, the SID mapping is resolved.
- If the UID is not found in secmap, the UNIX name related to the UID must be found.
- The UDS (NIS server, LDAP server, or local files) is searched using the UID. If the UID is found, the related UNIX name is the user name.
- If the UID is not found in the UDS but there is a default Windows account, the UID is mapped to the SID of the default Windows account.
- If the default Windows account information is not used, the UNIX name is translated into a Windows name. The ntxmap is used for this purpose.
- If the UNIX name is found in ntxmap, the entry is used as the Windows name.
- If the UNIX name is not found in ntxmap, the UNIX name is used as the Windows name.
- The Windows DC or the local group database is searched using the Windows name.
- If the Windows name is found, the SID mapping is resolved.
- If the Windows name contains a period, and the part of the name following the last period (.) matches an SMB server name, the local group database of that SMB server is searched to resolve the SID mapping.
- If the Windows name is not found but there is a default Windows account, the SID is mapped to that of the default Windows account.
- If the SID is not resolvable, access is denied.
If the mapping is found, it is added in the persistent Secmap database. If the mapping is not found, the failed mapping is added to the persistent secmap database.
The following diagram illustrates the process used to resolve a UID to an SID mapping:
Access policies for NFS, SMB, and FTP
In a multiprotocol environment, the storage system uses file system access policies to manage user access control of its file systems. There are two kinds of security, UNIX and Windows.
For UNIX security authentication, the credential is built from the UNIX Directory Services (UDS) with the exception for non-secure NFS access, where the credential is provided by the host client. User rights are determined from the mode bits and NFSv4 ACL. The user and group identifiers (UID and GID, respectively) are used for identification. There are no privileges associated with UNIX security.
For Windows security authentication, the credential is built from the Windows Domain Controller (DC) and Local Group Database (LGDB) of the SMB server. User rights are determined from the SMB ACLs. The security identifier (SID) is used for identification. There are privileges associated with Windows security, such as TakeOwnership, Backup, and Restore, that are granted by the LGDB or group policy object (GPO) of the SMB server.
The following table describes the access policies that define what security is used by which protocols:
For FTP, authentication with Windows or UNIX depends on the user name format that is used when authenticating to the NAS server. If Windows authentication is used, FTP access control is similar to that for SMB; otherwise, authentication is similar to that for NFS. FTP and SFTP clients are authenticated when they connect to the NAS server. It could be an SMB authentication (when the format of the user name is domain&#xser or user@domain) or a UNIX authentication (for the other formats of a single user name). The SMB authentication is ensured by the Windows DC of the domain defined in the NAS server. The UNIX authentication is ensured by the NAS server according to the encrypted password stored in either a remote LDAP server, a remote NIS server, or in the local password file of the NAS server.
Credentials for file level security
To enforce file-level security, the storage system must build a credential that is associated with the SMB or NFS request being handled. There are two kinds of credentials, Windows and UNIX. UNIX and Windows credentials are built by the NAS server for the following use cases:
- To build a UNIX credential with more than 16 groups for an NFS request. The extended credential property of the NAS server must be set to provide this ability.
- To build a UNIX credential for an SMB request when the access policy for the file system is UNIX.
- To build a Windows credential for an SMB request.
- To build a Windows credential for an NFS request when the access policy for the file system is Windows.
A persistent credential cache is used for the following:
- Windows credentials built for access to a file system having a Windows access policy.
- Unix credential for access through NFS if the extended credential option is enabled.
There is one cache instance for each NAS server.
Granting access to unmapped users
Multiprotocol requires the following:
- A Windows user must be mapped to a UNIX user.
- A UNIX user must be mapped to a Windows user in order to build the Windows credential when the user is accessing a file system that has a Windows access policy.
Two properties are associated to the NAS server with regards to unmapped users:
- The default UNIX user.
- The default Windows user.
When an unmapped Windows user attempts to connect to a multiprotocol file system and the default UNIX user account is configured for the NAS server, the user identifier (UID) and primary group identifier (GID) of the default UNIX user are used in the Windows credential. Similarly, when an unmapped UNIX user attempts to connect to a multiprotocol file system and the default Windows user account is configured for the NAS server, the Windows credential of the default Windows user is used.
UNIX credential for NFS requests
To handle NFS requests for an NFS only or multi-protocol file system with a UNIX or native access policy, a UNIX credential must be used. The UNIX credential is always embedded in each request; however, the credential is limited to 16 extra groups. The NFS server extendedUnixCredEnabled property provides the ability to build a credential with more than 16 groups. If this property is set, the active UDS is queried with the UID to get the primary GID and all the group GIDs to which it belongs. If the UID is not found in the UDS, the UNIX credential embedded in the request is used.
UNIX credential for SMB requests
To handle SMB requests for a multi-protocol file system with a UNIX access policy, a Windows credential must first be built for the SMB user at the session setup time. The SID of the Windows user is used to find the name from the AD. That name is then used (optionally through ntxmap) to find a Unix UID and GID from the UDS or local file (passwd file). The owner UID of the user is included in the Windows credential. When accessing a file system with a UNIX access policy, the UID of the user is used to query the UDS to build the UNIX credential, similar to building an extended credential for NFS. The UID is required for quota management.
Windows credential for SMB requests
To handle SMB requests for an SMB only or a multi-protocol file system with a Windows or native access policy, a Windows credential must be used. The Windows credential for SMB needs to be built only once at the session setup request time when the user connects.
When using Kerberos authentication, the credential of the user is included in the Kerberos ticket of the session setup request, unlike when using NT LAN Manager (NTLM). Other information is queried from the Windows DC or the LGDB. For Kerberos the list of extra group SIDs is taken from the Kerberos ticket and the list of extra local group SIDs. The list of privileges are taken from the LGDB. For NTLM the list of extra group SIDs is taken from the Windows DC and the list of extra local group SIDs. The list of privileges are taken from the LGDB.
Additionally, the corresponding UID and primary GID are also retrieved from the user mapping component. Since the primary group SID is not used for access checking, the UNIX primary GID is used instead.
Windows credential for NFS requests
The Windows credential is only built or retrieved when a user through an NFS request attempts to access a file system that has a Windows access policy. The UID is extracted from the NFS request. There is a global Windows credential cache to help avoid building the credential on each NFS request with an associated retention time. If the Windows credential is found in this cache, no other action is required. If the Windows credential is not found, the UDS or local file is queried to find the name for the UID. The name is then used (optionally, through ntxmap) to find a Windows user, and the credential is retrieved from the Windows DC or LGDB. If the mapping is not found, the Windows credential of the default Windows user is used instead, or the access is denied.
Multiprotocol file system security settings
Unity offers the ability to customize the access, rename, and locking policies for a multiprotocol file system.
File system access policies
You can select one of the following access policies for a multiprotocol file system:
- Native Security
- UNIX Security
- Windows Security
For information about these access policies, see Access policies for NFS, SMB, and FTP.
File system rename policies
You can select one of the following rename policies for a multiprotocol file system. This policy controls the circumstances under which NFS and SMB clients can rename a directory. Value is one of the following:
All NFS and SMB clients can rename directories without any restrictions.
(Default) Only NFS clients can rename directories without any restrictions. An SMB client cannot rename a directory in the path if at least one file is opened in the directory or in one of its subdirectories. For example, if the path to a file is C:\Dir1\Dir2\Dir3\File1.txt, and an SMB client opens File1, neither Dir1, Dir2 , or Dir3 can be renamed.
NFS and SMB clients cannot rename a directory if at least one file is opened in the directory or in one of its subdirectories.
File system locking policies
SMB and NFS have their own lock range. Protocol specifications define lock ranges as mandatory for SMB but may be advisory for NFS. NFSv3/v3 uses a separate protocol (NLM) that is always advisory. NFSv4 has the lock management integrated in the protocol itself, but may also be advisory or mandatory, depending of the implementation.
A locking policy property is used to define the alternate behavior. You can select one of the following locking policies for a multiprotocol file system:
(Default) Uses the SMB and NFSv4 protocols to manage range locks for a file that is in use by another user. A mandatory locking policy prevents data corruption if there is concurrent access to the same locked data.
In response to lock requests, reports that there is a range lock conflict, but does not prevent access to the file. This policy allows NFSv3 applications that are not range-lock compliant to continue working, but risks data corruption if there are concurrent writes.