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.
If you are configuring NFSv4.1 access for the first time on the cluster, follow the entire procedure at Workflow for Enabling Client Protocol Access, paying attention to the options required for NFSv4.1 and Kerberos.
If you are already have a view and view policy set up for NFSv4.1 access and you want to make changes to enable Kerberos, do the following:
Make sure the cluster is joined to Active Directory with the required user and group entries and DNS related configuration as described in Workflow for Enabling Client Protocol Access
Complete server-side configuration of ID mapping. This must be done correctly on the cluster to ensure successful NFSv4.1 Kerberos IO.
In the view policy, you may need to adjust the Minimal Protection Level setting, which controls which NFSv4.1 client security modes to allow to access any views that use the view policy. It 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.
Each Linux client needs to be configured such that the following requirements are met:
The rpc.gssd authentication service is running.
NFS ID mapping is configured to ensure successful NFSv4.1 Kerberos IO.
The client must have a machine account in 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. rpc.gssd requires a local client keytab file to establish a valid machine credential. This enables rpc.gssd to perform the mount request.
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.
We recommend the following procedure to achieve the above requirements:
The required packages vary with the Linux distribution and the configuration methods you use. The following package install commands work with the configuration method being described here:
yum install -y nfs-utils sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients nfs4-acl-tools
apt-get install nfs-common sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-bin nfs4-acl-tools krb5-user ldap-utils sssd-tools
zypper install nfs-client sssd realmd adcli samba-client krb5-client openldap2-client nfsidmap sssd-tools nfs4-acl-tools sssd-ad yast2-nfs-client
This procedure uses realmd, which is an on-demand system DBus service that enables callers to configure network authentication and domain membership. realmd discovers information about a domain or realm automatically, saving you more complicated configuration. To obtain the latest version of realmd and to read its documentation, go to https://www.freedesktop.org/software/realmd.
The realmd join operation does the following:
Discovers information about a specified Active Directory domain.
Installs the necessary software to join the domain. By default, this is System Security Services Daemon (SSSD). It can be changed to Winbind in the realmd configuration file.
If administrative credentials are required, it prompts you for a password.
Creates or updates an account in the domain for the computer.
Creates a host keytab file at /etc/krb5.keytab.
Configures the SSSD (or Winbind) services, restarts and enables them.
Enables domain users in /etc/nsswitch.conf.
To join the Active Directory domain:
realm discovercommand without any options to retrieve the Active Directory domain's Kerberos realm name:
realm discover AD_DOMAIN
For AD_DOMAIN, enter the FQDN of the Active Directory domain.
The Kerberos realm name is displayed in the output as realm-name. For example:
# realm discover labnet.vastdata.com labnet.vastdata.com type: kerberos realm-name: LABNET.VASTDATA.COM domain-name: labnet.vastdata.com configured: no server-software: active-directory client-software: sssd
realm joincommand with the following usage:
realm join AD DOMAIN --user=DOMAIN_JOIN_USER --user-principal=host/CLIENT_FQDN@KRB_REALM
The usage includes these parameters:
--user. Include this if you need to specify a user for joining the domain other than the Administrator user, which is the default user name. Supply the user name of an administrator user who has permission to join the Active Directory domain.
--user-principal. Use this parameter to set a lowercase userPrincipalName attribute for the machine account. This simplifies use of the kinit command which is used to obtain a ticket granting ticket (TGT) for the mount request or access request. By default, realmd creates uppercase principals.
CLIENT_FQDN is the host name of the local client computer with the Active Directory domain name appended. Specify this value in lowercase.
KRB_REALM is the Kerberos realm name obtained in the realm discover output.
For example, if the Linux client host name is darkstar, the Active Directory domain name is labnet.vastdata.com, the value of realm-name in the
realm discoveroutput is LABNET.VASTDATA.COM, and your Active Directory user is the Administrator user, then you would run:
realm join labnet.vastdata.com –-user-principal=host/darkstar.labnet.vastdata.com@LABNET.VASTDATA.COM
After the join operation is done, there are a various manual changes to make to the configuration files that are created and populated in the process:
Realmd populates /etc/krb5.conf, /etc/krb5.keytab and /etc/sssd/sssd.conf, however some configuration is missing or needs changing.
Open /etc/krb5.conf. This is the main Kerberos configuration file.
Add the following line to the
[libdefaults]section of the file:
With this setting enabled, initial ticket requests to the KDC will request canonicalization of the client principal name, and answers with different client principals than the requested principal will be accepted.
Verify the creation of the Kerberos keytab file. This is a file that contains pairs of Kerberos principals and encryption keys. You can verify its creation using
#klist -k -e Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 5 DARKSTAR$@LABNET.VASTDATA.COM (aes128-cts-hmac-sha1-96) 5 DARKSTAR$@LABNET.VASTDATA.COM (aes256-cts-hmac-sha1-96) 5 host/darkstar.labnet.vastdata.com@LABNET.VASTDATA.COM (aes128-cts-hmac-sha1-96) 5 host/darkstar.labnet.vastdata.com@LABNET.VASTDATA.COM (aes256-cts-hmac-sha1-96) 5 host/DARKSTAR@LABNET.VASTDATA.COM (aes128-cts-hmac-sha1-96) 5 host/DARKSTAR@LABNET.VASTDATA.COM (aes256-cts-hmac-sha1-96) 5 RestrictedKrbHost/DARKSTAR@LABNET.VASTDATA.COM (aes128-cts-hmac-sha1-96) 5 RestrictedKrbHost/DARKSTAR@LABNET.VASTDATA.COM (aes256-cts-hmac-sha1-96) 5 RestrictedKrbHost/darkstar.labnet.vastdata.com@LABNET.VASTDATA.COM (aes128-cts-hmac-sha1-96) 5 RestrictedKrbHost/darkstar.labnet.vastdata.com@LABNET.VASTDATA.COM (aes256-cts-hmac-sha1-96)
Initialize the keytab file:
# kinit -k # klist -e Ticket cache: KCM:0 Default principal: DARKSTAR$@LABNET.VASTDATA.COM Valid starting Expires Service principal 11/05/2021 09:27:45 11/05/2021 19:27:45 krbtgt/LABNET.VASTDATA.COM@LABNET.VASTDATA.COM renew until 11/12/2021 08:27:45, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
In the /etc/sssd/sssd.conf file, under the section
[domain/ad_domain](where ad_domain is your Active Directory domain) make sure you have the following setting:
Optionally, in the same
[domain/ad_domain]section of the sssd.conf file, if you would like to make all users and groups in the domain visible from the local client in the output of the
getentcommand, add the following:
enumerate = true
Depending on the number of users within Active Directory, the enumerate option can have a significant initial performance impact. Enumerations may take several minutes after SSSD’s initial start-up, during which time responsiveness could be considered slow.
Ensure that /etc/sssd/sssd.conf is owned by “root” with permissions set to owner read and write only:
# chown root:root /etc/sssd/sssd.conf # chmod 600 /etc/sssd/sssd.conf
In the /etc/idmap.conf file, under the
[General]section, add the following:
Domain = DEFAULT_REALM
DEFAULT_REALM must be equal to the value of default_realm in the
[libdefaults]section of /etc/krb5.conf.
Also in /etc/idmap.conf, in the
[Translation]section, change the translation method to sss:
Method = sss
When you're done with manual changes to the configurations, restart services per the instructions below for the Linux distribution:
On CentOS 8 or UbuntU 20, you need to restart the sssd and gssd services since the configuration was manually changed:
# systemctl restart sssd rpc-gssd
On CentOS 7:
# authconfig --enablesssd --enablesssdauth --update # systemctl restart nfs-client.target nfs-secure sssd
Enable/configure NFS as follows, depending on distribution:
CentOS. Optionally we can force the client to use NFSv4.1, the minor version of NFSv4 supported by VAST by modifying /etc/nfsmount.conf, this removes the need to specify the vers option within the mount command:
# echo Nfsvers=4.1 >> /etc/nfsmount.conf
OpenSUSE. Enable GSSD with the NFS client:
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 18.104.22.168, a client mount to 22.214.171.124:/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.