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.	How to Automatically Configure a Master KDC
	Configures and builds the master KDC server and database for a realm using an interactive process, which is sufficient for most installations	How to Interactively Configure a Master KDC
	Configures and builds the master KDC server and database for a realm using a manual process, which is needed for more complex installations	How to Manually Configure a Master KDC
	Configures and builds the master KDC server and database for a realm using a manual process and using LDAP for the KDC	How to Configure a KDC to Use an LDAP Data Server
Configure a slave KDC server.	Configures and builds a slave KDC server for a realm using an automatic process, which is good for scripts	How to Automatically Configure a Slave KDC
	Configures and builds a slave KDC server for a realm using an interactive process, which is sufficient for most installations	How to Interactively Configure a Slave KDC
	Configures and builds a slave KDC server for a realm using a manual process, which is needed for more complex installations	How to Manually Configure a Slave KDC
Refresh principal keys on a KDC server.	Updates the session key on a KDC server to use new encryption types.	How to Refresh the Ticket-Granting Service Keys on a Master Server

How to Automatically Configure a Master KDC

In the Oracle Solaris 11 release, a master KDC can be automatically configured by using the following procedure.

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

Create the KDC.

Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.

kdc1# kdcmgr -a kws/admin -r EXAMPLE.COM create master

Starting server setup
---------------------------------------

Setting up /etc/krb5/kdc.conf

Setting up /etc/krb5/krb5.conf

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 password>
Re-enter KDC database master key to verify: <Type it again>

Authenticating as principal root/admin@EXAMPLE.COM with password. 
WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy 
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. 

Setting up /etc/krb5/kadm5.acl. 

--------------------------------------------------- 
Setup COMPLETE. 

kdc1#

How to Interactively Configure a Master KDC

In the Oracle Solaris release, a master KDC can be interactively configured by using the following procedure.

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

Create the KDC.

Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.

kdc1# kdcmgr create master

Starting server setup
---------------------------------------

Enter the Kerberos realm: EXAMPLE.COM

Setting up /etc/krb5/kdc.conf

Setting up /etc/krb5/krb5.conf

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 password>
Re-enter KDC database master key to verify: <Type it again>

Enter the krb5 administrative principal to be created: kws/admin

Authenticating as principal root/admin@EXAMPLE.COM with password. 
WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy 
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. 

Setting up /etc/krb5/kadm5.acl. 

--------------------------------------------------- 
Setup COMPLETE. 

kdc1#

Example 21-1 Displaying the Status of a KDC Server

The kdcmgr status command can be used to display information about either a master or a slave KDC server.

How to Manually Configure a Master KDC

In this procedure, incremental propagation is configured. In addition, the following configuration parameters are used:

Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
admin principal = kws/admin
Online help URL = http://docs.oracle.com/cd/E23824_01/html/821-1456/aadmin-23.html

Note - Adjust the URL to point to the section, as described in Online Help URL in the Graphical Kerberos Administration Tool.

