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.
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. | |
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. | |
3. Configure the KDC servers. |
Configures and builds the master KDC and the slave KDC servers and the KDC database for a realm. | |
4. (Optional) Increase security on the KDC servers. |
Prevents security breaches on the KDC servers. | |
5. (Optional) Configure swappable KDC servers. |
Makes the task of swapping the master KDC and a slave KDC easier. |
Once the required steps have been completed, the following procedures can be used, when appropriate.
Task |
Description |
For Instructions |
---|---|---|
Configure cross-realm authentication. |
Enables communications from one realm to another realm. | |
Configure Kerberos application servers. |
Enables a server to support services such as ftp, telnet, and rsh using Kerberos authentication. | |
Configure Kerberos clients. |
Enables a client to use Kerberos services. | |
Configure Kerberos NFS server. |
Enables a server to share a file system that requires Kerberos authentication. | |
Increase security on an application server. |
Increases security on an application server by restricting access to authenticated transactions only. |
After you install the Kerberos software, you must configure the KDC servers. Configuring a master KDC and at least one slave KDC provides the service that issues credentials. These credentials are the basis for the Kerberos service, so the KDCs must be installed before you attempt other tasks.
The most significant difference between a master KDC and a slave KDC is that only the master KDC can handle database administration requests. For instance, changing a password or adding a new principal must be done on the master KDC. These changes can then be propagated to the slave KDCs. Both the slave KDC and master KDC generate credentials. This feature provides redundancy in case the master KDC cannot respond.
Table 23–1 Configuring KDC Servers (Task Map)
Task |
Description |
For Instructions |
---|---|---|
Configuring a Master KDC |
Configures and builds the master KDC server and database for a realm using an automatic process, which is good for scripts. | |
Configures and builds the master KDC server and database for a realm using an interactive process, which is sufficient for most installations | ||
Configures and builds the master KDC server and database for a realm using a manual process, which is needed for more complex installations | ||
Configures and builds the master KDC server and database for a realm using a manual process and using LDAP for the KDC | ||
Configuring a slave KDC server. |
Configures and builds a slave KDC server for a realm using an automatic process, which is good for scripts | |
Configures and builds a slave KDC server for a realm using an interactive process, which is sufficient for most installations | ||
Configures and builds a slave KDC server for a realm using a manual process, which is needed for more complex installations | ||
Refreshing principal keys on a KDC server. |
Updates the session key on a KDC server to use new encryption types. |
How to Refresh the Ticket Granting Service Keys on a Master Server |
Starting with the Solaris Express Developer Edition 1/08 release, 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.
kdc1# kdcmgr -a kws/admin -r EXAMPLE.COM create master Starting server setup --------------------------------------- Setting up /etc/krb5/kdc.conf Setting up /etc/krb5/krb5.conf Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the password> Re-enter KDC database master key to verify: <Type it again> Authenticating as principal root/admin@EXAMPLE.COM with password. WARNING: no policy specified for kws/admin@EXAMPLE.COM; defaulting to no policy Enter password for principal "kws/admin@EXAMPLE.COM": <Type the password> Re-enter password for principal "kws/admin@EXAMPLE.COM": <Type it again> Principal "kws/admin@EXAMPLE.COM" created. Setting up /etc/krb5/kadm5.acl. --------------------------------------------------- Setup COMPLETE. kdc1# |
Starting with the Solaris Express Developer Edition 1/08 release, a master 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.
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# |
The kdcmgr status command can be used to display information about either a master or a slave KDC server.
In this procedure, incremental propagation is configured. In addition, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
admin principal = kws/admin
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Adjust 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.
Edit the Kerberos configuration file (krb5.conf).
You need to change the realm names and the names of the servers. See the krb5.conf(4) man page for a full description of this file.
kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc1.example.com admin_server = kdc1.example.com } [domain_realm] .example.com = EXAMPLE.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956 } |
In this example, the lines for default_realm, kdc, admin_server, and all domain_realm entries were changed. In addition, the line that defines the help_url was edited.
If you want to restrict the encryption types, you can set the default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.
Edit the KDC configuration file (kdc.conf).
You need to change the realm name. See the kdc.conf(4) man page for a full description of this file.
kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] EXAMPLE.COM = { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s sunw_dbprop_enable = true sunw_dbprop_master_ulogsize = 1000 } |
In this example, the realm name definition in the realms section was changed. Also, in the realms section, lines to enable incremental propagation and to select the number of updates the KDC master keeps in the log were added.
If you want to restrict the encryption types, you can set the permitted_enctypes, supported_enctypes, or master_key_type lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.
Create the KDC database by using the kdb5_util command.
The kdb5_util command creates the KDC database. Also, when used with the -s option, this command creates a stash file that is used to authenticate the KDC to itself before the kadmind and krb5kdc daemons are started.
kdc1 # /usr/sbin/kdb5_util create -s Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM' master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <Type the key> Re-enter KDC database master key to verify: <Type it again> |
Edit the Kerberos access control list file (kadm5.acl).
Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC.
kws/admin@EXAMPLE.COM * |
The entry gives the kws/admin principal in the EXAMPLE.COM realm the ability to modify principals or policies in the KDC. The default installation includes an asterisk (*) to match all admin principals. This default could be a security risk, so it is more secure to include a list of all of the admin principals. See the kadm5.acl(4) man page for more information.
Start the kadmin.local command and add principals.
The next substeps create principals that are used by the Kerberos service.
kdc1 # /usr/sbin/kadmin.local kadmin.local: |
Add administration principals to the database.
You can add as many admin principals as you need. You must add at least one admin principal to complete the KDC configuration process. For this example, a kws/admin principal is added. You can substitute an appropriate principal name instead of “kws.”
kadmin.local: addprinc kws/admin Enter password for principal kws/admin@EXAMPLE.COM:<Type the password> Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again> Principal "kws/admin@EXAMPLE.COM" created. kadmin.local: |
Create the kiprop principals.
The kiprop principal is used to authorize updates from the master KDC.
kadmin.local: addprinc -randkey kiprop/kdc1.example.com Principal "kiprop/kdc1.example.com@EXAMPLE.COM" created. kadmin.local: |
Quit kadmin.local.
You have added all of the required principals for the next steps.
kadmin.local: quit |
Start the Kerberos daemons.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
Start kadmin and add more principals.
At this point, you can add principals by using the Graphical Kerberos Administration Tool. To do so, you must log in with one of the admin principal names that you created earlier in this procedure. However, the following command-line example is shown for simplicity.
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
Create the master KDC host principal.
The host principal is used by Kerberized applications, such as kprop to propagate changes to the slave KDCs. This principal is also used to provide secure remote access to the KDC server using applications, like ssh. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.
kadmin: addprinc -randkey host/kdc1.example.com Principal "host/kdc1.example.com@EXAMPLE.COM" created. kadmin: |
(Optional) Create the kclient principal.
This principal is used by the kclient utility during the installation of a Kerberos client. If you do not plan on using this utility, then you do not need to add the principal. The users of the kclient utility need to use this password.
kadmin: addprinc clntconfig/admin Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password> Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again> Principal "clntconfig/admin@EXAMPLE.COM" created. kadmin: |
Add the master KDC's host principal to the master KDC's keytab file.
Adding the host principal to the keytab file allows this principal to be used by application servers, like sshd, automatically.
kadmin: ktadd host/kdc1.example.com Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
Quit kadmin.
kadmin: quit |
(Optional) Synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.
Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
Configure Slave KDCs.
To provide redundancy, make sure to install at least one slave KDC. See How to Manually Configure a Slave KDC for specific instructions.
Starting with the Solaris 10 5/08 and the Solaris Express Developer Edition 1/08 releases, a KDC can be configured to use an LDAP data server by using the following procedure.
In this procedure, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
Master KDC = kdc1.example.com
Directory Server = dsserver.example.com
admin principal = kws/admin
Online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
Adjust 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 JavaTM Directory Server Enterprise Edition release.
Become superuser on the KDC.
Configure the master KDC to use SSL to reach the directory server.
The following steps configure a Solaris Express Developer Release KDC to use the Directory Server 6.1 self-signed certificate. If the certificate has expired, follow the instructions for renewing a certificate in To Manage Self-Signed Certificates in Sun Java System Directory Server Enterprise Edition 6.3 Administration Guide.
On the directory server, export the self-signed directory server certificate.
# /export/sun-ds6.1/ds6/bin/dsadm show-cert -F der /export/sun-ds6.1/directory2 \ defaultCert > /tmp/defaultCert.cert.der |
On the master KDC, import the directory server certificate.
# pktool setpin keystore=nss dir=/var/ldap # chmod a+r /var/ldap/*.db # pktool import keystore=nss objtype=cert trust="CT" infile=/tmp/defaultCert.certutil.der \ label=defaultCert dir=/var/ldap |
On the master KDC, test that SSL is working.
This example assumes that the cn=directory managerentry has administration privileges.
/usr/bin/ldapsearch -Z -P /var/ldap -D "cn=directory manager" \ -h dsserver.example.com -b "" -s base objectclass='*' Subject: "CN=dsserver.example.com,CN=636,CN=Directory Server,O=Example Corporation |
Note that the CN=dsserver.example.com entry should include the fully qualified host name, not a short version.
Populate the LDAP directory, if necessary.
Add the Solaris Kerberos schema to the existing schema.
# ldapmodify -h dsserver.example.com -D "cn=directory manager" -f /usr/share/lib/ldif/kerberos.ldif |
Create the Kerberos container in the LDAP directory.
Add the following entries to the krb5.conf file.
Define the database type.
Add an entry to define the database_moduleto the realms section.
database_module = LDAP |
Define the database module.
[dbmodules] LDAP = { ldap_kerberos_container_dn = "cn=krbcontainer,dc=example,dc=com" db_library = kldap ldap_kdc_dn = "cn=kdc service,ou=profile,dc=example,dc=com" ldap_kadmind_dn = "cn=kadmin service,ou=profile,dc=example,dc=com" ldap_cert_path = /var/ldap ldap_servers = ldaps://dsserver.example.com } |
Create the KDC in the LDAP directory.
This command creates krbcontainer and several other objects. It also creates a /var/krb5/.k5.EXAMPLE.COM master key stash file.
# kdb5_ldap_util -D "cn=directory manager" create -P abcd1234 -r EXAMPLE.COM -s |
Stash the KDC bind Distinguished Name (DN) passwords.
These passwords are used by the KDC when it binds to the DS. The KDC uses different roles depending on the type of access the KDC is using.
# kdb5_ldap_util stashsrvpw "cn=kdc service,ou=profile,dc=example,dc=com" # kdb5_ldap_util stashsrvpw "cn=kadmin service,ou=profile,dc=example,dc=com" |
Add KDC service roles.
Create a kdc_roles.ldif file with contents like this:
dn: cn=kdc service,ou=profile,dc=example,dc=com cn: kdc service sn: kdc service objectclass: top objectclass: person userpassword: test123 dn: cn=kadmin service,ou=profile,dc=example,dc=com cn: kadmin service sn: kadmin service objectclass: top objectclass: person userpassword: test123 |
Create the role entries in the LDAP directory
# ldapmodify -a -h dsserver.example.com -D "cn=directory manager" -f kdc_roles.ldif |
Set the ACLs for the KDC-related roles.
# cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager" # Set kadmin ACL for everything under krbcontainer. dn: cn=krbcontainer,dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///cn=krbcontainer,dc=example,dc=com")(targetattr="krb*")(version 3.0;\ acl kadmin_ACL; allow (all)\ userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";) # Set kadmin ACL for everything under the people subtree if there are # mix-in entries for krb princs: dn: ou=people,dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///ou=people,dc=example,dc=com")(targetattr="krb*")(version 3.0;\ acl kadmin_ACL; allow (all)\ userdn = "ldap:///cn=kadmin service,ou=profile,dc=example,dc=com";) EOF |
Edit the Kerberos configuration file (krb5.conf).
You need to change the realm names and the names of the servers. See the krb5.conf(4) man page for a full description of this file.
kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc1.example.com admin_server = kdc1.example.com } [domain_realm] .example.com = EXAMPLE.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956 } |
In this example, the lines for default_realm, kdc, admin_server, and all domain_realm entries were changed. In addition, the line that defines the help_url was edited.
If you want to restrict the encryption types, you can set the default_tkt_enctypes or default_tgs_enctypes lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.
Edit the KDC configuration file (kdc.conf).
You need to change the realm name. See the kdc.conf(4) man page for a full description of this file.
kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] EXAMPLE.COM = { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s sunw_dbprop_enable = true sunw_dbprop_master_ulogsize = 1000 } |
In this example, the realm name definition in the realms section was changed. Also, in the realms section, lines to enable incremental propagation and to select the number of updates the KDC master keeps in the log were added.
If you want to restrict the encryption types, you can set the permitted_enctypes, supported_enctypes, or master_key_type lines. Refer to Using Kerberos Encryption Types for a description of the issues involved with restricting the encryption types.
Edit the Kerberos access control list file (kadm5.acl).
Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC.
kws/admin@EXAMPLE.COM * |
The entry gives the kws/admin principal in the EXAMPLE.COM realm the ability to modify principals or policies in the KDC. The default installation includes an asterisk (*) to match all admin principals. This default could be a security risk, so it is more secure to include a list of all of the admin principals. See the kadm5.acl(4) man page for more information.
Start the kadmin.local command and add principals.
The next substeps create principals that are used by the Kerberos service.
kdc1 # /usr/sbin/kadmin.local kadmin.local: |
Add administration principals to the database.
You can add as many admin principals as you need. You must add at least one admin principal to complete the KDC configuration process. For this example, a kws/admin principal is added. You can substitute an appropriate principal name instead of “kws.”
kadmin.local: addprinc kws/admin Enter password for principal kws/admin@EXAMPLE.COM:<Type the password> Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again> Principal "kws/admin@EXAMPLE.COM" created. kadmin.local: |
Quit kadmin.local.
You have added all of the required principals for the next steps.
kadmin.local: quit |
Start the Kerberos daemons.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
Start kadmin and add more principals.
At this point, you can add principals by using the Graphical Kerberos Administration Tool. To do so, you must log in with one of the admin principal names that you created earlier in this procedure. However, the following command-line example is shown for simplicity.
kdc1 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
Create the master KDC host principal.
The host principal is used by Kerberized applications, such as klist and kprop. Solaris 10 clients use this principal when mounting an authenticated NFS file system. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.
kadmin: addprinc -randkey host/kdc1.example.com Principal "host/kdc1.example.com@EXAMPLE.COM" created. kadmin: |
(Optional) Create the kclient principal.
This principal is used by the kclient utility during the installation of a Kerberos client. If you do not plan on using this utility, then you do not need to add the principal. The users of the kclient utility need to use this password.
kadmin: addprinc clntconfig/admin Enter password for principal clntconfig/admin@EXAMPLE.COM:<Type the password> Re-enter password for principal clntconfig/admin@EXAMPLE.COM: <Type it again> Principal "clntconfig/admin@EXAMPLE.COM" created. kadmin: |
Add the master KDC's host principal to the master KDC's keytab file.
Adding the host principal to the keytab file allows this principal to be used automatically.
kadmin: ktadd host/kdc1.example.com Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/kdc1.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
Quit kadmin.
kadmin: quit |
(Optional) Synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.
Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
Configure Slave KDCs.
To provide redundancy, make sure to install at least one slave KDC. See How to Manually Configure a Slave KDC for specific instructions.
Starting with the Solaris Express Developer Edition 1/08 release, 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.
kdc2# kdcmgr -a kws/admin -r EXAMPLE.COM create -m kdc1 slave Starting server setup --------------------------------------- Setting up /etc/krb5/kdc.conf Setting up /etc/krb5/krb5.conf Obtaining TGT for kws/admin ... Password for kws/admin@EXAMPLE.COM: <Type the password> Setting up /etc/krb5/kadm5.acl. Setting up /etc/krb5/kpropd.acl. Waiting for database from master... Waiting for database from master... Waiting for database from master... kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the password> --------------------------------------------------- Setup COMPLETE. kdc2# |
Starting with the Solaris Express Developer Edition 1/08 release, 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.
kdc1# kdcmgr create slave Starting server setup --------------------------------------- Enter the Kerberos realm: EXAMPLE.COM What is the master KDC's host name?: kdc1 Setting up /etc/krb5/kdc.conf Setting up /etc/krb5/krb5.conf Obtaining TGT for kws/admin ... Password for kws/admin@EXAMPLE.COM: <Type the password> Setting up /etc/krb5/kadm5.acl. Setting up /etc/krb5/kpropd.acl. Waiting for database from master... Waiting for database from master... Waiting for database from master... kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the password> --------------------------------------------------- Setup COMPLETE. kdc2# |
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.conf(4) man page for a full description of this file.
kdc1 # cat /etc/krb5/krb5.conf . . [realms] EXAMPLE.COM = { kdc = kdc1.example.com kdc = kdc2.example.com admin_server = kdc1.example.com } |
On the master KDC, add an kiprop entry to kadm5.acl.
This entry allows the master KDC to receive requests for incremental propagation for the kdc2 server.
kdc1 # cat /etc/krb5/kadm5.acl */admin@EXAMPLE.COM * kiprop/kdc2.example.com@EXAMPLE.COM p |
On the master KDC, restart kadmind to use the new entries in the kadm5.acl file.
kdc1 # svcadm restart network/security/kadmin |
On all slave KDCs, copy the KDC administration files from the master KDC server.
This step needs to be followed on all slave KDCs, because the master KDC server has updated information that each KDC server needs. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master KDC:
/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
On all slave KDCs, add an entry for the master KDC and each slave KDC into the database propagation configuration file, kpropd.acl.
This information needs to be updated on all slave KDC servers.
kdc2 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM |
On all slave KDCs, make sure that the Kerberos access control list file, kadm5.acl, is not populated.
An unmodified kadm5.acl file would look like:
kdc2 # cat /etc/krb5/kadm5.acl */admin@___default_realm___ * |
If the file has kiprop entries, remove them.
On the new slave, change an entry in kdc.conf.
Replace the sunw_dbprop_master_ulogsize entry with an entry defining sunw_dbprop_slave_poll. The entry sets the poll time to 2 minutes.
kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] EXAMPLE.COM= { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal 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 |
On the new slave, create a stash file by using kdb5_util.
kdc2 # /usr/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the key> |
(Optional) On the new slave KDC, synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.
Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
On the new slave, start the KDC daemon (krb5kdc).
kdc2 # svcadm enable network/security/krb5kdc |
When the Ticket Granting Service (TGS) principal only has a DES key, which is the case for Solaris KDC servers created prior to the Solaris 10 release, the key restricts the encryption type of the Ticket Granting Ticket (TGT) session key to DES. If a Solaris KDC is updated to Solaris 10 which supports additional, stronger encryption types, the administrator may expect that stronger encryption will be used for all session keys generated by the KDC. However if the existing TGS principal does not have it's keys refreshed to include the new encryption types, then the TGT session key will be continue to be limited to DES. The following procedure refreshes the key so that additional encryption types may be used.
Refresh the TGS service principal key.
kdc1 % /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM |
If you are logged on to the KDC master as root, you can refresh the TGS service principal with the following command:
kdc1 # kadmin.local -q 'cpw -randkey krbtgt/EXAMPLE.COM@EXAMPLE.COM' |
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).
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: quit |
The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@EAST.EXAMPLE.COM must be the same in both realms.
Add entries to the Kerberos configuration file (krb5.conf) to define domain names for every realm.
# cat /etc/krb5/krb5.conf [libdefaults] . . [domain_realm] .eng.east.example.com = ENG.EAST.EXAMPLE.COM .east.example.com = EAST.EXAMPLE.COM |
In this example, domain names for the ENG.EAST.EXAMPLE.COM and EAST.EXAMPLE.COM realms are defined. It is important to include the subdomain first, because the file is searched top down.
Copy the Kerberos configuration file to all clients in this realm.
For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.
Repeat all of these steps in the second realm.
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: quit |
The password that is specified for each service principal must be identical in both KDCs. Thus, the password for the service principal krbtgt/ENG.EAST.EXAMPLE.COM@SALES.WEST.EXAMPLE.COM must be the same in both realms.
Add entries in the Kerberos configuration file to define the direct path to the remote realm.
This example shows the clients in the ENG.EAST.EXAMPLE.COM realm. You would need to swap the realm names to get the appropriate definitions in the SALES.WEST.EXAMPLE.COM realm.
# cat /etc/krb5/krb5.conf [libdefaults] . . [capaths] ENG.EAST.EXAMPLE.COM = { SALES.WEST.EXAMPLE.COM = . } SALES.WEST.EXAMPLE.COM = { ENG.EAST.EXAMPLE.COM = . } |
Copy the Kerberos configuration file to all clients in the current realm.
For cross-realm authentication to work, all systems (including slave KDCs and other servers) must have the new version of the Kerberos configuration file (/etc/krb5/krb5.conf) installed.
Repeat all of these steps for the second realm.
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.
(Optional) Install the NTP client or another clock synchronization mechanism.
See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
Add principals for the new server and update the server's keytab.
The following command reports the existence of the host principal:
boston # klist -k |grep host 4 host/boston.example.com@EXAMPLE.COM 4 host/boston.example.com@EXAMPLE.COM 4 host/boston.example.com@EXAMPLE.COM 4 host/boston.example.com@EXAMPLE.COM |
If the command does not return a principal, then create new principals using the following steps.
How to use the Graphical Kerberos Administration Tool to add a principal is explained in How to Create a New Kerberos Principal. The example in the following steps shows how to add the required principals using the command line. You must log in with one of the admin principal names that you created when configuring the master KDC.
boston # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
Create the server's host principal.
The host principal is used:
To authenticate traffic when using the remote commands, such as rsh and ssh.
By pam_krb5 to prevent KDC spoofing attacks by using the host principal to verify that a user's Kerberos credential was obtained from a trusted KDC.
To allow the root user to automatically acquire a Kerberos credential without requiring that a root principal exist. This can be useful when doing a manual NFS mount where the share requires a Kerberos credential.
This principal is required if traffic using the remote application is to be authenticated using the Kerberos service. If the server has multiple hostnames associated with it, then create a principal for each hostname using the FQDN form of the hostname.
kadmin: addprinc -randkey host/boston.example.com Principal "host/boston.example.com" created. kadmin: |
Add the server's host principal to the server's keytab.
If the kadmin command is not running, restart it with a command similar to the following: /usr/sbin/kadmin -p kws/admin
If the server has multiple hostnames associated with it, then add a principal to the keytab for each hostname.
kadmin: ktadd host/boston.example.com Entry for principal host/boston.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/boston.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/boston.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/boston.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/boston.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
Quit kadmin.
kadmin: quit |
NFS services use UNIX user IDs (UIDs) to identify a user and cannot directly use GSS credentials. To translate the credential to a UID, a credential table that maps user credentials to UNIX UIDs might need to be created. See Mapping GSS Credentials to UNIX Credentials for more information on the default credential mapping. The procedures in this section focus on the tasks that are necessary to configure a Kerberos NFS server, to administer the credential table, and to initiate Kerberos security modes for NFS-mounted file systems. The following task map describes the tasks that are covered in this section.
Table 23–2 Configuring Kerberos NFS Servers (Task Map)
Task |
Description |
For Instructions |
---|---|---|
Configure a Kerberos NFS server. |
Enables a server to share a file system that requires Kerberos authentication. | |
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. | |
Change the credential table that maps user credentials to UNIX UIDs. |
Updates information in 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. | |
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 |
In this procedure, the following configuration parameters are used:
Realm name = EXAMPLE.COM
DNS domain name = example.com
NFS server = denver.example.com
admin principal = kws/admin
Complete the prerequisites for configuring a Kerberos NFS server.
The master KDC must be configured. To fully test the process, you need several clients.
(Optional) Install the NTP client or another clock synchronization mechanism.
Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be synchronized with the time on the KDC server within a maximum difference defined by the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
Configure the NFS server as a Kerberos client.
Follow the instructions in Configuring Kerberos Clients.
Start kadmin.
You can use the Graphical Kerberos Administration Tool to add a principal, as explained in How to Create a New Kerberos Principal. To do so, you must log in with one of the admin principal names that you created when you configured the master KDC. However, the following example shows how to add the required principals by using the command line.
denver # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
Create the server's NFS service principal.
Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.
Repeat this step for each unique interface on the system that might be used to access NFS data. If a host has multiple interfaces with unique names, each unique name must have its own NFS service principal.
kadmin: addprinc -randkey nfs/denver.example.com Principal "nfs/denver.example.com" created. kadmin: |
Add the server's NFS service principal to the server's keytab file.
Repeat this step for each unique service principal created in Step a.
kadmin: ktadd nfs/denver.example.com Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs denver.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
Quit kadmin.
kadmin: quit |
(Optional) Create special GSS credential maps, if needed.
Normally, the Kerberos service generates appropriate maps between the GSS credentials and the UNIX UIDs. The default mapping is described in Mapping GSS Credentials to UNIX Credentials. If the default mapping is not sufficient, see How to Create a Credential Table for more information.
Share the NFS file system with Kerberos security modes.
See How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes for more information.
The gsscred credential table is used by an NFS server to map Kerberos credentials to a UID. By default, the primary part of the principal name is matched to a UNIX login name. For NFS clients to mount file systems from an NFS server with Kerberos authentication, this table must be created if the default mapping is not sufficient.
Edit /etc/gss/gsscred.conf and change the security mechanism.
Change the mechanism to files.
Create the credential table by using the gsscred command.
# gsscred -m kerberos_v5 -a |
The gsscred command gathers information from all sources that are listed with the passwd entry in the /etc/nsswitch.conf file. You might need to temporarily remove the files entry, if you do not want the local password entries included in the credential table. See the gsscred(1M) man page for more information.
This procedure requires that the gsscred table has already been created on the NFS server. See How to Create a Credential Table for instructions.
Become superuser on the NFS server.
Add an entry to the credential table by using the gsscred command.
# gsscred -m mech [ -n name [ -u uid ]] -a |
Defines the security mechanism to be used.
Defines the principal name for the user, as defined in the KDC.
Defines the UID for the user, as defined in the password database.
Adds 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.
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-system |
Specifies the security modes to be used when sharing the file system. When using multiple security modes, the first mode in the list is used as the default.
Defines the path to the file system to be shared.
All clients that attempt to access files from the named file system require Kerberos authentication. To access files, the user principal on the NFS client should be authenticated.
(Optional) If the automounter is being used, edit the auto_master database to select a security mode other than the default.
You need not follow this procedure if you are not using the automounter to access the file system or if the default selection for the security mode is acceptable.
file-system auto_home -nosuid,sec=mode |
(Optional) Manually issue the mount command to access the file system by using a non-default mode.
Alternatively, you could use the mount command to specify the security mode, but this alternative does not take advantage of the automounter.
# mount -F nfs -o sec=mode file-system |
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 nfssec(5) man page for more information.
# sharemgr share -F nfs -p -o sec=krb5:krb5i:krb5p /export/home |
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. | |
Configure a Kerberos client. |
Manually installs a Kerberos client. Use this procedure if each client installation requires unique installation parameters. | |
Automatically installs a Kerberos client. Use this procedure if the installation parameters for each client are the same. | ||
Interactively installs a Kerberos client. Use this procedure if only a few of the installation parameters need to change. | ||
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 |
Disable verification of the KDC that issued a client Ticket Granting Ticket (TGT). |
Allows clients that do not have a host principal stored in the local keytab file to skip the security check that verifies that the KDC that issued the TGT is the same server that issued the host principal. |
How to Disable Verification of the Ticket Granting Ticket (TGT) |
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–10 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.conf(4) 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.
(Optional) Enable DNS resource record creation for the client.
The first command causes DNS records to be created when the client is joined to the Active Directory domain. The second command records this change in the running configuration of this service.
client# svccfg -s smb/server setprop smbd/ddns_enable=true client# svcadm refresh smb/server |
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/6956
Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in the Online Help URL in the Graphical Kerberos Administration Tool.
Become superuser.
Edit the Kerberos configuration file (krb5.conf).
To change the file from the Kerberos default version, you need to change the realm names and the server names. You also need to identify the path to the help files for gkadmin.
kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kdc1.example.com kdc = kdc2.example.com admin_server = kdc1.example.com } [domain_realm] .example.com = EXAMPLE.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956 |
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.
(Optional) 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.conf(4) man page for more information. Note that referrals are always tried first.
(Optional) Change the process used to determine the realm for a host.
Starting with the Solaris 10 5/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.conf(4) man page for more information. Note that referrals will always be tried first.
(Optional) Synchronize the client's clock with the master KDC's clock by using NTP or another clock synchronization mechanism.
Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be synchronized with the time on the KDC server within a maximum difference defined in the clockskew relation in the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
Start kadmin.
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: |
(Optional) Create a user principal if a user principal does not already exist.
You need to create a user principal only if the user associated with this host does not already have a principal assigned to him or her.
kadmin: addprinc mre Enter password for principal mre@EXAMPLE.COM: <Type the password> Re-enter password for principal mre@EXAMPLE.COM: <Type it again> kadmin: |
(Optional) Create a root principal and add the principal to the server's keytab file.
This step is required so that the client can have root access to file systems mounted using the NFS service. This step is also required if non-interactive root access is needed, such as running cron jobs as root.
If the client does not require root access to a remote file system which is mounted using the NFS service, then you can skip this step. The root principal should be a two component principal with the second component the host name of the Kerberos client system to avoid the creation of a realm wide root principal. Note that when the principal instance is a host name, the FQDN must be specified in lowercase letters, regardless of the case of the domain name in the /etc/resolv.conf file.
kadmin: addprinc -randkey root/client.example.com Principal "root/client.example.com" created. kadmin: ktadd root/client.example.com Entry for principal root/client.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal root/client.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal root/client.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal root/client.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal root/client.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
Create a host principal and add the principal to the server's keytab file.
The host principal is used by remote access services to provide authentication. The principal allows root to acquire a credential, if there is not one already in the keytab file.
kadmin: addprinc -randkey host/denver.example.com Principal "host/denver.example.com@EXAMPLE.COM" created. kadmin: ktadd host/denver.example.com Entry for principal host/denver.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/denver.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/denver.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/denver.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal host/denver.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
(Optional) Add the server's NFS service principal to the server's keytab file.
This step is only required if the client needs to access NFS file systems using Kerberos authentication.
kadmin: ktadd nfs/denver.example.com Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs/denver.example.com with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs/denver.example.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs/denver.example.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab. Entry for principal nfs/denver.example.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab. kadmin: |
Quit kadmin.
kadmin: quit |
(Optional) Enable Kerberos with NFS.
Enable Kerberos security modes in the /etc/nfssec.conf file.
Edit the /etc/nfssec.conf file and remove the “#” that is placed in front of the Kerberos security modes.
# cat /etc/nfssec.conf . . # # Uncomment the following lines to use Kerberos V5 with NFS # krb5 390003 kerberos_v5 default - # RPCSEC_GSS krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS |
Enable DNS.
If the /etc/resolv.conf file has not already been created, then create this file as the service principal canonicalization is dependent upon DNS to do this. See the resolv.conf(4) man page for more information.
Restart the gssd service.
After the /etc/resolv.conf file has been created or modified you must then restart the gssd daemon to reread any changes.
# svcadm restart network/rpc/gss |
If you want the client to automatically renew the TGT or to warn users about Kerberos ticket expiration, create an entry in the /etc/krb5/warn.conf file.
See the warn.conf(4) man page for more information.
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 disables the security check that checks that the KDC of the host principal stored in the local /etc/krb5/krb5.keytab file is the same KDC that issued the Ticket Granting Ticket. This check prevents DNS spoofing attacks. However, for some client configurations, the host principal may not be available, so this check would need to be disabled to allow the client to function. These are the configurations that require that this check is disabled:
The client IP address is dynamically assigned. For instance, a DHCP client.
The client is not configured to host any services, so no host principal was created.
The host key is not stored on the client.
Become superuser.
Change the krb5.conf file.
If the verify_ap_req_nofail option is set to false, the TGT verification process is not enabled. See the krb5.conf(4) man page for more information about this option.
client # cat /etc/krb5/krb5.conf [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false ... |
The verify_ap_req_nofail option can be entered in either the [libdefaults] or the [realms] section of the krb5.conf file. If the option is in the [libdefaults]section, the setting is used for all realms. If the option is in the [realms]section, the setting only applies to the defined realm.
This procedure allows a client to access a NFS file system that requires Kerberos authentication with the root ID privilege. In particular, when the NFS file system is shared with options like: -o sec=krb5,root=client1.sun.com.
Become superuser.
Start kadmin.
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 |
(Optional) Force an immediate password change, if needed.
The newly created Kerberos accounts can have their password expiration time set to the current time (now), in order to force an immediate Kerberos password change. To set the expiration time to now, add the expire_pw option to the lines which use the pam_krb5_migrate module. See the pam_krb5_migrate(5) man page for more information.
# cat /etc/pam.conf . . dtlogin auth optional pam_krb5_migrate.so.1 expire_pw |
Add the pam_krb5 module to the account stack.
This addition allows for password expiration in Kerberos to block access.
# cat /etc/pam.conf . . # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account required pam_krb5.so.1 other account required pam_unix_account.so.1 |
Add the pam_krb5 module to the password stack.
This addition allows for passwords to be updated when the password expire.
# cat /etc/pam.conf . . # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 |
On the master KDC, update the access control file.
The following entries grant migrate and inquire privileges to the host/server1.example.com service principal for all users, excepting the root user. It is important that users who should not be migrated are listed in the kadm5.acl file using the U privilege. These entries need to be before the permit all or ui entry. See the kadm5.acl(4) man page for more information.
kdc1 # cat /etc/krb5/kadm5.acl host/server1.example.com@EXAMPLE.COM U root host/server1.example.com@EXAMPLE.COM ui * */admin@EXAMPLE.COM * |
On the master KDC, restart the Kerberos administration daemon.
This step allows the kadmind daemon to use the new kadm5.acl entries.
kdc1 # svcadm restart network/security/kadmin |
On the master KDC, add entries to the pam.conf file.
The following entries enable the kadmind daemon to use the k5migrate PAM service, to validate UNIX user password for accounts that require migration.
# grep k5migrate /etc/pam.conf k5migrate auth required pam_unix_auth.so.1 k5migrate account required pam_unix_account.so.1 |
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.
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.
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 Manually Configure a Slave KDC for instructions.
Move the master KDC commands.
To prevent the master KDC commands from being run from this slave KDC, move the kprop, kadmind, and kadmin.local commands to a reserved place.
kdc4 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save kdc4 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save kdc4 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save |
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: |
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 acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s sunw_dbprop_enable = true # sunw_dbprop_master_ulogsize = 1000 sunw_dbprop_slave_poll = 2m } |
On the old master KDC, move the master KDC commands and the kadm5.acl file.
To prevent the master KDC commands from being run, move the kprop, kadmind, and kadmin.local commands to a reserved place.
kdc1 # mv /usr/lib/krb5/kprop /usr/lib/krb5/kprop.save kdc1 # mv /usr/lib/krb5/kadmind /usr/lib/krb5/kadmind.save kdc1 # mv /usr/sbin/kadmin.local /usr/sbin/kadmin.local.save kdc1 # mv /etc/krb5/kadm5.acl /etc/krb5/kadm5.acl.save |
On the DNS server, change the alias names for the master KDC.
To change the servers, edit the example.com zone file and change the entry for masterkdc.
masterkdc IN CNAME kdc4 |
On the DNS server, restart the Internet domain name server.
Run the following command to reload the new alias information:
# svcadm refresh network/dns/server |
On the new master KDC, move the master KDC commands and the slave kpropd.acl file.
kdc4 # mv /usr/lib/krb5/kprop.save /usr/lib/krb5/kprop kdc4 # mv /usr/lib/krb5/kadmind.save /usr/lib/krb5/kadmind kdc4 # mv /usr/sbin/kadmin.local.save /usr/sbin/kadmin.local kdc4 # mv /etc/krb5/kpropd.acl /etc/krb5/kpropd.acl.save |
On the new master KDC, create the Kerberos access control list file (kadm5.acl).
Once populated, the /etc/krb5/kadm5.acl file should contain all principal names that are allowed to administer the KDC. The file should also list all of the slaves that make requests for incremental propagation. See the kadm5.acl(4) man page for more information.
kdc4 # cat /etc/krb5/kadm5.acl kws/admin@EXAMPLE.COM * kiprop/kdc1.example.com@EXAMPLE.COM p |
On the new master KDC, specify the update log size in the kdc.conf file.
Comment out the sunw_dbprop_slave_poll entry and add an entry defining sunw_dbprop_master_ulogsize. The entry sets the log size to 1000 entries.
kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] EXAMPLE.COM= { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal 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, 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 Manually Configure a Master KDC.
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...]] |
Prints the name of each principal and policy that is being backed up.
Defines the name of the database to back up. Note that you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal.
Defines the file that is used to back up the database. You can specify an absolute path for the file. If you don't specify a file, the database is dumped to standard output.
Defines a list of one or more principals (separated by a space) to back up. You must use fully qualified principal names. If you don't specify any principals, the entire database is backed up.
In the following example, the Kerberos database is backed up to a file called dumpfile. Because the -verbose option is specified, each principal is printed as it is backed up.
# kdb5_util dump -verbose dumpfile kadmin/kdc1.eng.example.com@ENG.EXAMPLE.COM krbtgt/ENG.EXAMPLE.COM@ENG.EXAMPLE.COM kadmin/history@ENG.EXAMPLE.COM pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM changepw/kdc1.eng.example.com@ENG.EXAMPLE.COM |
In the following example, the pak and pak/admin principals from the Kerberos database are backed up.
# kdb5_util dump -verbose dumpfile pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM pak/admin@ENG.EXAMPLE.COM pak@ENG.EXAMPLE.COM |
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] |
Prints the name of each principal and policy that is being restored.
Defines the name of the database to restore. Note you can specify an absolute path for the file. If the -d option is not specified, the default database name is /var/krb5/principal.
Updates the existing database. Otherwise, a new database is created or the existing database is overwritten.
Defines the file from which to restore the database. You can specify an absolute path for the file.
Start the KDC daemons.
kdc1 # svcadm enable -r network/security/krb5kdc kdc1 # svcadm enable -r network/security/kadmin |
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.conf(4) man page for more information.
kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] EXAMPLE.COM= { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal 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: |
On the master KDC, add a kiprop entry to kadm5.acl
This entry allows the master KDC to receive requests for incremental propagation from the kdc2 server.
kdc1 # cat /etc/krb5/kadm5.acl */admin@EXAMPLE.COM * kiprop/kdc2.example.com@EXAMPLE.COM p |
Comment out the kprop line in the root crontab file.
This step prevents the master KDC from propagating its copy of the KDC database.
kdc1 # crontab -e #ident "@(#)root 1.20 01/11/06 SMI" # # The root crontab should be used to perform accounting data collection. # # The rtc command is run to adjust the real time clock if and when # daylight savings time changes. # 10 3 * * * /usr/sbin/logadm 15 3 * * 0 /usr/lib/fs/nfs/nfsfind 1 2 * * * [ -x /usr/sbin/rtc ] && /usr/sbin/rtc -c > /dev/null 2>&1 30 3 * * * [ -x /usr/lib/gss/gsscred_clean ] && /usr/lib/gss/gsscred_clean #10 3 * * * /usr/lib/krb5kprop_script kdc2.example.sun.com #SUNWkr5ma |
Restart kadmind.
kdc1 # svcadm restart network/security/kadmin |
Reconfigure all slave KDC servers that use incremental propagation.
See How to Reconfigure a Slave KDC to Use Incremental Propagation for complete instructions.
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 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/6956
Adjust the URL to point to the “Graphical Kerberos Administration Tool” section, as described in the Online Help URL in the Graphical Kerberos Administration Tool.
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.conf(4) man page for a full description of this file.
kdc1 # cat /etc/krb5/krb5.conf . . [realms] EXAMPLE.COM = { kdc = kdc1.example.com kdc = kdc2.example.com kdc = kdc3.example.com admin_server = kdc1.example.com } |
On the master KDC, add an entry for the master KDC and each slave KDC into the kpropd.acl file.
See the kprop(1M) man page for a full description of this file.
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.example.com@EXAMPLE.COM host/kdc2.example.com@EXAMPLE.COM host/kdc3.example.com@EXAMPLE.COM |
On all slave KDCs, copy the KDC administration files from the master KDC server.
This step needs to be followed on all slave KDCs, because the master KDC server has updated information that each KDC server needs. You can use ftp or a similar transfer mechanism to grab copies of the following files from the master KDC:
/etc/krb5/krb5.conf
/etc/krb5/kdc.conf
/etc/krb5/kpropd.acl
On all slave KDCs, make sure that the Kerberos access control list file, kadm5.acl, is not populated.
An unmodified kadm5.acl file would look like:
kdc2 # cat /etc/krb5/kadm5.acl */admin@___default_realm___ * |
If the file has kiprop entries, remove them.
On the new slave, start the kadmin command.
You must log in with one of the admin principal names that you created when you configured the master KDC.
kdc2 # /usr/sbin/kadmin -p kws/admin Enter password: <Type kws/admin password> kadmin: |
Add the slave's host principal to the slave's keytab file by using kadmin.
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.com |
You might also want to change the time of the backups. This entry starts the backup process every day at 3:10 AM.
On the new slave, start the Kerberos propagation daemon.
kdc3 # svcadm enable network/security/krb5_prop |
On the master KDC, back up and propagate the database by using kprop_script.
If a backup copy of the database is already available, it is not necessary to complete another backup. See How to Manually Propagate the Kerberos Database to the Slave KDCs for further instructions.
kdc1 # /usr/lib/krb5/kprop_script kdc3.example.com Database propagation to kdc3.example.com: SUCCEEDED |
On the new slave, create a stash file by using kdb5_util.
kdc3 # /usr/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <Type the key> |
(Optional) On the new slave KDC, synchronize the master KDCs clock by using NTP or another clock synchronization mechanism.
Installing and using the Network Time Protocol (NTP) is not required. However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file for authentication to succeed. See Synchronizing Clocks Between KDCs and Kerberos Clients for information about NTP.
On the new slave, start the KDC daemon (krb5kdc).
kdc3 # svcadm enable network/security/krb5kdc |
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 2004 |
The following is a sample of results from running the kproplog command on a slave KDC server.
kdc2 # /usr/sbin/kproplog -h Kerberos update log (/var/krb5/principal.ulog) Update log dump: Log version #: 1 Log state: Stable Entry block size: 2048 Number of entries: 0 First serial #: None Last serial #: 140465 First time stamp: None Last time stamp: Fri Nov 28 01:06:13 2004 |
Notice that the values for the last serial number and the last timestamp are identical, which indicates that the slave is synchronized with the master KDC server.
In the slave KDC server output, notice that no update entries exist in the slave KDC server's update log. No entries exist because the slave KDC server does not keep a set of updates, unlike the master KDC server. Also, the KDC slave server does not include information on the first serial number or the first timestamp because this is not relevant information.
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.
(Optional) Back up the database by using the kdb5_util command.
# /usr/sbin/kdb5_util dump /var/krb5/slave_datatrans |
Propagate the database to a slave KDC by using the kprop command.
# /usr/lib/krb5/kprop -f /var/krb5/slave_datatrans slave-KDC |
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.
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.com |
The slave-1's kprop_script entry would look similar to the following:
0 4 * * * /usr/lib/krb5/kprop_script slave-2.example.com slave-3.example.com |
Note that the propagation on the slave starts an hour after it is propagated by the master.
The kpropd.acl file on the propagation slaves would contain the following entry:
host/master.example.com@EXAMPLE.COM |
The kpropd.acl file on the KDC slaves being propagated by slave-1 would contain the following entry:
host/slave-1.example.com@EXAMPLE.COM |
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-file |
Where 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.
Table 23–3 Configuring KDC Servers to Use LDAP (Task Map)
Task |
Description |
For Instructions |
---|---|---|
Configuring a Master KDC |
Configures and builds the master KDC server and database for a realm using a manual process and using LDAP for the KDC. | |
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 |
This procedure allows for Kerberos principal attributes to be associated with non-Kerberos object class types. In this procedure the krbprincipalaux, and krbTicketPolicyAux and krbPrincipalName attributes are associated with the people object class.
In this procedure, the following configuration parameters are used:
Directory Server = dsserver.example.com
user principal = willf@EXAMPLE.COM
Become superuser.
Prepare each entry in the people object class.
Repeat this step for each entry.
cat << EOF | ldapmodify -h dsserver.example.com -D "cn=directory manager" dn: uid=willf,ou=people,dc=example,dc=com changetype: modify objectClass: krbprincipalaux objectClass: krbTicketPolicyAux krbPrincipalName: willf@EXAMPLE.COM EOF |
Add a subtree attribute to the realm container.
This step allows for searching of principal entries in the ou=people,dc=example,dc=com container, as well as in the default EXAMPLE.COM container.
# kdb5_ldap_util -D "cn=directory manager" modify \ -subtrees 'ou=people,dc=example,dc=com' -r EXAMPLE.COM |
(Optional) If the KDC records are stored in DB2, migrate DB2 entries.
(Optional) 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.
Follow these steps to increase security on Kerberos application servers and on KDC servers.
Table 23–4 Increasing Security on Kerberos Servers (Task Map)
Task |
Description |
For Instructions |
---|---|---|
Enabling access using Kerberos authentication |
Restrict network access to a server to allow Kerberos authentication only | |
Restricting access to the KDC servers |
Increases the security of the KDC servers and their data. | |
Increasing password security by using a dictionary file |
Increases the security of any new passwords by checking the new password against a dictionary. |
This procedure restricts network access to the server that is running telnet, ftp, rcp, rsh, and rlogin to use Kerberos authenticated transactions only.
Change the exec property for the telnet service.
Add the -a user option to the exec property for telnet to restrict access to those users who can provide valid authentication information.
# inetadm -m svc:/network/telnet:default exec="/usr/sbin/in.telnetd -a user" |
(Optional) If not already configured, change the exec property for the telnet service.
Add the -a option to the exec property for ftp to permit only Kerberos authenticated connections.
# inetadm -m svc:/network/ftp:default exec="/usr/sbin/in.ftpd -a" |
Disable other services.
The in.rshd and in.rlogind daemons should be disabled.
# svcadm disable network/shell # svcadm disable network/login:rlogin |
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.
A dictionary file can be used by the Kerberos service to prevent words in the dictionary from being used as passwords when creating new credentials. Preventing the use of dictionary terms as passwords makes it harder for someone else to guess any password. By default the /var/krb5/kadm5.dict file is used, but it is empty.
Become superuser on the master KDC.
Edit the KDC configuration file (kdc.conf).
You need add a line to instruct the service to use a dictionary file. In this example, the dictionary that is included with the spell utility is used. See the kdc.conf(4) man page for a full description of the configuration file.
kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] EXAMPLE.COM = { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s sunw_dbprop_enable = true sunw_dbprop_master_ulogsize = 1000 dict_file = /usr/share/lib/dict/words } |
Restart the Kerberos daemons.
kdc1 # svcadm restart -r network/security/krb5kdc kdc1 # svcadm restart -r network/security/kadmin |