System Administration Guide: Security Services

Chapter 23 Configuring the Kerberos Service (Tasks)

This chapter provides configuration procedures for KDC servers, network application servers, NFS servers, and Kerberos clients. Many of these procedures require superuser access, so they should be used by system administrators or advanced users. Cross-realm configuration procedures and other topics related to KDC servers are also covered.

The following topics are covered.

Configuring the Kerberos Service (Task Map)

Parts of the configuration process depend on other parts and must be done in a specific order. These procedures often establish services that are required to use the Kerberos service. Other procedures are not dependent on any order, and can be done when appropriate. The following task map shows a suggested order for a Kerberos installation.

Task	Description	For Instructions
1. Plan for your Kerberos installation.	Lets you resolve configuration issues before you start the software configuration process. Planning ahead saves you time and other resources in the long run.	Chapter 22, Planning for the Kerberos Service
2. (Optional) Install NTP.	Configures the Network Time Protocol (NTP) software, or another clock synchronization protocol. In order for the Kerberos service to work properly, the clocks on all systems in the realm must be synchronized.	Synchronizing Clocks Between KDCs and Kerberos Clients
3. Configure the KDC servers.	Configures and builds the master KDC and the slave KDC servers and the KDC database for a realm.	Configuring KDC Servers
4. (Optional) Increase security on the KDC servers.	Prevents security breaches on the KDC servers.	How to Restrict Access to KDC Servers
5. (Optional) Configure swappable KDC servers.	Makes the task of swapping the master KDC and a slave KDC easier.	How to Configure a Swappable Slave KDC

Configuring Additional Kerberos Services (Task Map)

Once the required steps have been completed, the following procedures can be used, when appropriate.

Task	Description	For Instructions
Configure cross-realm authentication.	Enables communications from one realm to another realm.	Configuring Cross-Realm Authentication
Configure Kerberos application servers.	Enables a server to support services such as `ftp`, `telnet`, and `rsh` using Kerberos authentication.	Configuring Kerberos Network Application Servers
Configure Kerberos clients.	Enables a client to use Kerberos services.	Configuring Kerberos Clients
Configure Kerberos NFS server.	Enables a server to share a file system that requires Kerberos authentication.	Configuring Kerberos NFS Servers
Increase security on an application server.	Increases security on an application server by restricting access to authenticated transactions only.	How to Enable Only Kerberized Applications

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 23–1 Configuring KDC Servers (Task Map)


Task	Description	For Instructions
Configuring a master KDC server.	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
Configuring a slave KDC server.	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
Refreshing 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 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://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 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.

Become superuser on the master KDC.

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

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:

Create the kiprop principals.

The kiprop principal is used to authorize updates from the master KDC.

kadmin.local: addprinc -randkey kiprop/kdc1.example.com
Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
kadmin.local:

Create a keytab file for the kadmind service.

This command sequence creates a special keytab file with principal entries for kadmin/<FQDN> and changepw/<FQDN>. These principals are needed for the kadmind service and for passwords to be changed. 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. The kadmin/changepw principal is used to change passwords from clients that are not running a Solaris release.

kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.example.com
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc1.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 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 AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc1.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local:

Add the kiprop principal for the master KDC server to the kadmind keytab file.

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

kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kiprop/kdc1.example.com
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
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 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 /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 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

Starting with the Solaris 10 5/08 release, 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
FMRI for the LDAP service = svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1
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.

Create a certificate for the directory server and import the certificate.

The following steps configure a S10 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.2 Administration Guide.

Export the self-signed Directory Server certificate.

# /usr/sfw/bin/certutil -L -n defaultCert -d /export/sun-ds6.1/directory/alias \
        -P 'slapd-' -a > /var/tmp/ds_cert.pem

Create the local certificate database.

# /usr/sfw/bin/certutil -N -d /var/ldap

Add the directory server certificate to the local certificate database.

# /usr/sfw/bin/certutil -A -n defaultCert -i /var/tmp/ds_cert -a -t CT -d /var/ldap

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

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 –

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
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
                }

Note –

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.

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:

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 specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.

Quit kadmin.local.

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

(Optional) Configure LDAP dependency 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 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.

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.

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

On the master KDC, become superuser.

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 /etc/resolv.conf file.
  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 2 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
                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
                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 /etc/resolv.conf file.

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 # /usr/lib/krb5/kpropd

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>

Kill the Kerberos propagation daemon.
kdc2 # pkill kpropd

(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).

When the krb5kdc service is enabled, kpropd also starts if the system is configured as a slave.
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 Solaris 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 Solaris KDC is updated to Solaris 10 which supports additional, stronger encryption types, the administrator may expect that stronger encryption will be used for all session keys generated by the KDC. However if the existing TGS principal does not have it's 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 may 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 23–1 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'

Configuring Cross-Realm Authentication

You have several ways of linking realms together so that users in one realm can be authenticated in another realm. Cross-realm authentication is accomplished by establishing a secret key that is shared between the two realms. The relationship of the realms can be either hierarchal or directional (see Realm Hierarchy).

How to Establish Hierarchical Cross-Realm Authentication

The example in this procedure uses two realms, ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

Before You Begin

The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.

Become superuser on the first master KDC.

Create ticket-granting ticket service principals for the two realms.

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

# /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM
Enter password for principal krgtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM: <Type password>
kadmin: addprinc krbtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
Enter password for principal krgtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type password>
kadmin: quit

Note –

The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM must be the same in both realms.

Add entries to the Kerberos configuration file (krb5.conf) to define domain names for every realm.
# cat /etc/krb5/krb5.conf [libdefaults] . . [domain_realm] .eng.east.example.com = ENG.EAST.EXAMPLE.COM .east.example.com = EAST.EXAMPLE.COM
In this example, domain names for the ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM realms are defined. It is important to include the subdomain first, because the file is searched top down.

Copy the Kerberos configuration file to all clients in this realm.

For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.

Repeat all of these steps in the second realm.

How to Establish Direct Cross-Realm Authentication

The example in this procedure uses two realms, ENG.EAST.EXAMPLE.COM and SALES.WEST.EXAMPLE.COM. Cross-realm authentication will be established in both directions. This procedure must be completed on the master KDC in both realms.

Before You Begin

The master KDC for each realm must be configured. To fully test the authentication process, several Kerberos clients must be configured.

Become superuser on one of the master KDC servers.

Create ticket-granting ticket service principals for the two realms.

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

# /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: addprinc krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM
Enter password for principal 
  krgtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM: <Type the password>
kadmin: addprinc krbtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM
Enter password for principal 
  krgtgt/SALES.WEST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <Type the password>
kadmin: quit

Note –

The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM must be the same in both realms.

Add entries in the Kerberos configuration file to define the direct path to the remote realm.

This example shows the clients in the ENG.EAST.EXAMPLE.COM realm. You would need to swap the realm names to get the appropriate definitions in the SALES.WEST.EXAMPLE.COM realm.

# cat /etc/krb5/krb5.conf
[libdefaults]
 .
 .
[capaths]
    ENG.EAST.EXAMPLE.COM = {
        SALES.WEST.EXAMPLE.COM = .
    }

    SALES.WEST.EXAMPLE.COM = {
         ENG.EAST.EXAMPLE.COM = .
    }

Copy the Kerberos configuration file to all clients in the current realm.

For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.

Repeat all of these steps for the second realm.

Configuring Kerberos Network Application Servers

Network application servers are hosts that provide access using one or more of the following network applications: ftp, rcp, rlogin, rsh, ssh, and telnet. Only a few steps are required to enable the Kerberos version of these commands on a server.

How to Configure a Kerberos Network Application Server

This procedure uses the following configuration parameters:

Application server = boston
admin principal = kws/admin
DNS domain name = example.com
Realm name = EXAMPLE.COM

Before You Begin

This procedure requires that the master KDC has been configured. To fully test the process, several Kerberos clients must be configured.

(Optional) Install the NTP client or another clock synchronization mechanism.

See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

Add principals for the new server and update the server's keytab.

The following command reports the existence of the host principal:

boston # klist -k |grep host
4 host/boston.example.com@EXAMPLE.COM
4 host/boston.example.com@EXAMPLE.COM
4 host/boston.example.com@EXAMPLE.COM
4 host/boston.example.com@EXAMPLE.COM

