System Administration Guide: Security Services
|
|||
|
1. Security Services (Overview) Part II System, File, and Device Security 2. Managing Machine Security (Overview) 3. Controlling Access to Systems (Tasks) 4. Virus Scanning Service (Tasks) 5. Controlling Access to Devices (Tasks) 6. Using the Basic Audit Reporting Tool (Tasks) 7. Controlling Access to Files (Tasks) Part III Roles, Rights Profiles, and Privileges 8. Using Roles and Privileges (Overview) 9. Using Role-Based Access Control (Tasks) 10. Role-Based Access Control (Reference) Part IV Solaris Cryptographic Services 13. Solaris Cryptographic Framework (Overview) 14. Solaris Cryptographic Framework (Tasks) 15. Solaris Key Management Framework Part V Authentication Services and Secure Communication 16. Using Authentication Services (Tasks) 19. Using Solaris Secure Shell (Tasks) 20. Solaris Secure Shell (Reference) 21. Introduction to the Kerberos Service 22. Planning for the Kerberos Service 23. Configuring the Kerberos Service (Tasks) Configuring the Kerberos Service (Task Map) Configuring Additional Kerberos Services (Task Map) Configuring Cross-Realm Authentication Configuring Kerberos Network Application Servers Configuring Kerberos NFS Servers Synchronizing Clocks Between KDCs and Kerberos Clients Swapping a Master KDC and a Slave KDC Managing a KDC on an LDAP Directory Server Increasing Security on Kerberos Servers 24. Kerberos Error Messages and Troubleshooting 25. Administering Kerberos Principals and Policies (Tasks) 26. Using Kerberos Applications (Tasks) 27. The Kerberos Service (Reference) 28. Solaris Auditing (Overview) 29. Planning for Solaris Auditing 30. Managing Solaris Auditing (Tasks) |
Administering the Kerberos DatabaseThe Kerberos database is the backbone of Kerberos and must be maintained properly. This section provides some procedures on how to administer the Kerberos database, such as backing up and restoring the database, setting up incremental or parallel propagation, and administering the stash file. The steps to initially set up the database are in How to Configure a Master KDC. Backing Up and Propagating the Kerberos DatabasePropagating the Kerberos database from the master KDC to the slave KDCs is one of the most important configuration tasks. If propagation doesn't happen often enough, the master KDC and the slave KDCs will lose synchronization. So, if the master KDC goes down, the slave KDCs will not have the most recent database information. Also, if a slave KDC has been configured as a master KDC for purposes of load balancing, the clients that use that slave KDC as a master KDC will not have the latest information. Therefore, you must make sure that propagation occurs often enough or else configure the servers for incremental propagation, based on how often you change the Kerberos database. Incremental propagation is preferred over manual propagation because there is more administrative overhead when you manually propagate the database. Also, there are inefficiencies when you do full propagation of the database. When you configure the master KDC, you set up the kprop_script command in a cron job to automatically back up the Kerberos database to the /var/krb5/slave_datatrans dump file and propagate it to the slave KDCs. But, as with any file, the Kerberos database can become corrupted. If data corruption occurs on a slave KDC, you might never notice, because the next automatic propagation of the database installs a fresh copy. However, if corruption occurs on the master KDC, the corrupted database is propagated to all of the slave KDCs during the next propagation. And, the corrupted backup overwrites the previous uncorrupted backup file on the master KDC. Because there is no “safe” backup copy in this scenario, you should also set up a cron job to periodically copy the slave_datatrans dump file to another location or to create another separate backup copy by using the dump command of kdb5_util. Then, if your database becomes corrupted, you can restore the most recent backup on the master KDC by using the load command of kdb5_util. Another important note: Because the database dump file contains principal keys, you need to protect the file from being accessed by unauthorized users. By default, the database dump file has read and write permissions only as root. To protect against unauthorized access, use only the kprop command to propagate the database dump file, which encrypts the data that is being transferred. Also, kprop propagates the data only to the slave KDCs, which minimizes the chance of accidentally sending the database dump file to unauthorized hosts. Caution - If the Kerberos database is updated after it has been propagated and if the database subsequently is corrupted before the next propagation, the KDC slaves will not contain the updates. The updates will be lost. For this reason, if you add significant updates to the Kerberos database before a regularly scheduled propagation, you should manually propagate the database to avoid data loss. The kpropd.acl FileThe 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 CommandThe kprop_script command uses the kprop command to propagate the Kerberos database to other KDCs. If the kprop_script command is run on a slave KDC, it propagates the slave KDC's copy of the Kerberos database to other KDCs. The kprop_script accepts a list of host names for arguments, separated by spaces, which denote the KDCs to propagate. When kprop_script is run, it creates a backup of the Kerberos database to the /var/krb5/slave_datatrans file and copies the file to the specified KDCs. The Kerberos database is locked until the propagation is finished. How to Back Up the Kerberos Database
Example 23-14 Backing Up the Kerberos DatabaseIn 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/[email protected] krbtgt/[email protected] kadmin/[email protected] pak/[email protected] [email protected] changepw/[email protected] In the following example, the pak and pak/admin principals from the Kerberos database are backed up. # kdb5_util dump -verbose dumpfile pak/[email protected] [email protected] pak/[email protected] [email protected] How to Restore the Kerberos Database
Example 23-15 Restoring the Kerberos DatabaseIn the following example, the database called database1 is restored into the current directory from the dumpfile file. Because the -update option isn't specified, a new database is created by the restore. # kdb5_util load -d database1 dumpfile How to Convert a Kerberos Database After a Server UpgradeIf your KDC database was created on a server running the Solaris 8 or Solaris 9 release, converting the database allows you to take advantage of the improved database format. Before You BeginMake sure that the database is using an older format.
How to Reconfigure a Master KDC to Use Incremental PropagationThe 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:
How to Reconfigure a Slave KDC to Use Incremental Propagation
How to Configure a Slave KDC to Use Full PropagationThis 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:
Before You BeginThe master KDC must be configured. For specific instructions if this slave is to be swappable, see Swapping a Master KDC and a Slave KDC.
How to Verify That the KDC Servers Are SynchronizedIf incremental propagation has been configured, this procedure ensures that the information on the slave KDC has been updated.
Example 23-16 Verifying That the KDC Servers Are SynchronizedThe following is a sample of results from running the kproplog command on the master KDC server. kdc1 # /usr/sbin/kproplog -h
Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
Log version #: 1
Log state: Stable
Entry block size: 2048
Number of entries: 2500
First serial #: 137966
Last serial #: 140465
First time stamp: Fri Nov 28 00:59:27 2004
Last time stamp: Fri Nov 28 01:06:13 2004The following is a sample of results from running the kproplog command on a slave KDC server. kdc2 # /usr/sbin/kproplog -h
Kerberos update log (/var/krb5/principal.ulog)
Update log dump:
Log version #: 1
Log state: Stable
Entry block size: 2048
Number of entries: 0
First serial #: None
Last serial #: 140465
First time stamp: None
Last time stamp: Fri Nov 28 01:06:13 2004Notice that the values for the last serial number and the last timestamp are identical, which indicates that the slave is synchronized with the master KDC server. In the slave KDC server output, notice that no update entries exist in the slave KDC server's update log. No entries exist because the slave KDC server does not keep a set of updates, unlike the master KDC server. Also, the KDC slave server does not include information on the first serial number or the first timestamp because this is not relevant information. How to Manually Propagate the Kerberos Database to the Slave KDCsThis procedure shows you how to propagate the Kerberos database by using the kprop command. Use this procedure if you need to synchronize a slave KDC with the master KDC outside the periodic cron job. Unlike the kprop_script, you can use kprop to propagate just the current database backup without first making a new backup of the Kerberos database. Note - Do not use this procedure if you are using incremental propagation.
Example 23-17 Manually Propagating the Kerberos Database to the Slave KDCs Using kprop_scriptIf you want to back up the database and propagate it to a slave KDC outside the periodic cron job, you can also use the kprop_script command as follows: # /usr/lib/krb5/kprop_script slave-KDC Setting Up Parallel PropagationIn most cases, the master KDC is used exclusively to propagate its Kerberos database to the slave KDCs. However, if your site has many slave KDCs, you might consider load-sharing the propagation process, known as parallel propagation. Note - Do not use this procedure if you are using incremental propagation. Parallel propagation allows specific slave KDCs to share the propagation duties with the master KDC. This sharing of duties enables the propagation to be done faster and to lighten the work for the master KDC. For example, say your site has one master KDC and six slave KDCs (shown in Figure 23-2), where slave-1 through slave-3 consist of one logical grouping and slave-4 through slave-6 consist of another logical grouping. To set up parallel propagation, you could have the master KDC propagate the database to slave-1 and slave-4. In turn, those KDC slaves could propagate the database to the KDC slaves in their group. Figure 23-2 Example of Parallel Propagation Configuration
Configuration Steps for Setting Up Parallel PropagationThe 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:
Example 23-18 Setting Up Parallel PropagationUsing 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/[email protected] The kpropd.acl file on the KDC slaves being propagated by slave-1 would contain the following entry: host/[email protected] Administering the Stash FileThe stash file contains the master key for the Kerberos database, which is automatically created when you create a Kerberos database. If the stash file gets corrupted, you can use the stash command of the kdb5_util utility to replace the corrupted file. The only time you should need to remove a stash file is after removing the Kerberos database with the destroy command of kdb5_util. Because the stash file is not automatically removed with the database, you have to remove the stash file to finish the cleanup. How to Remove a Stash File
|
||
|