Installation and Migration Guide

Adding Kerberos V4 to the SP system

This section describes the tasks involved in adding Kerberos V4 to the SP system.

Installing and configuring Kerberos V4

If any node in a partition is running a level earlier than |PSSP 3.4, you must install and configure Kerberos V4 and activate it as an authentication method in that SP system partition. In addition to Kerberos V4, you can also select to install and configure DCE for each system partition.

Setting up PSSP authentication

To provide Kerberos V4 authentication services on your SP system, choose from the following three authentication implementations.

1. The authentication services provided with the SP system, based on MIT Kerberos V4. SP authentication services are designed to provide an easily-installable and configurable Kerberos for the SP system.
2. An existing implementation of MIT Kerberos V4, provided it is compatible with the SP Kerberos-authenticated services.
3. AFS version 3.3 or later.

Once you have installed and initialized Kerberos V4 authentication on your SP system, you can add other IBM RS/6000 workstations to your authentication realm. Two reasons for adding additional workstations might be:

1. If you are not using AFS authentication servers, you may want the added reliability of one or more secondary SP authentication servers. Providing secondary servers is particularly important if your SP system has to provide high availability with no single points of failure.
2. If you also want to install the SP authenticated services on office workstations. This will help you to manage the SP system, without having to login to the control workstation or the SP nodes directly.

When you use the SP authentication server support in the ssp.authent option, you may choose to have more than one server system. If you configure your local authentication realm with more than one server, you must designate one as the primary server. All others are secondary servers. Only the primary server has the administrative daemon, kadmind, that manages the content of the authentication database. The databases used by the secondary authentication servers are copies of the primary database and are updated periodically from the primary authentication server.

Additional servers can provide for greater reliability, since the authentication service will try all servers listed in the configuration file before failing a service request. If there are network problems, or if your primary server system fails, authentication requests can be handled as long as one of the configured servers is active and accessible. There may also be performance reasons to configure a secondary server. Only when there is an authentication server running on the control workstation can the switch be used for authentication protocol traffic to and from the SP nodes. In configurations where you are integrating the SP system into an existing authentication realm, where the primary authentication server is already on another workstation, you can make this possible by setting up a secondary server on the control workstation. In this way, you could have multiple SP systems in the same authentication realm, and give all SP nodes access to an authentication server across the switch.

Adding principals and changing passwords takes place in the primary database and is propagated to secondary databases through periodic updates only. Secondary databases are maintained by the kpropd daemon that runs only on secondary server workstations and receives the database content in encrypted form from the kprop program that runs on the primary server workstation. The SP authentication services include a script that you can schedule for execution in the root crontab file to keep your secondary authentication databases up-to-date.

Configuration files

Use the following configuration files located in the /etc directory to set up your system's authentication realm:

• /etc/inetd.conf

  This file contains information used by the internet routing daemon inetd to route incoming requests for service to one of a large number of dynamically started daemons that are named in the file. When the SP authentication services are installed on your systems, the file is updated to route "kshell" service requests to the AIX Kerberos-authenticated remote command daemon (krshd). You should not modify this information, but you might have to resolve conflicts with names of locally installed services.

• /etc/services

  This file maps the names of network services to the well-known ports that they use to receive requests from their clients. This file may already contain entries relating to authentication services, since the file shipped with AIX 4.1 contains entries used by DCE. In addition to the DCE entries, many other reserved port names were added in this version of AIX, including an entry for the Kerberos V5 port, 88. The service name for this port is given as "kerberos", which is also the name used by the standard MIT Kerberos V4 service. The port number usually assigned to the Kerberos V4 service is 750. In order to be consistent with and interoperate with AIX 3.2.5 systems running PSSP 1.2 with authentication services based on Kerberos V4, it was necessary to use the name "kerberos4". You do not have to create an entry in the file for "kerberos4", because the default port of 750/udp will be used if no "kerberos4" entry is found. If you are not using AFS Version 3.4 authentication servers, you should only have to modify /etc/services if you are using some other service that uses one or more of the traditionally used (but not formally reserved) Kerberos V4 ports. They are:

  Service name: kerberos4 Port: 750/udp

  Service name: kerberos_admin Port: 751/tcp

  Service name: krb_prop Port: 754/tcp

  You will also have to modify this file if you are using AFS Version 3.4 authentication servers. The kaserver in AFS Version 3.4 for AIX 4.1 accepts Kerberos V4 protocol requests using the well-defined udp port assigned to the "kerberos" service assigned to port 88 in the file distributed with the base operating system. MIT Kerberos V4, on which PSSP authentication services are based, uses a default port number of 750. PSSP authentication commands use the service name "kerberos4" to avoid this conflict with the Kerberos V5 service name, which is also used by DCE. For PSSP authentication commands to communicate with an AFS 3.4 kaserver, you must do either of the following:

  1. Stop the kaserver, redefine the udp port number for the "kerberos" service to 750 on the server system, then restart the kaserver.
  2. Add a statement to /etc/services that defines the udp port for the "kerberos4" service as 88 on the SP control workstation and on any other independent workstation that will be a client system for PSSP authenticated services.
