Print Email PDF

Using Active Directory for POSIX Attributes in Qumulo Core

This article explains how to use AD for POSIX attributes in Qumulo Core for environments with multi-protocol access (NFS and SMB) that manage POSIX and Windows identities within Active Directory


  • Cluster running Qumulo Core
  • Active Directory

NOTE: Any clusters already joined to a Active Directory domain will need to leave the domain and re-join.


SMB and NFS live in separate identity domains. A file written in a linux environment may be unaccessible on a Windows machine since the storage cannot determine the person trying to access the file. Both protocols have unique identifiers and the system has no way to link them together when they represent the same identity.

Several solutions have been devised to solve this problem. A common solution is to map the two identities--POSIX identities for NFS clients and Windows identities for SMB clients--using Active Directory as the single source of truth. This standard is specified in RFC2307.

This feature enables Qumulo Core to respect POSIX-to-Windows identity mappings when those mappings are maintained in the customer’s Active Directory.

  • User object in Active Directory: SID or “objectSid” assigned to every object in Windows
  • Attributes tab: AD administrators enter the NFS UID of the user, thereby mapping one identity (the user’s Windows SID) to the other (that same person’s NFS UID).

If you have mapped this inside your AD server and this feature is enabled, Qumulo Core will see that NFS UID 2053 is the same person as SID S-1-5-21-..... in Windows.

Whenever that user’s identity is required (i.e. to check permissions), Qumulo Core will use the mapping to retrieve the entire identity of that user referencing the NFS UIDs and GIDs and all the SIDs, including the group IDs of all relevant parent groups.

It’s worth noting that this method of full credential expansion also allows customers who use this feature to support more than 16 group memberships for their NFS users as long as their group membership is configured in Active Directory.

Enable via the Web UI

  • Login to the Web UI
  • Hover over Cluster and click Active Directory


  • When joining a domain, select Yes on Use Active Directory for POSIX Attributes


  • Input a Base DN (optional) to limit the part of an Active Directory tree that Qumulo Core queries

Once the cluster is joined to Active Directory, all sessions (SMB) or operations (NFS) will result in a full credential expansion for each user. So when NFS UID 2053 tries to access a file, the cluster will first query the AD server to find all the groups that user belongs to, map that user and groups to all the Windows SIDs, and then apply permissions based on that fully expanded credential set. So in the example above, Qumulo Core would know that SID 1-5-21-... is the same person as NFS UID 2053.

Control via the API

To turn the feature on and off, use the fields “use_ad_posix_attributes” and “base_dn” under the Active Directory endpoints:

  • Get Configuration and Status - /v1/ad/status
  • Get Operation Status - /v1/ad/monitor
  • Join Active Directory - /v1/ad/join

To translate identities in one domain to identities in another domain (POSIX, Windows, Qumulo local), use the following endpoints:

Under the Active Directory section

  • UID to SIDs - /v1/ad/uids/:uid:/sids (Note: this is UID to plural SIDs because one UID could be mapped to multiple SIDs. We saw this with a customer during our pre-release testing)
  • SID to UID - /v1/ad/uids/:sid:/uid
  • SID to GID - /v1/ad/uids/:uid:/gid
  • GID to SIDs - /v1/ad/uids/:gid:/sids
  • SID to Expanded Group SIDs - /v1/ad/uids/:gid:/sids

Under the Auth section

  • Get Related Auth IDs - /v1/auth/auth-ids/:id:/related-identities
  • POSIX UID to All Related Identities - /v1/auth/posix-uids/:id:/related-identities
  • POSIX GID to All Related Identities - /v1/auth/posix-gids/:id:/related-identities
  • Windows NT SID to All Related Identities - /v1/auth/sids/:id:/related-identities
  • Local Username to All Related Identities - /v1/auth/local-username/:username:/related-identities
Was this article helpful?
1 out of 1 found this helpful



Please sign in to leave a comment.

Have more questions?
Open a Case
Share it, if you like it.