Red Hat Enterprise Linux 5 Administration Unleashed

280CHAPTER 12Identity ManagementCreating the Kerberos DatabaseTo create the Kerberos database, use the kdb5_util command. Optionally, also create astash file, or an encrypted file containing a copy of the master keys. The stash file alsoserves as an automatic authentication system for the KDC to itself when the Kerberosdaemons are started. Because the stash file contains the master key, be sure it is only readableby the root user and is on the local file system for the KDC. Do not include the stashfile in your backup plan unless access to the file system containing the backup files areheavily restricted to trusted administrators because it can be used to gain access to theentire Kerberos database. To create the database and stash file, use the following commandas root (replace with the name of the realm such as EXAMPLE.COM):/usr/kerberos/sbin/kdb5_util create -r -sThe -s option creates the stash file. If you don’t want to create one, do not include the -soption. The utility prompts you for the master key as shown in Listing 12.9.LISTING 12.9Creating the Kerberos Database and Stash FileLoading random dataInitializing database ‘/var/kerberos/krb5kdc/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:Re-enter KDC database master key to verify:The utility creates the following files in the /var/kerberos/krb5kdc/ directory:. principal: Kerberos database file.. principal.ok: Kerberos database file.. principal.kadm5: Kerberos administrative database file.. principal.kadm5.lock: Kerberos administrative database lock file.. .k5.: Stash file (if -s is used). Replace .Managing Kerberos PrincipalsKerberos users allowed access to the database are called principals, which are divided intothree components in the form /@. Principals can have multipleinstances: a null instance represented by a username and realm such as tfox@EXAMPLE.COM, an admin instance represented by a username followed by /admin and arealm such as tfox/admin@EXAMPLE.COM, and a root instance represented by a usernamefollowed by /root and a realm such as tfox/root@EXAMPLE.COM. Having an admin and rootinstance for users allows them to authenticate as a different principal when performingadministrative tasks but use a non-privileged principal when performing user operations.This is similar to the non-root user and root user concept: Only perform actions as a privilegeduser when necessary to prevent unintended operations.