This section describes the steps you take to update Kerberos V4 on the backup control workstation.
If the primary control workstation is either a primary or secondary Kerberos V4 authentication server, then the backup control workstation must be configured as a secondary authentication server. If the primary control workstation is an authentication client, the backup control workstation must also be configured as an authentication client.
Follow the instructions in Step 12.1: Initializing as a secondary Kerberos V4 authentication server or in Step 12.2: Initializing as an authentication client system to configure the backup control workstation as either a secondary authentication server or as an authentication client.
The following example illustrates the procedure you should follow to initialize the backup control workstation as a secondary authentication server.
For example, to add sp2cw.xyz.com as a secondary server for the authentication realm XYZ.COM, add this line to /etc/krb.conf:
XYZ.COM sp2cw.xyz.com
setup_authent requires you to login to the authentication service using the same administrative principal name that was defined when the primary server was set up. The remainder of the initialization of authentication services on this secondary local system takes place automatically.
The following example shows the interaction you can expect when you run setup_authent when initializing as a secondary authentication server.
#setup_authent <screenclear> ************************************************************************ Logging into Kerberos as an admin user You must assume the role of a Kerberos administrator <user> to complete the initialization of Kerberos on the local system. The k4init command is invoked and will prompt you for the password. If you are setting up your primary server here, you have just defined it. If you have defined multiple administrative principals, or if your primary authentication server is on another system, you must first enter the name of an administrative principal who has root privilege (UID 0). You need to be authenticated as this administrator so that this program can create the principals and service key files for the authenticated services that run on the SP system. For more information, see the k4init man page. ************************************************************************ setup_authent: Enter name of admin user: root Kerberos Initialization for "root.admin" Password: rootPassword sp2cw.xyz.com: success. sp2cw.xyz.com: Succeeded #
# k4list Ticket file: /tmp/tkt0 Principal: root.admin@XYZ.COM Issued Expires Principal Nov 11 16:26:11 Dec 12 16:26:11 krbtgt.XYZ.COM@XYZ.COM # <end_of_example>
The following example illustrates the procedure you should follow to initialize the backup control workstation as an authentication client.
setup_authent requires you to login to the authentication service using the same administrative principal name that was defined when the primary server was set up. The remainder of the initialization of authentication services on the local system takes place automatically.
The following example shows the interaction you can expect when you run setup_authent when initializing as an authentication client system.
#setup_authent <screenclear> ************************************************************************ Logging into Kerberos as an admin user You must assume the role of a Kerberos administrator <user>.admin to complete the initialization of Kerberos on the local system. The k4init command is invoked and will prompt you for the password. If you are setting up your primary server here, you have just defined it. If you have defined multiple administrative principals, or if your primary authentication server is on another system, you must first enter the name of an administrative principal who has root privilege (UID 0). You need to be authenticated as this administrator so that this program can create the principals and service key files for the authenticated services that run on the SP system. For more information, see the k4init man page. ************************************************************************ setup_authent: Enter name of admin user: root Kerberos Initialization for "root.admin" Password: rootPassword # k4list Ticket file: /tmp/tkt0 Principal: root.admin@XYZ.COM Issued Expires Principal Nov 11 16:26:11 Dec 12 16:26:11 krbtgt.XYZ.COM@XYZ.COM # # <end_of_example>
When control workstation services move back and forth between the two control workstations, the Kerberos V4 service keys must remain the same. The krb_srvtab file should be the same on both the primary and secondary authentication servers.
Enter the following commands on the backup control workstation:
/usr/lpp/ssp/rcmd/bin/rcp -p <primary_name>:/etc/krb-srvtab \
/etc/krb-srvtab.primary
cp -p /etc/krb-srvtab /etc/krb-srvtab.backup
cat /etc/krb-srvtab.primary >>/etc/krb-srvtab
Repeat this procedure whenever you change Kerberos V4 service keys on either of the two control workstations.
Make sure a Kerberos V4 principal and rcmd service key exist for the network address that matches the host name of the backup control workstation.
Run the /usr/lpp/ssp/kerberos/bin/kadmin command on the backup control workstation as follows:
Welcome to the Kerberos Administration Program, version 2 Type "help" if you need it.
admin: get_entry rcmd.BackupControlWorkstation
Admin password:
Info in Database for rcmd.BackupControlWorkstation:
Max Life: 255 Exp Date: Fri Apr 28 22:59:59 2000 Attribs: 00 key: 0 0 admin: q Cleaning up and exiting. # <end_of_example>
To verify the information, run the /usr/lpp/ssp/kerberos/bin/ksrvutil list command on the backup control workstation. The system will display information similar to the following:
Version Principal 2 rcmd.k21sha@PPD.POK.IBM.COM 2 hardmon.k21sha@PPD.POK.IBM.COM 2 rcmd.k21shacw@PPD.POK.IBM.COM 2 hardmon.k21shacw@PPD.POK.IBM.COM 1 hardmon.k21cw@PPD.POK.IBM.COM 1 rcmd.k21cw@PPD.POK.IBM.COM 1 rcmd.k21s@PPD.POK.IBM.COM 1 hardmon.k21s@PPD.POK.IBM.COM 1 rcmd.k21cw_bt@PPD.POK.IBM.COM 1 rcmd.k21s_bt@PPD.POK.IBM.COM # # <end_of_example>