Workflow for Enabling Client Protocol Access

To enable client users to access and write data to the cluster using any supported combination of access protocols, follow all steps described below for the cluster-side configuration:

For client-side configurations and usage of specific features, see the protocol-specific sections:

Kerberos authentication is used to authenticate all SMB client connections to the cluster. Similarly, Kerberos authentication is supported and typically used for NFSv4.1 client connections to the cluster.

When clients use Kerberos authentication, the mount request must specify the cluster using a DNS name rather than an IP address.

In order for the Kerberos protocol to be able to access the cluster and authenticate the NFSv4.1 or SMB service, the cluster's machine object in Active Directory must be configured with NFS/ and HOST/ type Service Principal Name (SPN) attributes (respectively for NFSv4.1 and SMB) for each FQDN that resolves to the IPs configured to provide network access to the cluster.

The default configuration enables clients to mount views specifying the cluster by the specific DNS name <cluster_machine_account_name>.<Active Directory domain name>, provided that this DNS name resolves to VIPs on the cluster. In the event that you are not using the VAST DNS service and your DNS server delegates requests for the above DNS name to all VIPs, you don't need to add any SPNs.

Assuming the VAST Cluster DNS service is enabled, you need to add SPN attributes to the machine account in Active Directory for the DNS service domain names that are configured for the VIP pools.

Add the following:

In which:

For example, supposing you have the following configuration:

In this case, in order to enable clients to mount views using NFSv4.1 with Kerberos, you'll need to add the following SPN attributes to the cluster's machine account in Active Directory:

One way to add SPNs to an Active Directory domain is to use the Active Directory Users and Computers MMC:

In order for users to be authorized correctly, they must have the correct attributes defined on the provider:

Users' memberships of any additional groups besides their default group should be defined in the provider.

For users to be able to access the cluster by NFSv3 or NFSv4.1, user entries must have the following attributes on an external provider domain:

Similarly, each group entry should have a gidNumber entry, to define the NFS group ID of the group.

One way you can update Active Directory user and group entries is via the Microsoft Management Console (MMC):

A user entry will automatically have a SID (Security Identifier), which is a unique identifier that Active Directory uses to identify objects as security principal.

Group memberships can be marked either by a member entry in each group that contains the user or by a memberOf entry in the user entry for each group that contains the user. This is known as "nested groups".

There is no need to add special attributes to providers for S3 users, since they are authorized via their access key pairs which must be issued via VMS. For a user to be matched to user entries on external providers, the access key pair needs to be generated by first querying providers for the user name and then issuing the key pair, as explained here. Once that is done, the user will be matched correctly to file permissions set by any protocol. S3 ACLs can specify users as <username>@<domain> or by a VAST ID as explained here. The user name should match the user name for the relevant user entry on the providers.

Follow these guidelines to set up a database owner user.

Create or modify the view policies you will need for the protocols you wish to use concurrently on a view. See Creating View Policies.

Views enable access to specific paths for specified protocols or combinations. See Creating Views.