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:
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. |
|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.
|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 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 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.
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.
|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: |
|/usr/lpp/ssp/sysctl/bin/install.cmds |/usr/lpp/ssp/sysctl/bin/switch.cmds |
|/usr/lpp/ssp/samples/sysctl/firstboot.cmds
With restricted root access, the following switch management commands can only be run from the control workstation:
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:
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.
|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: |
|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.
|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: |
|You will need to configure security and authentication options for these |licensed programs.
|Root user will not be able to issue the llctl -g start command |from the nodes or control workstation. You can use the dsh |command to run the llctl start command in parallel to the |appropriate nodes or you can create a new user id to perform LoadLeveler |administrative functions with the correct authorization to run rsh |commands.
|Some subscriptions to the Problem Management component of PSSP run using |PSSP-generated principals for the rsh and rcp |commands. Those principals are removed when AIX remote command |authorization is none and the subscriptions might fail on the nodes |and the control workstation. |
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:
Consider the following:
Choose which authentication services are to be used for the AIX authenticated remote commands. This involves the following:
Consider the following:
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: