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
- 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.
- Check the TLS version. Run the Get Config Properties List REST Service to check the TLS version. For the properties parameter, specify TransportListener.ssl.protocols.
- Update the TLS version if it is an older version (for example,
SSL_TLSv2). Run the Update Config Property REST Service to update the value of
TransportListener.ssl.protocols to
TLSv1.2
.
- For IBM Security Guardium Key Lifecycle Manager on Linux® or AIX®:
- Manually update the IPP port number in the IBM Security Guardium Key Lifecycle Manager server. Ensure that the value is greater than 1024.
- Reconfigure the IPP port number in all the clients or devices that are connected to the IBM Security Guardium Key Lifecycle Manager server.
- Validate that the required services, ports, and processes are running. See Validating services, ports, and processes.
- 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.
- 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 forUNKNOWN
devices to a new group, or allow the group to be determined when the devices make a first key service request.
- 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.
- Ensure that the paths for properties in the SKLMConfig.properties, datastore.properties, and ReplicationSKLMConfig.properties files are correct.
- 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.
- 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 asCONFLICTED
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.
- In the
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.
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.