test

System Administration Guide: Security Services

Configuring KDC Servers

After you install the SEAM software, you must configure the KDC servers. Configuring a master KDC and at least one slave KDC provides the service that issues credentials. These credentials are the basis for SEAM, so the KDCs must be installed before you attempt other tasks.

The most significant difference between a master KDC and a slave KDC is that only the master KDC can handle database administration requests. For instance, changing a password or adding a new principal must be done on the master KDC. These changes can then be propagated to the slave KDCs. Both the slave KDC and master KDC generate credentials. This feature provides redundancy in case the master KDC cannot respond.

How to Configure a Master KDC

In this procedure, the following configuration parameters are used:

  1. Complete the prerequisites for configuring a master KDC.

    This procedure requires that DNS must be running. For specific naming instructions if this master is to be swappable, see Swapping a Master KDC and a Slave KDC.

  2. Become superuser on the master KDC.

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

    You need to change the realm names and the names of the servers. See the krb5.conf(4) man page for a full description of this file.


    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
        }

    In this example, the lines for domain_realm, kdc, admin_server, and all domain_realm entries were changed. In addition, the line that defines the help_url was edited.

  4. Edit the KDC configuration file (kdc.conf).

    You need to change the realm name. See the kdc.conf(4) man page for a full description of this file. 


    kdc1 # cat /etc/krb5/kdc.conf
[kdcdefaults]
        kdc_ports = 88,750

[realms]
        EXAMPLE.COM= {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
        }

    In this example, the realm name definition in the realms section was changed.

  5. Create the KDC database by using the kdb5_util command.

    The kdb5_util command creates the KDC database. Also, when used with the -s option, this command creates a stash file that is used to authenticate the KDC to itself before the kadmind and krb5kdc daemons are started. 


    kdc1 # /usr/sbin/kdb5_util create -r EXAMPLE.COM -s
Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM'
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: <type the key>
Re-enter KDC database master key to verify: <type it again>

    The -r option followed by the realm name is not required if the realm name is equivalent to the domain name in the server's name space.

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

  7. Start the kadmin.local command.

    The next sub-steps create principals that are used by SEAM.


    kdc1 # /usr/sbin/kadmin.local
kadmin.local:

    1. Add administration principals to the database.

      You can add as many admin principals as you need. You must add at least one admin principal to complete the KDC configuration process. For this example, a kws/admin principal is added. You can substitute an appropriate principal name instead of “kws.”


      kadmin.local: addprinc kws/admin
Enter password for principal kws/admin@EXAMPLE.COM: <type the password>
Re-enter password for principal kws/admin@EXAMPLE.COM: <type it again>
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:

    2. Create a keytab file for the kadmind service.

      This command sequence creates a special keytab file with principal entries for kadmin and changepw. These principals are needed for the kadmind service. 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.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.example.com
Entry for principal kadmin/kdc1.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/kdc1.example.com
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type DES-CBC-CRC 
          added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:

    3. Quit kadmin.local.

      You have added all of the required principals for the next steps.


      kadmin.local: quit

  8. Start the Kerberos daemons.


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

  9. Start kadmin.

    At this point, you can add principals by using the SEAM Administration Tool. To do so, you must log on with one of the admin principal names that you created earlier in this procedure. However, the following command-line example is shown for simplicity. 


    kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin:

    1. Create the master KDC host principal.

      The host principal is used by Kerberized applications (such as klist and kprop) . 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 -randkey host/kdc1.example.com
Principal "host/kdc1.example.com@EXAMPLE.COM" created.
kadmin:

    2. (Optional) Create the master KDC root principal.

      This principal is used for authenticated NFS-mounting. So, the principal might not be necessary on a master KDC. 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/kdc1.example.com
Enter password for principal root/kdc1.example.com@EXAMPLE.COM: <type the password>
Re-enter password for principal root/kdc1.example.com@EXAMPLE.COM: <type it again>
Principal "root/kdc1.example.com@EXAMPLE.COM" created.
kadmin:

    3. Add the master KDC's host principal to the master KDC's keytab file.

      Adding the host principal to the keytab file allows this principal to be used automatically.


      kadmin: ktadd host/kdc1.example.com
