Securing the customer data

When deploying Fusion File Share Server, it is important to understand both how the customer wants to control access and the security options available with the Fusion solution. This document provides guidance on understanding customer needs as well as how to configure Fusion to provide security. This discussion presumes a Windows Active Directory environment and a system administrator who is available to answer questions.

Before deciding on any configuration for a customer, it’s important to document the answers to a few questions about the customer’s environment. Here is a list of questions to answer before considering configuration options:

1. Has the customer implemented RFC 2307?
   1. If yes, document the uidNumber and primaryGroupID values defined in AD
   2. Ask the customer if they want to use RFC 2307 ID mappings for access control
2. Are user ID mappings on the Linux host used for anything other than the convenience of seeing Owner and Group when issuing the command ‘ls -l’ on files and directories?
   1. Document what these other uses for ID mappings are
3. Will access be controlled with Windows ACLs? Many Windows system administrators refer to this as “file level permissions” or NTFS permissions. In Windows, these can be set by right-clicking on a file or directory and selecting the Security tab.
   1. If a customer doesn’t want to use Windows ACLs, it is important to document why.
4. Will access be controlled by share permissions? In Windows, these can be set by right clicking on a shared directory and selecting the Share tab.
5. How does the customer want permissions to be set on a newly created directory/file? Since Fusion runs on a Linux host, these permissions for directories and files are POSIX rwx bits for user+group+other
   1. Document the permissions the customer wants to implement for newly created files

Once these questions are asked and documented, the following topics can be reviewed to guide the configuration of a Fusion deployment.

Kerberos Authentication

It is important to understand the basics of Kerberos authentication. Authentication is necessary for the client to access Fusion SMB service. However, authentication does not authorize access to any directories or files. (Fusion also supports NTLM pass-through authentication but that is outside the scope of this discussion - Kerberos will be far more common since NTLM is insecure.) A diagram of Kerberos authentication is below for reference. Note that there is no direct communication between the Fusion server and the Active Directory Domain Controller (DC) for Kerberos authentication.

First the client gets and maintains a ticket-granting-ticket (TGT). As the name suggests, the TGT allows the client to request tickets for services available in the domain. The client presents the TGT when requesting a ticket for SMB service. The AD Domain Controller (DC) validates the TGT and returns an encrypted ticket to the client for SMB service. The client takes the encrypted ticket and presents it to the Fusion server. The ticket is decrypted by the Fusion server to validate it. The keys used to encrypt and decrypt the SMB service ticket were previously created as part of the setup process that integrates the Linux host with Active Directory (with tools winbind or adcli).

Kerberos authentication

SSSD and RFC 2307

By default, Fusion is configured with: userdb_idmap = nss

to specify using NSS which typically leverages SSSD. In this default configuration SSSD’s /etc/sssd/sssd.conf should specify:

ldap_id_mapping = True
ldap_schema = ad

This specifies that SSSD should map the user’s objectSID in Active Directory to POSIX UID/GID. This can be easily validated on a Linux system with the id utility:

~$ id foo
uid=1414601123(foo) gid=1414600513(domain users)
groups=1414600513(domain users),1414601115(testgroup)

~$ id bar
uid=1414601125(bar) gid=1414600513(domain users)
groups=1414600513(domain users)

Note that the GID is mapped from the user’s primary group in AD.

Fusion’s default configuration (using NSS and SSSD) can also be used in conjunction with RFC2307 which specifies storing Unix user identity (UID) and group identification (GID) in Active Directory. It allows for central administration of IDs in Active Directory and can be maintained through the Active Directory User and Computers (ADUC) snap-in for Microsoft management console (MMC). If uidNumber and primaryGroupID are set as attributes on user accounts in AD, they can be used instead of Windows SIDs to directly map the UID and GID.

Central administration of IDs in Active Directory through the Active Directory User and Computers (ADUC) snap-in for Microsoft management console (MMC).

For the mapping of RFC 2307 attributes to occur, the system-wide id mapper SSSD must instead include the following in the configuration file at /etc/sssd/sssd.conf

ldap_id_mapping = False
ldap_schema = rfc2307bis

It is also possible to implement RFC2307 without using SSSD. Although SSSD will commonly be used to map the uidNumber and primaryGroupID to POSIX UID/GID, Fusion does support directly mapping by specifying in the global section:

userdb_idmap = rfc2307[<:domain>]

Please note that for RFC2307 (with or without SSSD) Fusion supports a method of denying access to any users lacking uidNumber and primaryGroupID attributes. By specifying in the global section of tsmb.conf:

authz_require_posix = true

Fusion will require the presence of POSIX UID/GID to access the SMB service. This can be useful to reduce the scope of users able to access the SMB service to only those with RFC2307 implemented.

Dynamic ID mapping

