Configuring Kerberos NFS Servers

NFS services use UNIX user IDs (UIDs) to identify a user and cannot directly use GSS credentials. To translate the credential to a UID, a credential table that maps user credentials to UNIX UIDs might need to be created. See Mapping GSS Credentials to UNIX Credentials for more information on the default credential mapping. The procedures in this section focus on the tasks that are necessary to configure a Kerberos NFS server, to administer the credential table, and to initiate Kerberos security modes for NFS-mounted file systems. The following task map describes the tasks that are covered in this section.

Table 21-2 Configuring Kerberos NFS Servers (Task Map)

How to Configure Kerberos NFS Servers

In this procedure, the following configuration parameters are used:

• Realm name = EXAMPLE.COM

• DNS domain name = example.com

• NFS server = denver.example.com

• admin principal = kws/admin

Before You Begin

You must assume the root role on the NFS server. For more information, see How to Use Your Assigned Administrative Rights.

1. Complete the prerequisites for configuring a Kerberos NFS server.

   The master KDC must be configured. To fully test the process, you need several clients.

2. (Optional) Install the NTP client or another clock synchronization mechanism.

   Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be synchronized with the time on the KDC server within a maximum difference defined by the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

3. Configure the NFS server as a Kerberos client.

   Follow the instructions in Configuring Kerberos Clients.

4. Start kadmin.

   You can use the Graphical Kerberos Administration Tool to add a principal, as explained in How to Create a New Kerberos Principal. To do so, you must log in with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.

   denver # /usr/sbin/kadmin -p kws/admin
   Enter password: <Type kws/admin password>
   kadmin: 

   1. Create the server's NFS service principal.

      Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the name service.

      Repeat this step for each unique interface on the system that might be used to access NFS data. If a host has multiple interfaces with unique names, each unique name must have its own NFS service principal.

      kadmin: addprinc -randkey nfs/denver.example.com
      Principal "nfs/denver.example.com" created.
      kadmin:

   2. Add the server's NFS service principal to the server's keytab file.

      Repeat this step for each unique service principal created in Step a.

      kadmin: ktadd nfs/denver.example.com
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode
                with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc
                mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs denver.example.com with kvno 3, encryption type ArcFour
                with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode
                with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
      kadmin:

   3. Quit kadmin.

      kadmin: quit

5. (Optional) Create special GSS credential maps, if needed.

   Normally, the Kerberos service generates appropriate maps between the GSS credentials and the UNIX UIDs. The default mapping is described in Mapping GSS Credentials to UNIX Credentials. If the default mapping is not sufficient, see How to Create a Credential Table for more information.

6. Share the NFS file system with Kerberos security modes.

   See How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes for more information.

How to Create a Credential Table

The gsscred credential table is used by an NFS server to map Kerberos credentials to a UID. By default, the primary part of the principal name is matched to a UNIX login name. For NFS clients to mount file systems from an NFS server with Kerberos authentication, this table must be created if the default mapping is not sufficient.

Before You Begin

You must assume the root role on the NFS server. For more information, see How to Use Your Assigned Administrative Rights.

1. Edit /etc/gss/gsscred.conf and change the security mechanism.

   Change the mechanism to files.

2. Create the credential table by using the gsscred command.

   # gsscred -m kerberos_v5 -a

   The gsscred command gathers information from all sources that are listed with the passwd entry in the svc:/system/name-service/switch:default service. You might need to temporarily remove the files entry, if you do not want the local password entries included in the credential table. See the gsscred(1M) man page for more information.

How to Add a Single Entry to the Credential Table

Before You Begin

This procedure requires that the gsscred table has already been created on the NFS server. See How to Create a Credential Table for instructions.

You must assume the root role on the NFS server. For more information, see How to Use Your Assigned Administrative Rights.

• Add an entry to the credential table by using the gsscred command.

  # gsscred -m mech [ -n name [ -u uid ]] -a

  mech

  Defines the security mechanism to be used.

  name

  Defines the principal name for the user, as defined in the KDC.

  uid

  Defines the UID for the user, as defined in the password database.

  -a

  Adds the UID to principal name mapping.

Example 21-3 Adding a Multiple Component Principal to the Credential Table

