Access permissions of files and directories are stored internally in a protocol-independent format and translated into protocol-specific permissions as required depending on a configurable choice of security flavor. For example, the owning user of a file created via NFS is set based on the UID in the file creation request but the file is also recognized as being owned by the same user when that user requests access to the file via SMB, where the request identifies the user by its SMB user SID.
Access checks are performed for all identities belonging to the user, so that the user has equal access via all protocols.
Client user access requests via NFS or SMB are authorized as follows:
The user database is queried for the UID or the user SID declared in the request, and:
If the user is not found, such as for a new user previously unknown to the cluster, the providers are queried for the UID or SID and the user is added to the UDB. The query proceeds per User Query Flow.
If no external provider is configured and no local users are configured, then an NFS request may be authorized based on the UID and GIDs in the request, depending on the group membership source set in the view policy.
If the cluster is not joined to Active Directory, then SMB sessions cannot be created and hence, SMB requests cannot be made.
If the UID or SID is found, the user is identified in the user database with all of its equivalent user attributes and group memberships, learned from previous provider queries.
For a user that was found with an expired entry in the user database, the user information is refreshed from the providers, with a similar process to the user query flow. In the event that not all providers are reachable, the expired entry is used. (If any of the providers is down, user information retrieved from other providers is ignored.)
The permissions are checked according to the relevant permissions checking algorithm and access is authorized depending on the result of this check. The algorithm that is used varies depending on which security flavor is set in the view policy applied to the specific view. See Permissions Checking is According to Security Flavor for details.
For this permission check, the following apply:
User checks (such as for the owner or named users in POSIX permission bits) are done against all the equivalent user identities so that permissions given via either protocol are recognized as applying to the same user.
Group memberships are determined according to the group membership source setting in the view policy:
All views that are exposed to SMB clients use authorization providers as the source of group memberships.
Views that are exposed to NFS and not to SMB may use a view policy which uses any of the following as a group membership source:
Client. The GIDs declared in the NFS request as the user's leading group and auxiliary groups are trusted and provider-sourced groups are not considered.
Providers. Group memberships retrieved from authorization providers are considered as the user's group memberships (as for SMB-only and multiprotocol views). The GIDs declared in the request are ignored.
Client and Providers. Both the GIDs declared in the request and group memberships retrieved from authorization providers are considered.
For NFS requests, if the group membership source is Client, then group-based authorization is based on the GIDs declared in the request.
For SMB requests and for NFS requests if the group membership source is Providers, then all group memberships associated with the user in the user database are considered.
For NFS requests, if the group membership source is Client and Providers, then both the GIDs declared in the request and all group memberships associated with the user in the user database are considered.
The SMB group 'Everyone' and the NFS 'others' entity are considered equivalent.
New and expired users are retrieved through the following series of queries:
The primary provider for the access protocol is queried for the user ID attribute declared in the request:
If the request is sent via NFS, the POSIX Primary provider is queried for the UID. The POSIX Primary provider is the provider that takes precedence for POSIX attributes. If there is only one provider, that provider is the POSIX primary provider.
If the request is sent via SMB and declares a user SID, Active Directory is queried for the SID.
If the UID or SID is found on the provider, the user name and groups associated with the UID or SID are retrieved.
Additionally, if the request was sent via SMB and therefore the first provider queried was Active Directory, then POSIX attributes are also retrieved for the user.
Similarly, if the request was sent via NFS and the POSIX Primary provider is Active Directory, and therefore the first provider queried is Active Directory, then SMB attributes are also retrieved from Active Directory for the user.
If there is a second external provider, that provider is queried for a user name that matches the user name retrieved from the first provider. If a user with the queried user name is found, attributes of that matching user are retrieved from the second provider.
When the second provider is queried, the username searched for is the value of whichever user attribute is set as the match user attribute for the first provider. By default, this is the uid attribute for AD and LDAP. For successful matches, it must be set to the attribute that stores the user name on each LDAP/AD provider. The match user attribute is set in the Advanced-attribute mappings of the LDAP configuration.
The local provider is also queried by the user name.
New UIDs, GIDs and SIDs are added to the database, and a new user entry is added. The user database keeps track of the user's association with the various attributes.
Conflicts between providers are handled per Conflict Resolution and Merging Rules
In case of conflict between local and non local providers, the local provider's attributes override those of the other providers.
In case of conflicting POSIX attributes on external providers, the POSIX primary provider overrules the other external provider.
All groups found for the user on all providers with distinct group names are treated as distinct groups to which the user belongs. Groups are merged if they match according to a non-configurable group name attribute.