Home > Storage > PowerScale (Isilon) > Product Documentation > Protocols > PowerScale: Home Directory Storage Solutions for NFS and SMB Environments > Authentication providers and access management
Authentication services provide data security by verifying users’ identities before granting access to files and directories. PowerScale storage supports several methods of user authentication. Based on the results of these administrator-defined authentication policies, a PowerScale storage cluster allows or blocks access to stored data. A PowerScale storage cluster can be accessed via any of several different application-layer protocols—including SMB, NFS, HDFS, S3, HTTP, and FTP—and authentication policies can be planned and implemented across any or all of these protocols. The appropriate data-security and protocol-level access settings should be consistent with the organization’s specific requirements and overall security policies.
File- and directory-access permissions are enforced consistently across protocols, regardless of the actual security model being used. A user is granted or denied access to a file when using SMB as with NFS. Traditional UNIX (NFS) permissions are set on the file system by default. By using Windows Explorer or OneFS administrative tools, standard Windows Access Control List (ACL) permissions can be applied to directories and files.
In a multi-authentication-provider scenario, OneFS also supports configuring Windows-based ACLs for local, NIS and LDAP groups, as well as AD groups and users. After a file or directory has been configured with an ACL, however, the previous UNIX-mode bits for that object are no longer enforced.
PowerScale supports the following authentication providers:
This paper focuses primarily on integration with AD and LDAP authentication providers.
Since a PowerScale cluster can seamlessly emulate a Windows-based file server, it can also seamlessly integrate with Active Directory to provide home directory file services as an enterprise platform. In addition to the native SMB functionality that PowerScale provides, it also integrates with an organization’s existing file- and directory permissions models, and automated mapping of AD users with their designated home directories on the PowerScale storage cluster.
This section reviews Active Directory integration features and best practices for planning and provisioning AD-based home directory services.
When a PowerScale storage cluster is joined to an AD domain, a single computer account is created in the domain. This account is used to establish and maintain the trust relationship between the cluster and the domain. The account enables the authentication of users from the AD forest and the authorization of object access on the cluster, regardless of which node within the cluster a user or client connects to. Unless specified otherwise, joining a PowerScale storage cluster to AD automatically enables AD domain mode integration, in which the cluster leverages existing user and group objects to create and enforce ACLs on files and directories.
Cluster naming
While a PowerScale storage cluster is joined to an Active Directory domain using a single name, the resulting trust relationship between the cluster and AD is automatically extended to include all names by which the cluster is available on the network.
As an example, if SmartConnect network pools are used to manage client connections for optimal performance and client load balancing, each SmartConnect pool will require a unique FQDN on the network. Despite the multiple names to which a PowerScale storage cluster can respond, only one machine account—the one corresponding to the name configured on the Cluster Identity settings page—is necessary for the cluster within AD.
SmartConnect pools are explained in more detail in SmartConnect overview.
Permissions
ACL permissions, as applied to files and directories shared via SMB, can be created and modified through any of the following tools.
For share-level permissions:
In addition to creating and editing share-level permissions, any of these tools can also be used for creating shares on a PowerScale storage cluster.
For file and directory permissions:
Note: Using the ‘chmod’ utility to modify ACLs for files and directories is only available when logged in via SSH to a PowerScale cluster directly.
Integration with UNIX-style permissions
When an administrator uses a Windows client to change the ACL settings of a file, no information is lost because OneFS stores the original ACL and replaces it. The same holds true when an administrator uses a Windows client to change the permissions of a file with mode bits. OneFS maps the mode bits to a synthetic ACL and because the ACL model can capture the full range of POSIX permissions, so no security information
is lost. In such cases, OneFS replaces the file's synthetic ACL with an actual ACL that is equivalent to the mode bits.
The situation is different when a ‘chmod’ or ‘chown’ command modifies the permissions of a file protected by an ACL. In this circumstance, OneFS must map the permission changes between two disparate security models. To do so, OneFS, in its default setting, merges the ACL with a patch derived from the change in mode bits. In most cases, this preserves the ACL information and minimizes conflicts between expected and actual effective permissions.
OneFS creates a heterogeneous environment with four primary types of network access to files. These access types also apply to directories and other securable system objects:
When a UNIX user requests a file protected with POSIX mode bits over NFS, OneFS controls access by using the file’s POSIX permissions. The process is similar when a Windows user requests a file with an ACL: The rights in the user’s access token are evaluated against the file’s ACL under the Windows security model.
When a Windows user attempts to access a UNIX file, a problem occurs because the permissions set with POSIX-mode bits are incompatible with the Windows security model. Similarly, when a UNIX user requests access to a Windows file, the permissions set with an ACL do not work with the UNIX security model.
Because the two models are different and because the Windows model has a richer set of rights, there is no one-to-one mapping between the two types of permissions. As a result, a file’s security could be compromised, or a user who expects to gain access to a file could be denied access.
More information on running a PowerScale storage cluster in multi-protocol mode is provided in the Dell EMC PowerScale OneFS: Authentication, Identity Management, and Authorization white paper.
Creating home directories in Active Directory
A PowerScale storage cluster that functions as a Windows file server in an AD forest supports the same method of home directory creation and end-user association as any other Windows file server.
Since the /ifs/home directory is already present on the cluster, creating an SMB share that presents the /ifs/home directory to SMB clients as a shared folder can be accomplished via any of the tools mentioned in Shared-folder permissions above. Once this folder has been shared, home directories can be automatically populated as subdirectories of the /ifs/home directory using standard AD methods: PowerShell scripts, batch-mode scripts, or Active Directory Users and Computers (ADUC) using the ‘Profiles’ tab and the %username% variable. Home directory redirection in Active Directory.
Organizations with end-user home directories on a PowerScale storage cluster can use Group Policy Object (GPO) redirection of the default end-user “My Documents” directory from the local Windows client to their PowerScale-based home directory. This redirection facilitates centralized user-document storage and end-user portability across multiple Windows devices.
Home directory default and custom permissions
If the %username% variable is used in ADUC, the corresponding directories will be created automatically on the PowerScale storage cluster under the designated home directory share, as with any Windows server. While AD will automatically set the home directory permissions to grant Full Control access to the corresponding user account for that directory, it will also propagate the file-level permissions from the parent directory into the newly-created home directory.
In addition to the features and integrated security settings enabled by Active Directory, a PowerScale storage cluster can be configured to authenticate users and groups against a Lightweight Directory Access Protocol (LDAP) repository to grant or block access to data stored on the cluster.
The LDAP service of a PowerScale storage cluster supports the following features:
Configuring and enabling LDAP integration
On a PowerScale cluster, the necessary LDAP settings, including the cluster’s base distinguished name (base DN), port number, and at least one LDAP server, must be configured on the cluster in order to enable LDAP.
LDAP configuration
The base DN, also referred to as the search base, identifies the record in the directory from which searches initiated by LDAP clients occur. Base DNS may include a common name (cn), locality (l), domain controller (dc), organizational unit (ou), or other components.
Enabling and disabling LDAP integration
Once the LDAP configuration options have been set in OneFS, the LDAP service is automatically enabled. It can be disabled at any time, either explicitly, or by removing all servers and the base DN from the LDAP configuration settings page. Removing these entries will automatically disable the LDAP service.
Creating home directories for LDAP users
As with Active Directory integration, home-directory creation can be created manually, or scripted and provisioned automatically, and mounted via either SMB or NFS protocol connection.
The following guidelines are included and recommended within this paper to satisfy common availability, performance, and security requirements:
This section contains overall recommendations for optimizing directory security and management simplicity.