IBM Books

Planning Volume 2, Control Workstation and Software Environment

Choosing authentication options

Networked applications have client and server parts executing on different hosts. An authentication service allows networked applications to determine their mutual identities for security. This authentication service is provided by one or more authentication servers (daemons) running on systems that are accessible from application client and server systems. An authentication server provides the credentials for the application client and server to perform the authentication task. In a given authentication implementation, when there is more than one authentication server, one is the primary server and all others are replica or secondary servers. You can choose which authentication services to use on your SP system from the set of those supported in PSSP 3.4.

To consider which authentication service is right for you, answer the following questions:

  1. How restrictive does your system need to be?
  2. Do you require a level of security that AIX alone does not offer?
  3. Does the PSSP implementation of Kerberos V4 offer the level of security you need?
  4. Do the DCE security services offer the level of security you need?
  5. |Do you want to restrict the PSSP installation, configuration, and |system management software, hereafter called simply the PSSP system management |software, from using the rsh and rcp commands as a root |user from a node? See Considering restricted root access.
  6. |Do you want the PSSP system management software to use a secure |remote command process of your choice in place of rsh or |rcp commands? See Considering a secure remote command process.

In considering how restrictive you need to be, think about how users connect to your system. Are they connected directly, through the Internet, another external network, a protected LAN? Even if you want all the data available to everyone, you probably still want to protect it from being inadvertently changed or destroyed. Only you can judge which security services offer enough control and protection for your needs. Of those supported on the SP system, the DCE security services offer the greatest granularity of control. There are also other options that you can choose in addition to the security services.

DCE restriction:

If you plan to have DCE authentication enabled, you cannot use HACWS. If you already use HACWS, do not enable DCE authentication. Do not use IPv6 aliases if you plan to use DCE.

The AIX trusted computing base option:

The AIX mksysb image (SPIMG) that comes with PSSP does not have the AIX trusted computing base option enabled. The AIX trusted computing base option and PSSP security management do not conflict. If you want to enable the AIX trusted computing base option, you must create and use your own customized mksysb. Customization to enable that option can only be done during your installation phase prior to creating the mksysb. See the information about working with the AIX image in the book PSSP: Installation and Migration Guide.

Considering restricted root access

|The SP system supports using the AIX authenticated remote commands |(rsh, rcp, rlogin), plus the ftp and telnet |commands for system management. Those commands are available for |general use and support multiple authentication methods. Several SP |system components rely on the ability to use the rsh command to |issue remote commands as the root user from a node to be run on the |control workstation or from the control workstation to be run on nodes. |Likewise, several components use the rcp command to copy files |between the control workstation and nodes. In order to provide this |capability, PSSP has effectively defined one root user across the entire |SP system. Gaining access as root on any node in the SP system |implies that you can gain access as root on the control workstation and all |other nodes in the SP system.

|When, for instance, the SP is used as a server consolidation system, |this single root user might not be desirable. As of PSSP 3.2, |the restricted root access option is available to limit the use of |rsh and rcp within PSSP system management. It |restricts the SP software from automatically using rsh and |rcp commands as root user from a node. When restricted root |access is active, any such actions can only be run from the control |workstation or from nodes explicitly configured to authorize them. It |restricts root rsh and rcp authorizations from the nodes |to the control workstation, but permits control workstation to node |rsh and rcp access.

At the time restricted root access is activated, the SP and the root owned remote command authorizations are reconfigured such that:

When PSSP system management on the nodes needs to copy or access files or run commands on other nodes or on the control workstation, sysctl is used to perform the task from the control workstation. The restrictions imposed by using restricted root access have implications for the functionality of some PSSP and non-PSSP components as well as system management.

|Restricted root access can be activated under all the security |configurations supported by PSSP 3.2 or later. However, |restricted root access is most relevant when you use a secure remote command |process and with PSSP security methods dce, |dce:compat, and compat. Otherwise, |restricted root access under the minimal security state none/std is |of little value.

For the remainder of this section, all references to access control lists (ACLs) apply to root owned sysctl and AIX remote command ACLs because they apply to the different PSSP security configurations.

How does it work?