Before You Begin

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

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

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
        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://docs.oracle.com/cd/E23824_01/html/821-1456/aadmin-23.html
        }

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.
```
kdc1 # cat /etc/krb5/kdc.conf
[kdcdefaults]
        kdc_ports = 88,750

[realms]
        EXAMPLE.COM = {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
                }
```
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.
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: 
```

Start the Kerberos daemons.

kdc1 # svcadm enable -r network/security/krb5kdc
kdc1 # svcadm enable -r network/security/kadmin

Start kadmin and add more principals.

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.

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

Create the master KDC host principal.
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.
```
kadmin: addprinc -randkey host/kdc1.example.com
Principal "host/kdc1.example.com@EXAMPLE.COM" created.
kadmin: 
```
(Optional) Create the kclient principal.
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.
```
kadmin: addprinc clntconfig/admin
Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password>
Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again>
Principal "clntconfig/admin@EXAMPLE.COM" created.
kadmin: 
```

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 by application servers, like sshd, automatically.

kadmin: ktadd host/kdc1.example.com
Entry for principal host/kdc1.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 host/kdc1.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 host/kdc1.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 host/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

Quit kadmin.
```
kadmin: quit
```

(Optional) Synchronize the master KDCs 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.
Configure Slave KDCs.
To provide redundancy, make sure to install at least one slave KDC. See How to Manually Configure a Slave KDC for specific instructions.

How to Configure a KDC to Use an LDAP Data Server

Use the following procedure to configure a KDC to use an LDAP data server.

In this procedure, the following configuration parameters are used:

Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Directory Server = dsserver.example.com
admin principal = kws/admin
FMRI for the LDAP service = svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1
Online help URL = http://docs.oracle.com/cd/E23824_01/html/821-1456/aadmin-23.html

Note - Adjust the URL to point to the section, as described in Online Help URL in the Graphical Kerberos Administration Tool.

Before You Begin

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.

You must assume the root role on the KDC server. For more information, see How to Use Your Assigned Administrative Rights.

Configure the master KDC to use SSL to reach the directory server.
The following steps configure an 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.
1. On the directory server, export the self-signed directory server certificate.
```
# /export/sun-ds6.1/ds6/bin/dsadm show-cert -F der /export/sun-ds6.1/directory2 \
        defaultCert > /tmp/defaultCert.cert.der
```
2. On the master KDC, import the directory server certificate.
```
# pktool setpin keystore=nss dir=/var/ldap
# chmod a+r /var/ldap/*.db
# pktool import keystore=nss objtype=cert trust="CT" infile=/tmp/defaultCert.certutil.der \
        label=defaultCert dir=/var/ldap
```
3. On the master KDC, test that SSL is working.
  This example assumes that the cn=directory managerentry has administration privileges.
```
/usr/bin/ldapsearch -Z -P /var/ldap -D "cn=directory manager" \
        -h dsserver.example.com -b "" -s base objectclass='*'
Subject:
    "CN=dsserver.example.com,CN=636,CN=Directory Server,O=Example Corporation
