pSeries or RS/6000 nodes that are in an SP system partition where DCE has been
configured. It can be started automatically or manually, depending on
the circumstances:
Managing the security configuration involves the following topics:
Displaying the current security configuration involves the following topics:
When you display the SP configuration database information for the SP system partitions, the output shows four attributes that define the security configuration for each partition:
For information on how to set the security configuration for a partition, see Changing the security configuration.
To show information for all system partitions using SMIT:
To show information for all system partitions using the CLI, run the following command:
splstdata -p
The output is similar to the following:
List System Partition Information System Partitions: -------------------------------------------------------------------- system3p0 system3p1 system3p2
Syspar: system3p0 -------------------------------------------------------------------- syspar_name system3p0 ip_address 19.4.60.145 install_image default syspar_dir /spdata/sys1/syspar_configs/3nsb0isb/config.4_4_40/ layout.3syspar-coex/syspar.3.system3p0 code_version PSSP-2.4 haem_cdb_version 939568157,265012085,0 auth_install dce:k4 auth_root_rcmd dce:k4 ts_auth_methods dce:compat auth_methods k5:k4:std
Syspar: system3p1 -------------------------------------------------------------------- syspar_name system3p1 ip_address 19.4.60.162 install_image default syspar_dir /spdata/sys1/syspar_configs/3nsb0isb/config.4_4_40/ layout.3syspar-coex/syspar.1.system3p1 code_version PSSP-2.4 haem_cdb_version 939568026,670463251,0 auth_install k4 auth_root_rcmd k4 ts_auth_methods compat auth_methods k4:std
Syspar: system3p2 ------------------------------------------------------------------- syspar_name system3p2 ip_address 19.4.60.183 install_image bos.obj.ssp.433 syspar_dir /spdata/sys1/syspar_configs/3nsb0isb/config.4_4_40/ layout.3syspar-coex/syspar.2.system3p2 code_version PSSP-3.2 haem_cdb_version 939568100,243454795,0 auth_install dce auth_root_rcmd dce:std ts_auth_methods dce auth_methods k5:std
As root on the control workstation, use the lsauthpar -v command to display the setting in the SP configuration database and also verify that the setting on each node in the partition matches it.
For example:
lsauthpar -vp system3p1
The output is similar to the following:
Remote command authentication methods for the partition: k4:std kerberos: Couldn't get credentials for the server: Server not found in Kerberos database. kerberos: Couldn't get credentials for the server: Server not found in Kerberos database. spk4rsh: 0041-004 Kerberos rcmd failed. rcmd protocol failure. system3n25.xyz.com: A remote host did not respond within the timeout period. No discrepancies were found.
The example shows some common error messages you might receive. The first two are the result of the rsh command attempting and failing to get Kerberos V5 credentials, because Kerberos V5 is the enabled authentication method on the control workstation. Since Kerberos V5 is not being used in this partition, however, no DCE service principal exists for the targeted nodes. The last two error messages indicate that the rsh command was unable to connect to one node in the partition to check its local setting. The last output line indicates that none of the contacted nodes in the partition has a setting that differs from the one displayed on the first line.
As the root user on the control workstation, use the lsauthpts -v command to display the setting in the SP configuration database and also verify that the setting on each node in the partition matches it.
For example:
SP_NAME=system3p1 lsauthpts -v
The output is similar to the following:
Trusted services authentication methods for the partition: dce:compat No discrepancies were found.
Changing the security configuration can involve the following:
|PSSP 3.4 provides the ability to remove the dependency PSSP has on |rsh and rcp commands issued as root. You can |enable restricted root access and the use of a secure remote command |process. You must already have chosen and installed the secure remote |command software on the control workstation before you can enable a secure |remote command process to be used by the PSSP software. That software |must be running and root must have the ability to successfully issue remote |commands to the nodes without being prompted for passwords or |passphrases.
|You can use SMIT or the spsitenv command to enable the secure |remote command process. You can set the names of the software |executables for secure remote commands and copies in the Site Information |Data. If you do not specify executables, the default is to use the |/bin/rsh and /bin/rcp executables for remote commands or |/bin/ssh and /bin/scp for secure remote commands.
|All nodes must be running PSSP 3.2 or later and the restricted root |access option must be enabled before you can enable a secure remote command |process.
|See the related discussions in the book PSSP: Installation and |Migration Guide.
|For example, to enable the default secure remote command process after you |enable restricted root access, you can run the command:
|spsitenv rcmd_pgm=secrshell dsh_remote_cmd=/bin/ssh remote_copy_cmd=/bin/scp
|Unless you want to replace the default process you only really need to use |the rcmd_pgm=secrshell option because the other two options in the |above command are the defaults.
The set of authentication methods to be used by the AIX remote commands can be specified using AIX commands. The PSSP security services provide additional commands to simplify your work.
The AIX base operating system provides the chauthent command to set which authentication methods are to be activated for use by the AIX remote commands on an AIX host. All methods specified as arguments in the command are enabled and all others are disabled.
|The authentication setting might be lost during a control |workstation or node reboot when you run the chauthent command |outside of the installation steps. The work-around is to run the |/usr/sbin/savebase command after running the chauthent |command.
If you were to use the chauthent command, you would have to run it with the same set of authentication methods on every host within an SP system partition. Another SP system partition can have a different set, but that set must be on every node in the system partition.
The SP security services component of PSSP provides the chauthpar command. Setting or changing the remote command authentication methods on the SP system involves the following:
Keep in mind, for remote commands to work in each SP system partition, the following restrictions apply:
To enable and disable authentication methods for remote commands using SMIT:
To enable and disable authentication methods using the CLI, run a command similar to the following which enables AIX remote command authentication using Kerberos V5 and standard AIX methods for the partition named system3p2:
chauthpar -vp system3p2 k5 std
The output is similar to the following:
The remote command authentication methods for this host are currently k5:k4:std The authentication methods by partition are currently system3p0 k5:k4:std system3p1 k4:std system3p2 std The partition to be modified is system3p2 spk4rsh: 0041-004 Kerberos rcmd failed. rcmd protocol failure. system3n21.xyz.com: A remote host did not respond within the timeout period.
The example shown includes some common error messages you might receive. They indicate that the rsh command was unable to connect to one node in the partition to change its local setting. It is changed automatically the next time the node is booted.
The SP security services component of PSSP provides the chauthpts, lsauthpts, chauthts, and lsauthts commands. Setting or changing the authentication methods to be used by SP trusted services involves the following:
Keep in mind, for SP trusted services to work in each SP system partition, the following restrictions apply:
To enable and disable authentication methods for SP trusted services using SMIT:
To enable and disable authentication methods using the CLI, run a command similar to the following which enables SP trusted services authentication using only the DCE method for the partition named sp1partA:
export SP_NAME=sp1partA chauthpts -v dce
The output is similar to the following:
The trusted services authentication methods for this host are currently dce:compat The authentication methods by partition are currently sp1partA dce:compat sp1partB compat The partition to be modified is sp1partA
As a result, the compatibility method is disabled and only the DCE method remains enabled as the authentication method for SP trusted services in partition sp1partA.
Both the chauthpar and chauthpts commands use the -c flag. This flag specifies that the command operate only on the control workstation, changing the SDR and AIX settings as specified by the command without making any changes on the nodes in the partition. Use the -c flag when you are enabling a method that is newly configured on the control workstation, but not yet enabled on the nodes. Use the chauthpar and chauthpts commands without the -c flag if you are removing a previously established authentication method from the nodes.
See the book PSSP: Installation and Migration Guide.
If your authentication requirements change, you might want to remove, from one or more SP system partitions or from the entire SP system, the capability of SP trusted services to use DCE authentication. You must have DCE cell administrator authority to run the rm_spsec command. These instructions show how to perform this task from the control workstation. If you want to do it from some other suitably configured workstation, see the rm_spsec command in the book PSSP: Command and Technical Reference.
To remove DCE authentication capability, do the following:
SP_NAME=syspar dsh -av /usr/lpp/ssp/bin/rm_spsec -t local
rm_spsec -t local -p syspar
rm_spsec -t local
rm_spsec -t admin -p syspar
rm_spsec -t admin node_dce_hostname
rm_spsec -t admin cws_dce_hostname
See the book PSSP: Installation and Migration Guide.
To take away your SP system's capability to run Kerberos V4 authentication, do the following:
Maintaining your authentication database involves the following topics:
See "Backing Up and Restoring the Registry Database" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components.
Keeping a current backup of the database contents is an important administrative task. The database utility commands that are available to the root user on the primary authentication database system include functions to use for this task. If you have secondary authentication servers and the documented installation steps for were followed, a backup of the database is automatically created every time the cron file entry propagates the database to the secondary servers.
The push-kprop script, invoked daily or at some other interval from the root user's cron file, creates a backup file in ASCII format called slavesave. This file is created in the database directory, where it is accessible only to the root user. If you want to create a backup file without using push-kprop (for example, if you do not have secondary servers and want to avoid the mail messages push-kprop sends to root), just add a cron entry to invoke the following command instead:
kdb_util dump /var/kerberos/database/slavesave
The result is a backup file with the same path name that can be used with the kdb_util load command to recover from a lost or corrupted database. You can also view or print it to examine the database contents.
See "Starting and Stopping DCE 3.1 for AIX" in the book IBM DCE Version 3.1 for AIX: Quick Beginnings.
If a Kerberos V4 daemon fails, it records an error condition in its log file and stops responding to client requests. Under these circumstances, you would need to restart it, after correcting the problem which caused the failure. There can be other circumstances, such as application of certain maintenance, where you might also have to stop and then restart one or more of the daemons that provide Kerberos V4 services. Each host that is an authentication server has two Kerberos V4 daemons that are started when the system is booted. The primary authentication server runs the kerberos daemon to provide ticket-granting services and the kadmind daemon to provide authentication database administration. Each secondary authentication server host also runs kerberos, and also the kpropd daemon, which is the "catcher" for database updates propagated from the primary server, usually via a cron job.
To stop the Kerberos V4 authentication server, enter the command:
stopsrc -s kerberos
To restart the Kerberos V4 authentication server, enter the command:
startsrc -s kerberos
To stop the Kerberos V4 database administration server, enter the command:
stopsrc -s kadmind
To restart the Kerberos V4 database administration server, enter the command:
startsrc -s kadmind
To stop the Kerberos V4 database propagation server, enter the command:
stopsrc -s kpropd
To restart the Kerberos V4 database propagation server, enter the command:
startsrc -s kpropd
In a traditional DCE environment, client and server authentication requires that the principal name and encryption key be contained in the DCE registry and in a server key file accessible by the server on the local host. Each server maintains its own key. There is one key file for each server. The server uses the information in the file to:
A DCE cell administrator controls the expiration of service principal keys by setting the password expiration policy for the primary organization of the service principal. The default policy is that keys will never expire, but an administrator can change that default at any time.
If a password expiration policy is set for the primary organization of the service principals, then the key of each service principal must be changed before the expiration time. If not, the service will not be able to log in to DCE and authenticate clients. If DCE is the only authentication method enabled, then the service is totally disabled.
Some SP trusted services use the automatic per-node key management component while others that can also operate outside of the PSSP environment do not.
See also "Creating and Maintaining Keys and Key Files" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components.
As of PSSP 3.2, the Key Management component runs in a DCE
environment to manage the keys for SP trusted services. Key Management
runs on the SP control workstation, SP nodes, and on other |IBM pSeries or RS/6000 nodes that are in an SP system partition where DCE has been
configured. It can be started automatically or manually, depending on
the circumstances:
pSeries or RS/6000 system:
nkeyman:2:once:/usr/lpp/ssp/bin/spnkeyman_start
All SP service principals that are created during SP DCE installation and configuration are placed in one SP DCE organization called spsec-services. The Key Management component periodically checks the password expiration information for all of the SP trusted services that use it. When a key change occurs, Key Management updates the key files on each node as needed and updates the associated registry for each service. Key management removes key files when nodes are removed, a node changes partitions, or when a service is removed from the SP system.
Ordinarily, a security administrator does not interact with the Key Management component, but for Key Management to run successfully there are several administrative restrictions:
If services fail with authentication problems or if a password expiration policy is set for the organization of SP trusted services and something prevents the Key Management component from processing successfully, see the book PSSP: Diagnosis Guide.
You might have to change keys for services, such as Topology Services, that do not use Key Management because they use other means of authentication. The RSCT Topology Services and Reliable Message Service both use connectionless protocols (UDP/IP) for daemon to daemon communication within an SP system partition. These services use the DES encryption routines directly to provide authentication and integrity for each UDP message. This is a case where IBM suggests the administrator establish a routine to periodically do the following:
See Chapter 23, The Topology Services subsystem for more information.
Other services that do not use Key Management are Event Management, Problem Management, LoadLeveler, and the RSCT Group Services.
Management of Kerberos V4 principals centers primarily on changing passwords in accordance with local security policy. For user principals this task is straightforward and can be done using simple tools. For service principals, password maintenance requires more than periodic changes to the authentication database. It also requires creation and distribution of files containing encrypted password information to the application server hosts.
The tasks involved are:
During setup for a node or control workstation, the keys for service principals are stored in the authentication database (for use by the authentication server) and on the node corresponding to the instance in the file /etc/krb-srvtab (for use by the service itself). Therefore, every node in the SP system contains a file, /etc/krb-srvtab, that contains the keys for the services that are provided on that node. On the control workstation, the hardmon and rcmd service principals are in the file. On the nodes, the rcmd service principals are in the file.
The local server key files on the control workstation and on other workstations are created by the setup_authent command when authentication is first set up on the system.
The setup_server command creates server key files for the SP nodes. When the control workstation is a PSSP authentication server, this occurs for each node when the script is run on the node's boot server. The setup_server command creates the files in the /spdata/sys1/k4srvtabs directory. When network boot occurs during install or customization, the file is transferred to the node using s1term command. The node uses the file to obtain tickets and invokes authenticated rsh to execute a script on the boot server that deletes the file.
When run on the control workstation for the first time, the setup_server command creates server key files for the SP node. The setup_server command creates the files in the /spdata/sys1/k4srvtabs directory. When network boot occurs during install or customization, the file is transferred to the node using the s1term command.
There are two programs that you can use to examine the content of a server key file on the local system, ksrvutil and k4list. To view the local system's server key file in /etc/krb-srvtab, enter ksrvutil list. The output will look like:
| Version Principal | 1 rcmd.cwktr@XYZ.ABC.COM | 1 hardmon.cwktr@XYZ.ABC.COM | 1 rcmd.cwkfddi@XYZ.ABC.COM | 1 hardmon.cwkfddi@XYZ.ABC.COM | 1 rcmd.cwken0@XYZ.ABC.COM | 1 hardmon.cwken0@XYZ.ABC.COM | 1 root.SPbgAdm@XYZ.ABC.COM
The same file, viewed by entering k4list -srvtab appears as:
|Server key file: /etc/krb-srvtab |Service Instance Realm Key Version |------------------------------------------------------ |rcmd cwktr XYZ.ABC.COM 1 |hardmon cwktr XYZ.ABC.COM 1 |rcmd cwkfddi XYZ.ABC.COM 1 |hardmon cwkfddi XYZ.ABC.COM 1 |rcmd cwken0 XYZ.ABC.COM 1 |hardmon cwken0 XYZ.ABC.COM 1 |root SPbgAdm XYZ.ABC.COM 1
To examine the server key file in the /spdata/sys1/k4srvtabs directory for a node whose host name is sp2node8, you would enter ksrvutil list -f /spdata/sys1/k4srvtabs/sp2node8-new-srvtab and the output might look like the following:
| 1 rcmd.n08tr0@XYZ.ABC.COM | 1 rcmd.n08tr1@XYZ.ABC.COM | 1 rcmd.n08fddi@XYZ.ABC.COM | 1 rcmd.n08css0@XYZ.ABC.COM | 1 rcmd.n08en0@XYZ.ABC.COM | 1 root.SPbgAdm@XYZ.ABC.COM
Changing the server keys involves two responsibilities:
You decide how frequently server keys need to be changed on your system. You may decide to set the server keys at setup time and never change them or you may decide to change them every six months. You should change the server keys if you have reason to believe system security has been compromised.
Use the ksrvutil command to change server keys. This command changes all of the server keys in the local server key file. The keys for all of the services provided on a single node, or the control workstation, are changed in a single call to ksrvutil. The keys are set to randomly generated values. The method of running ksrvutil to change the server keys for a node varies according to the authentication configuration of the system.
|Since the root.SPbgAdm principal is located in all |Kerveros V4 srvtab key files on the control workstation and the nodes, any |change made to the keys for root.SPbgAdm needs to be made to |the /etc/krb-srvtab file on the control workstation and the |nodes.
The ksrvutil command should be run on each node where the keys need to be changed. To change all of the server keys for a node to randomly generated values, enter:
|ksrvutil -i change
|The keys are updated in the node's /etc/krb-srvtab |file and in the authentication database on the control workstation. To |run the command, you must be root.
You can also use the ksrvutil command to change server keys on the control workstation, regardless of the location of the primary authentication database.
If the primary authentication database does not reside on the control workstation, do not use the ksrvutil command on the nodes of the SP system. If the primary authentication database for the local realm resides in some location other than the control workstation (even if a secondary authentication database is on the control workstation) or if the system is using AFS-based authentication services, the system maintains a copy on the control workstation of the /etc/krb-srvtab file on each node. These files are in the directory /spdata/sys1/k4srvtabs with a filename of nodename-new-srvtab. Changes to these srvtab files should be made only to the copy on the control workstation. The ksrvutil command is used to change the server keys.
To change all of the server keys for a node:
|ksrvutil -i -f nodename-new-srvtab change
To change the server keys for a node, you must have write access to the /etc/krb-srvtab file on the node and read-write permission to the /spdata/sys1/k4srvtabs/nodename-new-srvtab file.
When you change the server keys for a node, or for the control workstation, any service tickets that have been previously issued to users for those service instances are no longer valid. An attempt to use such a ticket to authenticate the user's identity to the server will fail. A message is issued that the server could not decode the ticket authenticator. In such a case, the user must issue a k4init command to obtain a new ticket-granting ticket and then reissue the service request.
See the ksrvutil discussion in the book PSSP: Command and Technical Reference for more information. Also, see the book PSSP: Diagnosis Guide for information on recreating server key files.
Normal distribution of server key files to nodes occurs during network boot of a node. The node boot process includes the following:
You can use ftp to transfer a new copy from the control workstation to a node at any time.
See "Changing the Registry's Master Key" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components.
Changing the master password can enhance database security somewhat, but is no substitute for adequate physical security. Changing the master password re-encrypts the database in the new key. It does not change any passwords (keys) themselves of the Kerberos V4 principals. Therefore, it offers limited protection if the system is possibly compromised unless all passwords are changed also.
Changing the master key is one of the capabilities of the kdb_util command. Only the root user can issue the various kdb_* commands on a system configured as a PSSP authentication server. An idiosyncrasy of these commands is that they prompt only once for the new password (unlike normal password-changing protocol).
After you change the password, be sure to issue the kstash command to store the new key in the /.k file. You also have to stop and restart the Kerberos V4 daemons on the server (kerberos and kadmind). If you have secondary servers, you need to force re-propagation of the database and respawning of the backup servers also.
To change the Kerberos V4 master password, do the following on the primary server:
k4init root.admin
/usr/kerberos/etc/kdb_util new_master_key /var/kerberos/database/newdb.$$ /usr/kerberos/etc/kdb_util load /var/kerberos/database/newdb.$$
/usr/kerberos/etc/kstash
stopsrc -s kadmind startsrc -s kadmind
if [[-s /var/kerberos/database/slavelist]]
then
/usr/kerberos/etc/push-kprop
cat /var/kerberos/database/slavelist | while read slave
do
/usr/lpp/ssp/rcmd/bin/rcp /.k $slave:/
/usr/lpp/ssp/rcmd/bin/rsh $slave \
stopsrc -s kerberos \; startsrc -s kerberos
done
fi