|Restricted root access can be enabled by setting a site environment |attribute in the SDR. Because the SDR in non-DCE environments can be |changed by root automatically, the SP_Restricted class was created |with the restrict_root_rcmd attribute. It can only be |changed by user root on the control workstation. The default |value is false.

|You can change the attribute by using the Site |environment SMIT panel or by using the spsitenv |command. When changed, the authorization files on the control |workstation and the nodes are immediately updated. All commands that |require rsh or rcp access check the attribute each time |access is required. They automatically use the sysctl method when |restricted root access is enabled.

AIX and PSSP remote commands

AIX remote command authorization files for root on the nodes and the control workstation are generated and updated by the updauthfiles script. This script is run at various times including when the restricted root access state is changed, when the security settings on the system are modified, and when a node is installed or booted.

When restricted root access is enabled, |updauthfiles removes all SP-generated entries in the remote command authorization files and adds the following entries, which are dependent on the authentication method set for auth_root_rcmd:

Any manual changes previously made to these files are not removed automatically. Also, before PSSP 3.2, the /.klogin entries generated by the SP were not saved in a separate file. If you have migrated your system from a previous release of PSSP, there might be SP-generated entries in your /.klogin file that are no longer recognized. It is a good idea to check the content of all root remote command authorization files after activating restricted root access.

The sysctl facility

The sysctl facility is an authenticated client-server system for running commands and TCL scripts remotely and in parallel. The sysctl server daemon sysctld processes all sysctl client requests for the node on which it runs. There is a sysctld daemon running on each node of the SP system as well as on the control workstation.

By default, the /etc/sysctl.conf configuration file is read and interpreted each time the sysctl server is started or restarted. This file contains the definitions of the commands that can be executed by sysctl. Additional sysctl commands are supplied with PSSP to enable restricted root access. Since the contents of the /etc/sysctl.conf file on the control workstation are different from the one on the nodes, the control workstation version should not be included in any file distribution scheme.

