Setting up a network for RPCSEC-GSS

Edit online

The network that is being set up in this scenario contains five servers and is configured for RPCSEC-GSS.

The five servers on the network are as follows:
  • kdc.austin.ibm.com
  • alpha.austin.ibm.com
  • beta.austin.ibm.com
  • gamma.austin.ibm.com
  • zeta.austin.ibm.com
The system kdc.austin.ibm.com will be configured as the Key Distribution Center (KDC) server, and the Kerberos realm AUSTIN.IBM.COM will be created, on which all of the systems except kdc.austin.ibm.com and zeta.austin.ibm.com will be NFS servers offering file systems exported with RPCSEC-GSS.

Systems alpha.austin.ibm.com and beta.austin.ibm.com have an additional link between them; across that link, they appear to each other as fast_alpha.test.austin.com and fast_beta.test.austin.ibm.com. For this reason, an additional configuration step will be required.

In addition, this network has the following users, which have been configured on some of the systems:
  • adam
  • brian
  • charlie
  • dave
  • eric
Note: The following setup is provided only as an example, and may not be appropriate for all environments. See the Administrator's and User's Guide for the Network Authentication Service before attempting to set up a new Kerberos realm.
Note: Kerberos requires that the system time be reasonably close throughout the network. Before beginning this procedure, you should set up a mechanism to automatically synchronize time throughout the network, such as the AIX timed daemon or an NTP setup.
  1. Set up the KDC server.
    Note: The KDC server should ideally not be used for any other purpose; if the KDC is compromised, all Kerberos principals are compromised.

    In this scenario, kdc.austin.ibm.com will be configured as the KDC server. The following configuration is for des3. If des would be preferred for performance reasons, add the argument -e des-cbc-crc:normal to the addprinc call and the ktadd call for the kadmin below.

    To configure your network with aes encryption, add the -e aes256-cts:normal argument to the addprinc call and the ktadd call for the kadmin command.

    1. Install the krb5.server.rte fileset on kdc.austin.ibm.com.
    2. Set up the KDC server. In this scenario, the following command was used: 
      config.krb5 -S -d austin.ibm.com -r AUSTIN.IBM.COM
      After running this command, the system will ask for a Master Database password and a password for the administrative principal.
    3. Create principals for each user and host by running the /usr/krb5/sbin/kadmin.local command on the KDC server. This example creates Kerberos principals that match the UNIX user name of the associated user. The principal name will be mapped to the user name by NFS to determine the UNIX credential associated with the principal. For a description of how to use more general mappings between principals and user names, see Identity mapping. For this network, we created the following principals:
      • adam
      • brian
      • charlie
      • dave
      • eric
      • nfs/alpha.austin.ibm.com
      • nfs/beta.austin.ibm.com
      • nfs/gamma.austin.ibm.com
      Note: The chosen user principal names must match the corresponding user names in the system's configured user registry (/etc/passwd, LDAP, NIS, and so on). NFS uses the principal name as a user name to obtain user and group IDs on the local system. If the names do not match, the access will be treated as an anonymous access.
    The KDC is now configured.
  2. Each NFS client and server will now be configured as Kerberos clients by using the config.krb5 command.
    How this is done will depend on how the KDC was configured. In this scenario we ran the following command on each NFS system: 
    config.krb5 -C -d austin.ibm.com -r AUSTIN.IBM.COM -c kdc.austin.ibm.com -s kdc.austin.ibm.com
    It is now possible to kinit as any of the user principals on any of the configured systems . For example, to kinit as user adam, run the following command: 
    /usr/krb5/bin/kinit adam
    You will need to specify adam's Kerberos, not AIX®, password.

    This example uses kinit to authenticate the user. It is possible to configure AIX to use Kerberos authentication during system login. For more information, see Authenticating to AIX Using Kerberos in Security.

  3. Each NFS server will now be configured with the appropriate keytab entry.
    In this scenario, we configured the keytab entry for alpha.austin.ibm.com as an example; the exact same process will be used on beta.austin.ibm.com and gamma.austin.ibm.com.
    1. From alpha.austin.ibm.com, run the kadmin command. Then, run the following command: 
      ktadd nfs/alpha.austin.ibm.com
      This creates a keytab file.
    2. Next, set up the gssd daemon to use the keytab file you just created with the nfshostkey command.
      In this scenario, we ran the following:
      nfshostkey -p nfs/alpha.austin.ibm.com -f /etc/krb5/krb5.keytab
    3. Set up the gssd daemon to start up automatically by running the following command: 
      chnfs -S -B
    Repeat this setup for each system.
  4. At this point, the NFS server will work, although, all users will come across as nobody. It is advisable to have all of the users exist on all servers with the same uid and gid; any users that do not exist will have access to the exported directory only as nobody. To get user names to map properly, you must configure the NFS registry daemon.
    1. Set up the domain using the chnfsdom command. In this scenario, the following command was run on all the NFS servers to set up austin.ibm.com as the domain: 
      chnfsdom austin.ibm.com
    2. Set up the /etc/nfs/realm.map file; this file should contain one line, with the realm name followed by the local domain.
      For our example network, these two files should look like this on all of the NFS servers:
      realm.map AUSTIN.IBM.COM		 austin.ibm.com
      The realm entry in this file is not case-sensitive, so technically, this entry is not required.
    3. For zeta.austin.ibm.com, which will not be an NFS server, start up the gssd daemon using the chnfs -S -B command. Before trying any Kerberos client operations, the user must use kinit to obtain valid credentials.
  5. In this scenario, there is fast network link configure between alpha.austin.ibm.com and beta.austin.ibm.com. Across this link, beta.austin.ibm.com will see alpha.austin.ibm.com as fast_alpha.test.austin.ibm.com, and alpha.autsin.ibm.com will see beta.austin.ibm.com as fast_beta.test.austin.ibm.com. Because neither nfs/fast_alpha.test.austin.ibm.com nor nfs/fast_beta.test.austin.ibm.com are valid principals, they will be unable to use this link for mounts.

    To correct this, the nfshostmap command will be used, which will map principal to handle this situation.

    1. On alpha.austin.ibm.com, we ran the following command: 
      nfshostmap -a beta.austin.ibm.com fast_beta.test.austin.ibm.com
      This tells alpha.austin.ibm.com that fast_beta.test.austin.ibm.com's principal is for beta.austin.ibm.com.
    2. On beta, we ran the following command: 
      nfshostmap -a alpha.austin.ibm.com fast_alpha.test.austin.ibm.com

    Servers can have multiple host principals. Assuming that the IP address for fast_alpha is 10.0.0.1 and the IP address for fast_beta is 10.0.0.2, complete the following steps to add multiple host principals:

    1. Add the nfs/fast_alpha.test.austin.ibm.com and nfs/fast_beta.test.austin.ibm.com principals to the appropriate keytab files.
    2. Run the nfshostkey command on the alpha server, as follows: 
      nfshostkey -a -p nfs/fast_alpha.test.austin.ibm.com -i 10.0.0.1
    3. Run the nfshostkey command on the beta server, as follows: 
      nfshostkey -a -p nfs/fast_beta.test.austin.ibm.com -i 10.0.0.2