Home > Storage > PowerScale (Isilon) > Product Documentation > Protocols > Dell PowerScale: Solution Design and Considerations for SMB Environments > Multi-protocol access
To provide multi-protocol access, access tokens are generated through the following steps:
The following sections focus on the considerations and common practices of step 2 through 4 and at the end will discuss some options in ACL policy settings.
The ID mapping service’s role is designed to map Windows SIDs to UNIX UIDs and GIDs and vice versa in order to associate a user’s identity across different directory services.
The followings are some considerations and recommendations for ID mapping:
Use Active Directory with RFC 2307
Use Microsoft Active Directory with RFC 2307 attributes to manage Linux, UNIX, and Windows systems and make sure your domain controllers are running Windows Server 2003R2 or later. Integrating UNIX and Linux systems with Active Directory centralizes identity management and eases interoperability.
If you use Microsoft Active Directory with RFC 2307 attributes to manage Linux, UNIX, and Windows systems, the following fields are required in Active Directory:
For the detailed configuration steps, see OneFS: How to configure OneFS and Active Directory for RFC2307 compliance.
Do not use overlapping ID ranges
In networks with multiple identity sources, such as LDAP and Active Directory with RFC 2307 attributes, you should ensure that UID and GID ranges do not overlap. It is also important that the range from which OneFS automatically allocates UIDs and GIDs does not overlap with any other ID range. OneFS automatically allocates UIDs and GIDs from the range 1,000,000-2,000,000 which is configurable. If UIDs and GIDs overlap multiple directory services, some users might gain access to other users’ directories and files. A typical scenario is when LDAP provides extended AD attributes with a 1000,000+ UID or GID, and this overlap with the one generated on OneFS.
See ID mapping ranges for more information about how to configure ID ranges.
Avoid common UIDs and GIDs
Do not include commonly used UIDs and GIDs in your ID ranges. For example, UIDs and GIDs below 1,000 are reserved for system accounts; do not assign them to users or groups.
The user mapping service combines access tokens from different directory services into a single token. When the names of an account in different directory services match exactly, OneFS automatically combines their access tokens into a single token. On the other hand, you can set rule to modify the user mapping behavior.
You can also test the user mapping rule. For more details, see Test a user-mapping rule.
The followings are some considerations and recommendations for user mapping:
Employ a consistent username strategy
In an environment with two or more identity management systems, the simplest configuration is naming users consistently, so that each UNIX user corresponds to a similarly named Windows user. Before assigning a UID and GID, OneFS searches its other authentication providers, such as LDAP, for other identities with the same name. If OneFS finds a match, the mapping service by default selects the associated UID and group memberships. Naming users consistently also allows user mapping rules with wildcards to match names and map them without explicitly specifying each pair of accounts.
Avoid using UPNs in mapping rules
You cannot use a User Principal Name (UPN) in a user mapping rule. A UPN is an Active Directory domain and username that are combined into an Internet-style name with an @ symbol, such as an email address: jane@example. If you include a UPN in a rule, the mapping service ignores it and may return an error. Instead, specify names in the format DOMAIN\user.com.
Native on-disk identity
The native identity option is likely to be the best for a network with UNIX and Windows systems and this is the default setting. In native mode, OneFS favors setting the UID as the on-disk identity because doing so improves NFS performance. OneFS stores only one type of identifier—either a UID and a GID or a SID—on disk at a time. As a common practice, if you change the on-disk identity, you should run the repair permissions job; see the OneFS Administration Guide.
See PowerScale Multiprotocol Data Access with a Unified Security Model for details of on-disk identity.
A PowerScale cluster includes ACL policies that control how permissions are processed and managed. In the following section, we will explore several options to manage ACL policy manually in the environment.
ACL policies for different environment
For UNIX, Windows, or mixed (Windows + UNIX) environments, optimal permission policy settings are already selected. It is recommended that one of these pre-defined environment templates be used for most workflows. In some cases, one or more of the policy settings might need to be modified. Any modification to the default policy settings will automatically create a Custom environment ACL policy.
You can choose to manually configure ACL policies by selecting Custom environment. The following sections discuss the options in detail.
Chmod command on files with existing ACLs
There are six policy options to configure how OneFS processes a chmod command run on a file with an ACL. The option to merge the new permissions with the ACL is the recommended and defaulted approach because it best balances the preservation of security with the expectations of users. However, you can choose to manually configure this option if necessary to support your particular environment.
Table 3 lists the consideration for all the six options you can choose.
Table 3. Options for configuring how OneFS processes chmod
Settings | Consideration |
Merge the new permissions with the existing ACL | This is the default and recommended option. |
Remove the existing ACL and set UNIX permissions instead | This option can cause information from ACLs, such as the right to write a DACL to a file, to be lost, resulting in a behavior that gives precedence to the last person who changed the mode of a file. As a result, the expectations of other users might go unfulfilled. Moreover, in an environment governed by compliance regulations, you could forfeit the rich information in the ACL, such as access control entries for allowing or denying access to specific groups, resulting in settings that might violate your compliance thresholds. |
Remove the existing ACL and create an ACL equivalent to the UNIX permissions | This option can have the same effect as removing the ACL and setting UNIX permissions instead: Important security information that is stored in the original ACL can be lost, potentially leading to security or compliance violations. |
Remove the existing ACL and create an ACL equivalent to the UNIX permissions for all the users and groups referenced in the old ACL | This option improves matters over the first two settings because it preserves the access of all the groups and users who were listed in the ACL. |
Deny permission to modify the ACL | This option can result in unexpected behavior for users who are owners of the file and expect to be able to change its permissions. |
Ignore the operation if file has an existing ACL | This is very similar to the previous setting which results inability to change the permission through chmod. Select this option if you defined an inheritable ACL on a directory and want to use that ACL for permissions. |
This setting is located under ACL Policy Settings > General ACL Settings, as shown in Figure 1.
Figure 1. Use the chmod command on files with existing ACLs
Inheritance of ACLs created on directories by chmod
On Windows systems, the ACEs for directories can define detailed inheritance rules. On a UNIX system, the mode bits are not inherited. For a secure mixed environment with SMB and NFS, the recommended and default setting is Do not make ACLs inheritable.
You can find this setting under ACL Policy Settings > General ACL Settings, as shown in Figure 2.
Figure 2. ACLs created on directories by the chmod command
Chown and chgrp commands on files with existing ACLs
For a mixed environment with multiprotocol file sharing, the default option Modify the owner and/or group and ACL permissions is the recommended approach because it preserves the ACEs that explicitly allow or deny access to specific users and groups. Otherwise, a user or group who was explicitly denied access to a file or directory might be able to gain access, possibly leading to security or compliance violations.
You can find this setting under ACL Policy Settings > General ACL Settings, as shown in Figure 3.
Figure 3. Use the chown and chgrp commands on files with existing ACLs