If the command does not return a principal, then create new principals using the following steps.

How to use the Graphical Kerberos Administration Tool to add a principal is explained in How to Create a New Kerberos Principal. The example in the following steps shows how to add the required principals using the command line. You must log in with one of the admin principal names that you created when configuring the master KDC.

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

Create the server's host principal.

The host principal is used:
- To authenticate traffic when using the remote commands, such as rsh and ssh.
- By pam_krb5 to prevent KDC spoofing attacks by using the host principal to verify that a user's Kerberos credential was obtained from a trusted KDC.
- To allow the root user to automatically acquire a Kerberos credential without requiring that a root principal exist. This can be useful when doing a manual NFS mount where the share requires a Kerberos credential.
This principal is required if traffic using the remote application is to be authenticated using the Kerberos service. If the server has multiple hostnames associated with it, then create a principal for each hostname using the FQDN form of the hostname.
kadmin: addprinc -randkey host/boston.example.com Principal "host/boston.example.com" created. kadmin:

Add the server's host principal to the server's keytab.

If the kadmin command is not running, restart it with a command similar to the following: /usr/sbin/kadmin -p kws/admin

If the server has multiple hostnames associated with it, then add a principal to the keytab for each hostname.

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

Configuring Kerberos NFS Servers

NFS services use UNIX user IDs (UIDs) to identify a user and cannot directly use GSS credentials. To translate the credential to a UID, a credential table that maps user credentials to UNIX UIDs might need to be created. See Mapping GSS Credentials to UNIX Credentials for more information on the default credential mapping. The procedures in this section focus on the tasks that are necessary to configure a Kerberos NFS server, to administer the credential table, and to initiate Kerberos security modes for NFS-mounted file systems. The following task map describes the tasks that are covered in this section.

Table 23–2 Configuring Kerberos NFS Servers (Task Map)


Task	Description	For Instructions
Configure a Kerberos NFS server.	Enables a server to share a file system that requires Kerberos authentication.	How to Configure Kerberos NFS Servers
Create a credential table.	Generates a credential table which can be used to provide mapping from GSS credentials to UNIX user IDs, if the default mapping is not sufficient.	How to Create a Credential Table
Change the credential table that maps user credentials to UNIX UIDs.	Updates information in the credential table.	How to Add a Single Entry to the Credential Table
Create credential mappings between two like realms.	Provides instructions on how to map UIDs from one realm to another if the realms share a password file.	How to Provide Credential Mapping Between Realms
Share a file system with Kerberos authentication.	Shares a file system with security modes so that Kerberos authentication is required.	How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

How to Configure Kerberos NFS Servers

In this procedure, the following configuration parameters are used:

Realm name = EXAMPLE.COM
DNS domain name = example.com
NFS server = denver.example.com
admin principal = kws/admin

Complete the prerequisites for configuring a Kerberos NFS server.

The master KDC must be configured. To fully test the process, you need several clients.

(Optional) Install the NTP client or another clock synchronization mechanism.

Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be synchronized with the time on the KDC server within a maximum difference defined by the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

Configure the NFS server as a Kerberos client.

Follow the instructions in Configuring Kerberos Clients.

Start kadmin.

You can use the Graphical Kerberos Administration Tool to add a principal, as explained in How to Create a New Kerberos Principal. To do so, you must log in with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.

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

Create the server's NFS service 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 /etc/resolv.conf file.

Repeat this step for each unique interface on the system that might be used to access NFS data. If a host has multiple interfaces with unique names, each unique name must have its own NFS service principal.
kadmin: addprinc -randkey nfs/denver.example.com Principal "nfs/denver.example.com" created. kadmin:

Add the server's NFS service principal to the server's keytab file.

Repeat this step for each unique service principal created in Step a.

kadmin: ktadd nfs/denver.example.com
Entry for principal nfs/denver.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 nfs/denver.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 nfs/denver.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 nfs denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.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) Create special GSS credential maps, if needed.

Normally, the Kerberos service generates appropriate maps between the GSS credentials and the UNIX UIDs. The default mapping is described in Mapping GSS Credentials to UNIX Credentials. If the default mapping is not sufficient, see How to Create a Credential Table for more information.

Share the NFS file system with Kerberos security modes.

See How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes for more information.

How to Create a Credential Table

The gsscred credential table is used by an NFS server to map Kerberos credentials to a UID. By default, the primary part of the principal name is matched to a UNIX login name. For NFS clients to mount file systems from an NFS server with Kerberos authentication, this table must be created if the default mapping is not sufficient.

Edit /etc/gss/gsscred.conf and change the security mechanism.

Change the mechanism to files.

Create the credential table by using the gsscred command.
# gsscred -m kerberos_v5 -a
The gsscred command gathers information from all sources that are listed with the passwd entry in the /etc/nsswitch.conf file. You might need to temporarily remove the files entry, if you do not want the local password entries included in the credential table. See the gsscred(1M) man page for more information.

How to Add a Single Entry to the Credential Table

Before You Begin

This procedure requires that the gsscred table has already been created on the NFS server. See How to Create a Credential Table for instructions.

Become superuser on the NFS server.

Add an entry to the credential table by using the gsscred command.
# gsscred -m mech [ -n name [ -u uid ]] -a
mech

Defines the security mechanism to be used.

name

Defines the principal name for the user, as defined in the KDC.

uid

Defines the UID for the user, as defined in the password database.

-a

Adds the UID to principal name mapping.

Example 23–2 Adding a Multiple Component Principal to the Credential Table

In the following example, an entry is added for a principal named sandy/admin, which is mapped to UID 3736.

# gsscred -m kerberos_v5 -n sandy/admin -u 3736 -a

Example 23–3 Adding a Principal in a Different Domain to the Credential Table

In the following example, an entry is added for a principal named sandy/admin@EXAMPLE.COM, which is mapped to UID 3736.

# gsscred -m kerberos_v5 -n sandy/admin@EXAMPLE.COM -u 3736 -a

How to Provide Credential Mapping Between Realms

This procedure provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID.

Become superuser.

On the client system, add entries to the krb5.conf file.

# cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = CORP.EXAMPLE.COM
 .
[realms]
    CORP.EXAMPLE.COM = {
        .
        auth_to_local_realm = SALES.EXAMPLE.COM
        .
    }

Example 23–4 Mapping Credentials Between Realms Using the Same Password File

This example provides appropriate credential mapping between realms that use the same password file. In this example, the realms CORP.EXAMPLE.COM and SALES.EXAMPLE.COM use the same password file. The credentials for bob@CORP.EXAMPLE.COM and bob@SALES.EXAMPLE.COM are mapped to the same UID. On the client system, add entries to the krb5.conf file.

# cat /etc/krb5/krb5.conf
[libdefaults]
        default_realm = CORP.EXAMPLE.COM
 .
[realms]
    CORP.EXAMPLE.COM = {
        .
        auth_to_local_realm = SALES.EXAMPLE.COM
        .
    }

Troubleshooting

See Observing Mapping from GSS Credentials to UNIX Credentials to help with the process of troubleshooting credential mapping problems.

How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

This procedure enables a NFS server to provide secure NFS access using different security modes or flavors. When a client negotiates a security flavor with the NFS server, the first flavor that is offered by the server that the client has access to is used. This flavor is used for all subsequent client requests of the file system shared by the NFS server.

Become superuser on the NFS server.

Verify that there is an NFS service principal in the keytab file.

The klist command reports if there is a keytab file and displays the principals. If the results show that no keytab file exists or that no NFS service principal exists, you need to verify the completion of all the steps in How to Configure Kerberos NFS Servers.

# klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
---- ---------------------------------------------------------
   3 nfs/denver.example.com@EXAMPLE.COM
   3 nfs/denver.example.com@EXAMPLE.COM
   3 nfs/denver.example.com@EXAMPLE.COM
   3 nfs/denver.example.com@EXAMPLE.COM

Enable Kerberos security modes in the /etc/nfssec.conf file.

Edit the /etc/nfssec.conf file and remove the “#” that is placed in front of the Kerberos security modes.

# cat /etc/nfssec.conf
 .
 .
#
# Uncomment the following lines to use Kerberos V5 with NFS
#
krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS

