Configuring Cross-Realm Authentication

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

How to Establish Hierarchical Cross-Realm Authentication

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

1. Complete the prerequisites for establishing hierarchical cross-realm authentication.

   The master KDC for each realm must be configured. To fully test the authentication process, several clients or slave KDCs must be installed.

2. Become superuser on the first master KDC.

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

   You must log on 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 the password> kadmin: addprinc krbtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM Enter password for principal krgtgt/EAST.EXAMPLE.COM@ENG.EAST.EXAMPLE.COM: <type the password> kadmin: quit

   ---

   Note - The password that is entered 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.

   ---

4. Add entries to the Kerberos configuration file to define domain names for every realm (krb5.conf).

   # 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, since the file is searched top down.

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

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

6. Repeat these steps in the second realm.

How to Establish Direct Cross-Realm Authentication

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

1. Complete the prerequisites for establishing direct cross-realm authentication.

   The master KDC for each realm must be configured. To fully test the authentication process, several clients or slave KDCs must be installed.

2. Become superuser on one of the master KDC servers.

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

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

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

   ---

   Note - The password that is entered 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.

   ---

4. Add entries in the Kerberos configuration file to define the direct path to the remote realm (krb5.conf).

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

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

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

6. Repeat these steps for the second realm.

Configuring SEAM NFS Servers

NFS services use UNIX user IDs (UIDs) to identify a user and cannot directly use principals. To translate the principal to a UID, a credential table that maps user principals to UNIX UIDs must be created. The procedures in this section focus on the tasks that are necessary to configure a SEAM 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 8-3 Configuring SEAM NFS Servers (Task Map)

Task	Description	For Instructions
Configure a SEAM NFS server	Enables a server to share a file system that requires Kerberos authentication.	"How to Configure SEAM NFS Servers"
Create a credential table	Generates a credential table.	"How to Create a Credential Table"
Change the credential table that maps user principles to UNIX UIDs	Updates information in the credential table.	"How to Add a Single Entry to the Credential Table"
Share a file system with Kerberos authentication	Shares a file system with security modes so that Kerberos authentication is required.	"How to Set Up a Secure NFS Environment With Multiple Kerberos Security Modes"

How to Configure SEAM NFS Servers

In this procedure, the following configuration parameters are used:

• Realm name = EXAMPLE.COM

• DNS domain name = example.com

• NFS server = denver.example.com

• admin principal = kws/admin

1. Complete the prerequisites for configuring a SEAM NFS server.

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

2. (Optional)

   Install the NTP client or other clock synchronization mechanism.

   It is not required to install and use the Network Time Protocol (NTP). However, every clock must be within the default time that is defined in the libdefaults section of the krb5.conf file in order for authentication to succeed. See "Synchronizing Clocks between KDCs and SEAM Clients" for information about NTP.

3. Start kadmin.

   You can use the SEAM Administration Tool to add a principal, as explained in "How to Create a New Principal". To do so, you must log on 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:

   1. Create the server's NFS service principal.

      Note that when the principal instance is a host name, the FQDN must be entered in lowercase letters, regardless of the case of the domainname in the /etc/resolv.conf file.

      kadmin: addprinc -randkey nfs/denver.example.com Principal "nfs/denver.example.com" created. kadmin:

   2. (Optional)

      Create a root principal for the NFS server.

      kadmin: addprinc root/denver.example.com Enter password for principal root/denver.example.com@EXAMPLE.COM: <type the password> Re-enter password for principal root/denver.example.com@EXAMPLE.COM: <type it again> Principal "root/denver.example.com@EXAMPLE.COM" created. kadmin:

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

      kadmin: ktadd nfs/denver.example.com kadmin: Entry for principal nfs/denver.example.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin:

   4. Quit kadmin.

      kadmin: quit

4. Create the gsscred table.

   See "How to Create a Credential Table" for more information.

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

6. On each client, authenticate both the user principal and the root principal.

   See "Setting Up Root Authentication to Mount NFS File Systems" for more information.