Configuring KDC Servers

After you install the Kerberos 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 the Kerberos service, 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.

Table 21-1 Configuring KDC Servers (Task Map)

Task

Description

For Instructions

Configure a master KDC.

Configures and builds
the master KDC server and database for a realm by using an automatic
process, which is good for scripts.

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

Note - If you want to restrict the encryption types, you can set the
default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved
with restricting the encryption types.

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.

In this example, the realm name definition in the realms section was changed.
Also, in the realms section, lines to enable incremental propagation and to select
the number of updates the KDC master keeps in the log were added.

Note - If you want to restrict the encryption types, you can set the
permitted_enctypes, supported_enctypes, or master_key_type lines. Refer to Using Kerberos Encryption Types for a description of
the issues involved with restricting the encryption types.

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

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.

kws/admin@EXAMPLE.COM *

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

Start the kadmin.local command and add principals.

The next substeps create principals that are used by the Kerberos service.

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

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

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

The host principal is used by Kerberized applications, such as kprop to propagate changes
to the slave KDCs. This principal is also used to provide secure
remote access to the KDC server using applications, like ssh. 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.

This principal is used by the kclient utility during the installation of a Kerberos
client. If you do not plan on using this utility, then you
do not need to add the principal. The users of the kclient utility need
to use this password.

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

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

This procedure also requires that the host is configured to use
DNS. For better performance, install the KDC and the LDAP Directory Service on the
same server. In addition, a directory server should be running. The following procedure
works with servers using the Sun Directory Server Enterprise Edition 7.0 release.

Become superuser on the KDC.

Configure the master KDC to use SSL to reach the directory server.

The following steps configure an Oracle Solaris release KDC to use the Directory Server
self-signed certificate. If the certificate has expired, follow the instructions for renewing a
certificate in To Manage Self-Signed Certificates.

On the directory server, export the self-signed directory server certificate.

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

Note - If you want to restrict the encryption types, you can set the
default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved
with restricting the encryption types.

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.

In this example, the realm name definition in the realms section was changed.
Also, in the realms section, lines to enable incremental propagation and to select
the number of updates the KDC master keeps in the log were added.

Note - If you want to restrict the encryption types, you can set the
permitted_enctypes, supported_enctypes, or master_key_type lines. Refer to Using Kerberos Encryption Types for a description of
the issues involved with restricting the encryption types.

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.

kws/admin@EXAMPLE.COM *

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

Start the kadmin.local command and add principals.

The next substeps create principals that are used by the Kerberos service.

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

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

If the LDAP and KDC servers are running on the same host and
if the LDAP service is configured with a SMF FMRI, add a
dependency to the LDAP service for the Kerberos daemons. This dependency will restart the
KDC service if the LDAP service is restarted.

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

The host principal is used by Kerberized applications, such as klist and kprop.
Clients use this principal when mounting an authenticated NFS file system. 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.

This principal is used by the kclient utility during the installation of a Kerberos
client. If you do not plan on using this utility, then you
do not need to add the principal. The users of the kclient utility need
to use this password.

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

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

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

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 specified
in lowercase letters, regardless of the case of the domain name in the
name service.

On the master KDC, restart kadmind to use the new entries in the
kadm5.acl file.

kdc1 # svcadm restart network/security/kadmin

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

This step needs to be followed on all slave KDCs, because 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

On all slave KDCs, add an entry for the master KDC and
each slave KDC into the database propagation configuration file, kpropd.acl.

Add the slave's host principal to the slave's keytab file by using
kadmin.

This entry allows kprop and other Kerberized applications to function. 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.

(Optional) On the new slave KDC, synchronize the master KDC's clock by using NTP
or another clock synchronization mechanism.

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

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

kdc2 # svcadm enable network/security/krb5kdc

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

When the ticket-granting service (TGS) principal only has a DES key, which is
the case for KDC servers created prior to the Solaris 10 release,
the key restricts the encryption type of the ticket-granting ticket (TGT) session key to
DES. If a KDC is updated to a release that supports
additional, stronger encryption types, the administrator can expect that stronger encryption will be used
for all session keys generated by the KDC. However, if the
existing TGS principal does not have its keys refreshed to include the new
encryption types, then the TGT session key will be continue to be limited
to DES. The following procedure refreshes the key so that additional encryption types can
be used.