Edit the /etc/dfs/dfstab file and add the sec= option with the required security modes to the appropriate entries.
share -F nfs -o sec=mode file-system
mode

Specifies the security modes to be used when sharing the file system. When using multiple security modes, the first mode in the list is used as the default.

file-system

Defines the path to the file system to be shared.

All clients that attempt to access files from the named file system require Kerberos authentication. To access files, the user principal on the NFS client should be authenticated.

Make sure that the NFS service is running on the server.

If this command is the first share command or set of share commands that you have initiated, the NFS daemons are likely not running. The following command restarts the daemons:
# svcadm restart network/nfs/server

(Optional) If the automounter is being used, edit the auto_master database to select a security mode other than the default.

You need not follow this procedure if you are not using the automounter to access the file system or if the default selection for the security mode is acceptable.
file-system auto_home -nosuid,sec=mode

(Optional) Manually issue the mount command to access the file system by using a non-default mode.

Alternatively, you could use the mount command to specify the security mode, but this alternative does not take advantage of the automounter.
# mount -F nfs -o sec=mode file-system

Example 23–5 Sharing a File System With One Kerberos Security Mode

In this example, the dfstab file line means that Kerberos authentication must succeed before any files can be accessed through the NFS service.

# grep krb /etc/dfs/dfstab
share -F nfs -o sec=krb5 /export/home

Example 23–6 Sharing a File System With Multiple Kerberos Security Modes

In this example, all three Kerberos security modes have been selected. Which mode is used is negotiated between the client and the NFS server. If the first mode in the command fails, then the next is tried. See the nfssec(5) man page for more information.

# grep krb /etc/dfs/dfstab
share -F nfs -o sec=krb5:krb5i:krb5p /export/home

Configuring Kerberos Clients

Kerberos clients include any host, that is not a KDC server, on the network that needs to use Kerberos services. This section provides procedures for installing a Kerberos client, as well as specific information about using root authentication to mount NFS file systems.

Configuring Kerberos Clients (Task Map)

The following task map includes all of the procedures associated with setting up Kerberos clients. Each row includes a task identifier, a description of why you would want to do that task, followed by a link to the task.

Task	Description	For Instructions
Establish a Kerberos client installation profile.	Generates a client installation profile that can be used to automatically install a Kerberos client.	How to Create a Kerberos Client Installation Profile
Configure a Kerberos client.	Manually installs a Kerberos client. Use this procedure if each client installation requires unique installation parameters.	How to Manually Configure a Kerberos Client
	Automatically installs a Kerberos client. Use this procedure if the installation parameters for each client are the same.	How to Automatically Configure a Kerberos Client
	Interactively installs a Kerberos client. Use this procedure if only a few of the installation parameters need to change.	How to Interactively Configure a Kerberos Client
Allow a client to access a NFS file system as the `root` user	Creates a `root` principal on the client, so that the client can mount a NFS file system shared with `root` access. Also, allows for the client to set up non-interactive `root` access to the NFS file system, so that cron jobs can run.	How to Access a Kerberos Protected NFS File System as the `root` User
Disable verification of the KDC that issued a client Ticket Granting Ticket (TGT).	Allows clients that do not have a host principal stored in the local keytab file to skip the security check that verifies that the KDC that issued the TGT is the same server that issued the host principal.	How to Disable Verification of the Ticket Granting Ticket (TGT)

How to Create a Kerberos Client Installation Profile

This procedure creates a kclient profile that can be used when you install a Kerberos client. By using the kclient profile, you reduce the likelihood of typing errors. Also, using the profile reduces user intervention as compared to the interactive process.

Become superuser.

Create a kclient installation profile.

A sample kclient profile could look similar to the following:

client# cat /net/denver.example.com/export/install/profile
REALM EXAMPLE.COM
KDC kdc1.example.com
ADMIN clntconfig
FILEPATH /net/denver.example.com/export/install/krb5.conf
NFS 1
DNSLOOKUP none

How to Automatically Configure a Kerberos Client

Before You Begin

This procedure uses an installation profile. See How to Create a Kerberos Client Installation Profile.

Become superuser.

Run the kclient installation script.

You need to provide the password for the clntconfig principal to complete the process.

client# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile

Starting client setup
---------------------------------------------------

kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>

nfs/client.example.com entry ADDED to KDC database.
nfs/client.example.com entry ADDED to keytab.

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Copied /net/denver.example.com/export/install/krb5.conf.

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

client#

Example 23–7 Automatically Configuring a Kerberos Client With Command-Line Overrides

The following example overrides the DNSARG and the KDC parameters that are set in the installation profile.

# /usr/sbin/kclient -p /net/denver.example.com/export/install/profile\
-d dns_fallback -k kdc2.example.com

Starting client setup
---------------------------------------------------

kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>

nfs/client.example.com entry ADDED to KDC database.
nfs/client.example.com entry ADDED to keytab.

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Copied /net/denver.example.com/export/install/krb5.conf.

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

client#

How to Interactively Configure a Kerberos Client

This procedure uses the kclient installation utility without a installation profile.

Become superuser.

Run the kclient installation script.

You need to provide the following information:
- Kerberos realm name
- KDC master host name
- Administrative principal name
- Password for the administrative principal

Example 23–8 Running the `kclient` Installation Utility

The following output shows the results of running the kclient command.

client# /usr/sbin/kclient

Starting client setup
---------------------------------------------------

Do you want to use DNS for kerberos lookups ? [y/n]: n
        No action performed.
Enter the Kerberos realm: EXAMPLE.COM
Specify the KDC hostname for the above realm: kdc1.example.com

Setting up /etc/krb5/krb5.conf.

Enter the krb5 administrative principal to be used: clntconfig/admin
Obtaining TGT for clntconfig/admin ...
Password for clntconfig/admin@EXAMPLE.COM: <Type the password>
Do you plan on doing Kerberized nfs ? [y/n]: n

host/client.example.com entry ADDED to KDC database.
host/client.example.com entry ADDED to keytab.

Do you want to copy over the master krb5.conf file ? [y/n]: y
Enter the pathname of the file to be copied: \
/net/denver.example.com/export/install/krb5.conf

Copied /net/denver.example.com/export/install/krb5.conf.

---------------------------------------------------
Setup COMPLETE !
#

How to Manually Configure a Kerberos Client

In this procedure, the following configuration parameters are used:

Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Slave KDC = kdc2.example.com
NFS server = denver.example.com
Client = client.example.com
admin principal = kws/admin
User principal = mre
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 the Online Help URL in the Graphical Kerberos Administration Tool.

Become superuser.

Edit the Kerberos configuration file (krb5.conf).

To change the file from the Kerberos default version, you need to change the realm names and the server names. You also need to identify the path to the help files for gkadmin.

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

Note –

(Optional) Change the process used to locate the KDCs.

Starting with the Solaris 10 5/08release, by default the Kerberos realm to KDC mapping is determined in the following order:
- The definition in the realms section in krb5.conf.
- By looking up SRV records in DNS.
You can change this behavior by adding dns_lookup_kdc or dns_fallback to the libdefaults section of the krb5.conf file. See the krb5.conf(4) man page for more information. Note that referrals are always tried first.

(Optional) Change the process used to determine the realm for a host.

Starting with the Solaris 10 5/08release, by default the host to realm mapping is determined in the following order:
- If the KDC supports referrals, then the KDC may inform the client which realm the host belongs to.
- By the definition of domain_realm in the krb5.conf file.
- The DNS domainname of the host.
- The default realm.
You can change this behavior by adding dns_lookup_kdc or dns_fallback to the libdefaults section of the krb5.conffile. See the krb5.conf(4) man page for more information. Note that referrals will always be tried first.

(Optional) Synchronize the client's clock with 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 synchronized with the time on the KDC server within a maximum difference defined in the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.

Start kadmin.

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

(Optional) Create a user principal if a user principal does not already exist.

You need to create a user principal only if the user associated with this host does not already have a principal assigned to him or her.
kadmin: addprinc mre Enter password for principal mre@EXAMPLE.COM: <Type the password> Re-enter password for principal mre@EXAMPLE.COM: <Type it again> kadmin:

(Optional) Create a root principal and add the principal to the server's keytab file.

