Note
The flow described below does not include the selection of a tenant, which can depend on the client IP and/or the requested VIP. For information about tenant selection, see Overview of Tenants.
VAST Cluster stores user and group attributes in the cluster's internal user database which supports multiple authorization providers and attribute types. Client user access requests are authorized as follows:
VAST Cluster queries the cluster's user database for the user attribute declared in the request, which may be any of the following:
The NFS UID number in NFSv3 RPCs or in NFSv4.1 RPCs if ID mapping is not enabled on the client.
The user principle name in NFSv4.1 RPCs where ID mapping is enabled on the client.
The user sid in SMB requests.
The user's access key in S3 requests.
Then:
If the UID, SID, user name or access key is found in the user database, the user is identified in the user database with all of its equivalent user attributes and group memberships, learned from previous provider queries.
If a declared S3 access key is not found in the cluster's user database, the request fails.
If any other declared user attribute is not found, such as for a new user previously unknown to the cluster, the auth providers are queried with the relevant user attribute and the user is added to the user database. 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.
Note
If the cluster is not joined to Active Directory, then SMB sessions cannot be created and hence, SMB requests cannot be made.
Note
User entries in the cluster's user database are refreshed at a configurable refresh interval with a similar process to the user query flow. If any of the providers is down, the expired entry remains in use until the next refresh time.
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 ⚠️ Controlling File and Directory Permissions Across Protocols 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-based authorization for NFSv4.1 requests using Kerberos authentication is done against the Active Directory domain.
Group-based authorization is otherwise done according to the group membership source setting in the view policy:
Views exposed to SMB must use authorization providers as the group membership source.
S3 requests do not declare group memberships. Views that are exposed to S3 should therefore be set to use authorization providers as the group membership source.
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.
Note
This option is not supported with NFSv4.1.
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. If the GID provided by the client does not match the GID retrieved from the authorization provider, the GID from the client is set.
Therefore:
For NFSv3 requests, if the group membership source is Client, then group-based authorization is based on the GIDs declared in the request.
For SMB requests, S3 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', the S3 group 'AllUsers', the NFS 'others' entity and the NFSv4 'EVERYONE' entity used in NFSv4.1 ACLs are considered equivalent.