```
  Note that the CN=dsserver.example.com entry should include the fully qualified host name, not a short version.
Populate the LDAP directory, if necessary.

Add the Kerberos schema to the existing schema.

# ldapmodify -h dsserver.example.com -D "cn=directory manager" -f /usr/share/lib/ldif/kerberos.ldif

Create the Kerberos container in the LDAP directory.

Add the following entries to the krb5.conf file.

Define the database type.
Add an entry to define the database_module to the realms section.
```
database_module = LDAP
```

Define the database module.

[dbmodules]
    LDAP = {
        ldap_kerberos_container_dn = "cn=krbcontainer,dc=example,dc=com"
        db_library = kldap
        ldap_kdc_dn = "cn=kdc service,ou=profile,dc=example,dc=com"
        ldap_kadmind_dn = "cn=kadmin service,ou=profile,dc=example,dc=com"
        ldap_cert_path = /var/ldap
        ldap_servers = ldaps://dsserver.example.com
    }

Create the KDC in the LDAP directory.
This command creates krbcontainer and several other objects. It also creates a /var/krb5/.k5.EXAMPLE.COM master key stash file.
```
# kdb5_ldap_util -D "cn=directory manager" create -P abcd1234 -r EXAMPLE.COM -s
```

Stash the KDC bind Distinguished Name (DN) passwords.
These passwords are used by the KDC when it binds to the DS. The KDC uses different roles depending on the type of access the KDC is using.
```
# kdb5_ldap_util stashsrvpw "cn=kdc service,ou=profile,dc=example,dc=com"
# kdb5_ldap_util stashsrvpw "cn=kadmin service,ou=profile,dc=example,dc=com"
```

Add KDC service roles.

Create a kdc_roles.ldif file with contents like this:

dn: cn=kdc service,ou=profile,dc=example,dc=com
cn: kdc service
sn: kdc service
objectclass: top
objectclass: person
userpassword: test123

dn: cn=kadmin service,ou=profile,dc=example,dc=com
cn: kadmin service
sn: kadmin service
objectclass: top
objectclass: person
userpassword: test123

Create the role entries in the LDAP directory

# ldapmodify -a -h dsserver.example.com -D "cn=directory manager" -f kdc_roles.ldif

Set the ACLs for the KDC-related roles.

# cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager" 
# Set kadmin ACL for everything under krbcontainer.
dn: cn=krbcontainer,dc=example,dc=com
changetype: modify
add: aci
aci: (target="ldap:///cn=krbcontainer,dc=example,dc=com")(targetattr="krb*")(version 3.0;\
      acl kadmin_ACL; allow (all)\
      userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";)

# Set kadmin ACL for everything under the people subtree if there are
# mix-in entries for krb princs:
dn: ou=people,dc=example,dc=com
changetype: modify
add: aci
aci: (target="ldap:///ou=people,dc=example,dc=com")(targetattr="krb*")(version 3.0;\
      acl kadmin_ACL; allow (all)\
      userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";)
EOF

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
        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://docs.oracle.com/cd/E23824_01/html/821-1456/aadmin-23.html
        }

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.

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
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
                }
```
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: 
```
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. Quit kadmin.local.
  You have added all of the required principals for the next steps.
```
kadmin.local: quit
```

(Optional) Configure LDAP dependencies for Kerberos services.

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.

Add the dependency to the krb5kdc service.

# svccfg -s security/krb5kdc
svc:/network/security/krb5kdc> addpg dsins1 dependency
svc:/network/security/krb5kdc> setprop dsins1/entities = \
    fmri: "svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1"
svc:/network/security/krb5kdc> setprop dsins1/grouping = astring: "require_all"
svc:/network/security/krb5kdc> setprop dsins1/restart_on = astring: "restart"
svc:/network/security/krb5kdc> setprop dsins1/type = astring: "service"
svc:/network/security/krb5kdc> exit

Add the dependency to the kadmin service.

# svccfg -s security/kadmin
svc:/network/security/kadmin> addpg dsins1 dependency
svc:/network/security/kadmin> setprop dsins1/entities =\
    fmri: "svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1"
svc:/network/security/kadmin> setprop dsins1/grouping = astring: "require_all"
svc:/network/security/kadmin> setprop dsins1/restart_on = astring: "restart"
svc:/network/security/kadmin> setprop dsins1/type = astring: "service"
svc:/network/security/kadmin> exit

Start the Kerberos daemons.

kdc1 # svcadm enable -r network/security/krb5kdc
kdc1 # svcadm enable -r network/security/kadmin

Start kadmin and add more principals.

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.

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

Create the master KDC host principal.
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.
```
kadmin: addprinc -randkey host/kdc1.example.com
Principal "host/kdc1.example.com@EXAMPLE.COM" created.
kadmin: 
```
(Optional) Create the kclient principal.
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.
```
kadmin: addprinc clntconfig/admin
Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password>
Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again>
Principal "clntconfig/admin@EXAMPLE.COM" created.
kadmin: 
```

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
Entry for principal host/kdc1.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 host/kdc1.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 host/kdc1.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 host/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

Quit kadmin.
```
kadmin: quit
```

(Optional) Synchronize the master KDCs 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.
Configure Slave KDCs.
To provide redundancy, make sure to install at least one slave KDC. See How to Manually Configure a Slave KDC for specific instructions.

How to Automatically Configure a Slave KDC

In the Oracle Solaris release, a slave KDC can be automatically configured by using the following procedure.

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

Create the KDC.

Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.

kdc2# kdcmgr -a kws/admin -r EXAMPLE.COM create -m kdc1 slave

Starting server setup
---------------------------------------

Setting up /etc/krb5/kdc.conf

Setting up /etc/krb5/krb5.conf
Obtaining TGT for kws/admin ... 
Password for kws/admin@EXAMPLE.COM: <Type the password>

Setting up /etc/krb5/kadm5.acl. 

Setting up /etc/krb5/kpropd.acl. 

Waiting for database from master... 
Waiting for database from master... 
Waiting for database from master... 
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 password>

--------------------------------------------------- 
Setup COMPLETE. 

kdc2#

How to Interactively Configure a Slave KDC

Use the following procedure to interactively configure a slave KDC.

Before You Begin

You must assume the root role. For more information, see How to Use Your Assigned Administrative Rights.

Create the KDC.

Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.

kdc1# kdcmgr create slave

Starting server setup
---------------------------------------

Enter the Kerberos realm: EXAMPLE.COM
What is the master KDC's host name?: kdc1

Setting up /etc/krb5/kdc.conf

Setting up /etc/krb5/krb5.conf
Obtaining TGT for kws/admin ... 
Password for kws/admin@EXAMPLE.COM: <Type the password>

Setting up /etc/krb5/kadm5.acl. 

Setting up /etc/krb5/kpropd.acl. 

Waiting for database from master... 
Waiting for database from master... 
Waiting for database from master... 
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 password>

--------------------------------------------------- 
Setup COMPLETE. 

kdc2#

How to Manually Configure a Slave KDC

In this procedure, a new slave KDC named kdc2 is configured. Also, incremental propagation is configured. This procedure uses the following configuration parameters:

Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com
admin principal = kws/admin

Before You Begin

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.

You must assume the root role on the KDC server. For more information, see How to Use Your Assigned Administrative Rights.

On the master KDC, start kadmin.
You must log in with one of the admin principal names that you created when you configured the master KDC.
```
kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: 
```
1. 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.
```
kadmin: addprinc -randkey host/kdc2.example.com
Principal "host/kdc2.example.com@EXAMPLE.COM" created.
kadmin: 
```
2. On the master KDC, create the kiprop principal.
  The kiprop principal is used to authorize incremental propagation from the master KDC.
```
kadmin: addprinc -randkey kiprop/kdc2.example.com
Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.
kadmin:
```
3. Quit kadmin.
```
kadmin: quit
```

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

On the master KDC, add an kiprop entry to kadm5.acl.
This entry allows the master KDC to receive requests for incremental propagation for the kdc2 server.
```
kdc1 # cat /etc/krb5/kadm5.acl
*/admin@EXAMPLE.COM *
kiprop/kdc2.example.com@EXAMPLE.COM p
```
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.
This information needs to be updated on all slave KDC servers.
```
kdc2 # cat /etc/krb5/kpropd.acl
host/kdc1.example.com@EXAMPLE.COM
host/kdc2.example.com@EXAMPLE.COM
```
On all slave KDCs, make sure that the Kerberos access control list file, kadm5.acl, is not populated.
An unmodified kadm5.acl file would look like:
```
kdc2 # cat /etc/krb5/kadm5.acl
*/admin@___default_realm___ *
```
If the file has kiprop entries, remove them.

On the new slave, change an entry in kdc.conf.

Replace the sunw_dbprop_master_ulogsize entry with an entry defining sunw_dbprop_slave_poll. The entry sets the poll time to two minutes.

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

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

On the new slave, start the kadmin command.

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

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

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.

kadmin: ktadd host/kdc2.example.com
Entry for principal host/kdc2.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 host/kdc2.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 host/kdc2.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 host/kdc2.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc2.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

Add the kiprop principal to the slave KDC's keytab file.

Adding the kiprop principal to the krb5.keytab file allows the kpropd command to authenticate itself when incremental propagation is started.

kadmin: ktadd kiprop/kdc2.example.com
Entry for principal kiprop/kdc2.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 kiprop/kdc2.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 kiprop/kdc2.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 kiprop/kdc2.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc2.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

Quit kadmin.
```
kadmin: quit
```

On the new slave, start the Kerberos propagation daemon.
```
kdc2 # svcadm enable network/security/krb5_prop
```

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

kdc2 # /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>

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

Refresh the TGS service principal key.

kdc1 % /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM

Example 21-2 Refreshing the Principal Keys from a Master Server

If you are logged on to the KDC master as root, you can refresh the TGS service principal with the following command:

kdc1 # kadmin.local -q 'cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM'

Skip Navigation Links
Exit Print View
	Oracle Solaris 11.1 Administration: Security Services Oracle Solaris 11.1 Information Library