This step is required so that the client can have root access to file systems mounted using the NFS service. This step is also required if non-interactive root access is needed, such as running cron jobs as root.

If the client does not require root access to a remote file system which is mounted using the NFS service, then you can skip this step. The root principal should be a two component principal with the second component the host name of the Kerberos client system to avoid the creation of a realm wide root 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 /etc/resolv.conf file.

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

Create a host principal and add the principal to the server's keytab file.

The host principal is used by remote access services to provide authentication. The principal allows root to acquire a credential, if there is not one already in the keytab file.

kadmin: addprinc -randkey host/denver.example.com
Principal "host/denver.example.com@EXAMPLE.COM" created.
kadmin: ktadd host/denver.example.com
Entry for principal host/denver.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/denver.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/denver.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/denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/denver.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin:

(Optional) Add the server's NFS service principal to the server's keytab file.

This step is only required if the client needs to access NFS file systems using Kerberos authentication.

kadmin: ktadd nfs/denver.example.com
Entry for principal nfs/denver.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 nfs/denver.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 nfs/denver.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 nfs/denver.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal nfs/denver.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) Enable Kerberos with NFS.

Enable Kerberos security modes in the /etc/nfssec.conf file.

Edit the /etc/nfssec.conf file and remove the “#” that is placed in front of the Kerberos security modes.

# cat /etc/nfssec.conf
 .
 .
#
# Uncomment the following lines to use Kerberos V5 with NFS
#
krb5            390003  kerberos_v5     default -               # RPCSEC_GSS
krb5i           390004  kerberos_v5     default integrity       # RPCSEC_GSS
krb5p           390005  kerberos_v5     default privacy         # RPCSEC_GSS

Enable DNS.

If the /etc/resolv.conf file has not already been created, then create this file as the service principal canonicalization is dependent upon DNS to do this. See the resolv.conf(4) man page for more information.

Restart the gssd service.

After the /etc/resolv.conf file has been created or modified you must then restart the gssd daemon to reread any changes.
# svcadm restart network/rpc/gss

If you want the client to automatically renew the TGT or to warn users about Kerberos ticket expiration, create an entry in the /etc/krb5/warn.conf file.

See the warn.conf(4) man page for more information.

Example 23–9 Setting Up a Kerberos Client Using a Non-Solaris KDC

A Kerberos client can be set up to work with a non-Solaris 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
        }

Example 23–10 DNS TXT Records for the Mapping of Host and Domain Name to Kerberos Realm

@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                        IN      NS      kdc1.example.com.
kdc1                    IN      A       192.146.86.20
kdc2                    IN      A       192.146.86.21

_kerberos.example.com.             IN      TXT     "EXAMPLE.COM"
_kerberos.kdc1.example.com.        IN      TXT     "EXAMPLE.COM"
_kerberos.kdc2.example.com.        IN      TXT     "EXAMPLE.COM"

Example 23–11 DNS SRV Records for Kerberos Server Locations

This example defines the records for the location of the KDCs, the admin server, and the kpasswd server, respectively.

@ IN SOA kdc1.example.com root.kdc1.example.com (
                                1989020501   ;serial
                                10800        ;refresh
                                3600         ;retry
                                3600000      ;expire
                                86400 )      ;minimum

                                   IN      NS      kdc1.example.com.
kdc1                               IN      A       192.146.86.20
kdc2                               IN      A       192.146.86.21

_kerberos._udp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 0 0 88  kdc2.example.com
_kerberos._udp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos._tcp.EXAMPLE.COM         IN      SRV 1 0 88  kdc1.example.com
_kerberos-adm._tcp.EXAMPLE.COM     IN      SRV 0 0 749 kdc1.example.com
_kpasswd._udp.EXAMPLE.COM          IN      SRV 0 0 749 kdc1.example.com

How to Disable Verification of the Ticket Granting Ticket (TGT)

This procedure disables the security check that checks that the KDC of the host principal stored in the local /etc/krb5/krb5.keytab file is the same KDC that issued the Ticket Granting Ticket. This check prevents DNS spoofing attacks. However, for some client configurations, the host principal may not be available, so this check would need to be disabled to allow the client to function. These are the configurations that require that this check is disabled:

The client IP address is dynamically assigned. For instance, a DHCP client.
The client is not configured to host any services, so no host principal was created.
The host key is not stored on the client.

Become superuser.

Change the krb5.conf file.

If the verify_ap_req_nofail option is set to false, the TGT verification process is not enabled. See the krb5.conf(4) man page for more information about this option.
client # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false ...
Note –
The verify_ap_req_nofail option can be entered in either the [libdefaults] or the [realms] section of the krb5.conf file. If the option is in the [libdefaults]section, the setting is used for all realms. If the option is in the [realms]section, the setting only applies to the defined realm.

How to Access a Kerberos Protected NFS File System as the `root` User

This procedure allows a client to access a NFS file system that requires Kerberos authentication with the root ID privilege. In particular, when the NFS file system is shared with options like: -o sec=krb5,root=client1.sun.com.

Become superuser.

Start kadmin.

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

Create a root principal for the NFS client.

This principal is used to provide root equivalent access to NFS mounted file systems that require Kerberos authentication. The root principal should be a two component principal with the second component the host name of the Kerberos client system to avoid the creation of a realm wide root 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 /etc/resolv.conf file.
kadmin: addprinc -randkey root/client.example.com Principal "root/client.example.com" created. kadmin:

Add the root principal to the server's keytab file.

This step is required if you added a root principal so that the client can have root access to file systems mounted using the NFS service. This step is also required if non-interactive root access is needed, such as running cron jobs as root.

kadmin: ktadd root/client.example.com
Entry for principal root/client.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 root/client.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 root/client.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 root/client.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal root/client.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

How to Configure Automatic Migration of Users in a Kerberos Realm

Users, who do not have a Kerberos principal, can be automatically migrated to an existing Kerberos realm. The migration is achieved by using the PAM framework for the service in use by stacking the pam_krb5_migrate module in the service's authentication stack in /etc/pam.conf.

In this example, the dtlogin and other PAM service names are configured to use the automatic migration. The following configuration parameters are used:

Realm name = EXAMPLE.COM
Master KDC = kdc1.example.com
Machine hosting the migration service = server1.example.com
Migration service principal = host/server1.example.com

Before You Begin

Setup server1 as a Kerberos client of the realm EXAMPLE.COM. See Configuring Kerberos Clients for more information.

Check to see if a host service principal for server1 exists.

The host service principal in the keytab file of server1 is used to authenticate the server to the master KDC.

server1 # klist -k
Keytab name: FILE:/etc/krb5/krb5.keytab
	KVNO Principal
	---- ------------------------------------------------
	   3 host/server1.example.com@EXAMPLE.COM
	   3 host/server1.example.com@EXAMPLE.COM
	   3 host/server1.example.com@EXAMPLE.COM
	   3 host/server1.example.com@EXAMPLE.COM

Make changes to the PAM configuration file.

Add entries for the dtlogin service.

# cat /etc/pam.conf
 .
 .
#
# dtlogin service (explicit because of pam_krb5_migrate)
#
dtlogin       auth requisite          pam_authtok_get.so.1
dtlogin       auth required           pam_dhkeys.so.1
dtlogin       auth required           pam_unix_cred.so.1
dtlogin       auth sufficient         pam_krb5.so.1
dtlogin       auth requisite          pam_unix_auth.so.1
dtlogin       auth optional           pam_krb5_migrate.so.1

(Optional) Force an immediate password change, if needed.

The newly created Kerberos accounts can have their password expiration time set to the current time (now), in order to force an immediate Kerberos password change. To set the expiration time to now, add the expire_pw option to the lines which use the pam_krb5_migrate module. See the pam_krb5_migrate(5) man page for more information.
# cat /etc/pam.conf . . dtlogin auth optional pam_krb5_migrate.so.1 expire_pw

Add the pam_krb5 module to the account stack.

This addition allows for password expiration in Kerberos to block access.

# cat /etc/pam.conf
 .
 .
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other   account requisite       pam_roles.so.1
other   account required        pam_krb5.so.1
other   account required        pam_unix_account.so.1

Add the pam_krb5 module to the password stack.

This addition allows for passwords to be updated when the password expire.