In the following example, an entry is added for a principal named sandy/admin, which is mapped to UID 3736.

# gsscred -m kerberos_v5 -n sandy/admin -u 3736 -a

Example 21-4 Adding a Principal in a Different Domain to the Credential Table

In the following example, an entry is added for a principal named sandy/admin@EXAMPLE.COM, which is mapped to UID 3736.

# gsscred -m kerberos_v5 -n sandy/admin@EXAMPLE.COM -u 3736 -a

How to Provide Credential Mapping Between Realms

This procedure provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID.

Before You Begin

You must assume the root role on the client system. For more information, see How to Use Your Assigned Administrative Rights.

• On the client system, add entries to the krb5.conf file.

  # cat /etc/krb5/krb5.conf
  [libdefaults]
          default_realm = CORP.EXAMPLE.COM
   .
  [realms]
      CORP.EXAMPLE.COM = {
          .
          auth_to_local_realm = SALES.EXAMPLE.COM
          .
      }

Example 21-5 Mapping Credentials Between Realms Using the Same Password File

This example provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID. On the client system, add entries to the krb5.conf file.

# cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = CORP.EXAMPLE.COM
 .
[realms]
    CORP.EXAMPLE.COM = {
        .
        auth_to_local_realm = SALES.EXAMPLE.COM
        .
    }

Troubleshooting

See Observing Mapping From GSS Credentials to UNIX Credentials to help with the process of troubleshooting credential mapping problems.

How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

This procedure enables a NFS server to provide secure NFS access using different security modes or flavors. When a client negotiates a security flavor with the NFS server, the first flavor that is offered by the server that the client has access to is used. This flavor is used for all subsequent client requests of the file system shared by the NFS server.

Before You Begin

You must assume the root role on the NFS server. For more information, see How to Use Your Assigned Administrative Rights.

1. Verify that there is an NFS service principal in the keytab file.

   The klist command reports if there is a keytab file and displays the principals. If the results show that no keytab file exists or that no NFS service principal exists, you need to verify the completion of all the steps in How to Configure Kerberos NFS Servers.

   # klist -k
   Keytab name: FILE:/etc/krb5/krb5.keytab
   KVNO Principal
   ---- ---------------------------------------------------------
      3 nfs/denver.example.com@EXAMPLE.COM
      3 nfs/denver.example.com@EXAMPLE.COM
      3 nfs/denver.example.com@EXAMPLE.COM
      3 nfs/denver.example.com@EXAMPLE.COM

2. Enable Kerberos security modes in the /etc/nfssec.conf file.

   Edit the /etc/nfssec.conf file and remove the “#” that is placed in front of the Kerberos security modes.

   # cat /etc/nfssec.conf
    .
    .
   #
   # Uncomment the following lines to use Kerberos V5 with NFS
   #
   krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
   krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
   krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS

3. Share the file systems with the appropriate security modes.

   share -F nfs -o sec=mode file-system

   mode

   Specifies the security modes to be used when sharing the file system. When using multiple security modes, the first mode in the list is used as the default.

   file-system

   Defines the path to the file system to be shared.

   All clients that attempt to access files from the named file system require Kerberos authentication. To access files, the user principal on the NFS client should be authenticated.

4. (Optional) If the automounter is being used, edit the auto_master database to select a security mode other than the default.

   You need not follow this procedure if you are not using the automounter to access the file system or if the default selection for the security mode is acceptable.

   file-system  auto_home  -nosuid,sec=mode

5. (Optional) Manually issue the mount command to access the file system by using a non-default mode.

   Alternatively, you could use the mount command to specify the security mode, but this alternative does not take advantage of the automounter.

   # mount -F nfs -o sec=mode file-system

Example 21-6 Sharing a File System With One Kerberos Security Mode

In this example, Kerberos authentication must succeed before any files can be accessed through the NFS service.

# share -F nfs -o sec=krb5 /export/home

Example 21-7 Sharing a File System With Multiple Kerberos Security Modes

In this example, all three Kerberos security modes have been selected. Which mode is used is negotiated between the client and the NFS server. If the first mode in the command fails, then the next is tried. See the nfssec(5) man page for more information.

# share -F nfs -o sec=krb5:krb5i:krb5p /export/home