Post-upgrade tasks for IBM Security Guardium Key Lifecycle Manager

Validate the configuration and protect the data by completing the post-upgrade tasks on the target version of IBM® Security Guardium® Key Lifecycle Manager.

General

  1. If you see a TLS error on the Welcome page of IBM Security Guardium Key Lifecycle Manager graphical user interface after the upgrade, check the TransportListener.ssl.protocols configuration property. The supported TLS version is TLS 1.2.
  2. For IBM Security Guardium Key Lifecycle Manager on Linux® or AIX®:
    1. Manually update the IPP port number in the IBM Security Guardium Key Lifecycle Manager server. Ensure that the value is greater than 1024.

      See Specifying port and timeout settings.

    2. Reconfigure the IPP port number in all the clients or devices that are connected to the IBM Security Guardium Key Lifecycle Manager server.
  3. Validate that the required services, ports, and processes are running. See Validating services, ports, and processes.
  4. Immediately after the upgrade, back up IBM Security Guardium Key Lifecycle Manager, Version 4.2.

    Retain a copy of version 4.2 backup files in a location that is not in the IBM Security Guardium Key Lifecycle Manager, Version 4.2 directory path. If IBM Security Guardium Key Lifecycle Manager is removed, the separate location ensures that other processes cannot remove backup files.

    Additionally, retain the IM_DATA_DIR/logs/sklmLogs/migration.log files for future reference.

  5. Review the following considerations:
    • The upgrade process creates clients and associates them with certificates that did not have associated clients before upgrade. Objects that are associated with the certificates are also automatically added to the new clients.

      Certificate names are used as client names. If two clients have the same name, a random string is appended to each of them. If you want, you can modify the client name as according to your requirement. For more information, see the Update Client REST Service topic.

    • IBM Security Guardium Key Lifecycle Manager stores information about data served to clients in a database table. If the number of records is equal to or greater than 100000, the data is archived during the cross-migration operation.
    • Retain a replica of the earlier version of IBM Security Guardium Key Lifecycle Manager to ensure that you have a working environment and data in case data validation post upgrade determines that there is a problem with version 4.2.

      The upgrade process does not remove the earlier version of IBM Security Guardium Key Lifecycle Manager.

      Note: Because the IP ports are shared between the two versions, do not run both versions at the same time. If migration cannot complete these steps, migration process issues a warning and a successful completion message. Examine the IM_DATA_DIR/logs/sklmLogs/migration.log file for messages and take the appropriate manual actions.

      For the definition of IM_DATA_DIR, see Definitions for HOME and other directory variables.

    • Create users, user groups, and roles by using the graphical user interface or REST interface. This data is not migrated. For more information, see Managing users, roles, and groups.
    • After migration completes, one or more devices might be associated with the UNKNOWN device group. You can assign the device group for UNKNOWN devices to a new group, or allow the group to be determined when the devices make a first key service request.
  6. Ensure that the paths for properties in the SKLMConfig.properties, datastore.properties, and ReplicationSKLMConfig.properties files are correct.
  7. Remove the earlier version of IBM Security Guardium Key Lifecycle Manager. For instructions, use the procedure from the respective version's topic in the IBM Documentation.
  8. Resolve possible problems with certificates and keys.

    Earlier versions of IBM Security Guardium Key Lifecycle Manager do not restrict device groups to which a certificate and its keys can be associated. Certificates and keys that belong to multiple device types in the earlier IBM Security Guardium Key Lifecycle Manager versions are marked as CONFLICTED in version 4.2. You cannot change their device group to another device group. IBM Security Guardium Key Lifecycle Manager can use a certificate or key that is marked as CONFLICTED for both read and write operations.

Inline migration

  • If LDAP was configured on the earlier version of IBM Security Guardium Key Lifecycle Manager: Post upgrade, LDAP configuration and users are not migrated. Also, the LDAP user ID that you specified for the application administrator user during the V4.2 installation changes to SKLMAdmin, but the password remains the same. You must use these user credentials for your first-time login.

    If required, you need to configure LDAP post upgrade. For more information, see Configuring LDAP-based user authentication.

  • If Kerberos was configured on the earlier version of IBM Security Guardium Key Lifecycle Manager: Post upgrade, Kerberos configuration is not migrated.

    If required, you need to configure Kerberos post upgrade. For more information, see Managing password-less authentication with the database by using Kerberos.

  • During inline migration, if the IBM Security Guardium Key Lifecycle Manager V4.2 is installed but the data migration task fails, start the stand-alone migration-recovery script. For more information, see Recovery from migration failure.
    Note: Use the migration-recovery script before you make any updates or changes to the IBM Security Guardium Key Lifecycle Manager configuration.
  • If the earlier version of IBM Security Guardium Key Lifecycle Manager is configured with Luna HSM client that is installed on Linux platform, perform the following configuration activities:
    • In the hsmusers group, which is created during the Luna HSM client installation, add the Db2 Administrator user ID (for example, klmdb42). Luna HSM client is installed using the root user while the IBM Security Guardium Key Lifecycle Manager process runs using a non-root user. Adding this user is required for communication of the HSM with IBM Security Guardium Key Lifecycle Manager.
    • Check the luna.cfg file permissions and ensure that the klmdb42 database user has read permission to the file.

Multi-Master configuration

If you performed cross-migration and had Multi-Master cluster in the earlier version of IBM Security Guardium Key Lifecycle Manager, set up the Multi-Master cluster in the upgraded version. For more information, see Setting up Multi-Master cluster on a cross-migrated IBM Security Guardium Key Lifecycle Manager server.

Migration failure

If migration fails and you choose to complete the remaining IBM Security Guardium Key Lifecycle Manager installation process, you can use a stand-alone migration-recovery script, only if no updates or changes are made to the IBM Security Guardium Key Lifecycle Manager configuration. For more information, see Recovery from migration failure.

(Optional) Remove the earlier version of IBM Security Guardium Key Lifecycle Manager server

Verify that the clients (for example, storage devices) that are using the IBM Security Guardium Key Lifecycle Manager server are working with the migrated server. You can then remove the source cluster.

For instructions, see the uninstallation topic for that version in the IBM Documentation. For example, to uninstall version 3.0, see Uninstallation of IBM Security Guardium Key Lifecycle Manager.

Important: To uninstall version 4.1 on Windows, see Uninstalling IBM Security Guardium Key Lifecycle Manager V4.1 on Windows.

What to do next

From the Welcome page, configure the drive types, keys, and certificates that your organization requires, or get started with using the product. See Administering.