kadmin: Entry for principal host/kdc1.example.com with
  kvno 3, encryption type DES-CBC-CRC added to keytab
  WRFILE:/etc/krb5/krb5.keytab
kadmin:

    4. Quit kadmin.


      kadmin: quit

  10. Add an entry for each KDC into the propagation configuration file (kpropd.acl).

    See the kprop(1M) man page for a full description of this file.


    kdc1 # cat /etc/krb5/kpropd.acl
host/kdc1.example.com@EXAMPLE.COM
host/kdc2.example.com@EXAMPLE.COM

  11. (Optional) Synchronize the master KDCs 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.

How to Configure a Slave KDC

In this procedure, a new slave KDC named kdc3 is configured. This procedure uses the following configuration parameters:

  1. Complete the prerequisites for configuring a slave KDC.

    The master KDC must be configured. For specific instructions if this slave is to be swappable, see Swapping a Master KDC and a Slave KDC.

  2. On the master KDC, become superuser.

  3. On the master KDC, start kadmin.

    You must log on with one of the admin principal names that you created when you configure the master KDC.


    kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Enter kws/admin password>
kadmin:

    1. On the master KDC, add slave host principals to the database, if not already done.

      In order for the slave to function, it must have a host 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 -randkey host/kdc3.example.com
Principal "host/kdc3@EXAMPLE.COM" created.
kadmin:

    2. (Optional) On the master KDC, create the slave KDC root principal.

      This principal is only needed if the slave will be NFS-mounting an authenticated file system. 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/kdc3.example.com
Enter password for principal root/kdc3.example.com@EXAMPLE.COM: <type the password>
Re-enter password for principal root/kdc3.example.com@EXAMPLE.COM: <type it again>
Principal "root/kdc3.example.com@EXAMPLE.COM" created.
kadmin:

    3. Quit kadmin.


      kadmin: quit

  4. On the master KDC, edit the Kerberos configuration file (krb5.conf).

    You need to add an entry for each slave. See the krb5.conf(4) man page for a full description of this file.


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

[realms]
                EXAMPLE.COM = {
                kdc = kdc1.example.com
                kdc = kdc2.example.com
                kdc = kdc3.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

  5. On the master KDC, add an entry for each slave KDC into the database propagation configuration file (kpropd.acl).

    See the kprop(1M) man page for a full description of this file. 


    kdc1 # cat /etc/krb5/kpropd.acl
host/kdc1.example.com@EXAMPLE.COM
host/kdc2.example.com@EXAMPLE.COM
host/kdc3.example.com@EXAMPLE.COM

  6. On all slave KDCs, copy the KDC administration files from the master KDC server.

    This step needs to be followed on all slave KDCs, since the master KDC server has updated information that each KDC server needs. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master KDC:

    • /etc/krb5/krb5.conf

    • /etc/krb5/kdc.conf

    • /etc/krb5/kpropd.acl

  7. On the new slave, add the slave's host principal to the slave's keytab file by using kadmin.

    You must log on with one of the admin principal names that you created when you configure the master KDC. This entry allows kprop and other Kerberized applications to function. 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.


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

  8. On the master KDC, add slave KDC names to the cron job, which automatically runs the backups, by running crontab -e.

    Add the name of each slave KDC server at the end of the kprop_script line. 


    10 3 * * * /usr/lib/krb5/kprop_script kdc2.example.com kdc3.example.com

    You might also want to change the time of the backups. This configuration starts the backup process every day at 3:10 AM.

  9. On the master KDC, back up and propagate the database by using kprop_script.

    If a backup copy of the database is already available, it is not necessary to complete another backup. See How to Manually Propagate the Kerberos Database to the Slave KDCs for further instructions.


    kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com
Database propagation to kdc3.example.com: SUCCEEDED

  10. On the new slave, create a stash file by using kdb5_util.


    kdc3 # /usr/sbin/kdb5_util stash
kdb5_util: Cannot find/read stored master key while reading master key
kdb5_util: Warning: proceeding without master key

Enter KDC database master key: <type the key>

  11. (Optional) On the new slave KDC, synchronize the master KDCs 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.

  12. On the new slave, start the KDC daemon (krb5kdc).


    kdc3 # /etc/init.d/kdc start