View figure.
Planning the installation and configuration of Kerberos V4 involves:
When you set up your Kerberos V4 authentication realm and install and configure your SP system, the roles of system installer, system administrator, and security administrator become intertwined. This is because some of the PSSP installation and customization scripts are designed to automatically recognize the authentication entities that have to be created for the remote commands and the SP trusted services. The setup_server script creates service principals whenever it discovers a new network interface defined on the control workstation for which it has no Kerberos V4 principal defined. At these times, the script must be running in an environment where the invoking user has authentication credentials as a database administrator. If the script needs credentials but finds that you are not authorized as an admin principal, it will fail. If this happens, obtain the appropriate credentials and issue the command or invoke it from SMIT again.
Other installation and customization tasks invoke the setup_server script internally. Any of these tasks which involve adding or renaming of adapters or host names also require credentials as a database administrator. Examples of installation scripts used to perform these tasks are spadaptrs, sphostnam, spbootins, and spethernt.
Other administration tasks that simply use the remote command facilities of dsh, rsh, or rcp require normal user credentials for the principals, since they do not involve changes to the authentication database.
Plan activities to authorize the appropriate people and assign the installation and configuration tasks respectively. You must define at least one user principal authorized to perform installation tasks. A system administrator, logged on as root, must assume the identity of this principal. When you use authentication services provided by AFS or another Kerberos implementation, this principal should already exist in the authentication database. For SP authentication services and other Kerberos V4 implementations, the administrator's principal can have any name with an instance of admin. An AFS principal has administrative authority if it has an admin attribute in its definition.
This section describes the various ways you can configure an SP system in an authentication realm. The following sections illustrate the possible authentication configurations used with the control workstation. The configurations also include other |pSeries or RS/6000 workstations on which you install SP authentication services, and non-RS/6000 workstations, when the authentication servers are configured in each of the supported manners. The control workstation and the SP nodes are always in a single authentication realm, which may optionally include other workstations and even other SP systems. The authentication servers can be on any workstation in the realm, but not on SP nodes. If you have AFS installed on your workstations, you can choose to use AFS servers for authentication, but are not required to do so. If you do not use AFS, you can use SP authentication servers or other Kerberos V4 servers. The SP nodes will have authentication services installed for all authentication configurations.
Figure 24. The control workstation as primary Kerberos V4 authentication server
View figure.
CWS-Primary
Figure 24 illustrates this configuration as follows:
Figure 25. The control workstation as secondary Kerberos V4 authentication server
View figure.
CWS-Secondary
Figure 25 illustrates this configuration as follows:
Figure 26. The control workstation as client of Kerberos V4 authentication server
View figure.
CWS-Client
Figure 26 illustrates this configuration as follows:
Figure 27. Using AFS authentication services
View figure.
AFS Server
Figure 27 illustrates this configuration as follows:
Selecting SP options for installation depends on where the authentication server is located. SP authentication code is distributed in two separately installable options. The ssp.authent file set contains only parts required on a system that is to be an authentication server. The remainder of Kerberos V4 authenticated services is distributed in the ssp.clients file set.
You must install ssp.authent on the control workstation, if it is to be a Kerberos V4 authentication server, either primary or secondary. You can also install ssp.authent on any other |pSeries or RS/6000 workstation that you plan to be an authentication server. You will not be able to install it if the system already has a Kerberos V4 implementation installed. If you want to install the SP authentication facilities, you must first remove the other Kerberos implementation.
You must install ssp.clients on the SP control workstation, even in the case where you intend to use AFS or Kerberos V4 authentication. You need to also install it on any other |pSeries or RS/6000 workstation that you plan to be an authentication server or from which you plan to perform system management tasks using System Monitor commands, AIX remote commands, or the sysctl remote command execution facility. Workstations using Kerberos V4 authentication do not require ssp.clients if they are not using SP system management tools. All SP nodes will have ssp.clients installed.
For some of these configurations, you need to create a configuration file (/etc/krb.conf) that lists the local realm name and all server host names. The following list identifies the cases in which you must provide the /etc/krb.conf file, and shows simple examples:
XYZ.COM
XYZ.COM spcw.xyz.com admin server
XYZ.COM ksecondary.xyz.com
XYZ.COM
XYZ.COM kprimary.xyz.com admin server
XYZ.COM spcw.xyz.com
XYZ.COM
XYZ.COM kprimary.xyz.com admin server
XYZ.COM ksecondary.xyz.com
See the krb.conf file format man pages in PSSP: Command and Technical Reference for more information and examples.
If you are using AFS authentication servers, your authentication realms are the same as your AFS cells. The name of the local realm for the SP system will be automatically set to the name of the AFS cell of the control workstation, and is converted to upper case.
When you are not using AFS, the following considerations apply. An SP system must be installed in a single Kerberos V4 authentication realm. This is the case if you are installing SP Kerberos V4 authentication on only the control workstation. The authentication realm could be an existing realm, consisting of systems using another Kerberos implementation, to which you add the SP system. You can give the realm any name you like or default the authentication realm name to the domain part of the server's host name, converted to upper case.
Whenever you have additional SP systems or other workstations using authenticated services, you must decide whether you want them all in the same realm, sharing a single set of principals in one master authentication database. Generally a single realm is easier to manage and easier for users who don't have to concern themselves with selecting the correct realm when identifying a principal.
If there is to be any use of authenticated services between two different authentication realms, each realm must have a unique name. If you choose to have multiple realms, and there are systems in both whose host names have the same domain part, you can configure only one using the default authentication realm name. If there is any chance that you would add additional authentication realms and want to use authenticated services between systems in them, it is best to create your own non-default and meaningful realm names when you plan your configuration.
See the section on working with authentication realms in PSSP: Administration Guide for more information.