--- title: "Kerberos Authentication for NFSv4.1" slug: "kerberos-authentication-for-nfsv41" updated: 2026-10-27T17:23:45Z published: 2026-10-27T17:23:45Z canonical: "docs.vastdata.com/kerberos-authentication-for-nfsv41" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.vastdata.com/llms.txt > Use this file to discover all available pages before exploring further. # Kerberos Authentication for NFSv4.1 The VAST Cluster NFSv4.1 implementation includes support for Kerberos security flavors, in which the client uses the RPCSEC_GSS authentication, integrity and privacy services. - [Cluster and Active Directory Configuration for Kerberos Authentication](/docs-5-3/docs/en/kerberos-authentication-for-nfsv41#cluster-and-active-directory-configuration-for-kerberos-authentication) - [Client Configurations for Kerberos Authentication](/docs-5-3/docs/en/kerberos-authentication-for-nfsv41#client-configurations-for-kerberos-authentication) - [Client Mounting for Kerberos Authentication](/docs-5-3/docs/en/kerberos-authentication-for-nfsv41#client-mounting-for-kerberos-authentication) - [Data Access for Client Users](/docs-5-3/docs/en/kerberos-authentication-for-nfsv41#data-access-for-client-users) ## Kerberos Security Modes VAST Cluster supports NFSv4.1 client mounts using all of the following kerberos security modes: - Kerberos authentication (*krb5*), using the RPCSEC_GSS authentication service, which provides cryptographic proof of the user's identity in each RPC request. - Kerberos 5 authentication with integrity checking (*krb5i*). *Krb5i* uses the RPCSEC_GSS integrity service, which uses checksums to verify the integrity of each NFS message transferred between client and server. This is useful both for security reasons (for example, to ensure that data has not been tampered with) and for data integrity reasons (for example, to prevent data corruption when using NFS over unreliable networks). - Kerberos 5 authentication with privacy checking (*krb5p*). *Krb5p* the RPCSEC_GSS privacy service, which uses checksums to encrypt all the traffic between client and the server. This is more secure and also incurs more load. ## Cluster and Active Directory Configuration for Kerberos Authentication 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](/docs-5-3/docs/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](/docs-5-3/docs/workflow-for-enabling-client-protocol-access) - Complete server-side configuration of [ID mapping](/docs-5-3/docs/en/nfsv41-id-mapping). This must be done correctly on the cluster to ensure successful NFSv4.1 Kerberos IO.NFSv4.1 ID Mapping - In the view policy, you may need to adjust the Kerberos Authentication Minimal protection level, which controls which NFSv4.1 client security modes to allow to access any views that use the view policy. It can be set to one of the following: - Kerberos Privacy. Allows client mounts only if they use Kerberos 5 authentication with privacy checking (krb5p), the highest level Kerberos security mode. - Kerberos Integrity. Allows client mounts only if they use either Kerberos 5 authentication with privacy checking (*krb5p*) or Kerberos 5 authentication with integrity (*krb5i*). - Kerberos Auth-only. Allows client mounts with Kerberos authentication only and allows any of the three Kerberos security modes (*krb5*, *krb5i*, or *krb5p*). - System. Allows client mounts using either the AUTH_SYS RPC security flavor (the traditional default NFS authentication scheme) or with any of the three Kerberos security modes (*krb5*, *krb5i*, or *krb5p*). - None. Allows client mounts with the AUTH_NONE (anonymous access), or AUTH_SYS RPC security flavors, or with any of the three Kerberos security modes (*krb5*, *krb5i*, or *krb5p*). To modify this setting in a view policy, see [Modifying View Policies](/docs-5-3/docs/en/modifying-view-policies). To modify a view (which includes selecting a view policy), see [Modifying Views](/docs-5-3/docs/en/modifying-views).Modifying Views ## Client Configurations for Kerberos Authentication Each Linux client needs to be configured such that the following requirements are met: - The rpc.gssd authentication service is running. - NFS [ID mapping](/docs-5-3/docs/en/nfsv41-id-mapping) is configured to ensure successful NFSv4.1 Kerberos IO.NFSv4.1 ID Mapping - 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 domain controller 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: 1. [Install required packages](/docs-5-3/docs/en/kerberos-authentication-for-nfsv41#install-required-packages) 2. [Join the Active Directory domain using realmd](/docs-5-3/docs/en/kerberos-authentication-for-nfsv41#join-the-active-directory-domain-using-realmd) 3. [Apply Manual Configurations and Restart Services](/docs-5-3/docs/en/kerberos-authentication-for-nfsv41#apply-manual-configurations-and-restart-services) ### Install required packages 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: - For CentOS: ```plaintext yum install -y nfs-utils sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients nfs4-acl-tools ``` - For UbuntU: ```plaintext 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 ``` - For OpenSUSE: ```plaintext zypper install nfs-client sssd realmd adcli samba-client krb5-client openldap2-client nfsidmap sssd-tools nfs4-acl-tools sssd-ad yast2-nfs-client ``` ### Join the Active Directory domain using realmd 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: 1. Use the `realm discover` command without any options to retrieve the Active Directory domain's Kerberos realm name: ```plaintext 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: ```plaintext # 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 ``` 2. Run the `realm join` command with the following usage: ```plaintext 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 discover` output is *LABNET.VASTDATA.COM*, and your Active Directory user is the *Administrator* user, then you would run: ```plaintext realm join labnet.vastdata.com –-user-principal=host/darkstar.labnet.vastdata.com@LABNET.VASTDATA.COM ``` ### Apply Manual Configurations and Restart Services 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. 1. Open */etc/krb5.conf*. This is the main Kerberos configuration file. 2. Add the following line to the `[libdefaults]` section of the file: ```plaintext canonicalize=true ``` 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. 3. 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`: ```plaintext #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) ``` 4. Initialize the keytab file: ```plaintext # 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 ``` 5. 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: ```plaintext ldap_id_mapping=false ``` 6. 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 `getent` command, add the following: ```plaintext enumerate = true ``` > **Caution** > > 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. 7. Ensure that */etc/sssd/sssd.conf* is owned by “root” with permissions set to owner read and write only: ```plaintext # chown root:root /etc/sssd/sssd.conf # chmod 600 /etc/sssd/sssd.conf ``` 8. In the */etc/idmap.conf* file, under the `[General]` section, add the following: ```plaintext Domain = DEFAULT_REALM ``` *DEFAULT_REALM* must be equal to the value of *default_realm* in the `[libdefaults]` section of */etc/krb5.conf*. 9. Also in */etc/idmap.conf*, in the `[Translation]` section, change the translation method to *sss*: ```plaintext Method = sss ``` 10. 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: ```plaintext # systemctl restart sssd rpc-gssd ``` - On CentOS 7: ```plaintext # authconfig --enablesssd --enablesssdauth --update # systemctl restart nfs-client.target nfs-secure sssd ``` 11. 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: ```plaintext # echo Nfsvers=4.1 >> /etc/nfsmount.conf ``` - OpenSUSE. Enable GSSD with the NFS client: 1. Using yast2, navigate to Network Services > NFS Client. 2. In the NFS Settings tab: - Enable NFSv4. - Set NFSv4 Domain Name if not already set. - Enable GSS Security. 3. Run these commands: ```plaintext # systemctl enable nfs # systemctl start nfs # systemctl restart sssd ``` ## Client Mounting for Kerberos Authentication - 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 1.2.3.4, a client mount to *1.2.3.4:/volume1* would not be able to send a request to the cluster with Kerberos authentication. - In the client mount, set security mode to one of the following: - *sec=krb5* for Kerberos authentication. - *sec=krb5i* for Kerberos V5 authentication with integrity checking (checksums) to verify that the data has not been tampered with. - *sec=krb5p* for Kerberos V5 authentication, integrity checksums, and privacy protection (encryption) on the shared filesystem. For example, suppose: - The DNS name for virtual IP pool poolA is *poolA.cluster1.ourcorporation.com*, > [!NOTE] > **Note** > > It is assumed that you have done appropriate DNS configuration on the Cluster and on Active Directory, for this DNS name, including configuring the cluster's machine object in Active Directory with an NFS/ type Service Principal Name (SPN) attribute, as described in [(For Kerberos Only) Configure Active Directory SPNs for VAST Cluster DNS Service Domains](/docs-5-3/multiprotocol-access/workflow-for-enabling-client-protocol-access.html). - 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: ```plaintext # 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. ## Data Access for Client Users 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).