Sun Microsystems, Inc.
spacerspacer
spacer www.sun.com docs.sun.com |
spacer
black dot
 
 
8.  Configuring SEAM (Tasks) Configuring SEAM Clients How to Configure a SEAM Client  Previous   Contents   Next 
   
 

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.

Synchronizing Clocks between KDCs and SEAM Clients

All hosts that participate in the Kerberos authentication system must have their internal clocks synchronized within a specified maximum amount of time (known as clock skew). This requirement provides another Kerberos security check. If the clock skew is exceeded between any of the participating hosts, client requests are rejected.

The clock skew also determines how long application servers must keep track of all Kerberos protocol messages, in order to recognize and reject replayed requests. So, the longer the clock skew value, the more information that application servers have to collect.

The default value for the maximum clock skew is 300 seconds (five minutes). You can change this default in the libdefaults section of the krb5.conf file.


Note - For security reasons, do not increase the clock skew beyond 300 seconds.


Since it is important to maintain synchronized clocks between the KDCs and SEAM clients, you should use the Network Time Protocol (NTP) software to synchronize them. NTP public domain software from the University of Delaware is included in the Solaris software, starting with the Solaris 2.6 release.


Note - Another way to synchronize clocks is to use the rdate command and cron jobs, a process that can be less involved than using NTP. However, this section will continue to focus on using NTP. And, if you use the network to synchronize the clocks, the clock synchronization protocol must itself be secure.


NTP enables you to manage precise time or network clock synchronization, or both, in a network environment. NTP is basically a server/client implementation. You pick one system to be the master clock (the NTP server). Then, you set up all your other systems (the NTP clients) to synchronize their clocks with the master clock.

To synchronize the clocks, NTP uses the xntpd daemon, which sets and maintains a UNIX system time-of-day in agreement with Internet standard time servers. The following shows an example of this server/client NTP implementation.

Figure 8-1 Synchronizing Clocks by Using NTP

To ensure that the KDCs and SEAM clients maintain synchronized clocks, implement the following steps:

  1. Set up an NTP server on your network (this server can be any system, except the master KDC). See "Managing Network Time Protocol (Tasks)" in System Administration Guide: Resource Management and Network Services to find the NTP server task.

  2. As you configure the KDCs and SEAM clients on the network, set them up to be NTP clients of the NTP server. See "Managing Network Time Protocol (Tasks)" in System Administration Guide: Resource Management and Network Services to find the NTP client task.

Swapping a Master KDC and a Slave KDC

You should use the procedures in this section to make the swap of a master KDC with a slave KDC easier. You should swap the master KDC with a slave KDC only if the master KDC server fails for some reason, or if the master KDC needs to be re-installed (for example, because new hardware is installed).

How to Configure a Swappable Slave KDC

Perform this procedure on the slave KDC server that you want to have available to become the master KDC.

  1. Use alias names for the master KDC and the swappable slave KDC during the KDC installation.

    When you define the host names for the KDCs, make sure that each system has an alias included in DNS. Also, use the alias names when you define the hosts in the /etc/krb5/krb5.conf file.

  2. Follow the steps to install a slave KDC.

    Prior to any swap, this server should function as any other slave KDC in the realm. See "How to Configure a Slave KDC" for instructions.

  3. Move the master KDC commands.

    To prevent the master KDC commands from being run from this slave KDC, move the kprop, kadmind and kadmin.local commands to a reserved place.

    kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save
    kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save
    kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save
  4. Comment out the kprop line in the root crontab file.

    This step prevents the slave KDC from propagating its copy of the KDC database.

    kdc4 # crontab -e
    #ident  "@(#)root       1.19    98/07/06 SMI"   /* SVr4.0 1.1.3.1       */
    #
    # The root crontab should be used to perform accounting data collection.
    #
    # The rtc command is run to adjust the real time clock if and when
    # daylight savings time changes.
    #
    10 3 * * 0,4 /etc/cron.d/logchecker
    10 3 * * 0   /usr/lib/newsyslog
    15 3 * * 0 /usr/lib/fs/nfs/nfsfind
    1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
    30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
    #10 3 * * * /usr/lib/krb5kprop_script kdc1.example.sun.com #SUNWkr5ma

How to Swap a Master KDC and a Slave KDC

