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. | |
Create a credential table. |
Generates a credential table which can be used to provide mapping from GSS credentials to UNIX user IDs, if the default mapping is not sufficient. | |
Change the credential table that maps user credentials to UNIX UIDs. |
Updates information in the credential table. | |
Create credential mappings between two like realms. |
Provides instructions on how to map UIDs from one realm to another if the realms share a password file. | |
Share a file system with Kerberos authentication. |
Shares a file system with security modes so that Kerberos authentication is required. |
How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes |
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.
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.
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 |
Defines the security mechanism to be used.
Defines the principal name for the user, as defined in the KDC.
Defines the UID for the user, as defined in the password database.
Adds the UID to principal name mapping.
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 |
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 |
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.
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 . } |
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 . } |
See Observing Mapping from GSS Credentials to UNIX Credentials to help with the process of troubleshooting credential mapping problems.
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/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 |
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 |
Edit the /etc/dfs/dfstab file and add the sec= option with the required security modes to the appropriate entries.
share -F nfs -o sec=mode file-system |
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.
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.
Make sure that the NFS service is running on the server.
If this command is the first share command or set of share commands that you have initiated, the NFS daemons are likely not running. The following command restarts the daemons:
# svcadm restart network/nfs/server |
(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 |
In this example, the dfstab file line means that Kerberos authentication must succeed before any files can be accessed through the NFS service.
# grep krb /etc/dfs/dfstab share -F nfs -o sec=krb5 /export/home |
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.
# grep krb /etc/dfs/dfstab share -F nfs -o sec=krb5:krb5i:krb5p /export/home |