# cat /etc/pam.conf
 .
 .
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password management
#
other   password required       pam_dhkeys.so.1
other   password requisite      pam_authtok_get.so.1
other   password requisite      pam_authtok_check.so.1
other   password sufficient     pam_krb5.so.1
other   password required       pam_authtok_store.so.1

On the master KDC, update the access control file.

The following entries grant migrate and inquire privileges to the host/server1.example.com service principal for all users, excepting the root user. It is important that users who should not be migrated are listed in the kadm5.acl file using the U privilege. These entries need to be before the permit all or ui entry. See the kadm5.acl(4) man page for more information.
kdc1 # cat /etc/krb5/kadm5.acl host/server1.example.com@EXAMPLE.COM U root host/server1.example.com@EXAMPLE.COM ui * */admin@EXAMPLE.COM *

On the master KDC, restart the Kerberos administration daemon.

This step allows the kadmind daemon to use the new kadm5.acl entries.
kdc1 # svcadm restart network/security/kadmin

On the master KDC, add entries to the pam.conf file.

The following entries enable the kadmind daemon to use the k5migrate PAM service, to validate UNIX user password for accounts that require migration.
# grep k5migrate /etc/pam.conf k5migrate auth required pam_unix_auth.so.1 k5migrate account required pam_unix_account.so.1

Synchronizing Clocks Between KDCs and Kerberos 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.

Because maintaining synchronized clocks between the KDCs and Kerberos clients is important, 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 focuses 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 23–1 Synchronizing Clocks by Using NTP

Diagram shows a central NTP server as the master clock
for NTP clients and Kerberos clients that are running the xntpd daemon.

Ensuring that the KDCs and Kerberos clients maintain synchronized clocks involves implementing the following steps:

Setting 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: Network Services to find the NTP server task.
As you configure the KDCs and Kerberos clients on the network, setting them up to be NTP clients of the NTP server. See Managing Network Time Protocol (Tasks) in System Administration Guide: 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. This procedure assumes that you are using incremental propagation.

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.

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 Manually Configure a Slave KDC for instructions.

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

How to Swap a Master KDC and a 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. This procedure assumes that you are using incremental propagation.

Before You Begin

This procedure requires that the slave KDC server has been set up as a swappable slave. For more information, see How to Configure a Swappable Slave KDC).

On the new master KDC, start kadmin.

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

Create new principals for the kadmind service.

The following example shows the first addprinc command on two lines, but it should be typed on one line.

kadmin: addprinc -randkey -allow_tgs_req +password_changing_service -clearpolicy \
       changepw/kdc4.example.com
Principal "changepw/kdc4.example.com@ENG.SUN.COM" created.
kadmin: addprinc -randkey -allow_tgs_req -clearpolicy kadmin/kdc4.example.com
Principal "kadmin/kdc4.example.com@EXAMPLE.COM" created.
kadmin:

Create a keytab file.

kadmin: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc4.example.com
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/kdc4.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc4.example.com
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal changepw/kdc4.example.com with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin: ktadd -k /etc/krb5/kadm5.keytab kadmin/changepw
Entry for principal kadmin/changepw with kvno 3, encryption type AES-256 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type AES-128 CTS mode
with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type Triple DES cbc
mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type ArcFour
with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kadmin/changepw with kvno 3, encryption type DES cbc mode
with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin:

Quit kadmin.
kadmin: quit

On the new master KDC, force synchronization.

The following steps force a full KDC update on the slave server.
kdc4 # svcadm disable network/security/krb5kdc kdc4 # rm /var/krb5/principal.ulog

On the new master KDC, verify that the update is complete.
kdc4 # /usr/sbin/kproplog -h

On the new master KDC, restart the KDC service.

kdc4 # svcadm enable -r network/security/krb5kdc

On the new master KDC, clear the update log.

These steps reinitialize the update log for the new master KDC server.
kdc4 # svcadm disable network/security/krb5kdc kdc4 # rm /var/krb5/principal.ulog

On the old master KDC, kill the kadmind and krb5kdc processes.

When you kill the kadmind process, you prevent any changes from being made to the KDC database.
kdc1 # svcadm disable network/security/kadmin kdc1 # svcadm disable network/security/krb5kdc

On the old master KDC, specify the poll time for requesting propagations.

Comment out the sunw_dbprop_master_ulogsize entry in /etc/krb5/kdc.conf and add an entry defining sunw_dbprop_slave_poll. The entry sets the poll time to 2 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
                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
                sunw_dbprop_enable = true
#               sunw_dbprop_master_ulogsize = 1000
                sunw_dbprop_slave_poll = 2m
        }

On the old master KDC, move the master KDC commands and the kadm5.acl file.

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

kdc1 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save
kdc1 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save
kdc1 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save
kdc1 # mv /etc/krb5/kadm5.acl /etc/krb5/kadm5.acl.save

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

On the DNS server, restart the Internet domain name server.

Run the following command to reload the new alias information:
# svcadm refresh network/dns/server

On the new master KDC, move the master KDC commands and the slave kpropd.acl file.

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
kdc4 # mv /etc/krb5/kpropd.acl /etc/krb5/kpropd.acl.save

On the new master KDC, create 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 file should also list all of the slaves that make requests for incremental propagation. See the kadm5.acl(4) man page for more information.
kdc4 # cat /etc/krb5/kadm5.acl kws/admin@EXAMPLE.COM * kiprop/kdc1.example.com@EXAMPLE.COM p

On the new master KDC, specify the update log size in the kdc.conf file.

Comment out the sunw_dbprop_slave_poll entry and add an entry defining sunw_dbprop_master_ulogsize. The entry sets the log size to 1000 entries.

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
                sunw_dbprop_enable = true
#               sunw_dbprop_slave_poll = 2m
                sunw_dbprop_master_ulogsize = 1000
        }

On the new master KDC, add the kiprop principal to the kadmind keytab file.

kdc4 # kadmin.local
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kiprop/kdc4.example.com
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc4.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin.local: quit

On the new master KDC, start kadmind and krb5kdc.

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

On the old master KDC, add the kiprop service principal.

Adding the kiprop principal to the krb5.keytab file allows the kpropd daemon to authenticate itself for the incremental propagation service.

kdc1 # /usr/sbin/kadmin -p kws/admin
Authenticating as pricipal kws/admin@EXAMPLE.COM with password.
Enter password: <Type kws/admin password>
kadmin: ktadd kiprop/kdc1.example.com
Entry for principal kiprop/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 kiprop/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 kiprop/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 kiprop/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
kadmin: quit

On the old master KDC, add an entry for each KDC listed in krb5.conf to the propagation configuration file, kpropd.acl.

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

On the old master KDC, start kpropd and krb5kdc.

When the krb5kdc daemon is started, kpropd also starts if the system is configured as a slave.
kdc1 # svcadm enable network/security/krb5kdc

Administering the Kerberos Database

The Kerberos database is the backbone of Kerberos and must be maintained properly. This section provides some procedures on how to administer the Kerberos database, such as backing up and restoring the database, setting up incremental or parallel propagation, and administering the stash file. The steps to initially set up the database are in How to Manually Configure a Master KDC.

Backing Up and Propagating the Kerberos Database

Propagating the Kerberos database from the master KDC to the slave KDCs is one of the most important configuration tasks. If propagation doesn't happen often enough, the master KDC and the slave KDCs will lose synchronization. So, if the master KDC goes down, the slave KDCs will not have the most recent database information. Also, if a slave KDC has been configured as a master KDC for purposes of load balancing, the clients that use that slave KDC as a master KDC will not have the latest information. Therefore, you must make sure that propagation occurs often enough or else configure the servers for incremental propagation, based on how often you change the Kerberos database. Incremental propagation is preferred over manual propagation because there is more administrative overhead when you manually propagate the database. Also, there are inefficiencies when you do full propagation of the database.

When you configure the master KDC, you set up the kprop_script command in a cron job to automatically back up the Kerberos database to the /var/krb5/slave_datatrans dump file and propagate it to the slave KDCs. But, as with any file, the Kerberos database can become corrupted. If data corruption occurs on a slave KDC, you might never notice, because the next automatic propagation of the database installs a fresh copy. However, if corruption occurs on the master KDC, the corrupted database is propagated to all of the slave KDCs during the next propagation. And, the corrupted backup overwrites the previous uncorrupted backup file on the master KDC.

