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.
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 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-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.
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.
-
New and expired users are retrieved through the following series of queries.
-
The primary provider for the access protocol is queried for the user attribute declared in the request:
-
If the request is sent via NFSv3, 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 request is sent via NFSv4.1 and the cluster is joined to Active Directory, then Active Directory is queried for the user attribute that is declared, which is the UID number, if ID mapping is disabled, or the user name, if ID mapping is enabled.
-
-
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.
-
Users are merged if their match user attributes match. The match user attribute is configurable in that you can set which attribute on the POSIX primary provider is used to match the users.
-
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.
Comments
0 comments
Article is closed for comments.