Troubleshooting security updates

Edit online

Troubleshoot issues that might occur after you upgrade IBM® Storage Protect.

Symptom Resolution
An administrator account cannot log in to a system that is using software earlier than V8.1.2. After an administrator successfully authenticates with the server by using IBM Storage Protect V8.1.2 or later software, the administrator can no longer authenticate with that server that uses client or server versions earlier than V8.1.2. This restriction also applies to the destination server when you use functions such as command routing, server-to-server export that authenticates with the destination IBM Storage Protect server as an administrator from another server, administrator connections that use the Operations Center, and connections from the administrative command-line client.
To resolve authentication issues for administrators, complete the following steps:
  1. Identify all systems from which administrators log in and which use the administrative ID to log in. Upgrade the system software to IBM Storage Protect V8.1.2 or later, and ensure that the server's certificate is installed on each system.
  2. Set the administrator’s SESSIONSECURITY parameter value to TRANSITIONAL by issuing the command update admin admin_name sessionsecurity=transitional
  3. Retry the administrator connection.
Tip: If necessary, create a separate administrator account to use only with clients and servers that are using V8.1.1 or earlier software.
Certificate distribution failed for a node, administrator, or server. A node, administrator, or server that is using V8.1.2 or later software has a SESSIONSECURITY value of STRICT, but you has to reset the value to TRANSITIONAL to retry certificate distribution.

When using the new protocol, the automatic transfer of a server’s public certificate is performed only on the first connection to a server with enhanced security. After the first connection, the SESSIONSECURITY parameter value of a node changes from TRANSITIONAL to STRICT. You can temporarily update a node, administrator, or server to TRANSITIONAL to allow another automatic transfer of the certificate. While in TRANSITIONAL, the next connection automatically transfers the certificate if needed and resets the SESSIONSECURITY parameter to STRICT.

Update the value of the SESSIONSECURITY parameter to TRANSITIONAL by issuing one of the following commands:
  • For client nodes, issue: 
    update node node_name sessionsecurity=transitional
  • For administrators, issue:
    update admin admin_name sessionsecurity=transitional
  • For servers, issue:
    update server server_name sessionsecurity=transitional
Alternatively, you can manually transfer and import the public certificate by using the dsmcert utility to issue the following commands:
openssl s_client -connect tapsrv04:1500 
-showcerts > tapsrv04.arm
dsmcert -add -server tapsrv04 -file tapsrv04.arm

If you are using CA-signed certificates, you must install the CA-root and any CA-intermediate certificates on each key database for the client, server, and storage agent that initiates SSL communication.

Certificate exchange between IBM Storage Protect servers was not successful. When using the new protocol, the automatic transfer of a server’s public certificate is performed only on the first connection to a server with enhanced security. After the first connection, the SESSIONSECURITY parameter value of a server changes from TRANSITIONAL to STRICT. Retry certificate exchange between two IBM Storage Protect servers. For information, see Retrying certificate exchange between servers.
Certificate exchange between an IBM Storage Protect server and a client node was not successful. When using the new protocol, the automatic transfer of a server’s public certificate is performed only on the first connection to a server with enhanced security. After the first connection, the SESSIONSECURITY parameter value of a node changes from TRANSITIONAL to STRICT. To retry certificate exchange between clients and servers at versions earlier than V8.1.2, complete these steps:
  1. For existing clients that are configured to use SSL with the cert.arm certificate, reconfigure them to use the cert256.arm certificate. For instructions, see Configuring storage agents, servers, clients, and the Operations Center to connect to the server by using SSL.
  2. Update the default certificate by issuing the following command from the server instance directory:
    gsk8capicmd_64 -cert -setdefault -db cert.kdb -stashed 
-label "TSM Server SelfSigned SHA Key"
  3. Restart the server.
For clients and servers at V8.1.2 and later, the certificates are automatically distributed. If communication between clients or servers fails, complete these steps to retry certificate acquisition:
  1. For nodes and administrators, set the SESSIONSECURITY parameter to TRANSITIONAL by issuing the following commands for each node or administrator that you want to retry:
    update node nodename sessionsecurity=transitional 
update admin adminname sessionsecurity=transitional
    Tip: Administrators that authenticate by using the dsmadmc command, dsmc command, or dsm program cannot authenticate by using an earlier version after authenticating by using V8.1.2 or later. To resolve authentication issues for administrators, see the following tips:
    • Ensure that all IBM Storage Protect software that the administrator account uses to log in is upgraded to V8.1.2 or later. If an administrator account logs on from multiple systems, ensure that the server's certificate is installed on each system before the administrator account is used for command routing.
    • After an administrator authenticates to a V8.1.2 or later server by using a V8.1.2 or later client, the administrator can authenticate only on clients or servers that are using V8.1.2 or later. An administrator command can be issued from any system. If necessary, create a separate administrator account to use only with clients and servers that are using V8.1.1 or earlier software.
  2. For storage agents, update the STASESSIONSECURITY option in the storage agent options file dsmsta.opt by changing the STRICT value to TRANSITIONAL.
  3. Restart the servers. Certificate changes do not take effect until you restart the servers or storage agents.
  4. If you are still unable to exchange certificates after completing Steps 1-4, manually add the certificates to the servers and storage agents and restart them. For instructions, see Configuring storage agents, servers, clients, and the Operations Center to connect to the server by using SSL.
You want to manually distribute certificates to client systems. The IBM Storage Protect server administrator can automatically deploy a backup-archive client to update workstations where the backup-archive client is already installed. For information, see Automatic backup-archive client deployment.

To manually add certificates to clients, see Configuring IBM Storage Protect client/server communication with Secure Sockets Layer.
You want to reset certificates for client-to-client sessions. The dsmcert utility that is installed with the IBM Storage Protect backup-archive client is used to create a certificate store for server certificates. Use the dsmcert utility to delete the files and re-import the certificates.
As a root user, you want to allow non-root users to manage your files. The trusted communications agent (TCA), previously used by non-root users in V8.1.0 and V7.1.6 and earlier IBM Storage Protect clients, is no longer available. Root users can use the following methods to allow non-root users to manage their files:
Help desk method
With the help desk method, the root user runs all backup and restore operations. The non-root user must contact the root user to request certain files to be backed up or restored.
Authorized user method
With the authorized user method, a non-root user is given read/write access to the password store by using the passworddir option to point to a password location that is readable and writable by the non-root user. This method allows non-root users to back up and restore their own files, use encryption, and manage their passwords with the passwordaccess generate option.

For more information, see Enable non-root users to manage their own data.

If neither of these methods are satisfactory, you must use the earlier clients that included the TCA.
You want to resolve GSKit compatibility issues. When multiple applications that use GSKit are installed on the same system, incompatibility issues might occur. To resolve these issues, see the following information:
For more information about troubleshooting security updates, see technote 2004844.