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 23–2 Configuring Kerberos
NFS Servers (Task Map)

Task

Description

For Instructions

Configure a Kerberos NFS server.

Enables a server to share a file system that requires Kerberos authentication.

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

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

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.

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 /etc/resolv.conf file.

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.

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.

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

Change the mechanism to files.

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 /etc/nsswitch.conf file. 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.

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 23–3 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.

Example 23–4 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.

Troubleshooting

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.

Become superuser on the NFS server.

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.

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.