Access to the new sysctl commands is provided through a set of sysctl access control list (ACL) files shipped with PSSP. For compat mode, these ACLs are installed in the /etc directory and contain a Kerberos V4 entry for the global SP principal root.SPbgAdm. For DCE mode, the sysctl daemon initializes new DCE ACL objects relating to the new sysctl commands with entries for the PSSP DCE principal, ssp/.../spbgroot, which allow the principal to access the new sysctl commands. (For minimal mode, none/std, with restricted root access enabled, sysctl ACL entries must be manually updated to allow the new sysctl commands to be executed. However, this is not a suggested security configuration under which to enable restricted root access.

For sysctl to function correctly with restricted root access enabled, it is important that the sysctl daemon use the same default TCP/IP port number on all nodes and on the control workstation.

Overall, sysctl becomes a critical part of the SP environment when operating with restricted root access.

Limitations when using restricted root access

Restricted root access is a feature that creates new functionality within PSSP and fundamentally changes authorization methods. Obviously, this has consequences for some PSSP components and some AIX software programs that are used in an SP environment.


When restricted root access is enabled, it can only be used in a system with all nodes running PSSP 3.2 or later. If you are restricting root access in order to use a secure remote command process, the control workstation must have PSSP 3.4 and all the nodes must have PSSP 3.2 or later. At activation time, the spsitenv command checks whether all nodes are at a correct level. If there are nodes at a level earlier than PSSP 3.2, restricted root access cannot be activated. That also affects the ability to activate a secure remote command process.


During configuration and run time the Virtual Shared Disk component of PSSP (VSD) and the GPFS licensed program rely on existing combinations of rsh and sysctl commands and nested sysctl calls to access information on the control workstation as well as on other nodes (node-to-node). The existing architecture relies on the existence of a common PSSP root identity that can be authorized successfully under rsh and sysctl ACLs. When restricted root access is enabled, the common PSSP root access required by VSD and GPFS is disabled. When attempting to activate restricted root access, if VSD adapters are defined or if GPFS is installed on the control workstation, the activation will fail.


The HACMP licensed program can use Kerberos V4 as an authentication and authorization method that requires additional principals and interfaces defined in the Kerberos V4 database. When restricted root access is not enabled, adding additional principals to the Kerberos V4 database can be done manually or by running the cl_setup_kerberos script. This script is run from an HACMP node and does the following:

When restricted root access is enabled, the actions performed by cl_setup_kerberos are no longer possible due to the HACMP rsh and rcp requirements from a node to the control workstation. Also, the HACMP nodes can no longer use rsh and rcp to synchronize the HACMP ODM, given that the remote command authorization files on the control workstation (and other nodes) will no longer have common root authorization from node-to-node or node-to-control workstation. These authorizations will have to be added manually to the appropriate root-level remote command authorization files.

The synchronization capability can be restored by editing the /.klogin files on the HACMP nodes, for a compat/k4 enabled security mode, explicitly allowing both systems to have root access to each other. The restricted root access function will not interfere with custom settings.

Updating the Kerberos V4 database using the cl_setup_kerberos script requires root access to the control workstation, which is exactly what restricted root access was designed to eliminate. Manual updating of the Kerberos V4 database is the most secure way to ensure that the database is updated, but this is a complex and error-prone method. A work-around is to temporarily add the HACMP nodes to the /.klogin file on the control workstation, for a compat/k4 enabled security mode, run the cl_setup_kerberos script, and then remove the authorizations immediately afterwards.

See the HACMP documentation for details on running with HACMP under various PSSP security configurations.


When using the HACWS component of PSSP, there are no problems in the authentication of both systems on the nodes. However, you have to copy the authorization files, /.rhosts or /.klogin, to the backup control workstation. Also, it is important that you activate restricted root access from the active primary control workstation, since it is the Kerberos V4 Master.

There are other limitations and restrictions for HACWS, for instance it cannot run with DCE security mode enabled. For the complete list see Limits and restrictions.

|Boot-install servers
| |

|Using multiple boot-install servers is not suggested and is not |automatically supported by PSSP with restricted root access, a secure remote |command process, or with AIX authorization for remote commands set to |none. Boot-install servers are NIM Masters and they need to |have remote command access to the control workstation when changing SP |nodes. Boot-install servers also need rsh capability on |their client nodes during installation time. At runtime, remote command |authorization on the client nodes is only needed when a software or patch |update is required.

|However, depending on the size of your system and network loads, it might |not be possible to have a single boot-install server. Though PSSP does |not automatically create the correct entries in the authorization files to |allow the remote commands to function, you can create the |authorizations.

|To use multiple boot-install servers, you can manually establish the |correct authorizations on your system: |

  1. |On the control workstation, change the authorization files, depending on |the setting of the auth_root_rcmd attribute: |
  2. |On the boot-install server node, edit the |/etc/sysctl.conf file and include these entries:
  3. |If you are initiating a node install customization, add this entry:
  4. |For these changes to take effect, stop and restart sysctld on both the |control workstation and all boot-install servers. |


With restricted root access, the following switch management commands can only be run from the control workstation:


System management commands

With restricted root access, certain system management commands should only be run from the control workstation. If run from a node, authorization failures might prevent successful completion. The following commands should only be run from the control workstation:

splstdata (-d, -h, -i options only)

Additional security implications

Using restricted root access will not, in itself, make your SP system more secure. The fact that PSSP does not automatically authorize root to use rsh and rcp commands from a node and gain default access on other nodes within the SP does not prevent root from logging in to another node using the telnet command.

Even if you disable the ability for root to remotely log in to nodes and the control workstation, root can still use the su command to switch to another user and then exploit that user's remote command or other AIX and PSSP remote command capability to access other nodes or the control workstation.

You will have to adapt your user management for root to fit into the new access policy.

|Considering a secure remote command process

| |

|PSSP 3.4 gives you the ability to have the PSSP system |management software use a secure remote command process in place of |the AIX rsh and rcp commands when restricted root access |is enabled. You can acquire, install, and configure any secure remote |command software of your choice. With restricted root access and a |secure remote command process enabled, the PSSP system management software has |no dependency to internally issue rsh and rcp commands |as a root user from the control workstation to nodes, from nodes to nodes, nor |from nodes to the control workstation.

|You must have PSSP 3.4 and the secure remote command software |running on the control workstation, PSSP 3.2 or later running on the |nodes, and enable the restricted root access option before or when you enable |the secure remote command process. Then you can proceed to the rest of |the PSSP security configuration. |

|PSSP 3.4 supports three environment variables to let you pick |whether you want the PSSP system management software to use AIX rsh |and rcp remote commands or a secure remote command process for |parallel remote commands like dsh, pcp, and others. The following are |the environment variables and how to use them: |


|Enable use of the executables named by the DSH_REMOTE_CMD and |REMOTE_COPY_CMD environment variables. The default is |rsh. Set to secrshell to enable a secure remote |command process. |

|Specify the path and name of the remote command executable. The |default with rsh is /bin/rsh. The default with |secrshell is /bin/ssh. |

|Specify the path and name of the remote copy command executable. |The default with rsh is /bin/rcp. The default |with secrshell is /bin/scp. |

|Like the restricted root access option, a secure remote command process can |also be enabled by setting site environment attributes in the SDR. It |is extremely important to keep these environment variables consistent and set |to the remote command process you want to use. See Understanding remote command choices.

|Keep in mind that this support of a secure remote command process is |enabled only in the PSSP installation, configuration, and system |management software. You still need to explicitly grant the |authorization that PSSP would otherwise have granted automatically for other |applications that require root ability to issue rsh and |rcp commands, like LoadLeveler and Parallel Environment. |Some PSSP components, like virtual shared disks and problem management, and |licensed programs, like GPFS, are not supported in this environment. |See Limitations when using restricted root access and Considering choosing none for AIX remote command authorization. |

|Considering choosing none for AIX remote command authorization


|After you install the secure remote command software of your choice on the |control workstation and enable the restricted root access and secure remote |command process options, when setting your security configuration within each |SP system partition a choice of none is offered for AIX remote |command authorization. If you choose none, the PSSP system |management software does not generate any root entries in the |.klogin, .k5login, or |.rhosts files on the nodes in the partition. To be |able to set AIX authorization for remote commands to none in any |partition, PSSP 3.4 must be installed on all nodes in that |partition.

|A reason you might want to set none for AIX remote command |authorization is to add a greater level of security such that even the root |user is no longer automatically authorized to issue rsh or |rcp commands from the control workstation to the nodes. |Enabling the secure remote command process does not remove the capability of |root to issue rsh or rcp commands from the control |workstation to the nodes. It only ensures that the PSSP installation, |configuration, and system management scripts that run as root use the secure |remote command process instead. However, the root user or other |processes running as root can still run rsh or rcp |commands from the control workstation to the nodes. If the AIX remote |command authorization is none, some applications that still rely on |using rsh or rcp commands can no longer run.

|Certain PSSP components and licensed programs are affected when you choose |none for AIX remote command authorization: |

Recording your authentication options

Prepare your choices for the security configuration within each SP system partition. Use a separate copy of Table 71 for each SP system partition to record your choices for the following:

  1. The authentication services that PSSP is to automatically install.

    Consider the following:

  2. The authentication service for remote commands.

    Choose which authentication services are to be used for the AIX authenticated remote commands. This involves the following:

    1. The authorization files for AIX remote command authorization for the root user:
      • .k5login for Kerberos V5 authentication
      • .klogin for Kerberos V4 authentication
      • .rhosts for standard AIX authentication
      |You can operate with none of these files if you plan to enable the |restricted root access option and use a secure remote command process. |In that case you have the option to choose none. You will |probably have a secure login instead of rlogin. The ftp and telnet |commands do not require these files. See Considering restricted root access, Considering a secure remote command process, and Considering choosing none for AIX remote command authorization before you decide. |
    2. The authentication methods for AIX remote commands to be enabled in each SP system partition. Choose any combination of the following:
      • Kerberos V5
      • Kerberos V4
      • standard AIX

    Consider the following:

  3. The authentication methods for SP trusted services.

    The SP System Monitor command-line interface, the SP Perspectives graphical user interfaces, the PSSP remote execution facilities dsh and sysctl, and other SP trusted services all use authentication services. Choose which authentication methods are to be enabled for mutual authentication by SP trusted services within each SP system partition:

    The compatibility method lets the SP trusted services use whatever means of authentication they used before PSSP 3.2. Some used Kerberos V4 with access control lists, some had their own independent means, some simply required root access, and some did not require authentication.

    Consider the following:

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