configuringKerberosoverview 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) Configuring KDC Servers Configuring Kerberos Clients Configuring Cross-Realm Authentication Configuring Kerberos Network Application Servers Configuring Kerberos NFS Servers Synchronizing Clocks Between KDCs and Kerberos Clients Swapping a Master KDC and a Slave KDC Administering the Kerberos Database Increasing Security on Kerberos Servers configuringKerberostask map task mapsKerberos configuration 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 task mapsKerberos maintenanceOnce 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 Kerberosconfiguring 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.KDCslave or masterslave KDCsor mastermaster KDCslave KDCs andThe 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. Task Description For Instructions Configuring a Master KDC Configures and builds the master KDC server and database for a realm using an automatic process, which is good for scripts. How to Automatically Configure a Master KDC Configures and builds the master KDC server and database for a realm using an interactive process, which is sufficient for most installations How to Interactively Configure a Master KDC Configures and builds the master KDC server and database for a realm using a manual process, which is needed for more complex installations How to Configure a Master KDC Configures and builds the master KDC server and database for a realm using a manual process and using LDAP for the KDC How to Configure a KDC to Use an LDAP Data Server Configure a slave KDC server. Configures and builds a slave KDC server for a realm using an automatic process, which is good for scripts How to Automatically Configure a Slave KDC Configures and builds a slave KDC server for a realm using an interactive process, which is sufficient for most installations How to Interactively Configure a Slave KDC Configures and builds a slave KDC server for a realm using the manual process, which is needed for more complex installations How to Configure a Slave KDC KDCconfiguring masterautomatic configuringKerberosmaster KDC server automatically configuringKerberosmaster KDC server master KDCautomatically configuring Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a master KDC can be automatically configured by using the following procedure. Become superuser. Create the KDC.Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.kdcmgr commandconfiguring masterautomatickdc1# kdcmgr -a kws/admin -r EXAMPLE.COM create master Starting server setup --------------------------------------- Setting up /etc/krb5/kdc.conf Setting up /etc/krb5/krb5.conf Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the password> Re-enter KDC database master key to verify: <Type it again> Authenticating as principal root/admin@EXAMPLE.COM with password. WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy Enter password for principal "kws/admin@EXAMPLE.COM": <Type the password> Re-enter password for principal "kws/admin@EXAMPLE.COM": <Type it again> Principal "kws/admin@EXAMPLE.COM" created. Setting up /etc/krb5/kadm5.acl. --------------------------------------------------- Setup COMPLETE. kdc1# KDCconfiguring masterinteractive configuringKerberosmaster KDC server interactively configuringKerberosmaster KDC server master KDCinteractively configuring Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a master KDC can be interactively configured by using the following procedure. Become superuser. Create the KDC.kdcmgr commandconfiguring masterinteractiveRun the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.kdc1# kdcmgr create master Starting server setup --------------------------------------- Enter the Kerberos realm: EXAMPLE.COM Setting up /etc/krb5/kdc.conf Setting up /etc/krb5/krb5.conf Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the password> Re-enter KDC database master key to verify: <Type it again> Enter the krb5 administrative principal to be created: kws/admin Authenticating as principal root/admin@EXAMPLE.COM with password. WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy Enter password for principal "kws/admin@EXAMPLE.COM": <Type the password> Re-enter password for principal "kws/admin@EXAMPLE.COM": <Type it again> Principal "kws/admin@EXAMPLE.COM" created. Setting up /etc/krb5/kadm5.acl. --------------------------------------------------- Setup COMPLETE. kdc1# kdcmgr commandserver status The kdcmgr status command can be used to display information about either a master or a slave KDC server. KDCconfiguring mastermanual configuringKerberosmaster KDC server manually configuringKerberosmaster KDC server master KDCmanually configuring 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/6956Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in Online Help URL in the Graphical Kerberos Administration Tool. 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. krb5.conf fileeditingEdit the Kerberos configuration file (krb5.conf).You need to change the realm names and the names of the servers. See the krb5.conf4 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 }default_realm sectionkrb5.conf fileadmin_server sectionkrb5.conf filedomain_realm sectionkrb5.conf fileIn 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.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.conf4 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.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. kdb5_util commandcreating KDC databaseKDCcreating databasedatabasescreating KDCCreate 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> access control listACLkadm5.acl filemaster KDC entryEdit 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.acl4 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: kadmin.local commandadding administration principalsconfiguringKerberosadding administration principalsaddingadministration principals (Kerberos)principaladding administrationAdd 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: keytab filecreatingcreatingkeytab filekadmin.local commandcreating keytab fileCreate 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: KDCcreating host principalhost principalcreatingprincipalcreating hostkadmin commandcreating host principalCreate 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: clntconfig principalcreatingprincipalcreating clntconfigCreate 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: keytab fileadding master KDC's host principal toAdd 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 KDCsynchronizing clocksmaster KDCclock synchronizingKerberos master KDC andNTPmaster KDC andsynchronizing clocksmaster KDCSynchronize 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 Configure a Slave KDC for specific instructions. KDCconfiguring masterwith LDAP configuringKerberosmaster KDC server using LDAP manually configuringKerberosmaster KDC server using LDAP master KDCconfiguring with LDAP LDAPconfiguring master KDC using Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a KDC can be configured to use an LDAP data server by using the following procedure.In this procedure, the following configuration parameters are used: Realm name = EXAMPLE.COM DNS domain name = example.com Master KDC = kdc1.example.com Directory Server = dsserver.example.com admin principal = kws/admin Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in Online Help URL in the Graphical Kerberos Administration Tool. 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 Directory Server Enterprise Edition release. Become superuser on the KDC. Configure the master KDC to use SSL to reach the directory server.The following steps configure a Solaris Express Developer Release KDC to use the Directory Server 6.1 self-signed certificate. If the certificate has expired, follow the instructions for renewing a certificate in To Manage Self-Signed Certificates in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.On the directory server, export the self-signed directory server certificate.# /export/sun-ds6.1/ds6/bin/dsadm show-cert -F der /export/sun-ds6.1/directory2 \ defaultCert > /tmp/defaultCert.cert.der On the master KDC, import the directory server certificate.# pktool setpin keystore=nss dir=/var/ldap # chmod a+r /var/ldap/*.db # pktool import keystore=nss objtype=cert trust="CT" infile=/tmp/defaultCert.certutil.der \ label=defaultCert dir=/var/ldap On the master KDC, test that SSL is working.This example assumes that the cn=directory managerentry has administration privileges./usr/bin/ldapsearch -Z -P /var/ldap -D "cn=directory manager" \ -h dsserver.example.com -b "" -s base objectclass='*' Subject: "CN=dsserver.example.com,CN=636,CN=Directory Server,O=Example CorporationNote that the CN=dsserver.example.com entry should include the fully qualified host name, not a short version. Populate the LDAP directory, if necessary. Add the Solaris Kerberos schema to the existing schema.# ldapmodify -h dsserver.example.com -D "cn=directory manager" -f /usr/share/lib/ldif/kerberos.ldif Create the Kerberos container in the LDAP directory.Add the following entries to the krb5.conf file.Define the database type.Add an entry to define the database_moduleto the realms section.database_module = LDAP Define the database module.[dbmodules] LDAP = { ldap_kerberos_container_dn = "cn=krbcontainer,dc=example,dc=com" db_library = kldap ldap_kdc_dn = "cn=kdc service,ou=profile,dc=example,dc=com" ldap_kadmind_dn = "cn=kadmin service,ou=profile,dc=example,dc=com" ldap_cert_path = /var/ldap ldap_servers = ldaps://dsserver.example.com } Create the KDC in the LDAP directory.This command creates krbcontainer and several other objects. It also creates a /var/krb5/.k5.EXAMPLE.COM master key stash file.# kdb5_ldap_util -D "cn=directory manager" create -P abcd1234 -r EXAMPLE.COM -s Stash the KDC bind Distinguished Name (DN) passwords.These passwords are used by the KDC when it binds to the DS. The KDC uses different roles depending on the type of access the KDC is using.# kdb5_ldap_util stashsrvpw "cn=kdc service,ou=profile,dc=example,dc=com" # kdb5_ldap_util stashsrvpw "cn=kadmin service,ou=profile,dc=example,dc=com" Add KDC service roles.Create a kdc_roles.ldif file with contents like this:dn: cn=kdc service,ou=profile,dc=example,dc=com cn: kdc service sn: kdc service objectclass: top objectclass: person userpassword: test123 dn: cn=kadmin service,ou=profile,dc=example,dc=com cn: kadmin service sn: kadmin service objectclass: top objectclass: person userpassword: test123 Create the role entries in the LDAP directory# ldapmodify -a -h dsserver.example.com -D "cn=directory manager" -f kdc_roles.ldif Set the ACLs for the KDC-related roles.# cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager" # Set kadmin ACL for everything under krbcontainer. dn: cn=krbcontainer,dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///cn=krbcontainer,dc=example,dc=com")(targetattr="krb*")(version 3.0;\ acl kadmin_ACL; allow (all)\ userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";) # Set kadmin ACL for everything under the people subtree if there are # mix-in entries for krb princs: dn: ou=people,dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///ou=people,dc=example,dc=com")(targetattr="krb*")(version 3.0;\ acl kadmin_ACL; allow (all)\ userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";) EOF krb5.conf fileeditingEdit the Kerberos configuration file (krb5.conf).You need to change the realm names and the names of the servers. See the krb5.conf4 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 }default_realm sectionkrb5.conf fileadmin_server sectionkrb5.conf filedomain_realm sectionkrb5.conf fileIn 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.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.conf4 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.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. access control listACLkadm5.acl filemaster KDC entryEdit 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.acl4 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: kadmin.local commandadding administration principalsconfiguringKerberosadding administration principalsaddingadministration principals (Kerberos)principaladding administrationAdd 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: keytab filecreatingcreatingkeytab filekadmin.local commandcreating keytab fileCreate 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.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: 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: KDCcreating host principalhost principalcreatingprincipalcreating hostkadmin commandcreating host principalCreate 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: clntconfig principalcreatingprincipalcreating clntconfigCreate 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: keytab fileadding master KDC's host principal toAdd 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 KDCsynchronizing clocksmaster KDCclock synchronizingKerberos master KDC andNTPmaster KDC andsynchronizing clocksmaster KDCSynchronize 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 Configure a Slave KDC for specific instructions. automatically configuringKerberosslave KDC server slave KDCsautomatically configuring KDCconfiguring slaveautomatic configuringKerberosslave KDC server Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a slave KDC can be automatically configured by using the following procedure. Become superuser. Create the KDC.Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.kdcmgr commandconfiguring slaveautomatickdc2# kdcmgr -a kws/admin -r EXAMPLE.COM create -m kdc1 slave Starting server setup --------------------------------------- Setting up /etc/krb5/kdc.conf Setting up /etc/krb5/krb5.conf Obtaining TGT for kws/admin ... Password for kws/admin@EXAMPLE.COM: <Type the password> Setting up /etc/krb5/kadm5.acl. Setting up /etc/krb5/kpropd.acl. Waiting for database from master... Waiting for database from master... Waiting for database from master... kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the password> --------------------------------------------------- Setup COMPLETE. kdc2# interactively configuringKerberosslave KDC server slave KDCsinteractively configuring KDCconfiguring slaveinteractive configuringKerberosslave KDC server Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a slave KDC can be interactively configured by using the following procedure. Become superuser. Create the KDC.Run the kdcmgr utility to create the KDC. You need to provide both the master key password and the password for the administrative principal.kdcmgr commandconfiguring slaveinteractivekdc1# kdcmgr create slave Starting server setup --------------------------------------- Enter the Kerberos realm: EXAMPLE.COM What is the master KDC's host name?: kdc1 Setting up /etc/krb5/kdc.conf Setting up /etc/krb5/krb5.conf Obtaining TGT for kws/admin ... Password for kws/admin@EXAMPLE.COM: <Type the password> Setting up /etc/krb5/kadm5.acl. Setting up /etc/krb5/kpropd.acl. Waiting for database from master... Waiting for database from master... Waiting for database from master... kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the password> --------------------------------------------------- Setup COMPLETE. kdc2# slave KDCsconfiguring KDCconfiguring slavemanual manually configuringKerberosslave KDC server configuringKerberosslave KDC server 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 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: 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: 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: 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.conf4 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 KDCcopying administration files from slave to masterOn 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 # svcadm enable network/security/krb5_prop stash filecreatingcreatingstash filekdb5_util commandcreating stash fileOn 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> KDCsynchronizing clocksslave KDCclock synchronizingKerberos slave KDC andNTPslave KDC andsynchronizing clocksslave KDCOn 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. krb5kdc daemonstartingKDCstarting daemonstartingKDC daemonOn the new slave, start the KDC daemon (krb5kdc).kdc2 # svcadm enable network/security/krb5kdc realms (Kerberos)configuring cross-realm authentication configuringKerberoscross-realm authentication authenticationconfiguring cross-realm cross-realm authenticationconfiguring 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).hierarchical realmsconfiguring realms (Kerberos)hierarchical 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. 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: quitThe 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.COMIn 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. realms (Kerberos)direct direct realms 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. 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: quitThe 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 application servers application serverconfiguring 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.This procedure uses the following configuration parameters:Application server = boston admin principal = kws/admin DNS domain name = example.com Realm name = EXAMPLE.COM This procedure requires that the master KDC has been configured. To fully test the process, several Kerberos clients must be configured. 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.COMIf 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.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/adminkadmin: 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 task mapsconfiguring Kerberos NFS serversNFS 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.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 configuringKerberosNFS servers NFS serversconfiguring for Kerberos 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. 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 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. creatingcredential table user ID in NFS services principaluser ID comparison 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 -aThe 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 gsscred1M man page for more information. credential tableadding single entry to 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 ]] -amechDefines the security mechanism to be used. nameDefines the principal name for the user, as defined in the KDC. uidDefines the UID for the user, as defined in the password database. aAdds the UID to principal name mapping. 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 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 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 . } 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 . } See Observing Mapping from GSS Credentials to UNIX Credentials to help with the process of troubleshooting credential mapping problems. security modessetting up environment with multiple 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 Share the file systems with the appropriate security modes.sharemgr share -o sec=mode file-systemmodeSpecifies 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-systemDefines 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. 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 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 In this example, Kerberos authentication must succeed before any files can be accessed through the NFS service.# sharemgr share -F nfs -p -o sec=krb5 /export/home 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 nfssec5 man page for more information.# sharemgr share -F nfs -p -o sec=krb5:krb5i:krb5p /export/home clientsconfiguring Kerberos configuringKerberosclients 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.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 Automatically installs a Kerberos client of an Active Directory server. How to Configure a Kerberos Client for an Active Directory Server 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 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 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# 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# This procedure uses the kclient installation utility without a installation profile. In build 90 of the Solaris Express Community Edition release, the kclient utility has been expanded to improve ease of use and ability to work with Active Directory servers. See How to Configure a Kerberos Client for an Active Directory Server for more information. See Example 23–9 for an example of running kclient on a previous Solaris release. Become superuser. Run the kclient installation script.You need to provide the following information:Kerberos realm name KDC master host name KDC slave host names Domains to map to the local realm PAM service names and options to use for Kerberos authentication Indicate if the KDC server is not running a Solaris release.If this system is a client of a KDC server that is not running a Solaris release, you need to define the type of server that is running the KDC. The available servers are: Microsoft Active Directory, MIT KDC server, Heimdal KDC server, and Shishi KDC server. Select if DNS should be used for Kerberos lookups.If you use DNS for Kerberos lookups, you need to enter the DNS lookup option that you want to use. Valid options are dns_lookup_kdc, dns_lookup_realm, and dns_fallback. See the krb5.conf4 man page for more information about these values. Define the name of the Kerberos realm and the master KDC hostname.This information is added to the /etc/krb5/krb5.conf configuration file. Select if slave KDCs exist.If there are slave KDCs in the realm, then you need to enter the slave KDC host names. This information is used to create additional KDC entries in the client's configuration file. Indicate if service or host keys are required.Normally, service or host keys are not required unless the client system is hosting Kerberized services. Specify if the client is a member of a cluster.If the client is a member of a cluster, then you need to provide the logical name of the cluster. The logical host name is used when creating service keys, which is required when hosting Kerberos services from clusters. Identify any domains or hosts to map to the current realm.This mapping allows other domains to belong in the default realm of the client. Specify if the client will use Kerberized NFS.NFS service keys need to be created if the client will host NFS services using Kerberos. Indicate if the /etc/pam.conf file needs to be updated.This allows you to set which PAM services use Kerberos for authentication. You need to enter the service name and a flag indicating how Kerberos authentication is to be used. The valid flag options are:first – use Kerberos authentication first, and only use UNIX if Kerberos authentication fails only – use Kerberos authentication only optional – use Kerberos authentication optionally Select if the master /etc/krb5/krb5.conf file should be copied.This option allows for specific configuration information to be used when the arguments to kclient are not sufficient. client# /usr/sbin/kclient Starting client setup --------------------------------------------------- Is this a client of a non-Solaris KDC ? [y/n]: n No action performed. Do you want to use DNS for kerveros lookups ? [y/n]: n No action performed. Enter the Kerberos realm: EXAMPLE.COM Specify the KDC hostname for the above realm: kdc1.example.com Note, this system and the KDC's time must be within 5 minutes of each other for Kerberos to function. Both systems should run some form of time synchronization system like Network Time Protocol (NTP). Do you have any slave KDC(s) ? [y/n]: y Enter a comma-separated list of slave KDC host names: kdc2.example.com Will this client need service keys ? [y/n]: n No action performed. Is this client a member of a cluster that uses a logical host name ? [y/n]: n No action performed. Do you have multiple domains/hosts to map to realm ? [y/n]: y Enter a comma-separated list of domain/hosts to map to the default realm: engineering.example.com, \ example.com Setting up /etc/krb5/krb5.conf. Do you plan on doing Kerberized nfs ? [y/n]: y Do you want to update /etc/pam.conf ? [y/n]: y Enter a comma-separated list of PAM service names in the following format: service:{first|only|optional}: xscreensaver:first Configuring /etc/pam.conf. Do you want to copy over the master krb5.conf file ? [y/n]: n No action performed. --------------------------------------------------- Setup COMPLETE. 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 ! # This procedure uses the kclient installation utility without a installation profile. Become superuser. Enable DNS resource record creation for the client.This command causes DNS records to be created when the client is joined to the Active Directory domain.client# svccfg -s smb/server setprop smbd/ddns_enable=true Run the kclient installation script.You need to provide the following information:Password for the administrative principal The following output shows the results of running the kclient command using the ms_ad (Microsoft Active Directory) server type argument. The client will be joined to the Active Directory domain called EXAMPLE.COM.client# /usr/sbin/kclient -T ms_ad Starting client setup --------------------------------------------------- Attempting to join 'CLIENT' to the 'EXAMPLE.COM' domain. Password for Administrator@EXAMPLE.COM: <Type the password> Forest name found: example.com Looking for local KDCs, DCs and global catalog servers (SVR RRs). Setting up /etc/krb5/krb5.conf Creating the machine account in AD via LDAP. --------------------------------------------------- Setup COMPLETE. # 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/6956Adjust 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/6956If 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. Change the process used to locate the KDCs.Starting with the Solaris 10 5/08 and Solaris Express Developer Edition 1/08 releases, 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.conf4 man page for more information. Note that referrals are always tried first. Change the process used to determine the realm for a host.Starting with the Solaris 10 5/08 and Solaris Express Developer Edition 1/08 releases, 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.conf4 man page for more information. Note that referrals will always be tried first. 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.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 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: 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: 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: Add the host principal to the server's keytab file.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: Quit kadmin.kadmin: quit 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.conf4 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 ticketswarning about expirationwarning about ticket expirationIf 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.conf4 man page for more information. 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 } @ 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" 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 This procedure allows a client to access a NFS file system that requires Kerberos authentication with the root ID privilege. In particular, if the NFS file system is shared with options like: o sec=krb5,root=client1.sun.com. Become superuser. 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 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 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 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 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_migrate5 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.acl4 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 clock skewKerberos and synchronizing clocksoverview Network Time ProtocolNTP 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. 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.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.

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. master KDCswapping with slave KDC slave KDCsswapping with master KDC KDCswapping master and slave swapping master and slave KDCs 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). 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 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 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. 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 access control listACLkadm5.acl filemaster KDC entryOn 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.acl4 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.kdc1 # svcadm enable -r network/security/krb5_prop kdc1 # svcadm enable -r network/security/krb5kdc 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 Configure a Master KDC.databasesbacking up and propagating KDC KDCbacking up and propagating propagationKerberos database backupKerberos database slave_datatrans fileKDC propagation and 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.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 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 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. 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...]]verbosePrints the name of each principal and policy that is being backed up. dbnameDefines 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. filenameDefines 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. principalsDefines 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. 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.COMIn 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 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] verbosePrints the name of each principal and policy that is being restored. dbnameDefines 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. updateUpdates the existing database. Otherwise, a new database is created or the existing database is overwritten. filenameDefines 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 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 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. 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 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.conf4 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 fileAdding 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.aclThis 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. 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 Restart kpropd.kdc2 # svcadm restart network/security/krb5_prop 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/6956Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in the Online Help URL in the Graphical Kerberos Administration Tool. 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: 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: 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.conf4 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 kprop1M 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 KDCcopying administration files from slave to masterOn 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.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/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.comYou 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 stash filecreatingcreatingstash filekdb5_util commandcreating stash fileOn 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> KDCsynchronizing clocksslave KDCclock synchronizingKerberos slave server andNTPslave KDC andsynchronizing clocksslave KDCOn 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. krb5kdc daemonstartingKDCstarting daemonstartingKDC daemonOn the new slave, start the KDC daemon (krb5kdc).kdc3 # svcadm enable network/security/krb5kdc 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. 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 2004The 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 2004Notice 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. 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.Do not use this procedure if you are using incremental propagation. Become superuser on the master KDC. 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 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 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.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.

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

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. 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. 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.comThe 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.comNote 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.COMThe kpropd.acl file on the KDC slaves being propagated by slave-1 would contain the following entry:host/slave-1.example.com@EXAMPLE.COM 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. Become superuser on the KDC that contains the stash file. Remove the stash file.# rm stash-fileWhere stash-file is the path to the stash file. By default, the stash file is located at /var/krb5/.k5.realm. If you need to re-create the stash file, you can use the f option of the kdb5_util command. 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.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 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 If the KDC records are stored in DB2, migrate DB2 entries.Dump the DB2 entries.# kdb5_util dump > dumpfile Load the database into the LDAP server.# kdb5_util load -update dumpfile Add the principal attributes to the KDC.# kadmin.local -q 'addprinc willf' 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 Follow these steps to increase security on Kerberos application servers and on KDC servers. Kerberosenabling Kerberized applications only Kerberos commandsenabling only Kerberized enablingKerberized applications only 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" 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 accessrestricting for KDC servers KDCrestricting access to servers restricting access for 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 krdb5_kprop if the KDC is a slave or only 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.