Identity Mapping

The credentials used by Unix-based systems are based on User Identifiers (UIDs) and Group Indentifiers (GIDs). These integers that uniquely identify an account holder and the groups they belong to. Username/UID and Groupname/GID mappings exists either in flat files such as /etc/passwd and /etc/group or a directory service such as NIS or LDAP.
On the other hand, credentials used by Windows systems are based on Security Identifiers (SIDs). The following is an example SID:

S-1-5-21-372942913-2183038205-7263820342-8-1077

Where the first 1 is the SID revision level, the 5 component is the authority value, the 21-372942913-2183038205-7263820342 component identifies the local computer or domain, and the 1077 is the Relative ID that is unique to a User or Group within the domain.

Note: The number of values in this component may vary but typically there are four.

Since UIDs/GIDs and SIDs have different structures, in a heterogeneous environment, a mapping is required so that non-Windows systems can operate on UIDs and GIDs and Windows systems can operate on ACLs; this is referred to as Identity Mapping.

A common way to establish this mapping is to use an Active Directory server with RFC2307 extensions. In this setup, the AD database contains both a SID and a UID for a given user. When a Windows system needs access to the UID for a user, it performs a simple Active Directory query to retrieve it based on the SID. Similarly, if a Unix system needs to retrieve the SID, it can do so by performing an Active Directory query to retrieve it based on the UID. A similar process is used for mapping GID to/from SIDs. RFC2307 ID mapping is supported by all platforms.

When using the ACL security model, the use of RFC2307 requires that all systems bind to Active Directory. For Linux and Unix systems this requires the use of Winbind. This also requires setting the StorNext file system configuration global UnixIdMapping=winbind.

Linux StorNext appliances licensed for the NAS feature can be bound to Active Directory by running the following command in the NAS API:

x86_64:myhost> auth config ads administrator domaincontroller.mycompany.com mycompany.com rfc2307

If the SID for the logged in user does not have a UID configured in Active Directory, a newly created file will receive a UID equal to the value of the file system configuration setting UnixNobodyUidOnWindows. If the SID for the logged in user does not have a GID configured in Active Directory, a newly created file will receive a GID equal to the value of the file system configuration setting UnixNobodyGidOnWindows.

The UNIX modes are controlled by the following file system configuration parameters:

StorNext allows one set of values for all users of each file system.

Note: The value of the file’s Winodws read-only attribute does not affect the file’s Unix mode.

For Active Directory environments that do not require ACLs on Linux and Unix systems, but do require them for Mac and Windows clients, another form of Identity Mapping can be used called Unix ID Fabrication. In this configuration, the UID for an account is derived by extracting the first four bytes of the objectGUID in the Active Directory account record. To enable this behavior, Mac systems must bind to Active Directory using this form of ID mapping, the StorNext Security Model must be set to “legacy”, and the StorNext file system configuration global UnixIdFabricationOnWindows must be set to true.

For environments using Open Directory that do not have Windows systems but where the use of ACLs on Macs and Linux systems is required, a different form of ID Mapping is required. In this case, StorNext must be configured so the SID for a user can be derived using an algorithmic approach. The Security Model for this configuration should be set to acl and unixIdMapping should be set to algorithmic. In addition, a file named /usr/cvfs/config/domainsid must be populated on the MDC. This file needs to contain the domain SID being used by the Open Directory domain. This value can be determined by running a command on a Mac. For more information, refer to the domainsid(5) man-page.

When ACLs are used in pure Linux/Unix environments, SIDs can be synthesized using a simple algorithmic approach. In this case, the Security Model should be set to acl and the unixIdMapping should be set to algorithmic. The generated SIDs will then use the StorNext built-in domain SID, S-1-5-21-3274805877-1740924817-4269325941.

Finally, when using the unixpermbits security model, the windowsIdMapping variable controls the type of identity mapping performed by Windows clients.

There are 3 options:

  1. Ldap: Windows clients map SIDs to UIDs and GIDs using LDAP queries to the Active Directory server. In this case, the Active Directory server must be set up with RFC2307 extensions with the Unix UIDs and GIDs populated.
  2. MDC: Windows clients map user names to UIDs and GIDs by making remote procedure calls to the StorNext MDC. For this to work, the MDCs must have user account names that exactly match the ones used by Windows. For example, if a Windows user name is “lynn”, there must be a Unix account name on the MDC also named “lynn” whose name can only vary by case.
  3. None: All users map to the user “NOBODY”