NFSv4 in a multi-realm environment

Setting up Kerberos 5 for cross-realm support

Assuming that you already have two MIT Kerberos 5 realms, PRODUCTION and DEVELOPMENT, initialized. Here is how to set up cross-realm trusts between the them.

1. Set up so that authentications done in the PRODUCTION realm are accepted in the DEVELOPMENT realm. (DEVELOPMENT trusts PRODUCTION to properly authenticate users.)

   A principal, krbtgt/DEVELOPMENT@PRODUCTION, must be created in both realms using the same password. This password needs to be communicated between the administrators of the two realms out of band and securely.

   In each realm, do the following:

   $ kadmin kadmin: addprinc krbtgt/DEVELOPMENT@PRODUCTION Enter password for principal "krbtgt/DEVELOPMENT@PRODUCTION": <secret password> Re-enter password for principal "krbtgt/DEVELOPMENT@PRODUCTION": <secret password> Principal "krbtgt/DEVELOPMENT@PRODUCTION": created. kadmin: quit $

   Clients may now authenticate in the PRODUCTION realm, obtaining a TGT (Ticket Granting Ticket), krbtgt/PRODUCTION@PRODUCTION. When they attempt access to a Kerberized service in the DEVELOPMENT realm, the Kerberos libraries will automatically request a cross-realm ticket for principal, krbtgt/DEVELOPMENT@PRODUCTION. The library will then attempt to use that ticket to obtain a service ticket for the end service from the DEVELOPMENT realm. The identity in that service ticket will reflect the fact that the user originally authenticated in the PRODUCTION realm.

2. Allow initial authentications in the DEVELOPMENT realm to be acceptable in the PRODUCTION realm. (PRODUCTION trusts DEVELOPMENT to properly authenticate users.)

   A principal, krbtgt/PRODUCTION@DEVELOPMENT, must be created in both realms using the same password. This password needs to be communicated between the administrators of the two realms out of band and securely.

   In each realm do the following:

   $ kadmin kadmin: addprinc krbtgt/PRODUCTION@DEVELOPMENT Enter password for principal "krbtgt/PRODUCTION@DEVELOPMENT": <secret password> Re-enter password for principal "krbtgt/PRODUCTION@DEVELOPMENT": <secret password> Principal "krbtgt/PRODUCTION@DEVELOPMENT": created. kadmin: quit $

   Clients may now authenticate in the DEVELOPMENT realm, obtaining a TGT, (Ticket Granting Ticket), krbtgt/DEVELOPMENT@DEVELOPMENT. When they attempt access to a Kerberized service in the PRODUCTION realm, the Kerberos libraries will automatically request a cross-realm ticket for principal, krbtgt/PRODUCTION@DEVELOPMENT. The library will then attempt to use that ticket to obtain a service ticket for the end service from the PRODUCTION realm. The identity in that service ticket will reflect the fact that the user originally authenticated in the DEVELOPMENT realm.

   Notes:

   A common problem encountered in a cross-realm environment is the [domain_realm] mapping mapping in the client's /etc/krb5.conf file. The client library uses these mappings to determine the realm of the remote server. Make sure that the domain of the server's hostname maps to the correct realm.

   In the following example, the default realm for all hosts in the .umich.edu DNS domain is UMICH.EDU (line 1). The default realm for hosts in the .citi.umich.edu DNS domain is CITI.UMICH.EDU (line 2). However, the machine named citi.umich.edu should be considered to be in the CITI.UMICH.EDU realm although it may be considered to be in the .umich.edu DNS domain (line 3). Hosts tangent and foreign, although in the .citi.umich.edu DNS domain are in the TANGENT.REALM Kerberos realm (lines 4 and 5).

   [domain_realm]
           .umich.edu = UMICH.EDU
           .citi.umich.edu = CITI.UMICH.EDU
           citi.umich.edu = CITI.UMICH.EDU
           tangent.citi.umich.edu = TANGENT.REALM
           foreign.citi.umich.edu = TANGENT.REALM