IBM Books

Planning Volume 2, Control Workstation and Software Environment


Planning for DCE authentication

This section covers what you might need to plan after you decide to use DCE security services. Basically, after deciding to use DCE, there are certain actions you need to complete on your own, and others that PSSP helps you with. You need to obtain the DCE products to be installed, install the master and replica servers, and establish connectivity to the control workstation and nodes. The PSSP installation services help you install and configure the DCE clients on the nodes. Develop your own procedure by addressing each task and considering how to apply it in your situation. For instance:

The following tasks are involved in planning to use DCE authentication:

Deciding in which cell to configure DCE authentication

The SP system must be part of only one cell. For instance, you cannot have one partition in cell A and another in cell B. Install and configure the control workstation as a DCE client within that cell. You can also configure the control workstation as a DCE server but it might not be best for performance. Both the cell and the control workstation must be configured and running DCE before performing any PSSP installation and configuration tasks that set up DCE on the SP system.

Considering to exclude network interfaces from DCE Remote Procedure Call binding

Each time a DCE Remote Procedure Call (RPC) server is started, the Cell Directory Service (CDS) bindings are newly created, binding the server to all the network interfaces in the machine. To avoid performance degradation, you might want to exclude some interfaces from DCE RPC binding if some clients do not have a route to those interfaces. DCE provides the following environment variables with which you can exclude specific interfaces from being used:

You can use either one depending on whether you choose to identify them by interface name or by IP address. You can set these environment variables by using an export statement in a shell script before the servers are invoked from that same shell script. If the servers are to be started during the boot process, either of these environment variables must be in the /etc/environment file. Environment variables in that file are made available to all the processes after the next boot.

To exclude the interfaces with the names en0 and en1, for example, use the statement:

# export RPC_UNSUPPORTED_NETIFS=en0:en1

To exclude the interfaces with IP addresses 123.45.67.89 and 123.45.125.23, for example, use the statement:

# export RPC_UNSUPPORTED_NETADDRS=123.45.67.89:123.45.125.23

Planning location of DCE servers

The control workstation and SP nodes need connectivity to the servers. If you plan to configure the SP system into an existing DCE cell, record the locations of the DCE master and replica servers. If the SP system will have many nodes used as part of parallel jobs with many tasks using DCE authentication, consider having DCE replica servers for better performance. For new DCE cells, plan and record where to install your DCE master and replica servers. Your choices are:

The DCE master servers for a given cell must exist either on the SP control workstation or on a system external to the SP system. They cannot be on SP nodes if any partitions within the SP system are configured for DCE within that cell. SP nodes or the SP control workstation can be configured to run replica (secondary) DCE servers.

See Authentication servers for related information.

Establishing authorization to install and configure DCE

Only the root user on the SP control workstation can select to install and configure DCE for an SP system partition. On the control workstation, certain configuration tasks require DCE cell administrator authority. This might not be the person with root authority on the SP control workstation. Plan activities to authorize the appropriate people and assign the installation and configuration tasks respectively.

Preparing to configure SP trusted services to use DCE

A DCE cell administrator must prepare for configuring the SP security services, which are in the ssp.clients file set, before the config_spsec command is run either from SMIT or from the command line during installation and configuration.

The service configuration file /usr/lpp/ssp/config/spsec_defaults contains the information that is used during configuration for automatic creation of DCE entities in the DCE registry and the DCE Cell Directory Service (CDS) database. The file has the following information:

Before you install an SP system into an existing DCE cell, check those names to prevent conflicts with names that already exist in your DCE database. You might also want to consider if you have different security requirements in different SP system partitions. If you do, you might want to override some of the settings in the spsec_defaults file to set up access groups for partition-sensitive authentication.

Do not update the spsec_defaults file. If you want to replace a default name or set up partition-sensitive access groups, update the /spdata/sys1/spec/spsec_overrides file, which is also in the ssp.clients file set.

To apply any overrides, update the copy of the spsec_overrides file that is on the control workstation before the config_spsec command is run for the first time. That updated file is automatically copied to the nodes during the SP installation and configuration processing. For file content and override examples, see the book PSSP: Command and Technical Reference.

Note:
If you override any default DCE entities, be sure to instruct users in your organization that the respective default names used in the PSSP publications have been replaced. Also, if you plan to install SP security services on any network-attached |pSeries or RS/6000 workstations which are to function as SP clients, be sure to copy the spsec_overrides file to each of them before configuring security services on them. After the config_spsec command is run, do not modify the spsec_overrides file.

Deciding on granularity of access to the SDR

As in earlier releases, all users can read the SDR. Write and admin access can now be restricted. If you use DCE-only authentication, administrators whose duties involve performing tasks that create or update SDR information, by using SP Perspectives, SMIT, or SDR commands, will have to use the dce_login command with a principal that has been added to the appropriate SDR user access groups. IBM suggests that write and admin SDR access be limited to administrators who need to run scripts to install or configure the SP system. That includes those who manage virtual shared disks.

You can also grant SDR access on a partition basis by changing the spsec_overrides file to specify separate groups for different partitions.

Therefore, you need to consider and plan the granularity of protection you want to establish for giving principals write or admin access to the SDR. See the appendix about the SDR in the book PSSP: Administration Guide for more information.

Deciding on granularity of access to SP monitor objects

The SP system monitor allows authorized users to control and monitor the status of the frames, nodes, and switches of the SP system. It is a client-server application. The server, the hardmon daemon, executes only on the SP control workstation and controls the SP supervisor subsystem through the device special files for the RS-232 connections to each frame supervisor. Authorized users can use the SP Hardware Perspective or commands to see status information or control the power and the logical key switch position for node processors.

As of PSSP 3.2, the objects defined and controlled by the system monitor are the following:

  1. a single system object
  2. frame objects
  3. slot objects
  4. a hardmon object (the system monitor daemon)

The system object is the primary object and is the container for frame and slot objects. Monitor and control operations are performed on frame and slot objects. The hardmon object represents the administration function.

These objects are hierarchical: the system object contains frames and frame objects contain slot objects which represent node or switch processors. You can have potentially hundreds or thousands of objects and an access control list for each object. On the other hand, since the object structure is hierarchical you can have only the system object ACL and set principals and groups with authority to control the entire system. You can have system level, frame level, and slot level authorization. Authorization is checked from the lowest level to the highest level. If an ACL for the slot object does not exist, hardmon checks for the frame object. If an ACL for the frame object does not exist, hardmon uses the system object. The ACLs of a container object are copied to the contained object by default when the object is created.

Therefore, you need to consider and plan the granularity of object protection you want to establish for authorizing principals to monitor or control the system. The book PSSP: Administration Guide tells you about setting the authorizations.

Planning use of AIX remote commands

To use Kerberos V5 authentication within the AIX remote commands, DCE principals must be authorized to access an SP node with an AIX user id. This authorization is controlled through the use of a .k5login file in the AIX user's home directory. The .k5login file can be created and maintained by each user or by a system administrator.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]