• Deep dive: File system security and access in a multiprotocol environment

    PDF

    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.

    If the older SMB1 protocol does not need to be supported in your environment, it can be disabled by using the svc_nas service command. For more information about this service command, see the Service Commands Technical Notes.
    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.

    User mapping

    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.
    • ntxmap
    User mapping does not affect the users or groups that are local to the SMB 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:

    • LDAP
    • NIS
    • 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

    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
    secmap

    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

    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:

    1. secmap is searched for the SID. If the SID is found, the UID and GID mapping is resolved.
    2. If the SID is not found in secmap, the Windows name related to the SID must be found.
      1. 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.
      2. 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.
    3. The Windows name is translated into a UNIX name. The ntxmap is used for this purpose.
      1. If the Windows name is found in ntxmap, the entry is used as the UNIX name.
      2. If the Windows name is not found in ntxmap, the Windows name is used as the UNIX name.
    4. The UDS (NIS server, LDAP server, or local files) is searched using the UNIX name.
      1. If the UNIX user name is found in the UDS, the UID and GID mapping is resolved.
      2. If the UNIX name is not found, but the automatic mapping for unmapped Windows accounts feature is enabled, the UID is automatically assigned.
      3. 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.
      4. 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:

    Figure 1. Process for resolving an SID to a UID, primary GID mapping
    Process for resolving 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:

    1. secmap is searched for the UID. If the UID is found, the SID mapping is resolved.
    2. If the UID is not found in secmap, the UNIX name related to the UID must be found.
      1. 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.
      2. 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.
    3. 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.
      1. If the UNIX name is found in ntxmap, the entry is used as the Windows name.
      2. If the UNIX name is not found in ntxmap, the UNIX name is used as the Windows name.
    4. The Windows DC or the local group database is searched using the Windows name.
      1. If the Windows name is found, the SID mapping is resolved.
      2. 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.
      3. 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.
      4. 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:

    Figure 2. Process used to resolve a UID to an SID mapping
    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:

    Access policy
    Description
    Native (default)
    • Each protocol manages access with its native security.
    • Security for NFS shares uses the UNIX credential associated with the request to check the NFSv3 UNIX mode bits or NFSv4 ACL. The access is then granted or denied.
    • Security for SMB shares uses the Windows credential associated with the request to check the SMB ACL. The access is then granted or denied.
    • NFSv3 UNIX mode bits and NFSv4 ACL permission changes are synchronized to each other.
    • There is no synchronization between the Unix and Windows permissions.
    Windows
    • Secures file level access for Windows and UNIX using Windows security.
    • Uses a Windows credential to check the SMB ACL.
    • Permissions for newly created files are determined by an SMB ACL conversion. SMB ACL permission changes are synchronized to the NFSv3 UNIX mode bits or NFSv4 ACL.
    • NFSv3 mode bits and NFSv4 ACL permission changes are denied.
    UNIX
    • Secures file level access for Windows and UNIX using UNIX security.
    • Upon request for SMB access, the UNIX credential built from the local files or UDS is used to check the NFSv3 mode bits or NFSv4 ACL for permissions.
    • Permissions for newly created files are determined by the UMASK.
    • NFSv3 UNIX mode bits or NFSv4 ACL permission changes are synchronized to the SMB ACL.
    • SMB ACL permission changes are allowed in order to avoid causing disruption, but these permissions are not maintained.

    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.
    For an NFS request when the extended credential property is not set, the UNIX credential from the NFS request is used. When using Kerberos authentication for an SMB request, the Windows credential of the domain user is included in the Kerberos ticket of the session setup request.

    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.

    If the default UNIX user is not set in the UNIX Directory Services (UDS), SMB access is denied for unmapped users. If the default Windows user is not found in the Windows DC or the LGDB, NFS access on a file system that has a Windows access policy is denied for unmapped users.
    The default UNIX user can be a valid existing UNIX account name or follow the new format @uid=xxxx,gid=yyyy@, where xxxx and yyyy are the decimal numerical values of the UID and the primary GID, respectively, and can be configured on the system through either Unisphere or CLI.
    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.

    For NFS secure access, the credential is always built using the UDS.
    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.

    NTLM is an older suite of proprietary security protocols that provides authentication, integrity, and confidentiality to users. Kerberos is an open standard protocol that provides faster authentication through the use of a ticketing system. Kerberos adds greater security than NTLM to systems on a network.
    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:

    Setting
    Description
    Allowed
    All NFS and SMB clients can rename directories without any restrictions.
    SMB
    (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.
    Not Allowed
    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:

    Setting
    Description
    Mandatory
    (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.
    Advisory
    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.