Because there is no “safe” backup copy in this scenario, you should also set up a cron job to periodically copy the slave_datatrans dump file to another location or to create another separate backup copy by using the dump command of kdb5_util. Then, if your database becomes corrupted, you can restore the most recent backup on the master KDC by using the load command of kdb5_util.

Another important note: Because the database dump file contains principal keys, you need to protect the file from being accessed by unauthorized users. By default, the database dump file has read and write permissions only as root. To protect against unauthorized access, use only the kprop command to propagate the database dump file, which encrypts the data that is being transferred. Also, kprop propagates the data only to the slave KDCs, which minimizes the chance of accidentally sending the database dump file to unauthorized hosts.

Caution –

If the Kerberos database is updated after it has been propagated and if the database subsequently is corrupted before the next propagation, the KDC slaves will not contain the updates. The updates will be lost. For this reason, if you add significant updates to the Kerberos database before a regularly scheduled propagation, you should manually propagate the database to avoid data loss.

The `kpropd.acl` File

The kpropd.acl file on a slave KDC provides a list of host principal names, one name per line, that specifies the systems from which the KDC can receive an updated database through propagation. If the master KDC is used to propagate all the slave KDCs, the kpropd.acl file on each slave needs to contain only the host principal name of the master KDC.

However, the Kerberos installation and subsequent configuration steps in this book instruct you to add the same kpropd.acl file to the master KDC and the slave KDCs. This file contains all the KDC host principal names. This configuration enables you to propagate from any KDC, in case the propagating KDCs become temporarily unavailable. And, by keeping an identical copy on all KDCs, you make the configuration easy to maintain.

The `kprop_script` Command

The kprop_script command uses the kprop command to propagate the Kerberos database to other KDCs. If the kprop_script command is run on a slave KDC, it propagates the slave KDC's copy of the Kerberos database to other KDCs. The kprop_script accepts a list of host names for arguments, separated by spaces, which denote the KDCs to propagate.

When kprop_script is run, it creates a backup of the Kerberos database to the /var/krb5/slave_datatrans file and copies the file to the specified KDCs. The Kerberos database is locked until the propagation is finished.

How to Back Up the Kerberos Database

Become superuser on the master KDC.

Back up the Kerberos database by using the dump command of the kdb5_util command.
# /usr/sbin/kdb5_util dump [-verbose] [-d dbname] [filename [principals...]]
-verbose

Prints the name of each principal and policy that is being backed up.

dbname

Defines the name of the database to back up. Note that you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal.

filename

Defines the file that is used to back up the database. You can specify an absolute path for the file. If you don't specify a file, the database is dumped to standard output.

principals

Defines a list of one or more principals (separated by a space) to back up. You must use fully qualified principal names. If you don't specify any principals, the entire database is backed up.

Example 23–12 Backing Up the Kerberos Database

In the following example, the Kerberos database is backed up to a file called dumpfile. Because the -verbose option is specified, each principal is printed as it is backed up.

# kdb5_util dump -verbose dumpfile 
kadmin/kdc1.eng.example.com@ENG.EXAMPLE.COM 
krbtgt/ENG.EXAMPLE.COM@ENG.EXAMPLE.COM 
kadmin/history@ENG.EXAMPLE.COM 
pak/admin@ENG.EXAMPLE.COM 
pak@ENG.EXAMPLE.COM
changepw/kdc1.eng.example.com@ENG.EXAMPLE.COM

In the following example, the pak and pak/admin principals from the Kerberos database are backed up.

# kdb5_util dump -verbose dumpfile pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM
pak/admin@ENG.EXAMPLE.COM
pak@ENG.EXAMPLE.COM

How to Restore the Kerberos Database

Become superuser on the master KDC.

On the master, stop the KDC daemons.

kdc1 # svcadm disable network/security/krb5kdc
kdc1 # svcadm disable network/security/kadmin

Restore the Kerberos database by using the load command of the kdb_util command.
# /usr/sbin/kdb5_util load [-verbose] [-d dbname] [-update] [filename]
-verbose

Prints the name of each principal and policy that is being restored.

dbname

Defines the name of the database to restore. Note you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal.

-update

Updates the existing database. Otherwise, a new database is created or the existing database is overwritten.

filename

Defines the file from which to restore the database. You can specify an absolute path for the file.

Start the KDC daemons.

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

Example 23–13 Restoring the Kerberos Database

In the following example, the database called database1 is restored into the current directory from the dumpfile file. Because the -update option isn't specified, a new database is created by the restore.

# kdb5_util load -d database1 dumpfile

How to Convert a Kerberos Database After a Server Upgrade

If your KDC database was created on a server running the Solaris 8 or Solaris 9 release, converting the database allows you to take advantage of the improved database format.

Before You Begin

Make sure that the database is using an older format.

On the master, stop the KDC daemons.

kdc1 # svcadm disable network/security/krb5kdc
kdc1 # svcadm disable network/security/kadmin

Create a directory to store a temporary copy of the database.

kdc1 # mkdir /var/krb5/tmp
kdc1 # chmod 700 /var/krb5/tmp

Dump the KDC database.

kdc1 # kdb5_util dump /var/krb5/tmp/prdb.txt

Save copies of the current database files.

kdc1 # cd /var/krb5
kdc1 # mv princ* tmp/

Load the database.

kdc1 # kdb5_util load /var/krb5/tmp/prdb.txt

Start the KDC daemons.

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

How to Reconfigure a Master KDC to Use Incremental Propagation

The steps in this procedure can be used to reconfigure an existing master KDC to use incremental propagation. In this procedure, the following configuration parameters are used:

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

Add entries to kdc.conf.

You need to enable incremental propagation and select the number of updates the KDC master keeps in the log. See the kdc.conf(4) man page for more information.

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
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
        }

Create the kiprop principal.

The kiprop principal is used to authenticate the master KDC server and to authorize updates from the master KDC.

kdc1 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
kadmin: addprinc -randkey kiprop/kdc1.example.com
Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created.
kadmin: addprinc -randkey kiprop/kdc2.example.com
Principal "kiprop/kdc2.example.com@EXAMPLE.COM" created.
kadmin:

Add the kiprop principal to the kadmind keytab file

Adding the kiprop principal to the kadm5.keytab file allows the kadmind command to authenticate itself when it is started.

kadmin: ktadd -k /etc/krb5/kadm5.keytab kiprop/kdc1.example.com
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode
          with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type Triple DES cbc
          mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
Entry for principal kiprop/kdc1.example.com with kvno 3, encryption type DES cbc mode
          with RSA-MD5 added to keytab WRFILE:/etc/krb5/kadm5.keytab.
kadmin: quit

On the master KDC, add a kiprop entry to kadm5.acl

This entry allows the master KDC to receive requests for incremental propagation from the kdc2 server.
kdc1 # cat /etc/krb5/kadm5.acl */admin@EXAMPLE.COM * kiprop/kdc2.example.com@EXAMPLE.COM p

Comment out the kprop line in the root crontab file.

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

kdc1 # crontab -e
#ident  "@(#)root       1.20    01/11/06 SMI"
#
# 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 * * * /usr/sbin/logadm
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 kdc2.example.sun.com #SUNWkr5ma

Restart kadmind.

kdc1 # svcadm restart network/security/kadmin

Reconfigure all slave KDC servers that use incremental propagation.

See How to Reconfigure a Slave KDC to Use Incremental Propagation for complete instructions.

How to Reconfigure a Slave KDC to Use Incremental Propagation

Add entries to krb5.conf.

The new entries enable incremental propagation and set the poll time to 2 minutes.

kdc2 # cat /etc/krb5/krb5.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
                sunw_dbprop_enable = true
                sunw_dbprop_slave_poll = 2m
        }

Add the kiprop principal to the krb5.keytab file.

kdc2 # /usr/sbin/kadmin -p kws/admin
Enter password: <Type kws/admin password>
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

Disable kpropd.

kdc2 # svcadm disable network/security/krb5_prop

Restart the KDC server.

kdc2 # svcadm restart network/security/krb5kdc