Instead of fixed values stored in Active Directory as uidNumber and primaryGroupID, Fusion can also take the RID and map the value to a range of numbers for the UID.

The RID uniquely identifies a security principal relative to the local or domain security authority that issued the SID. RIDs, or relative identifiers, are the unique portion of a Windows SID (security identifier).

The syntax for mapping RID to UID is specified in a configuration option in the global section of tsmb.conf:

userdb_idmap = rid:[<domain>]:<uid_min>[:<uid_max>]

The mapping can be scoped to a particular domain as specified by [:domain] or can be left unspecified if the mapping should apply to any domain. Also <uid_max> can be omitted if a range check is not required.

So, for example, the Samba configuration below:

idmap config * : backend = rid
idmap config * : range = 1000000-1999999

would correspond to the Fusion configuration below: userdb_idmap = rid::1000000:1999999

If trusted domains are used, multiple rid entries can be specified, e.g.:

userdb_idmap = rid:tuxera.com:1000:1999, rid:example.com:2000:2999

For domains, any FQDN or NetBIOS name is acceptable. Note that <uid_max> cannot be omitted for the first domain with multiple rid entries, otherwise all UID-to-SID conversions will be consumed leaving none for trusted domains.

Windows ACLs

There are three security modes available for Fusion. The most common is the use of Windows ACLs. Fusion also supports two other security modes, none and POSIX.

Choosing ‘none’ as the security mode carries security risk and isn’t recommended. However, for air-gapped systems that are physically secured behind locked doors, there may be a small increase in performance since no ACLs are checked.

POSIX is not a common security mode for Fusion deployments. However, there may be use cases in which a customer wishes to use this mode in conjunction with RFC 2307.

Windows is the most common security mode because client access can be controlled with the Windows ACLs familiar to system administrators. This is the default mode for Fusion and the one that is generally recommended. The storage filesystem Fusion is exporting must support extended attributes because Fusion saves the ACL security descriptors in the extended attributes.

More information on the three security modes can be found in the document Fusion File Share ACLs.

Share permissions

Configuring share permissions is section 6.4 Access Permissions in the Fusion File Share Server Manual. These are specified in the share section of tsmb.conf and easily configured by predefined group, username, group or SID and the desired access of READ, CHANGE, FULL, or NO.

Share permissions control access only within the context of the SMB service. While share permissions are useful, they do not secure your customer’s data since access to directories and files on the Linux host are determined by POSIX. In fact, it is common practice for Windows system administrators to set share access permissions to fully open (EVERYONE:FULL) and control access only with ACLs.

Create Masks

Fusion also supports create masks on a per-share basis. This can be useful to control the default POSIX rwx bits for user+group+other when files and directories are created.

Create masks for files and directories can be specified by the following options in the share section and is the maximum allowed permission for a newly created file or directory (via a logical AND):

create_mask = <rwx>
directory_mask = <rwx>

Any bits not set will be masked off from the modes set on the file or directory. For example the default directory mask 0744 (below) will not allow the write bit for ‘group’ and ‘other’ to be set so that only the owner has modify permissions. A directory mask 0750 would remove access to 'Other' which is recommended for security.

• Default: create_mask = 0744
• Default: directory_mask = 0744

Additionally force_create_mode for files and force_directory_mode for directories can be specified by the following options in the share section and is the minimal required permissions for a newly created file or directory (via a logical OR):

force_create_mode = <rwx>
force_directory_mode = <rwx>

Force modes dictate the mode bit permissions that will always be set on a newly created file/directory and is applied after the file/directory mask. The default create mode 0000 (below) results in no changes. A force mode of 0755 would result in -rwxr-xr-x

• Default: force_create_mode = 0000
• Default: force_directory_mode = 0000

Any update of POSIX permissions (as the result of POSIX permission change via UNIX extensions or as a sync between Windows ACLs and POSIX permissions) will pass through the same filter of first logically AND the create mask and then logically OR the force mode:

NEW_POSIX_PERMISSIONS = (NEW_POSIX_PERMISSION & create_mask) | force_create_mode

By default, Fusion only maps the DOS attribute Archive to the User execute bit (u+x). If additionally enabled, the DOS attribute System can be mapped to Group execute bit (g+x) and the DOS attribute Hidden can be mapped to Other execute bit (o+x). Please see section 6.5 for configuring these mappings.

The mapping of DOS attributes can be affected by create masks. For example, if a create mask is create_mask = 0644 then a file created will have -rw-r--r--

Note that the create mask 0644 has not allowed the User execute bit (which by default maps to the DOS attribute Archive) to be set. Since the Owner’s maximum permission is 6 the execute bit cannot be set.

To give another example, if all DOS attributes mappings are enabled and not intended to be masked off, then a create mask of 0755 would result in a created file with -rwxr-xr-x (assuming Archive/System/Hidden bits are set).