Overview of Share-Level ACLs
Share-level ACLs can be used to specify maximum permissions allowed to security principals (users and groups) when accessing shares. A share-level ACL consists of Access Control Entries (ACEs). Each ACE specifies a security principal and a permission. When a user matches multiple ACEs (such as if the user belongs to different groups with different permissions), the least restrictive permission applies to the user.
The permissions that can be specified in a share-level ACE are:
READ. This permission is for read operations only.
CHANGE. This permission includes READ permission and permission to change files, create files, create directories, and to delete files and directories.
Note
CHANGE does not include permission to modify file attributes or ACLs.
FULL CONTROL. This permission includes CHANGE permission and permission to change file owners and Windows ACLs.
VAST Cluster supports share-level ACLs for SMB access. Share-level ACLs can be enabled and configured on each view. If there is a share-level ACL on a view, then, in order for a user to be able to access any file or directory on the cluster via SMB, the user needs to be granted access from the share-level ACL as well as from the file-system permissions. Share-level ACLs do not affect access for protocols other than SMB.
The default share-level permission configuration is:
Share-level ACL is disabled on each view.
The 'everyone' group has 'full control' share-level permission.
You can configure share-level ACL as follows:
You can change the default 'Everyone' Group share-level permission per tenant. This default permission affects all views associated with the tenant where share-level ACL is disabled. The permission can be set to read, change or full.
You can enable share-level ACL on any SMB-enabled view. Enabling share-level ACL disables the 'Everyone' Group share-level permission on the specific view. In this case, all attempts to access the view's share via SMB will fail except where an ACE is found in the share-level ACL that grants access to the requesting user (and the user has the required file/directory permission).
You can configure up to 200 ACEs in a view's share-level ACL.
Changes to share-level ACL impact all currently logged-in users, with a two minute caching delay in applying the changes to those users.
Using Well-Known SIDs in Share-Level ACLs
These well-known SIDs are supported in share-level ACLs:
Replicator
Remote Desktop Users
Network Configuration Operators
Administrators
Domain Controllers
Allowed RODC Password Replication Group
Denied RODC Password Replication Group
Read-only Domain Controllers
Enterprise Read-only Domain Controllers
Cloneable Domain Controllers
Print Operators
Certificate Service DCOM Access
RDS Remote Access Servers
RDS Endpoint Servers
RDS Management Servers
Storage Replica Administrators
Server Operators
Account Operators
Pre-Windows 2000 Compatible Access
Incoming Forest Trust Builders
Windows Authorization Access Group
Terminal Server License Servers
Key Admins Enterprise
Key Admins
DnsAdmins
DnsUpdateProxy
Backup Operators
Domain Computers
Schema Admins
Enterprise Admins
Cert Publishers
Domain Admins
Domain Guests
Group Policy Creator Owners
RAS and IAS Servers
Modifying the Default 'Everyone' Group Share-Level Permission
Modifying Default Share-Level Permission in VAST Web UI
From the left navigation menu, select Settings and then Tenants.
From the Actions menu for the relevant tenant (this would be the default tenant if you are not deploying multiple tenants), select Edit.
From the Default share-level ACL for others dropdown, select a permission type:
Full Control (default). Grants all SMB users full control share-level access to views that have Share-level ACL disabled.
Change. Grants all SMB users change share-level access to views that have Share-level ACL disabled.
Read. Grants all SMB users read share-level access to views that have Share-level ACL disabled.
Click Save to save your changes.
Modifying Default Share-Level Permission in VAST CLI
To change the default share-level permission for the cluster, run the cluster modify command with the --default-others-share-level-perm parameter and set the parameter to FULL, READ or CHANGE. For example:
vcli: admin> cluster modify --default-others-share-level-perm READTo change the default share-level permission for a tenant, run the tenant modify command with the --default-others-share-level-perm parameter and set the parameter to FULL, READ or CHANGE.
Managing Share-Level ACLs
Share-level ACLs are configured per view.
Managing Share-level ACLs in VAST Web UI
To enable and/or configure share-level ACL when you create a view, see Creating Views.
To disable share-level ACL on a view, or to add, remove and change ACEs in a share-level ACL, see Modifying Views.
Managing Share-level ACLs in VAST CLI
A view must be created before share-level ACL can be enabled and share-level ACEs can configured via CLI.
Once the view is created (which can be done via CLI using view create), you can configure and manage share-level ACL as follows:
To enable share-level ACL, run the view modify command with the
--enable-share-aclparameter.To disable share-level ACL if enabled, run the view modify command with the
--disable-share-aclparameter.To add an ACE to a share-level ACL in a given view:
Run a query by prefix against the Active Directory domain to get an identifier for the grantee. For a user, use the user query-by-prefix command. For a group, use the group query-by-prefix command. For a user, the identifier can be a SID or UID. For a group, the identifier can be a SID or a GID.
For example:
vcli: admin> user query-by-prefix --fqdn ad.arandomorg.com --prefix com +-------+-------------------+-----------------+----------------------------------------------+ | Name | FQDN | Identifier type | Identifier | +-------+-------------------+-----------------+----------------------------------------------+ | comet | ad.arandomorg.com | sid_str | S-x-x-xx-xxxxxxxxx-xxxxxxxxxx-xxxxxxxx-xxxxx | +-------+-------------------+-----------------+----------------------------------------------+Note the identifier type and the identifier in the query output, and then run the view modify command with the following parameters:
--share-ace-grantee users|groupsto specify grantee type.--share-ace-identifier <IDENTIFIER>to specify an identifier attribute for the grantee.--share-ace-permissions READ|CHANGE|FULLto specify what type of permission to grant.
Using the output in the above example, the following command would add an ACE for the queried user:
vcli: admin> view modify --id 101 --share-ace-grantee users --share-ace-identifier S-x-x-xx-xxxxxxxxx-xxxxxxxxxx-xxxxxxxx-xxxxx --share-ace-permissions FULL
To clear all ACEs from a share-level ACL in a given view: run the view modify command with the
--clear-share-aclparameter.vcli: admin> view modify --id 101 --clear-share-aclTo remove an ACE, run view modify with the
--remove-share-ace-nameoption, specifying the grantee name and the--remove-share-ace-fqdnoption, specifying an FQDN.To remove the ACE added in the above example, we provide the user's name and the domain:
vcli: admin> view modify --id 101 --remove-share-ace-name comet --remove-share-ace-fqdn ad.arandomorg.com