JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Security Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information

Preface

Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Using the Basic Audit Reporting Tool (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Network Services Authentication (Tasks)

15.  Using PAM

16.  Using SASL

17.  Using Secure Shell (Tasks)

18.  Secure Shell (Reference)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

Configuring the Kerberos Service (Task Map)

Configuring Additional Kerberos Services (Task Map)

Configuring KDC Servers

How to Automatically Configure a Master KDC

How to Interactively Configure a Master KDC

How to Manually Configure a Master KDC

How to Configure a KDC to Use an LDAP Data Server

How to Automatically Configure a Slave KDC

How to Interactively Configure a Slave KDC

How to Manually Configure a Slave KDC

How to Refresh the Ticket-Granting Service Keys on a Master Server

Configuring Cross-Realm Authentication

How to Establish Hierarchical Cross-Realm Authentication

How to Establish Direct Cross-Realm Authentication

Configuring Kerberos Network Application Servers

How to Configure a Kerberos Network Application Server

How to Use the Generic Security Service With Kerberos When Running FTP

Configuring Kerberos NFS Servers

How to Configure Kerberos NFS Servers

How to Create a Credential Table

How to Add a Single Entry to the Credential Table

How to Provide Credential Mapping Between Realms

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

Configuring Kerberos Clients

Configuring Kerberos Clients (Task Map)

How to Create a Kerberos Client Installation Profile

How to Automatically Configure a Kerberos Client

How to Interactively Configure a Kerberos Client

How to Configure a Kerberos Client for an Active Directory Server

How to Manually Configure a Kerberos Client

How to Disable Verification of the Ticket-Granting Ticket

How to Access a Kerberos Protected NFS File System as the root User

How to Configure Automatic Migration of Users in a Kerberos Realm

How to Configure Account Lockout

Synchronizing Clocks Between KDCs and Kerberos Clients

Swapping a Master KDC and a Slave KDC

How to Configure a Swappable Slave KDC

How to Swap a Master KDC and a Slave KDC

Administering the Kerberos Database

Backing Up and Propagating the Kerberos Database

The kpropd.acl File

The kprop_script Command

How to Back Up the Kerberos Database

How to Restore the Kerberos Database

How to Convert a Kerberos Database After a Server Upgrade

How to Reconfigure a Master KDC to Use Incremental Propagation

How to Reconfigure a Slave KDC to Use Incremental Propagation

How to Configure a Slave KDC to Use Full Propagation

How to Verify That the KDC Servers Are Synchronized

How to Manually Propagate the Kerberos Database to the Slave KDCs

Setting Up Parallel Propagation

Configuration Steps for Setting Up Parallel Propagation

Administering the Stash File

How to Remove a Stash File

How to Employ a New Master Key

Managing a KDC on an LDAP Directory Server

How to Mix Kerberos Principal Attributes in a Non-Kerberos Object Class Type

How to Destroy a Realm on an LDAP Directory Server

Increasing Security on Kerberos Servers

How to Enable Only Kerberized Applications

How to Restrict Access to KDC Servers

How to Use a Dictionary File to Increase Password Security

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)

Glossary

Index

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)

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 Configure Kerberos NFS Servers

In this procedure, the following configuration parameters are used:

  1. Become superuser on the NFS server.
  2. Complete the prerequisites for configuring a Kerberos NFS server.

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

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

  4. Configure the NFS server as a Kerberos client.

    Follow the instructions in Configuring Kerberos Clients.

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

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

  1. Become superuser on the NFS server.
  2. Edit /etc/gss/gsscred.conf and change the security mechanism.

    Change the mechanism to files.

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

  1. Become superuser on the NFS server.
  2. 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.

  1. Become superuser on the client system.
  2. 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.

  1. Become superuser on the NFS server.
  2. 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
  3. 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
  4. 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.

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