IBM Support

IBM Security Guardium Key Lifecycle Manager Version 4.1.0 Fix Packs

Fix Readme


Abstract

This page contains information about the fix packs that are released for IBM Security Guardium Key Lifecycle Manager Version 4.1.0.0.

Before you install a fix pack, you must have previously installed the base version (4.1.0.0) of the product. Fix packs are cumulative and contain all updates released before the fix pack.

Content

IBM Security Guardium Key Lifecycle Manager Version 4.1.0 Fix Pack 1 (4.1.0.1)
 

Refer to the Readme file for details about the fixed issues, and for instructions to download and apply the fix pack. 

IBM Security Guardium Key Lifecycle Manager Version 4.1.0.1 traditional offers the following enhancements: 

The documentation to support the base version of the release is available in the IBM product documentation.

Improved Multi-Master cluster management

To improve the performance of a highly available Multi-Master cluster, and to improve the stability of the cluster, V4.1.0.1 introduces changes to the HADR behavior.

With V4.1.0.1, the Multi-Master cluster does not use the HADR takeover service but it now uses the HADR reads on standby feature. With this feature, along with the primary database, the databases on all the standby servers are always in active state. The primary database is in read/write mode, while the other databases are in read-only mode.
When IBM Security Guardium Key Lifecycle Manager is unable to reach the primary database, it tries to connect to the database on the principal standby server for any client or device requests. If the database on the principal server is also unreachable, then the database on the auxiliary standby server is contacted.
 
Note: When the database of the primary server is unreachable, the Multi-Master cluster goes into read-only state. IBM Security Guardium Key Lifecycle Manager continues to support uninterrupted key serving. You can access all cryptographic objects. However, you cannot create, modify, or delete keys and other cryptographic objects.

Sections:

Changes to the existing Multi-Master behavior

-    The auto takeover functionality is discontinued.
-    Split-cluster scenario is not applicable.
-    The Join Back Cluster REST service is not applicable.
-    The Multi-Master section on the graphical user interface displays a Warning or an Error for the Db2 HADR status to indicate that the cluster is operating in a read-only state. See the following screen capture for reference:
 

Multi-Master cluster is in read-only mode

- The following table explains a Multi-Master cluster behavior based on the status of the Agent and database of the primary and principal standby servers.

Primary Agent Primary database Principal Standby Agent Principal Standby database Auto takeover Manual takeover Notes
Up Down Up Up No Yes. Promote the principal standby  server to primary.
Down or Unreachable Down or Unreachable Up Up No
Down Down or Unreachable Up or Down Down or Unreachable No Yes. Promote an auxiliary standby  server, if it exists, to primary. See HADR recovery steps.
Recovering a Multi-Master cluster from a read-only state

When the primary database is unreachable, the cluster goes into a read-only state. For the cluster to be back into healthy state, complete the HADR recovery actions in the following order:

1. Wait for the database of the primary server to be reachable again, so that the cluster restores its healthy state, and you can perform all operations on the cryptographic objects.
2. Promote the principal standby server to primary.
If you know that the primary database will be unreachable for a longer duration (for example, for operating system upgrade on the server or a network outage), promote the principal standby server to primary. Add the original primary server as a standby server.
After the original primary database is reachable again, you can promote it to primary.
If you want to continue with the current primary server, update the data source with the current primary details.
3. Only if the primary and principal standby servers are down: If you know that the primary and principal database will be unreachable for a longer duration, promote the auxiliary standby server to primary.
If you want to continue with the promoted primary server, update the data source with its details. 
Updating the data source
Complete the following steps on all the master servers of the cluster:
1. Update the data source by running the following command on all the master servers.
WAS_HOME\bin\wsadmin.bat -username  WASAdmin_user -password WASAdmin_password -lang jython -f SKLM_HOME\agent\agentSetupWAS.py DB_NAME Current_Primary_Hostname Current_Primary_Port Standby_Port Standby_Port
If multiple standby servers exist, provide the values in a comma-separated format. For example:
"C:\Program Files\IBM\WebSphere\AppServer\bin\wsadmin.bat" -username wasadmin -password changeMe  -lang jython -f "C:\Program Files\IBM\SKLMV41\agent\agentSetupWAS.py" sklmdb41 mserver1 50070 mserver2,mserver3 50070,50070
3. Restart the WebSphere Application Server.
Recovering a Multi-Master cluster from a possible split-cluster scenario
Use the steps in this section to recover a Multi-Master cluster from a possible split-cluster scenario.
Scenario:
When the primary server of a cluster is out of network for some time, it becomes unreachable, the primary database is unreachable, and the cluster goes in read-only mode. You promote the principal standby server to primary, and the cluster is in read/write mode. After connectivity with the original primary server is restored, Db2 disables HADR on the server.
As a result, the status of Db2 HADR on the new primary server displays an error or a warning symbol.
Solution:
Complete the following recovery steps:
1. On the new primary server: Take an online backup of the database.
For example:
DB2 BACKUP DATABASE SKLMDB41 ONLINE TO "C:\Users\sklmdb41\AppData\Local\Temp"
2. On the original primary server:
  2.1 Copy the backup file that is created in the earlier step to any directory. Let's consider the directory to be: C:\
  2.2 Restore the backup file.
  For example:
 db2 restore database sklmdb41 from C:\              
  2.3 Restore the HADR configuration.
  For example:
 db2 update db cfg for sklmdb41 using HADR_LOCAL_HOST host1 
 db2 update db cfg for sklmdb41 using HADR_LOCAL_SVC 60028
 db2 update db cfg for sklmdb41 using HADR_REMOTE_HOST host2
 Where,
  host1 is the host name of the original primary server
  host2 is the host name of the new primary server
 The HADR service on the original primary server is restored, and it is added to the cluster as a standby server.  The HADR status on the primary server is refreshed in a few minutes to display the Green status.

Back to top

Enabling password-less authentication with the database by using Kerberos

You can now enable Kerberos authentication for secure communication between IBM Security Guardium Key Lifecycle Manager (GKLM) and the Db2 database. Kerberos authentication replaces the need for using Db2 user credentials and removes the requirement of changing the database password when the operating system password changes.

Sections:

Overview

For a quick overview on Kerberos, see About Kerberos.

About Kerberos

Kerberos is a third-party authentication mechanism, in which users and services rely on the Kerberos server for authentication. Kerberos uses Key Distribution Center (KDC).  which is a central repository of IDs that uniquely identify users or services. An ID is a string and is known as a principal. A service is a resource that is provided to a user. For example, file server, application server, database.

Format of a principal is as follows: serviceuser/FQDN_GKLMserver@REALMNAME
For example: sklmdb41/gklmserver@EXAMPLE.COM

Where,

  • serviceuser is the name of the service to be authenticated, such as the Db2 service. For example: sklmdb41
  • FQDN_GKLMserver is the fully qualified dns name of the host system on which the Guardium Key Lifecycle Manager server is installed
  • REALMNAME is the Kerberos realm name. A Kerberos realm is a domain or a group of systems. Kerberos has authority to authenticate a user to a service that is hosted on a computer in this domain. The REALMNAME value must be specified in uppercase characters only.
Kerberos configuration involves the following high-level steps:
Prerequisite step: Install the Kerberos or Key Distribution Center (KDC) server.
Step 1: Install Kerberos client on the Guardium Key Lifecycle Manager server.
Step 2: Register service and client principals on the Kerberos server. 
              The service principal creates a service for Db2 that can be accessed by the client principal. 
Step 3: Configure Guardium Key Lifecycle Manager.
You will need the following script files for Step 3. These files are available in the SKLM_INSTALL_HOME/kerberos directory after you install the fix pack V4.1.0.1:
  • Windows:
    • db2ConfigureKerberos.bat
    • db2RemoveKerberos.bat
  • Linux and AIX:
    • db2ConfigureKerberos.sh
    • db2RemoveKerberos.sh

Also, to help with the configuration and management of Kerberos, the following new REST services are introduced with this fix pack. These REST services are available in the Swagger UI (under the Server Management section):

  • Configure Kerberos Authentication REST Service
  • Get Kerberos Configuration REST Service
  • Remove Kerberos Configuration REST Service
  • Configure Kerberos on Multi-Master Cluster REST Service