How to Configure a Slave KDC to Use Full Propagation

This procedure shows how to reconfigure a slave KDC server running the Solaris 10 release to use full propagation. Normally, the procedure would only need to be used if the master KDC server is running either the Solaris 9 release or an earlier release. In this case, the master KDC server can not support incremental propagation, so the slave needs to be configured to allow propagation to work.

In this procedure, a slave KDC named kdc3 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 and kdc3.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 the Online Help URL in the Graphical Kerberos Administration Tool.

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.

On the master KDC, become superuser.

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 /etc/resolv.conf file.
  kadmin: addprinc -randkey host/kdc3.example.com Principal "host/kdc3@EXAMPLE.COM" created. kadmin:
2. 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
                kdc = kdc3.example.com
                admin_server = kdc1.example.com
        }

On the master KDC, add an entry for the master KDC and each slave KDC into the kpropd.acl file.

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

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
- /etc/krb5/kpropd.acl

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

kadmin: ktadd host/kdc3.example.com
Entry for principal host/kdc3.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/kdc3.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/kdc3.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/kdc3.example.com with kvno 3, encryption type ArcFour
          with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.
Entry for principal host/kdc3.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 master KDC, add the slave KDC name 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 entry starts the backup process every day at 3:10 AM.

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

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

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>

(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).
kdc3 # svcadm enable network/security/krb5kdc

How to Verify That the KDC Servers Are Synchronized

If incremental propagation has been configured, this procedure ensures that the information on the slave KDC has been updated.

On the KDC master server, run the kproplog command.
kdc1 # /usr/sbin/kproplog -h

On a KDC slave server, run the kproplog command.
kdc2 # /usr/sbin/kproplog -h

Check that the last serial # and the last timestamp values match.

Example 23–14 Verifying That the KDC Servers Are Synchronized

The following is a sample of results from running the kproplog command on the master KDC server.

kdc1 # /usr/sbin/kproplog -h

Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
    Log version #: 1
    Log state: Stable
    Entry block size: 2048
    Number of entries: 2500
    First serial #: 137966
    Last serial #: 140465
    First time stamp: Fri Nov 28 00:59:27 2004
    Last time stamp: Fri Nov 28 01:06:13 2004

The following is a sample of results from running the kproplog command on a slave KDC server.

kdc2 # /usr/sbin/kproplog -h

Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
    Log version #: 1
    Log state: Stable
    Entry block size: 2048
    Number of entries: 0
    First serial #: None
    Last serial #: 140465
    First time stamp: None
    Last time stamp: Fri Nov 28 01:06:13 2004

Notice that the values for the last serial number and the last timestamp are identical, which indicates that the slave is synchronized with the master KDC server.

In the slave KDC server output, notice that no update entries exist in the slave KDC server's update log. No entries exist because the slave KDC server does not keep a set of updates, unlike the master KDC server. Also, the KDC slave server does not include information on the first serial number or the first timestamp because this is not relevant information.

How to Manually Propagate the Kerberos Database to the Slave KDCs

This procedure shows you how to propagate the Kerberos database by using the kprop command. Use this procedure if you need to synchronize a slave KDC with the master KDC outside the periodic cron job. Unlike the kprop_script, you can use kprop to propagate just the current database backup without first making a new backup of the Kerberos database.

Note –

Do not use this procedure if you are using incremental propagation.

Become superuser on the master KDC.

(Optional) Back up the database by using the kdb5_util command.
# /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans

Propagate the database to a slave KDC by using the kprop command.

# /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC

Example 23–15 Manually Propagating the Kerberos Database to the Slave KDCs Using `kprop_script`

If you want to back up the database and propagate it to a slave KDC outside the periodic cron job, you can also use the kprop_script command as follows:

# /usr/lib/krb5/kprop_script slave-KDC

Setting Up Parallel Propagation

In most cases, the master KDC is used exclusively to propagate its Kerberos database to the slave KDCs. However, if your site has many slave KDCs, you might consider load-sharing the propagation process, known as parallel propagation.

Note –

Do not use this procedure if you are using incremental propagation.

Parallel propagation allows specific slave KDCs to share the propagation duties with the master KDC. This sharing of duties enables the propagation to be done faster and to lighten the work for the master KDC.

For example, say your site has one master KDC and six slave KDCs (shown in Figure 23–2), where slave-1 through slave-3 consist of one logical grouping and slave-4 through slave-6 consist of another logical grouping. To set up parallel propagation, you could have the master KDC propagate the database to slave-1 and slave-4. In turn, those KDC slaves could propagate the database to the KDC slaves in their group.

Figure 23–2 Example of Parallel Propagation Configuration

Diagram shows a master KDC with two propagation slaves.
Each propagation slave propagates to its slaves the master KDC database.

Configuration Steps for Setting Up Parallel Propagation

The following is not a detailed step-by-step procedure, but a high-level list of configuration steps to enable parallel propagation. These steps involve the following:

On the master KDC, changing the kprop_script entry in its cron job to include arguments for only the KDC slaves that will perform the succeeding propagation (the propagation slaves).
On each propagation slave, adding a kprop_script entry to its cron job, which must include arguments for the slaves to propagate. To successfully propagate in parallel, the cron job should be set up to run after the propagation slave is itself propagated with the new Kerberos database.

Note –
How long it will take for a propagation slave to be propagated depends on factors such as network bandwidth and the size of the Kerberos database.
On each slave KDC, setting up the appropriate permissions to be propagated. This step is done by adding the host principal name of its propagating KDC to its kpropd.acl file.

Example 23–16 Setting Up Parallel Propagation

Using the example in Figure 23–2, the master KDC's kprop_script entry would look similar to the following:

0 3 * * * /usr/lib/krb5/kprop_script slave-1.example.com slave-4.example.com

The slave-1's kprop_script entry would look similar to the following:

0 4 * * * /usr/lib/krb5/kprop_script slave-2.example.com slave-3.example.com

Note that the propagation on the slave starts an hour after it is propagated by the master.

The kpropd.acl file on the propagation slaves would contain the following entry:

host/master.example.com@EXAMPLE.COM

The kpropd.acl file on the KDC slaves being propagated by slave-1 would contain the following entry:

host/slave-1.example.com@EXAMPLE.COM

Administering the Stash File

The stash file contains the master key for the Kerberos database, which is automatically created when you create a Kerberos database. If the stash file gets corrupted, you can use the stash command of the kdb5_util utility to replace the corrupted file. The only time you should need to remove a stash file is after removing the Kerberos database with the destroy command of kdb5_util. Because the stash file is not automatically removed with the database, you have to remove the stash file to finish the cleanup.

How to Remove a Stash File

Become superuser on the KDC that contains the stash file.

Remove the stash file.
# rm stash-file
Where stash-file is the path to the stash file. By default, the stash file is located at /var/krb5/.k5.realm.

Note –
If you need to re-create the stash file, you can use the -f option of the kdb5_util command.

Managing a KDC on an LDAP Directory Server

Most of the KDC administration tasks using an LDAP Directory Server are the same as those for the DB2 server. There are some new tasks that are specific to working with LDAP.

Table 23–3 Configuring KDC Servers to Use LDAP (Task Map)


Task	Description	For Instructions
Configuring 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
Mix Kerberos principal attributes with non-Kerberos object class types.	Allows information stored with the Kerberos records to be shared with other LDAP databases.	How to Mix Kerberos Principal Attributes in a Non-Kerberos Object Class Type
Destroy a Realm	Removes all of the data associated with a realm	How to Destroy a Realm on an LDAP Directory Server

How to Mix Kerberos Principal Attributes in a Non-Kerberos Object Class Type

This procedure allows for Kerberos principal attributes to be associated with non-Kerberos object class types. In this procedure the krbprincipalaux, and krbTicketPolicyAux and krbPrincipalName attributes are associated with the people object class.

In this procedure, the following configuration parameters are used:

Directory Server = dsserver.example.com
user principal = willf@EXAMPLE.COM

Become superuser.

Prepare each entry in the people object class.

Repeat this step for each entry.

cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager"
dn: uid=willf,ou=people,dc=example,dc=com
changetype: modify
objectClass: krbprincipalaux
objectClass: krbTicketPolicyAux
krbPrincipalName: willf@EXAMPLE.COM
EOF

