test

System Administration Guide: Security Services

Configuring SEAM Clients

SEAM clients include any host, not a KDC server, on the network that needs to use SEAM services. This section provides a procedure for installing a SEAM client, as well as specific information about using root authentication to mount NFS file systems.

How to Configure a SEAM Client

In this procedure, the following configuration parameters are used:

  1. Become superuser.

  2. Edit the Kerberos configuration file (krb5.conf).

    To change the file from the SEAM default version, you need to change the realm names and the names of the servers. You also need to identify the path to the help files for gkadmin. 


    kdc1 # cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = EXAMPLE.COM

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
#
# if the domain name and realm name are equivalent, 
# this entry is not needed
#
[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log

[appdefaults]
    gkadmin = {
        help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

  3. (Optional) Synchronize the client's clock with the master KDC's clock by using NTP or another clock synchronization mechanism.

    It is not required to install and use the Network Time Protocol (NTP). However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file in order for authentication to succeed. See Synchronizing Clocks between KDCs and SEAM Clients for information about NTP.

  4. (Optional) Create a user principal if a user principal does not already exist.

    You need to create a user principal only if the user associated with this host does not have a principal assigned already. See How to Create a New Principal for instructions on using the SEAM Administration Tool. The following is a command-line example.


    client1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: addprinc mre
Enter password for principal mre@EXAMPLE.COM: <type the password>
Re-enter password for principal mre@EXAMPLE.COM: <type it again>
kadmin:

  5. Create a root principal.

    Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.


    kadmin: addprinc root/client1.example.com
Enter password for principal root/client1.example.com@EXAMPLE.COM: <type the password>
Re-enter password for principal root/client1.example.com@EXAMPLE.COM: <type it again>
kadmin: quit

  6. (Optional) To use Kerberos with NFS, enable Kerberos security modes in the /etc/nfssec.conf file.

    Edit the /etc/nfssec.conf file and remove the “#” from 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

  7. (Optional) If you want a user on the SEAM client to automatically mount Kerberized NFS file systems that use Kerberos authentication, you must authenticate the root user.

    This process is done most securely by using the kinit command. However, users will need to use kinit as root every time they need to mount a file system that is secured by Kerberos. You can choose to use a keytab file instead. For detailed information about the keytab file requirement, see Setting Up Root Authentication to Mount NFS File Systems. 


    client1 # /usr/bin/kinit root/client1.example.com
Password for root/client1.example.com@EXAMPLE.COM: <Type password>

    To use the keytab file option, add the root principal to the client's keytab by using kadmin:


    client1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: ktadd root/client1.example.com
kadmin: Entry for principal root/client.example.com with
  kvno 3, encryption type DES-CBC-CRC added to keytab
  WRFILE:/etc/krb5/krb5.keytab
kadmin: quit

  8. If you want the client to warn users about Kerberos ticket expiration, create an entry in the /etc/krb5/warn.conf file.

    See the warn.conf(4) man page for more information.

Example—Setting Up a SEAM Client Using a Non-SEAM KDC

It is possible to set up a SEAM client to work with a non-SEAM KDC. In this case, a line must be included in the /etc/krb5/krb5.conf file in the realms section. This line changes the protocol that is used when the client is communicating with the Kerberos password-changing server. The format of this line follows.


[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                admin_server = kdc1.example.com
                kpasswd_protocol = SET_CHANGE
        }

Setting Up Root Authentication to Mount NFS File Systems

If users want to access a non-Kerberized NFS file system, either the NFS file system can be mounted as root, or the file system can be accessed automatically through the automounter whenever users access it (without requiring root permissions).

Mounting a Kerberized NFS file system is very much the same, but it does incur an additional obstacle. To mount a Kerberized NFS file system, users must use the kinit command as root to obtain credentials for the client's root principal, because a client's root principal is typically not in the client's keytab. This step is required even when the automounter is set up. This step also forces all users to know their system's root password and the root principal's password.

To bypass this step, you can add a client's root principal to the client's keytab file, which automatically provides credentials for root. Although this solution enables users to mount NFS file systems without running the kinit command and enhances ease-of-use, it is a security risk. For example, if someone gains access to a system with the root principal in its keytab, this person can obtain credentials for root. So make sure that you take the appropriate security precautions. See Administering Keytab Files for more information.