This section describes how to configure a Linux client for using NFSv4.1 with Kerberos.

Linux systems implement Kerberos support as a series of loosely related packages and configuration files. For this reason, configuration depends on the Linux distribution and version. This section refers to tools, packages, dæmons, configuration files, and other elements in Ubuntu 18.04 LTS.

Joining a Linux Client to a Domain

There are two common ways of joining a Linux client to an Active Directory (AD) domain automatically, by using samba or realmd. Both methods require creating the /etc/krb5.conf configuration file and defining a default domain and the relationships between domains and realms.

Configuring the /etc/krb5.conf File

The following is an example configuration for joining a domain.

[libdefaults]
    default_realm = MY-DOMAIN.EXAMPLE.COM

[realms]
    MY-DOMAIN.EXAMPLE.COM = {
        kdc = my-domain.example.com:88
        admin_server = my-domain.example.com:749
    }

[domain_realm]
    my-domain.example.com = MY-DOMAIN.EXAMPLE.COM
    .my-domain.exmaple.com = MY-DOMAIN.EXAMPLE.COM

To Join a Linux Client to a Domain by using samba

samba is a suite of Linux tools that provides Windows-like functionality on Linux. The net ads join command creates a machine account on the domain.

  1. To specify how the domain-join process behaves, edit the /etc/samba/smb.conf file. For example:

    workgroup = my-domain
    server role = member server
    realm = my-domain.example.com
    kerberos method = system keytab
    
  2. To join the domain, run the net ads join command. For example:

    $ net ads join my-domain.example.com -U Administrator
    
  3. samba doesn’t create configuration files. Configure the sssd and idmapd tools manually. For more information, see Mapping External Identities to Linux Identities.

To Join a Linux Client to a Domain by using realmd

realmd is a tool that allows managing realm-based authentication. It can be somewhat more difficult to use than samba. However, it creates a more complete configuration. For example, it configures the sssd tool during the domain-join process.

  1. To join a domain, use the realm join command. For example:

    $ realm join my-domain.example.com -U Administrator
    
  2. Configure the sssd and idmapd tools manually. For more information, see Mapping External Identities to Linux Identities.

To Configure DNS and Service Principal Name (SPN)

Kerberos relies on DNS to identify machines involved in authentication. NFS clients and servers require DNS A records for forward-DNS lookups and PTR records for reverse-DNS lookups.

  1. After you configure DNS, check DNS resolution from your client. For example:

    $ nslookup my-client-machine.my-domain.example.com
    
  2. In addition to DNS configuration, Linux clients require a standard host SPN on the machine account created while joining the domain. We recommend configuring the SPN by using the setspn command on the domain controller after the join procedure. For example:

    setspn -r my-client_machine
    

Mapping External Identities to Linux Identities

During the ID mapping process, a Linux system converts external identities to Linux identities.

  • For Qumulo Core, external identities are equivalent to Kerberos principals.
  • For Linux, identities are simple integers: UIDs and GIDs.

ID mapping is bidirectional. A system call, such as chown, that takes a UID or GID as input requires mapping the UID or GID be mapped to a domain user or group before passing it to your Qumulo cluster over NFS.

A system call, such as stat, that returns a UID or GID, requires that the domain user or group that returned from your Qumulo cluster over NFS be converted to a UID or GID before the system can present it to the user.

Configuring Active Directory Authentication by using sssd

sssd (System Security Services Daemon) is a tool responsible for managing authentication with external providers in Linux. To use NFSv4.1 with Kerberos, you must configure sssd with AD as the identity provider.

  • If you join domains by using samba, you must create the /etc/sssd.conf file.
  • If you join domains by using realmd, you might already have a /etc/sssd.conf file. For detailed configuration information, see sssd-ldap in the Linux documentation.

In the following example, the sssd.conf file configures basic ID mapping for AD.

[sssd]
domains = my-domain.example.com
config_file_version = 2
services = nss, pam

[domain/my-domain.example.com]
ad_domain = my-domain.example.com
krb5_realm = MY_DOMAIN.EXAMPLE.COM
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = ad

Configuring LDAP Queries against the Domain Controller (DC) by using sssd

Like Qumulo clusters, Linux systems can resolve details about user and group objects by querying the DC over LDAP. In particular, a Linux system looks for an object with a matching sAMAccountName (user) or CN (group)

  1. To toggle RFC 2307 for mappings in the sssd.conf file, configure the ldap_id_mapping field.

    • When you set the field to False, the client checks whether the RFC 2307 uidNumber or gidNumber are set on an object.

      • If the number is set, it becomes the Linux UID or GID for the operation.

      • Otherwise, the UID or GID becomes nobody or nogroup (65534).

    • When you set the field to True, the client assigns locally a new unique UID or GID to each objectSID that it finds on the DC.

    In both cases, the client communicates with the DC by using its machine account.

  2. To pick up changes to the /etc/sssd.conf file on a live system, restart the sssd service.

Configuring the Conversion of Local Identities to NFS Representations by Using idmapd

idmapd (or nfsidmap), is a tool that lets you convert local identities to their on-the-wire NFS representations. Although idmapd works with sssd, it has additional configuration options.

In the following example, the /etc/idmapd.conf file configures a Linux client joined to AD:

[General]
Domain = my-domain.example.com
Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs

[Mapping]
Nobody-User = nobody
Nobody-Group = nogroup

Authenticating as an AD User and Mounting Your Qumulo Cluster

Qumulo Core supports three methods of authenticating as an AD user and mounting your cluster over NFSv4.1 as the AD user. These methods, from least to most complex, and in an increasing order of utility, are:

  • By using a machine account
  • By using manual authentication with the kinit tool
  • By using the autofs tool

