To enable client users to access and write data to the cluster's Element Store using any supported combination of access protocols, follow all steps described below in order for the cluster side configuration:
For client side configurations and usage of specific features, see the protocol-specific sections:
If not yet configured, you will need to configure VIP Pools. VIP pools provide interfaces that can be used to access the cluster by client protocols.
You should also configure DNS forwarding to the VIP pools. It's recommended to use the VAST Cluster DNS Service. See DNS-Based VIP Distribution.
For all details relating to VIP Pool and DNS Service configuration, see Configuring Network Access.
Configure authorization/authentication providers.
Read about multiple provider support and client protocol combinations, and how to connect to each provider here: Connecting to Authorization Providers.
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.
Note
In the event that you choose to enable NFSv4.1 client access without Kerberos authentication, client mount requests can specify a VIP (an IP address), provided they do not mount with Kerberos.
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 (VIPs).
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:
VIP Pool Domain Name is the domain name value set in each VIP pool.
DNS Service Suffix is the domain suffix configured in the DNS Service configuration.
For example, supposing you have the following configuration:
One delegation rule on your central DNS server forwarding all requests for cluster.mycorp.com to the VAST DNS server.
The DNS Service enabled with DNS Service Suffix set to cluster.mycorp.com.
-
Three VIP pools with VIP Pool domain names:
VIP pool
VIP Pool Domain Name
vippool1
domain1
vippool2
domain2
vippool3
domain3
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:
NFS/domain1.cluster.mycorp.com
NFS/domain2.cluster.mycorp.com
NFS/domain3.cluster.mycorp.com
One way to add SPNs to an Active Directory domain is to use the Active Directory Users and Computers MMC:
On the Active Directory server machine, open the Active Directory Users and Computers MMC.
Under View, select Advanced Features.
Select Computers and in the left pane, locate the cluster's machine account object.
Right-click the object and select Properties.
Select the Attribute Editor tab and edit the servicePrincipalName attribute.
Add the entries.
Click OK in the editor and the properties dialogs as needed to save the entries.
In order for users to be authorized correctly, they must have the correct attributes defined on the provider:
Users' memberships of any additional groups beside 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:
uidNumber, defining the user's NFS user ID as used by Linux/UNIX.
gidNumber, defining the user's default (leading) NFS group ID as used by Linux/UNIX.
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):
On the Active Directory server machine, open the MMC and select Active Directory Users and Computers.
From the View menu, select Advanced Features.
For each user and group object, open the object and select the Attributes Editor tab. (This editor may need to be installed.)
Verify or fill the uidNumber attribute for users and the gidNumber attribute for both users and groups.
Note
We hope the above procedure is helpful. In the event that the above procedure does not match your Microsoft operating system interface exactly, please seek the exact procedure in Microsoft's documentation.
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.
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.
Comments
0 comments
Article is closed for comments.