The VAST Cluster NFSv4.1 implementation now includes support for Kerberos authentication, in which the client uses the RPCSEC_GSS authentication service. The service provides cryptographic proof of the user's identity in each RPC request. The Kerberos integrity checking and privacy services are not supported in this release.
The following configurations are required on the cluster to enable NFSv4.1 clients to authenticate using Kerberos:
For the complete procedure for cluster-side configuration of access for NFSv4.1 clients, including Kerberos authentication, see Enabling NFSv4.1 Access.
Kerberos support is enabled automatically on the cluster once the cluster is joined to an Active Directory domain. This must be the same domain to which client hosts are connected.
Additionally, since NFSv4.1 client mounts must specify the cluster using a DNS name, it might be necessary to add Service Principal Names to Active Directory. This is only needed to enable additional DNS names to be used beside <machine account name>.<AD domain name>, where machine account name is the machine account name defined for the cluster in the AD configuration and AD domain name is the name of the AD domain.
If there are additional DNS names beside <machine account name>.<AD domain name>, for which a DNS service is configured to forward requests to any VIP pools in the cluster, then, in order to enable clients to use those DNS names, you need to add HOST SPN attributes for these DNS names to the cluster's machine account in the Active Directory domain. For information about how DNS forwarding of DNS names to VIP pools may be configured, see DNS-Based VIP Distribution.
Add two entries per DNS name to the SPN attributes with the values
HOST/<short DNS name> where <FQDN> is the FQDN and <short DNS name> is the short DNS name of the same FQDN.
To add host SPNs to Active Directory:
Locate the cluster's machine account object in the Active Directory domain.
Open the machine account object's properties. This is usually done by right-clicking the object and selecting Properties.
In the properties, edit the servicePrincipalName attribute. This is usually found in the Attribute Editor tab where you can click the attribute to edit it in the Multi-valued String Editor.
Add one entry per DNS name with the value
HOST/<FQDN>where <FQDN > is the FQDN of the cluster and another entry with the value
HOST/<short DNS name>in which <short DNS name> is the short DNS name component of the FQDN.
For example, supposing you have configured your DNS server to map the cluster's VIPs to cluster.domain.com, then you will add two entries:
Click OK in the editor and the properties dialogs as needed to save the entries.
Server-side configuration of ID mapping must be done correctly on the cluster to ensure successful NFSv4.1 Kerberos IO.
The view policy controls which NFSv4.1 client security modes to allow to access any views that use the view policy.
This is controlled using the Minimal Protection Level view policy setting which can be set to any of the following:
Kerberos Auth-only. Allows client mounts with Kerberos authentication only.
System. Allows client mounts using either the AUTH_SYS RCP security flavor (the traditional default NFS authentication scheme) or Kerberos authentication.
None. Allows client mounts with the AUTH_NONE (anonymous access), or AUTH_SYS RCP security flavors, or with Kerberos authentication.
To modify this setting in a view policy, see Modifying View Policies.
To modify a view (which includes selecting a view policy), see Modifying Views.
The following requirements apply when configuring the Kerberos authentication service for use with VAST Cluster:
The rpc.gssd authentication service must be running on the client.
This service requires NFS ID mapping which must be correctly configured to ensure successful NFSv4.1 Kerberos IO.
The client must be joined to the same Active Directory domain as the cluster.
The keytab file that should be used by the rpc.gssd service when mounting, must be generated and referenced correctly in the configuration of the rpc.gssd authentication service.
The client must be using the Active Directory server as the DNS server.
Each client user must have a user account on the Active Directory domain.
When specifying the mount device, the client mount command must specify a DNS name that resolves to one of the cluster's VIP pools configured for client access, rather than specifying one of the VIPs in the VIP pool.
For example, supposing the view being mounted is on the path /volume1 and the DNS name that resolves to the relevant VIP pool is domain1.cluster.mycorp.com, then the following should be specified as the device: domain1.cluster.mycorp.com:/volume1 . Whereas supposing the VIP pool includes the IP 184.108.40.206, a client mount to 220.127.116.11:/volume1 would not be able to send a request to the cluster with Kerberos authentication.
In the client mount, set security mode to Kerberos authentication using sec=krb5.
The krb5i and krb5p security options are not supported.
For example, suppose:
The DNS name for VIP pool poolA is poolA.cluster1.ourcorporation.com,
A view on the cluster enabled for NFSv4.1 is created on the path /engineering,
The desired mount point is local directory /mnt/vast-engineering,
An NFSv4.1 mount command specifying Kerberos authentication could be:
# mount -t nfs -o vers=4.1,sec=krb5 poolA.cluster1.ourcorporation.com:/engineering /mnt/vast-engineering
In the above example, the NFS version is specified by vers=4.1. If you do not specify the NFS version, then the client tries version 4.2 first and negotiates down until it finds a version supported by the server. Since NFSv4.1 is the latest version of NFS supported by VAST Cluster, specifying the version is optional for NFSv4.1 mounts.
Client users need to obtain a Kerberos ticket in order to access data via the mounted view. This can be done by the user using the
kinit program or it can be done transparently to the user, using a program that logs into the Kerberos Key Distribution Center (KDC).