To Authenticate as an AD User by Using a Machine Account and Mount Your Qumulo Cluster

Machine account authentication uses one AD user for each Linux system. This machine account user is the same as the machine account created on the domain during the domain-join operation. Any user on the Linux system who has access to the machine account mount point can operate as the machine account user on a Qumulo cluster.

Machine account authentication can be useful for simple scenarios in which trusted users on trusted Linux machines require a secure mechanism for communicating with a Qumulo cluster. Because this is also the easiest authentication method to configure, it can be a good starting point for administrators who configure NFSv4.1 with Kerberos for the first time.

  1. Confirm that your /etc/nfs.conf file, contains the following flag.

    [gssd]
    use-machine-creds=true
    

    The use-machine-creds flag specifies whether authentication uses machine credentials when sudo mount is invoked for NFSv4.1 with Kerberos. When you set the flag to true, gssd authenticates as the machine account for the system on behalf of the NFS client. (It performs a kinit operation as the machine account). The credential cache that results from the kinit is usually located in /tmp. To search for the cache, use the ls /tmp/*krb5* command.

  2. Mount your cluster by using the krb5 security mechanism. For example:

    $ sudo mount -o vers=4.1,sec=krb5 my-cluster.my-domain.example.com:/ /mnt/point
    
  3. Use the Qumulo file system.

    $ cd /mnt/point
    $ touch filename
    $ ls -l filename
    -rw-r--r--    1 MY_MACHINE$    domain computers         0 Jun  9 23:18 filename
    

If the machine name isn’t visible, make sure that the AD container holds this machine in the Qumulo cluster’s Base DN configuration (typically, CN=Computers,DC=...). If the machine name is still not visible, configure the Linux client ID mapper to provide local mappings when no RFC 2307 mapping is available. It is uncommon for machine accounts to have RFC 2307 mappings.

To Authenticate as an AD User Manually by Using kinit and Mount Your Qumulo Cluster

kinit authentication is very similar to machine account authentication. The main difference is that you must create the credentials for the mount manually. You can use any user in the AD domain. However (this is also true for machine accounts), any local Linux user that can access the mount point can operate on the Qumulo cluster as this single user.

In environments where Linux systems map exactly to end users that have kinit-based Kerberos mounts on their Qumulo clusters, kinit might be sufficient.

  1. Authenticate by using kinit. For example:

    $ sudo kinit my-user
    
  2. When prompted for a password, use the AD domain password for the user.

  3. To confirm the result of the authentication operation, use the sudo klist command.

  4. Confirm that the /etc/nfs.conf file contains the following flag:

    [gssd]
    use-machine-creds=false
    

    The use-machine-creds flag specifies whether authentication uses machine credentials when sudo mount is invoked for NFSv4.1 with Kerberos. When you set the flag to false, gssd searches for an existing credential cache (which you created by running kinit) in /tmp/krb5cc_0 for authenticating with the Qumulo cluster.

  5. Mount your cluster by using the krb5 security mechanism. For example:

    $ sudo mount -o vers=4.1,sec=krb5 my-cluster.my-domain.example.com:/ /mnt/point
    
  6. Use the Qumulo file system.

    $ cd /mnt/point
    $ touch filename
    $ ls -l filename
    -rw-r--r--    1 my-user    domain users         0 Jun  9 23:18 filename
    

To Authenticate as an AD User Manually by Using autofs and Mount Your Qumulo Cluster

autofs is a dæmon that manages mount points for individual Linux users. For this reason, Linux users have different views of a mount point. autofs can authenticate an AD user through ssh, the Linux filesystem, or a Qumulo cluster mounted on a Linux system.

  1. Log in to an AD domain and configure sssd to authenticate with this domain. For example:

    $ sudo login my-domain-user
    

    Alternatively, you can use the following command.

    $ ssh my-domain_user@my-linux-system
    
  2. Configure the autofs mappings. For more information, see auto.master in the Linux documentation. The following is an example of a simple configuration that provides a single (direct) mount point which authenticates AD users automatically.

    a. To define a mount point and the path to its map file, add the following line to the /etc/auto.master file.

    /- /etc/auto.kerberos_nfs_mount_example --timeout 60
    

    For more information, see Autofs in the Ubuntu documentation.

    b. Add the following line to the /etc/auto.kerberos_nfs_mount_example map file.

    /mnt/qumulo_mount_point -vers=4.1,sec=krb5 <qumulo-cluster>.my-domain.example.com:/
    
  3. Restart autofs.

    $ sudo systemctl restart autofs
    

    autofs creates the /mnt/qumulo_mount_point directory and mounts it as necessary for any user. For example:

    $ ssh domain_user_1@my-linux-system touch /mnt/qumulo_mount_point/user1_file
    $ ssh domain_user_2@my-linux-system touch /mnt/qumulo_mount_point/user2_file
    $ ssh domain_user_3@my-linux-system ls -l /mnt/qumulo_mount_point
    -rw-r--r--    1 user1    domain users         0 Jun  9 23:18 user1_file
    -rw-r--r--    1 user2    domain users         0 Jun  9 23:18 user2_file
    

Network Time Protocol (NTP) Server

Kerberos is very sensitive to clock skew. It is important for all systems involved in a Kerberos relationship—the KDC, your Qumulo cluster, and any Linux clients—to have as little clock skew as possible. We recommend using the same NTP server for all three components.

  • You can use your AD domain controller as an NTP server. In the Web UI, on the Active Directory page, for Use Active Directory as your primary time server, click Yes.

  • To configure any other NTP server in the Web UI, click Cluster > Date & Time.

There are many NTP dæmons for Linux. For example, Ubuntu uses the NTP functionality in systemd (timedatectl and timesyncd).