For details, see Kerberos Rest Services PDF.
    Configuring Kerberos
    Before you begin:
    • Ensure that the computer on which you install the Kerberos server is secure and does not run any service other than KDC.
    • Ensure that the computers that host the Kerberos server and the Kerberos client (Guardium Key Lifecycle Manager server) have the same operating system.
    • For Guardium Key Lifecycle Manager server that is installed on Windows, you can configure Kerberos with Active Directory only.
    Depending on your deployment method, see the relevant section for instructions:
      Configuring Kerberos on a stand-alone Guardium Key Lifecycle Manager server
      Depending on the operating system of the Guardium Key Lifecycle Manager server, see the relevant section for configuration steps.
       

      Procedure on Windows

      Prerequisite Step: Install the Kerberos (Key Distribution Center - KDC) server

      You need to set up an Active Directory to install Kerberos server.

      If an Active Directory is already set up, you can skip this step.

      Set up the Active Directory:

      1. Open Server Manager.
      2. On the Server Manager Dashboard, click Add roles and features.
      3. Select Role-based or feature-based installation and click Next.
      4. Select the server and click Next.
      5. From the list of server roles, select Active Directory Domain Services, and click Next.
      6. Click Add Features.
      7. Retain the default selections, and click Next.
      8. On the Active Directory Domain Services page, click Next.
      9. Review the selections, and click Install.
      10. After the installation completes, click Promote this server to a domain controller.
      11. Select Add a new forest, and in the Root domain name field, type in a domain name that you want to use (for example, DOMAIN.TMP, then click Next.
      12. Enter the DSRM password, and click Next.
      13. On the DNS Options, Additional Options, Paths, and Review Options pages, retain the default values, and click Next to move through the pages.
      14. On the Prerequisite Checks page, click Install. The installation starts.
      15. After the installation completes, to verify Active Directory is set up, open Server Manager.
      16. Click Tools, and select Active Directory Users and Computers.
      17. Expand the domain root and then click Domain Controllers.
      The new Active Directory server is displayed.

      Step 1: Install the Kerberos client

      Complete this step on the Guardium Key Lifecycle Manager server. Add the host computer of the Guardium Key Lifecycle Manager server to the domain.

      1. Open Control Panel.
      2. Click System and Security, and then click System > Advanced system settings.
      3. In the System Properties dialog box, click the Computer Name tab and click Change.
      4. In the Member of section, select Domain, and type the name of the domain to which you want to add this computer, and then click OK.
      5. Click OK
      6. Restart the computer.

      Step 2: Register service and client principals on the Kerberos server

      Complete these steps on the Kerberos server:
      1. To register a service principal, create an Active Directory user. For example, db2serv.
        1.1 Open Server Manager.
        1.2 From the Tools menu, select Active Directory Administrative Center.
        1.3 In the left pane, expand ad (local) and select Users.
        1.4 In the right pane, under Users, click New, and select User from the menu.
        1.5 In the Create User dialog box, specify the required values, such as user name and password.
         Note: Ensure that the following conditions are met:
      • The valid characters are: 'A' through 'Z'; 'a' through 'z'; '0' through '9'; '# '; '@'; '$'; '_'; '!'; ' '('; ')'; '{'; '}'; '-'; '.'; and '^'. The following characters must be delimited with quotation marks when entered through the command line processor: '!'; ' '('; ')'; '{'; '}'; '-'; '.'; and '^'. A delimited authorization ID must not contain lowercase letters.
      • The name must not begin with the characters 'SYS', 'IBM', or 'SQL'. The name must not be: 'ADMINS', 'GUESTS', 'LOCAL', 'PUBLIC', or 'USERS'.
      2. To register a client principal, create another Active Directory user. For example, sklmdb41.
      3. Configure the service principal name to use the Db2 service by using the SetSPN utility.
          To do so, open the command-line interface and run these commands:
        setspn -U -S db2instance1/FQDN_GKLMserver@REALMNAME user_name
           For example:
        setspn -U -S sklmdb41/gklmserver@EXAMPLE.COM db2serv

      Step 3: Configure Guardium Key Lifecycle Manager to use Kerberos authentication with Db2

      Complete this step on the Guardium Key Lifecycle Manager server on which you installed the Kerberos client.
      1. Navigate to the SKLM_INSTALL_HOME/kerberos directory and run the db2ConfigureKerberos.bat script file as the process owner (Db2 Administrator user account).
      This script updates the kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
      Command to run the script file:
      "path\db2cmd.exe"       db2ConfigureKerberos.bat    path_of_krb5.conf     kdc_server     REALMNAME
      For example:
      "C:\Program Files\IBM\DB2SKLMV41\BIN\db2cmd.exe"    db2ConfigureKerberos.bat     krb5.conf    kdcserver.example.com       EXAMPLE.COM
      2. Add the Db2 service principal to DB2ADMNS and Administrator groups.
      3. Start the Db2 service as the service principal (For example, db2serv).
        To run the REST service, you can use the Swagger UI.
      5. Start the WebSphere Application Server service as the service principal (For example, db2serv).
      Guardium Key Lifecycle Manager is now configured to use Kerberos as the authentication mechanism with Db2 database.
      You can use the Get Kerberos Configuration REST Service to obtain the configuration details. To run the REST service, you can use the Swagger UI.

       

      Procedure on Linux

      Prerequisite Step: Install the Kerberos (Key Distribution Center - KDC) server

      If you want to use an existing Kerberos server, you can skip this step.
      1. Install the required packages for the KDC server:
        yum install krb5-server krb5-libs krb5-workstation
      2. Specify the realm name and the domain-to-realm mappings by editing the /etc/krb5.conf and /var/kerberos/krb5kdc/kdc.conf configuration files.
      For example:
      [libdefaults]
      default_realm = EXAMPLE.COM
      [realms]
      EXAMPLE.COM = {
      kdc = kerberos.example.com
      admin_server = kerberos.example.com
      }
      [domain_realm]
      .example.com = EXAMPLE.COM
      example.com = EXAMPLE.COM
      Where,
      EXAMPLE.COM and example.com refer to the realm name; and kerberos.example.com is the name of the Kerberos server.
      Note: Enter all realm names in uppercase characters and all dns host names and domain names in lowercase.
      3. Create the database by using the kdb5_util utility.
       kdb5_util create -s
      The database stores keys for a Kerberos realm.
      4. Edit the /var/kerberos/krb5kdc/kadm5.acl file.
        This file is used by kadmind to determine which principals have administrative access to the Kerberos database and   their level of access.
      For example:
      */admin@EXAMPLE.COM  *
      5. Create the first principal with the kadmin.local command.
      6. Start Kerberos using the following commands:
       systemctl start krb5kdc.service
       systemctl start kadmin.service

      Step 1: Install Kerberos client

      Complete this step on the Guardium Key Lifecycle Manager server.
      Run the command:
      yum install krb5-libs krb5-workstation

      Step 2: Register service and client principals on the Kerberos server

      1. Create service principal.
      kadmin -p root/admin -q "addprinc db2instance1/FQDN_GKLMserver@REALMNAME"
      For example:
      kadmin -p root/admin -q "addprinc sklmdb41/gklmserver@EXAMPLE.COM"
      2. Specify a password for the service principal.
      3. Create client principal.
      kadmin -p root/admin -q "addprinc db2instance1@REALMNAME"
      For example:
      kadmin -p root/admin -q "addprinc sklmdb41@EXAMPLE.COM"
      4. Specify a password for the client principal.
      5. Add service principal to the keytab file.
      kadmin -p root/admin -q "ktadd -k /etc/filename.keytab db2instance1/FQDN_GKLMserver@REALMNAME"
      For example:
      kadmin -p root/admin -q "ktadd -k /etc/onprem.keytab sklmdb41/gklmserver@EXAMPLE.COM"
      6. To verify the principals are correctly added, run the following command:
      kadmin.local -q "list_principals"
      7. Upload the keytab file on the Guardium Key Lifecycle Manager server. You can use the File Upload REST service.
      To run the REST service, you can use the Swagger UI.
      Note: If you are copying the file manually on the Guardium Key Lifecycle Manager server, ensure that the file owner is the process owner (For example, sklmdb41).

      Step 3: Configure Guardium Key Lifecycle Manager

      Complete this step on the Guardium Key Lifecycle Manager server on which you installed the Kerberos client.
      1. Navigate to the SKLM_INSTALL_HOME/kerberos directory and run the db2ConfigureKerberos.sh script file as the process owner (Db2 Administrator user account; for example, sklmdb41).
      This script updates the Kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
      Command to run the script file:
      ./db2ConfigureKerberos.sh    path_krb5.conf     path_krb5.keytab         kserver_hostname    REALMNAME   db2servicename     path_sqllib
       
      For example:
      ./db2ConfigureKerberos.sh      /opt/IBM/SKLMV41/kerberos/krb5.conf            /opt/IBM/WebSphere/AppServer/products/sklm/data/krb5.keytab           kdc.example.com         EXAMPLE.COM               sklmdb41/test.example.com@EXAMPLE.COM                 /home/sklmdb41/sqllib
        To run the REST service, you can use the Swagger UI.
      Guardium Key Lifecycle Manager is now configured to use Kerberos as the authentication mechanism with Db2 database.
      You can use the Get Kerberos Configuration REST Service to obtain the configuration details. To run the REST service, you can use the Swagger UI.
       
       

      Procedure on AIX

      Prerequisite Step: Install the Kerberos (Key Distribution Center - KDC) server

      If you want to use an existing Kerberos server, you can skip this step.
      To install the Kerberos server, run the following commands:
      tar -xvf NAS_1.4.0.10_aix_images.tar
      cd /images
      installp -ac -SvYXgd /images krb5.server
      installp -ac -SvYXgd /images krb5.toolkit
      export PATH=$PATH:/usr/krb5/sbin:/usr/krb5/bin
      timed -M
      hostname
      mkkrb5srv -r REALMNAME -s kserverhostname -d REALMNAME -a root/admin
      lsitab krb5kdc
      lsitab kadm
      Where,
      REALMNAME is the realm of the Kerberos server;
      kserverhostname is the host name of the system on which the Kerberos server is being installed

      Step 1: Install Kerberos client

      Complete this step on the GKLM server.

      1. Open the following URL and download the latest NAS (Network Authentication Service pack) compatible with your version of AIX: https://www.ibm.com/services/forms/preLogin.do?source=dm-nas
      2. Open the command-line interface and install the client using the installp command.
      For example:
      # /usr/sbin/installp -agYXd /path/to/apps/NAS1.4.0.10 all
      3. Include the LIBPATH to the Db2 profile file (for example: /home/sklmdb41/sqllib/db2profile).
      For example:
      export LIBPATH=/usr/krb5/lib:$LIBPATH
      4. Include the path in the Database user (for example, sklmdb41) profile (sklmdb41_home/.profile).
      For example:
      export PATH=$PATH:/usr/krb5/bin:/usr/krb5/sbin

      Step 2: Register service and client principals on the Kerberos server

      1. Create a service principal.
      kadmin -p root/admin -q "addprinc db2instance1/FQDN_GKLMserver@REALMNAME"
      For example:
      kadmin -p root/admin -q "addprinc sklmdb41/gklmserver@EXAMPLE.COM"
      2. Specify a password for the service principal.
      3. Create a client principal that will access the Db2 service.
      kadmin -p root/admin -q "addprinc db2instance1@REALMNAME"
      For example:
      kadmin -p root/admin -q "addprinc sklmdb41@EXAMPLE.COM"
      4. Specify a password for the client principal.
      5. Add the service principal to the keytab file.
      kadmin -p root/admin -q "ktadd -k /etc/filename.keytab db2instance1/FQDN_GKLMserver@REALMNAME"
      For example:
      kadmin -p root/admin -q "ktadd -k /etc/onprem.keytab sklmdb41/gklmserver@EXAMPLE.COM"
      6. To verify that the principals are correctly added, run the following command:
      kadmin.local -q "list_principals"
      7. Upload the keytab file on the Guardium Key Lifecycle Manager server by using the File Upload REST service.
      To run the REST service, you can use the Swagger UI.
      Note: If you are copying the file manually on the Guardium Key Lifecycle Manager server, ensure that the file owner is the process owner (For example, sklmdb41).

      Step 3: Configure Guardium Key Lifecycle Manager

      Complete this step on the Guardium Key Lifecycle Manager server on which you installed the Kerberos client.
      1. Navigate to the SKLM_INSTALL_HOME/kerberos directory and run the db2ConfigureKerberos.sh script file as the process owner (Db2 Administrator user account; for example, sklmdb41).
      This script updates the kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
      Command to run the script file:
      ./db2ConfigureKerberos.sh    path_krb5.conf     path_krb5.keytab         kserver_hostname         REALMNAME   db2servicename     path_sqllib
       
      For example:
      ./db2ConfigureKerberos.sh      /opt/IBM/SKLMV41/kerberos/krb5.conf            /opt/IBM/WebSphere/AppServer/products/sklm/data/krb5.keytab           kdc.example.com         EXAMPLE.COM               sklmdb41/test.example.com@EXAMPLE.COM                 /home/sklmdb41/sqllib
        To run the REST service, you can use the Swagger UI.
      Guardium Key Lifecycle Manager is now configured to use Kerberos as the authentication mechanism with Db2 database.
      You can use the Get Kerberos Configuration REST Service to obtain the configuration details. To run the REST service, you can use the Swagger UI.
       

      Procedure on Linux GKLM with Windows Active Directory as KDC Server

      Prerequisite Step: Install the Kerberos (Key Distribution Center - KDC) server

      You need to set up an Active Directory to install Kerberos server.

      If an Active Directory is already set up, you can skip this step.

      Set up the Active Directory:

      1. Open Server Manager.
      2. On the Server Manager Dashboard, click Add roles and features.
      3. Select Role-based or feature-based installation and click Next.
      4. Select the server and click Next.
      5. From the list of server roles, select Active Directory Domain Services, and click Next.
      6. Click Add Features.
      7. Retain the default selections, and click Next.
      8. On the Active Directory Domain Services page, click Next.
      9. Review the selections, and click Install.
      10. After the installation completes, click Promote this server to a domain controller.
      11. Select Add a new forest, and in the Root domain name field, type in a domain name that you want to use (for example, DOMAIN.TMP, then click Next.
      12. Enter the DSRM password, and click Next.
      13. On the DNS Options, Additional Options, Paths, and Review Options pages, retain the default values, and click Next to move through the pages.
      14. On the Prerequisite Checks page, click Install. The installation starts.
      15. After the installation completes, to verify Active Directory is set up, open Server Manager.
      16. Click Tools, and select Active Directory Users and Computers.
      17. Expand the domain root and then click Domain Controllers.
      The new Active Directory server is displayed.

      Step 1: Install Kerberos client

      Complete this step on the Guardium Key Lifecycle Manager server.
      Run the command:
      yum install krb5-libs krb5-workstation

      Step 2: Register service and client principals on the Kerberos server

      Complete these steps on the Kerberos server:
      1. To register a service principal, create an Active Directory user. For example, db2serv.
        1.1 Open Server Manager.
        1.2 From the Tools menu, select Active Directory Administrative Center.
        1.3 In the left pane, expand ad (local) and select Users.
        1.4 In the right pane, under Users, click New, and select User from the menu.
        1.5 In the Create User dialog box, specify the required values, such as user name and password.
         Note: Ensure that the following conditions are met:
      • The valid characters are: 'A' through 'Z'; 'a' through 'z'; '0' through '9'; '# '; '@'; '$'; '_'; '!'; ' '('; ')'; '{'; '}'; '-'; '.'; and '^'. The following characters must be delimited with quotation marks when entered through the command line processor: '!'; ' '('; ')'; '{'; '}'; '-'; '.'; and '^'. A delimited authorization ID must not contain lowercase letters.
      • The name must not begin with the characters 'SYS', 'IBM', or 'SQL'. The name must not be: 'ADMINS', 'GUESTS', 'LOCAL', 'PUBLIC', or 'USERS'.
      2. To register a client principal, create another Active Directory user. For example, sklmdb41.
      3. Configure the service principal name to use the Db2 service by using the SetSPN utility.
          To do so, open the command-line interface and run these commands:
        setspn -U -S db2instance1/FQDN_GKLMserver@REALMNAME user_name
           For example:
        setspn -U -S sklmdb41/gklmserver@EXAMPLE.COM db2serv
      4. Generate Keytab file on the Active Directory Server.
          To do so, open the command-line interface and run these commands:
        ktpass -out filename.keytab -mapuser service_principal -princ db2instance1/FQDN_GKLMserver@REALMNAME -pass password -ptype KRB5_NT_PRINCIPAL -target REALMNAME -kvno 0
           For example:
        ktpass -out linux.keytab -mapuser db2serv -princ sklmdb41/gklmserver@EXAMPLE.COM -pass PASSWORD -ptype KRB5_NT_PRINCIPAL /Target SKLM.COM /kvno 0
       
      5. Upload the keytab file on the Guardium Key Lifecycle Manager server. You can use the File Upload REST service.
      To run the REST service, you can use the Swagger UI.
      Note: If you are copying the file manually on the Guardium Key Lifecycle Manager server, ensure that the file owner is the process owner (For example, sklmdb41).

      Step 3: Configure Guardium Key Lifecycle Manager

      Complete this step on the Guardium Key Lifecycle Manager server on which you installed the Kerberos client.
      1. Navigate to the SKLM_INSTALL_HOME/kerberos directory and run the db2ConfigureKerberos.sh script file as the process owner (Db2 Administrator user account; for example, sklmdb41).
      This script updates the Kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
      Command to run the script file:
      ./db2ConfigureKerberos.sh    path_krb5.conf     path_krb5.keytab         kserver_hostname    REALMNAME   db2servicename     path_sqllib
       
      For example:
      ./db2ConfigureKerberos.sh      /opt/IBM/SKLMV41/kerberos/krb5.conf            /opt/IBM/WebSphere/AppServer/products/sklm/data/krb5.keytab           kdc.example.com         EXAMPLE.COM               sklmdb41/test.example.com@EXAMPLE.COM                 /home/sklmdb41/sqllib
      2. Run the command:
      echo 'export DB2_KRB5_PRINCIPAL=' >> ~/.bash_profile
      . ~/.bash_profile
        To run the REST service, you can use the Swagger UI.
      Guardium Key Lifecycle Manager is now configured to use Kerberos as the authentication mechanism with Db2 database.
      You can use the Get Kerberos Configuration REST Service to obtain the configuration details. To run the REST service, you can use the Swagger UI.
      Configure Kerberos on Guardium Key Lifecycle Manager in a replication setup
      Based on your requirement, you can configure Kerberos only on the master server, clone server, or both the servers.
      The procedure to configure Kerberos on a master or clone server is the same as the procedure for a stand-alone server. See, Procedure.

      Back to top

      Configure Kerberos on Guardium Key Lifecycle Manager in a Multi-Master cluster setup
      You can configure Kerberos on a server before or after setting up the Multi-Master cluster.
      Review the following considerations and requirements before you proceed with the Kerberos configuration:
      • Based on your requirements, you can configure Kerberos before or after you set up a Multi-Master cluster.
      • Ensure that the Kerberos client is installed on all master servers.
      • For a cluster, install only one instance of the Kerberos server.
      • Register a client principal with the same details on all master servers.
      • Register a unique service principal for every master server.
      • Only for Linux and AIX: Create a separate keytab file for every master server and add only that master server's service principal to it.
      • After you run the db2ConfigureKerberos.sh script, you must manually copy the krb5.conf file in SKLM_INSTALL_HOME/kerberos directory to WAS_HOME/java/8.0/jre/lib/security directory to ensure that the Agent service gets the Kerberos configuration details.
      To configure Kerberos before a Multi-Master cluster is set up
      Complete the following steps on every Guardium Key Lifecycle Manager server that you plan to add to the cluster:
      1. Configure Kerberos using the same procedure for a stand-alone server. See, Procedure.
      2. Copy the krb5.conf file from SKLM_INSTALL_HOME/kerberos directory to WAS_HOME/java/8.0/jre/lib/security directory to ensure that the Agent service is notified of the Kerberos configuration.
      To configure Kerberos on an existing Multi-Master cluster setup
      Complete the following steps on every master server of the cluster:
      1. Navigate to the SKLM_INSTALL_HOME/kerberos directory and run the db2ConfigureKerberos.sh script file.
      Run the command:
      ./db2ConfigureKerberos.sh path_of_krb5.conf path_of_krb5.keytab kdc_server realmName db2ServiceName path_of_sqllib_folder
      For example:
      ./db2ConfigureKerberos.sh SKLM_INSTALL_HOME/kerberos/krb5.conf path_of_krb5.keytab kdc_server realmName db2ServiceName path_of_sqllib_folder

      This script updates the Kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
      2. Copy the krb5.conf file from SKLM_INSTALL_HOME/kerberos directory to WAS_HOME/java/8.0/jre/lib/security directory to ensure that the Agent service gets the Kerberos configuration details.
      3. On the primary server, run the Configure Kerberos on Multi-Master Cluster REST service.
      To run the REST service, you can use the Swagger UI.

      Back to top

      Viewing Kerberos configuration details
      On the Guardium Key Lifecycle Manager server, run the Get Kerberos Configuration REST Service to retrieve details about the Kerberos configuration.
      To run the REST service, you can use the Swagger UI.
      Removing Kerberos configuration
      On the Guardium Key Lifecycle Manager server:
      1. Navigate to the SKLM_INSTALL_HOME/kerberos directory and run the db2RemoveKerberos script file.
      (For Linux and AIX) Run the command:
      ./db2RemoveKerberos.sh      path_of_krb5.conf     path_of_krb5.keytab     kdc_server     realmName     db2ServiceName   path_of_sqllib_folder
      For example:
      ./db2RemoveKerberos.sh  SKLM_INSTALL_HOME/kerberos/krb5.conf    /opt/IBM/WebSphere/AppServer/products/sklm/data/krb5.keytab kdc_server EXAMPLE.COM sklmdb41/test.example.com@EXAMPLE.COM/home/sklmdb41/sqllib
      (For Windows) Run the command:
      db2RemoveKerberos.bat
      2. Run the Remove Kerberos Configuration REST Service.
      To run the REST service, you can use the Swagger UI.
      The Kerberos configuration is removed from the Guardium Key Lifecycle Manager server.
      3. Only for Windows: Complete these steps:
       3.1 Remove the Guardium Key Lifecycle Manager server from the Active Directory domain.
       3.2 Restart the Db2 service and WebSphere Application Server service as the local Db2 Administrator user (for example, sklmdb41).
      Note: In case of replication or Multi-Master deployment, you need to complete the steps to remove Kerberos configuration on each server (master, clone).
      Troubleshooting Kerberos configuration
      The Kerberos logs are added to the SystemOut.log file of WebSphere Server, which is available at:
      WAS_HOME/profiles/KLMProfile/logs/server1/SystemOut.log
      The following table lists some possible errors and their solutions.

      No

      Error

      Solution

      1

      Unspecified GSS failure, minor code may provide more information clock skew too great 

      Synchronize the time clocks on the Kerberos and GKLM servers. Kerberos typically permits a 5-minute time skew.

      2

      kinit: Keytab contains no suitable keys for db2inst1/gklmserver@EXAMPLE.COM while getting initial credentials

      Ensure that the keytab file contains the service principal for Db2.

      Use the command:
      klist -kte path_of_keytab_file

      3

      SQL1365N db2start or db2stop failed in processing the plugin "IBMkrb5". Reason code = "10".

      Ensure that the Db2 instance owner (db2inst1) has read access to the keytab file. Also, ensure that the keytab file contains the service principal for Db2. 

      4

      javax.security.auth.login.FailedLoginException: Login error: com.ibm.security.krb5.KrbException, status code: 6

      message: Client/Server not found in Kerberos database

      Ensure that the correct client name, which is registered in KDC, is used in the Configure Kerberos REST API. Ensure the correct service principal name is specified in the REST API.

      On Windows, ensure that the service is correctly associated with the Db2 user in the Active Directory.
      Enhanced data migration functionality when using the cross-platform restore utility
      Applicable only when using the cross-migration utility with RESTORE_USER_ROLES property set to "y" in the restore.properties property file:
      After you restore data, credentials for same user accounts that exist on both the source (version earlier than V4.1.0.0) and the target (V4.1.0.1) servers are not migrated.
      For example: Consider that you want to migrate data from V2.6.0 (source) to V4.1.0.1 (target) using the cross-platform backup and restore utility and with the RESTORE_USER_ROLES property set as y.
      Both the source and target servers have the same application user (for example, sklmadmin); however, the password of the user varies.
      After you restore the data, on the target server, credentials for all users from the source server are restored on the target server. However, the password for the user (sklmadmin) will not be restored and you can continue to use the password that was set on the target server. 

      Back to top

      [{"Line of Business":{"code":"LOB24","label":"Security Software"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSTJE47","label":"IBM Security Guardium Key Lifecycle Manager"},"ARM Category":[{"code":"a8m0z000000cvdzAAA","label":"SKLM-\u003EINSTALL-\u003EFIXPACK"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"4.1.0"}]

      Document Information

      Modified date:
      03 July 2023

      UID

      ibm16428967

      Page Feedback