How to Configure a KDC to Use an LDAP Data Server (System Administration Guide: Security Services)

System Administration Guide: Security Services

How to Configure a KDC to Use an LDAP Data Server

Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a KDC can be configured to use an LDAP data server by using the following procedure.

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
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956

Note –
Adjust the URL to point to the “Graphical Kerberos Administration Tool” 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 procedure below works with servers using the Sun Java^TM Directory Server Enterprise Edition release.

Become superuser on the KDC.

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

The following steps configure a Solaris Express Developer Release KDC to use the Directory Server 6.1 self-signed certificate. If the certificate has expired, follow the instructions for renewing a certificate in To Manage Self-Signed Certificates in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.

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

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

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 Solaris 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_moduleto 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://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
        }

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.

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

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:

Quit kadmin.local.

You have added all of the required principals for the next steps.
kadmin.local: quit

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 klist and kprop. Solaris 10 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 /etc/resolv.conf file.
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.