IN THIS ARTICLE
Qumulo Core 5.0.5 (and higher) provides compatibility between third-party storage vendor POSIX placeholder SIDs and Qumulo POSIX SIDs. This article explains how SID equivalence works in Qumulo Core, how POSIX UIDs and GIDs map to SIDs, and how you can verify the expanded identities of POSIX SIDs by using the qq
CLI.
HOW SID EQUIVALENCE WORKS IN QUMULO CORE 5.0.5 (AND HIGHER)
During data migration from third-party servers to Qumulo, it is often necessary to use the SMB protocol to move data, primarily to preserve the more complex NTFS permission access-control lists (ACLs) that can't be transported over the NFSv3 protocol.
This scenario often applies to environments where multi-protocol access exists and the application of POSIX- and NTFS-style permissions is mixed in a way that requires a single protocol for handing both permission types. In such environments, many POSIX identities can belong to users that don't have direct mappings to NTFS identities. During the data migration process, this causes the source server to present this data over the SMB protocol by using the S-1-22-*
SID.
In Qumulo Core 5.0.4 (and lower), the file system has no direct relationship between Qumulo's S-1-55-8-*
SIDs and SIDs named S-1-22-*
or S-1-5-22-*
. This occasionally creates orphan SIDs, unmappable identities that require remapping to Qumulo-compatible values following data migration. The process of detecting and remapping of orphan SIDs requires the use of specialized, third-party tools, can be lengthy during data migrations with high file counts, and can add time to data cutover to a new Qumulo cluster.
Qumulo Core 5.0.5 (and higher) considers specific, third-party storage vendor POSIX placeholder SIDs to be equivalent to Qumulo POSIX SIDs, requiring no additional detection or remapping.
HOW POSIX UIDs AND GIDs MAP TO SIDs
When you create a file over the NFSv3 protocol, the file system writes the user ID (UID) and group ID (GID) for the current user to the file's metadata as the owner and group owner for the file.
In the following example, we assign UID 2000
to the user jane
and GID 20
to the Primary Group staff
.
-rw-r--r-- 1 2000 20 12325590 Apr 2 19:56 jane_file.txt
For a file server to be able to present this user and group information to a client that accesses this file over SMB, we must map these POSIX identities to a SID.
Notes:
- To simplify the mapping of NFS entities to SMB entities, Qumulo maps POSIX identities to SIDs by using queries for RFC2307 values to Active Directory. For more information, see Use Active Directory for POSIX Attributes.
- If a mapping of a POSIX ID to a SID through a directory service doesn't exist, the SMB server that presents the data must map the POSIX value to a placeholder POSIX identity SID.
In Qumulo Core, the prefix of a UID-to-SID mapping is S-1-5-88-1-
, followed by the UID and the prefix of a GID-to-SID mapping is S-1-5-88-2-
, followed by the GID. For the example user jane
, Qumulo Core creates the following mappings:
- UID
2000
to SIDS-1-5-88-1-2000
- GID
20
to SIDS-1-5-88-2-20
Certain third-party storage systems use the following placeholder SIDs:
- UID
S-1-22-1-
S-1-5-22-1-
- GID
S-1-22-2-
S-1-5-22-2-
These values often show up as the placeholder SIDs of local users, such as the administrative account of third-party storage or any other locally created user account.
VERIFYING EXPANDED IDENTITIES IN QUMULO CORE
You can verify the expanded identities of POSIX SIDs by using the qq auth_expand_identity
CLI command. The following examples show two expanded identities.
UID 2000 without an RFC2307 Equivalent in Active Directory
qq auth_expand_identity --sid "S-1-5-22-1-2000" Identity: S-1-5-22-1-2000 Type: User NFS Mapping: uid:2000 SMB Mapping: S-1-5-22-1-2000 Equivalent Identities: uid:2000
UID 2000 with an Equivalent SID in Active Directory
qq auth_expand_identity --sid "S-1-5-22-1-2000" Identity: S-1-5-22-1-2000 Type: User NFS Mapping: uid:2000 SMB Mapping: S-1-5-22-1-2000 Equivalent Identities: uid:2000 DOMAIN\jane S-1-5-21-12345678-12345678-12345678-1234
Comments
0 comments