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)
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
- Complete the prerequisites for configuring a Kerberos NFS server.
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.
- Configure the NFS server as a Kerberos client.
Follow the instructions in Configuring Kerberos Clients.
- 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:
- 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 /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.
kadmin: addprinc -randkey nfs/denver.example.com
Principal "nfs/denver.example.com" created.
kadmin:
- 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:
- Quit kadmin.
kadmin: quit
- (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.
- 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.
- 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.
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.
- Become superuser on the NFS server.
- 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 23-2 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 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/[email protected], which is mapped to UID 3736.
# gsscred -m kerberos_v5 -n sandy/[email protected] -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 [email protected] and [email protected] are mapped to the same
UID.
- Become superuser.
- 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 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 [email protected] and [email protected] 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.
- 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.
# klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
---- ---------------------------------------------------------
3 nfs/[email protected]
3 nfs/[email protected]
3 nfs/[email protected]
3 nfs/[email protected]
- 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
- Share the file systems with the appropriate security modes.
sharemgr share -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.
- (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
- (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 23-5 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.
# sharemgr share -F nfs -p -o sec=krb5 /export/home
Example 23-6 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.
# sharemgr share -F nfs -p -o sec=krb5:krb5i:krb5p /export/home