• /etc/krb.conf

  This file contains the name of the local realm for your SP system and identifies the host names of all the authentication servers for all Kerberos realms known to the local realm. For more information on the content of the file, see krb.conf in the book PSSP: Command and Technical Reference.

  If you configure your realm to use AFS authentication servers, this file is built for you automatically from the corresponding AFS configuration file CellServDB. When you use PSSP authentication servers, you create this file or one is generated by default by the setup_authent script that must run on each workstation after you install the PSSP files. You must provide the file if the workstation is a client workstation or a secondary authentication server. If it is the primary authentication server, you need to provide the file only if the system's host name contains no domain portion, following conventional network naming rules.

  By convention, Kerberos uses the domain portion of a network interface name, converted to upper case, as the default realm to which the host belongs. If you want to define your own local realm name that does not follow convention, or if the host name of your primary server host has no domain portion, you must supply a file with your choice of local realm name in the first line. When using AFS authentication, the local AFS cell name, contained in the ThisCell file, converted to uppercase, becomes the local Kerberos realm name.

• /etc/krb.realms

  This file maps network interface (host) names to realms. When Kerberos needs to determine to which realm a network interface is assigned, it looks in this file. If there is no entry for the host name or for the domain part of the host name, the default is a realm name equal to the domain portion of the host name, converted to upper case. Any network interface names on systems using SP authenticated services which have a domain portion which is not the same as the local realm name, except for case, must have an entry in this file.

  Entries for all network interfaces on the SP nodes and on the control workstation that require this mapping in /etc/krb.realms are added automatically by either setup_authent initially or by the setup_server script. The file is kept identical on the control workstation and the nodes by the node installation customization process. There may be cases involving other work stations, however, where you will have to add entries to the file on one or more systems.

  When you set up a secondary authentication server or set up a system as an authentication client system, you are instructed to copy the configuration files from the primary server. If the new system requires mapping in krb.realms, the setup_authent script will create the entry in the local copy of the file. You will have to manually add the entry for the workstation you just configured into the control workstation's file and into the files on any other client and server workstations already installed.

Setting up the primary authentication server

The first system that you set up, when you install your PSSP software, is your primary authentication server. The primary authentication server may be your control workstation or it could be some other IBM RS/6000 workstation. You may want to have your servers entirely off of the SP system itself to provide greater physical security for them. You may want to allow logins to the control workstation that are not appropriate for the authentication servers.

The setup_authent script is used to configure your authentication services. If you have installed the ssp.authent file set on the workstation prior to running the script, it assumes that the system will be a PSSP authentication server. If you provide your own krb.conf file, the script will look for an entry for the local host name. If it cannot find one, it allows you to configure the system without any server (as an authentication client system).

The setup_authent script creates the service principals for local service instances and creates the server key file for them. It updates the krb.realms file as needed, and creates the root user's .klogin file to authorize the initial administrator principal to use remote commands.

The daemons which provide the authentication server (the KDC), and the database administration server, are started by adding entries to /etc/inittab.

The procedure to set up the primary authentication server is the following:

1. Install ssp.clients and ssp.authent.
2. Create a /etc/krb.conf file if you want or if your host names do not follow Kerberos convention.
3. Execute the /usr/lpp/ssp/bin/setup_authent program and follow the instructions in the prompts.

Setting up secondary authentication servers

The procedure to set up a secondary authentication server is the following:

1. Install ssp.clients and ssp.authent.
2. Copy the /etc/krb.conf file from the primary authentication server to this secondary server system.
3. Add a line to the /etc/krb.conf file listing this system as a secondary server for the local realm.
4. Copy the /etc/krb.realms file from the primary server to the secondary server system.
5. Execute the /usr/lpp/ssp/bin/setup_authent program and follow the instructions when prompted.
6. If setup_authent created an entry for the local /etc/krb.realms file, copy the file to the other systems.
7. Add an entry for the new secondary server to the /etc/krb.conf file on the systems on which you had previously-initialized authentication.
8. On the primary server, if this is the first secondary server, you should create a root cron entry that invokes the script /usr/kerberos/etc/push-kprop to periodically propagate database changes.

The procedure to set up your SP control workstation as a secondary authentication server is the same. For more information, see Step 21.3: Initializing as a secondary Kerberos V4 authentication server.

Setting up authentication client systems

The procedure to set up an authentication client system is the following:

