Articles in this section

Kerberos Authentication

Sara Levy
  • Updated
Follow

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.

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 Enabling NFSv4.1 Access, paying attention to the options required for Kerberos support.

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 Using Active Directory (Support for Kerberos and ID Mapping)

  • 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.

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 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:

  1. Install required packages

  2. Join the Active Directory domain using realmd

  3. Apply some 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:

    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:

    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:

    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:

    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

  2. Run the realm join command 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 discover output 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
Apply some 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:

    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:

    #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:

    # 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: 

    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: 

    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:

    # 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: 

    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: 

    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:

      # systemctl restart sssd rpc-gssd

    • On CentOS 7:

      # 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:

      # 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:

        # 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 Kerberos authentication using sec=krb5.

    Note

    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.

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).

Related articles

Comments

0 comments

Article is closed for comments.