This procedure requires that the slave KDC server has been set up as a swappable slave (see "How to Configure a Swappable Slave KDC"). In this procedure, the master KDC server that is being swapped out is named kdc1. The slave KDC that will become the new master KDC is named kdc4.

  1. On the old master KDC, kill the kadmind process.

    kdc1 # /etc/init.d/kdc.master stop

    When you kill the kadmind process, you prevent any changes from being made to the KDC database.

  2. On the old master KDC, comment out the kprop line in the root crontab file.

    kdc1 # crontab -e
    #ident  "@(#)root       1.19    98/07/06 SMI"   /* SVr4.0 1.1.3.1       */
    #
    # The root crontab should be used to perform accounting data collection.
    #
    # The rtc command is run to adjust the real time clock if and when
    # daylight savings time changes.
    #
    10 3 * * 0,4 /etc/cron.d/logchecker
    10 3 * * 0   /usr/lib/newsyslog
    15 3 * * 0 /usr/lib/fs/nfs/nfsfind
    1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
    30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
    #10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.sun.com #SUNWkr5ma

    This step prevents the old master from propagating its copy of the KDC database.

  3. On the old master KDC, run kprop_script to back up and propagate the database.

    kdc1 # /usr/lib/krb5/kprop_script kdc4.example.com
    Database propagation to kdc4.example.com: SUCCEEDED
  4. On the old master KDC, move the master KDC commands.

    To prevent the master KDC commands from being run, move the kprop, kadmind and kadmin.local commands to a reserved place.

    kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save
    kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save
    kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save
    kdc4 # mv /etc/krb5/kadm5.acl /etc/krb5/kadm5.acl.save
  5. On the DNS server, change the alias names for the master KDC.

    To change the servers, edit the example.com zone file and change the entry for masterkdc.

    masterkdc IN CNAME kdc4
  6. On the DNS server, restart the Internet domain name server.

    Run the following command on both servers to get the new alias information:

    # pkill -1 in.named
  7. On the new master KDC, move the master KDC commands.

    kdc4 # mv /usr/lib/krb5/kprop.save /usr/lib/krb5/kprop
    kdc4 # mv /usr/lib/krb5/kadmind.save /usr/lib/krb5/kadmind
    kdc4 # mv /usr/sbin/kadmin.local.save /usr/sbin/kadmin.local
  8. On the new master KDC, edit the Kerberos access control list file (kadm5.acl).

    Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC. The first entry that is added might look similar to the following:

    kws/admin@EXAMPLE.COM   *

    This entry gives the kws/admin principal in the EXAMPLE.COM realm the ability to modify principals or policies in the KDC. The default installation includes an asterisk (*) to match all admin principals. This default could be a security risk, so it is more secure to include a list of all of the admin principals. See the kadm5.acl(4) man page for more information.

  9. On the new master KDC, create a keytab file for kadmin by using kadmin.local.

    This command sequence creates a special keytab file with principal entries for admin and changepw. These principals are needed for the kadmind service.

    kdc4 # /usr/sbin/kadmin.local
    kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc4.example.com
    Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type DES-CBC-CRC
              added to keytab WRFILE:/etc/krb5/kadm5.keytab.
    kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc4.example.com
    Entry for principal changepw/kdc4.example.com with kvno 3, encryption type DES-CBC-CRC 
              added to keytab WRFILE:/etc/krb5/kadm5.keytab.
    kadmin.local: quit
  10. On the new master KDC, start kadmind.

    kdc4 # /etc/init.d/kdc.master start
  11. Enable the kprop line in the root crontab file.

    kdc4 # crontab -e
    #ident  "@(#)root       1.19    98/07/06 SMI"   /* SVr4.0 1.1.3.1       */
    #
    # The root crontab should be used to perform accounting data collection.
    #
    # The rtc command is run to adjust the real time clock if and when
    # daylight savings time changes.
    #
    10 3 * * 0,4 /etc/cron.d/logchecker
    10 3 * * 0   /usr/lib/newsyslog
    15 3 * * 0 /usr/lib/fs/nfs/nfsfind
    1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1
    30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean
    10 3 * * * /usr/lib/krb5/kprop_script kdc1.example.sun.com #SUNWkr5ma
 
 
 
  Previous   Contents   Next