1. Install ssp.clients.
2. Copy the /etc/krb.conf file from the primary authentication server to this system.
3. Copy the /etc/krb.realms file from the primary server to this system.

   Note:

   If the new workstation is outside the realm of the primary server, the new workstation needs to be added to the primary server's /etc/krb.realms file first, before copying the /etc/krb.realms over to the new workstation. Otherwise, the next step, which runs the setup_authent program, will fail on the new client workstation.

4. Execute the /usr/lpp/ssp/bin/setup_authent program and follow the instructions when prompted.
5. If setup_authent created an entry for the local /etc/krb.realms file, copy the file to the other systems.

The procedure to set up your SP control workstation as an authentication client system is the same. For more information, see Step 21.4: Initializing as an authentication client system.

Directory path names for SP authentication services

Some of the directory paths that are used with authentication services are the following:

/usr/lpp/ssp/bin

Contains setup_authent

/usr/lpp/ssp/kerberos/bin

Contains commands for users of authentication services and authentication database administrators.

/usr/kerberos/bin

Contains a symbolic link for /usr/lpp/ssp/kerberos/bin

/usr/lpp/ssp/kerberos/etc

Contains authentication daemons and commands used by root to maintain a local SP authentication database.

/usr/kerberos/etc

Contains a symbolic link for /usr/lpp/ssp/kerberos/etc

/var/kerberos/database

Contains the SP authentication database on the server

/var/adm/SPlogs/kerberos

Contains error logs for the authentication servers

/etc

Contains the files krb.conf, krb.realms, and krb-srvtab

/usr/lpp/ssp/rcmd/bin

Contains an rsh and rcp link to the AIX versions of the remote commands. On the SP, these versions support Kerberos V4 through an SP-supplied remote command library.

/usr/vice/etc

Contains AFS cell information and utilities

/usr/afsws/etc

Contains AFS executables

Configure Kerberos V4 security for each system partition

Notes:

1. When adding k4 as an authentication method, you must ensure existing methods are also included. By not specifying a method, that method is removed. This will cause problems with configuration and the system.

2. All affected nodes must be set to customize to add Kerberos V4 authentication.

3. If the Kerberos V4 server will be external to the SP, it must be accessible and there must be rsh capability from the control workstation to the server system. You must issue the AIX chauthent command to allow for rsh access.

Perform the following steps to configure Kerberos V4 security for each system partition:

1. Kerberos V4 authentication must be set up on the control workstation before it can be selected for a system partition.

   If setup_authent was run previously, it is not necessary to run it again. Refer to Step 21: Initialize RS/6000 SP Kerberos V4 (optional) for information on the different ways you can run setup_authent.

2. To indicate that Kerberos V4 security be installed and configured on the nodes, issue:

   spsetauth -p partition1 -i dce k4
   

   The preceding example assumes that DCE was the current setting.

   Note:

   If you only want to install and configure Kerberos V4 on the nodes, you should proceed to Step 7. This step does not enable the SP system to use Kerberos V4. You will need to continue with the remaining steps to enable Kerberos V4 usage.

3. To select Kerberos V4 as an authorization method for AIX remote commands, issue:

   spsetauth -p partition1 -d dce k4
   

   This step generates the necessary authorization files for each selected method and removes files or entries that are not needed. When adding k4, you will need to add it to the current setting. This implies that if dce was previously set, it must also be set now.

4. All affected nodes must be shut down. Use the cshutdown command (without the -r flag because the nodes should not be rebooted at this time).
5. To enable authentication methods for AIX remote commands, issue:

   chauthpar -c -p partition1 k5 k4
   

   Note:

   To enable Kerberos V4 for authenticated remote commands, but not for SP Trusted Services, continue to Step 7.

6. To enable authentication methods for SP Trusted Services, issue:

   chauthpts -c -p partition1 dce compat
   

7. To set all affected nodes to customize, issue:

   spbootins -r customize -s yes -l 1,3,5
   

   Note:

   |In order to run the spbootins -s yes command, you must have |SDR write authority and be authorized to perform a remote command to the |target nodes. |

8. Use the cstartup command to reboot all affected nodes.

Your system is now configured and enabled to use Kerberos V4, where appropriate, as an authentication method.

Note:

The steps to add an authentication method basically work from (in order of SDR Syspar attributes) auth_install, auth_root_rcmd, auth_methods, ts_auth_methods. In order to remove a particular method, simply run the steps in reverse. For example, to remove dce as an authentication method for SP Trusted Services (and you have the settings dce.compat), issue:

chauthpts -p partition1 compat

This disables SP Trusted Services from using DCE as an authentication method. The steps for removing DCE or Kerberos V4 authentication are detailed in the "Changing the security configuration" chapter in PSSP: Administration Guide.