Add a subtree attribute to the realm container.

This step allows for searching of principal entries in the ou=people,dc=example,dc=com container, as well as in the default EXAMPLE.COM container.
# kdb5_ldap_util -D "cn=directory manager" modify \ -subtrees 'ou=people,dc=example,dc=com' -r EXAMPLE.COM

(Optional) If the KDC records are stored in DB2, migrate DB2 entries.
1. Dump the DB2 entries.
  # kdb5_util dump > dumpfile
2. Load the database into the LDAP server.
  # kdb5_util load -update dumpfile

(Optional) Add the principal attributes to the KDC.
# kadmin.local -q 'addprinc willf'

How to Destroy a Realm on an LDAP Directory Server

This procedure can be used if a different LDAP Directory Server has been configured to handle a realm.

Become superuser.

Destroy the realm.

# kdb5_ldap_util -D "cn=directory manager" destroy

Increasing Security on Kerberos Servers

Follow these steps to increase security on Kerberos application servers and on KDC servers.

Table 23–4 Increasing Security on Kerberos Servers (Task Map)


Task	Description	For Instructions
Enabling access using Kerberos authentication	Restrict network access to a server to allow Kerberos authentication only	How to Enable Only Kerberized Applications
Restricting access to the KDC servers	Increases the security of the KDC servers and their data.	How to Restrict Access to KDC Servers
Increasing password security by using a dictionary file	Increases the security of any new passwords by checking the new password against a dictionary.	How to Use a Dictionary File to Increase Password Security

How to Enable Only Kerberized Applications

This procedure restricts network access to the server that is running telnet, ftp, rcp, rsh, and rlogin to use Kerberos authenticated transactions only.

Change the exec property for the telnet service.

Add the -a user option to the exec property for telnet to restrict access to those users who can provide valid authentication information.
# inetadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user"

(Optional) If not already configured, change the exec property for the telnet service.

Add the -a option to the exec property for ftp to permit only Kerberos authenticated connections.
# inetadm -m svc:/network/ftp:default exec="/usr/sbin/in.ftpd -a"

Disable other services.

The in.rshd and in.rlogind daemons should be disabled.

# svcadm disable network/shell
# svcadm disable network/login:rlogin

How to Restrict Access to KDC Servers

Both master KDC servers and slave KDC servers have copies of the KDC database stored locally. Restricting access to these servers so that the databases are secure is important to the overall security of the Kerberos installation.

Disable remote services, as needed.

To provide a secure KDC server, all nonessential network services should be disabled . Depending on your configuration, some of these services may already be disabled. Check the service status with the svcs command. In most circumstances, the only services that would need to run would be krb5kdc and kadmin if the KDC is a master. In addition, any services that use loopback tli (ticlts, ticotsord, and ticots) can be left enabled.

# svcadm disable network/comsat
# svcadm disable network/dtspc/tcp
# svcadm disable network/finger
# svcadm disable network/login:rlogin
# svcadm disable network/rexec
# svcadm disable network/shell
# svcadm disable network/talk
# svcadm disable network/tname
# svcadm disable network/uucp
# svcadm disable network/rpc_100068_2-5/rpc_udp

Restrict access to the hardware that supports the KDC.

To restrict physical access, make sure that the KDC server and its monitor are located in a secure facility. Users should not be able to access this server in any way.

Store KDC database backups on local disks or on the KDC slaves.

Make tape backups of your KDC only if the tapes are stored securely. Follow the same practice for copies of keytab files. It would be best to store these files on a local file system that is not shared with other systems. The storage file system can be on either the master KDC server or any of the slave KDCs.

How to Use a Dictionary File to Increase Password Security

A dictionary file can be used by the Kerberos service to prevent words in the dictionary from being used as passwords when creating new credentials. Preventing the use of dictionary terms as passwords makes it harder for someone else to guess any password. By default the /var/krb5/kadm5.dict file is used, but it is empty.

Become superuser on the master KDC.

Edit the KDC configuration file (kdc.conf).

You need add a line to instruct the service to use a dictionary file. In this example, the dictionary that is included with the spell utility is used. See the kdc.conf(4) man page for a full description of the configuration 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
                sunw_dbprop_enable = true
                sunw_dbprop_master_ulogsize = 1000
                dict_file = /usr/share/lib/dict/words
                }

Restart the Kerberos daemons.

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

Chapter 23 Configuring the Kerberos Service (Tasks)

Configuring the Kerberos Service (Task Map)

Configuring Additional Kerberos Services (Task Map)

Configuring KDC Servers

How to Manually Configure a Master KDC

Before You Begin

How to Configure a KDC to Use an LDAP Data Server

Before You Begin

How to Manually Configure a Slave KDC

Before You Begin

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

Example 23–1 Refreshing the Principal Keys from a Master Server

Configuring Cross-Realm Authentication

How to Establish Hierarchical Cross-Realm Authentication

Before You Begin

How to Establish Direct Cross-Realm Authentication

Before You Begin

Configuring Kerberos Network Application Servers

How to Configure a Kerberos Network Application Server

Before You Begin

Configuring Kerberos NFS Servers

How to Configure Kerberos NFS Servers

How to Create a Credential Table

How to Add a Single Entry to the Credential Table

Before You Begin

Example 23–2 Adding a Multiple Component Principal to the Credential Table

Example 23–3 Adding a Principal in a Different Domain to the Credential Table

How to Provide Credential Mapping Between Realms

Example 23–4 Mapping Credentials Between Realms Using the Same Password File

Troubleshooting

How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes

Example 23–5 Sharing a File System With One Kerberos Security Mode

Example 23–6 Sharing a File System With Multiple Kerberos Security Modes

Configuring Kerberos Clients

Configuring Kerberos Clients (Task Map)

How to Create a Kerberos Client Installation Profile

How to Automatically Configure a Kerberos Client

Before You Begin

Example 23–7 Automatically Configuring a Kerberos Client With Command-Line Overrides

How to Interactively Configure a Kerberos Client

Example 23–8 Running the kclient Installation Utility

How to Manually Configure a Kerberos Client

Example 23–9 Setting Up a Kerberos Client Using a Non-Solaris KDC

Example 23–10 DNS TXT Records for the Mapping of Host and Domain Name to Kerberos Realm

Example 23–11 DNS SRV Records for Kerberos Server Locations

How to Disable Verification of the Ticket Granting Ticket (TGT)

How to Access a Kerberos Protected NFS File System as the root User

How to Configure Automatic Migration of Users in a Kerberos Realm

Before You Begin

Synchronizing Clocks Between KDCs and Kerberos Clients

Figure 23–1 Synchronizing Clocks by Using NTP

Swapping a Master KDC and a Slave KDC

How to Configure a Swappable Slave KDC

How to Swap a Master KDC and a Slave KDC

Before You Begin

Administering the Kerberos Database

Backing Up and Propagating the Kerberos Database

The kpropd.acl File

The kprop_script Command

How to Back Up the Kerberos Database

Example 23–12 Backing Up the Kerberos Database

How to Restore the Kerberos Database

Example 23–13 Restoring the Kerberos Database

How to Convert a Kerberos Database After a Server Upgrade

Before You Begin

How to Reconfigure a Master KDC to Use Incremental Propagation

How to Reconfigure a Slave KDC to Use Incremental Propagation

How to Configure a Slave KDC to Use Full Propagation

Before You Begin

How to Verify That the KDC Servers Are Synchronized

Example 23–14 Verifying That the KDC Servers Are Synchronized

How to Manually Propagate the Kerberos Database to the Slave KDCs

Example 23–15 Manually Propagating the Kerberos Database to the Slave KDCs Using kprop_script

Setting Up Parallel Propagation

Figure 23–2 Example of Parallel Propagation Configuration

Configuration Steps for Setting Up Parallel Propagation

Example 23–16 Setting Up Parallel Propagation

Administering the Stash File

How to Remove a Stash File

Managing a KDC on an LDAP Directory Server

Example 23–8 Running the `kclient` Installation Utility

How to Access a Kerberos Protected NFS File System as the `root` User

The `kpropd.acl` File

The `kprop_script` Command

Example 23–15 Manually Propagating the Kerberos Database to the Slave KDCs Using `kprop_script`