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
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:
- Improved Multi-Master cluster management
- Enabling password-less authentication with the database by using Kerberos
- Enhanced data migration functionality when using the cross-platform restore utility
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.
Sections:
- Changes to the existing Multi-Master behavior
- Recovering a Multi-Master cluster from a read-only state
- Recovering a Multi-Master cluster from a possible split-cluster scenario
Changes to the existing Multi-Master behavior
- 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:
- 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. |
See HADR recovery steps.
|
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. |
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:
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.
If you want to continue with the promoted primary server, update the data source with its details.
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
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.
For example:
DB2 BACKUP DATABASE SKLMDB41 ONLINE TO "C:\Users\sklmdb41\AppData\Local\Temp"
For example:
db2 restore database sklmdb41 from C:\
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
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
- Configuring Kerberos
- Viewing Kerberos configuration details
- Removing Kerberos configuration
- Troubleshooting Kerberos configuration
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.
- 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
- 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.
- Stand-alone Guardium Key Lifecycle Manager server
- Guardium Key Lifecycle Manager in a replication setup
- Guardium Key Lifecycle Manager in a Multi-Master setup
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:
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.
Step 2: Register service and client principals on the Kerberos server
- 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'.
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
This script updates the kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
Procedure on Linux
Prerequisite Step: Install the Kerberos (Key Distribution Center - KDC) server
yum install krb5-server krb5-libs krb5-workstation
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.
kdb5_util create -s
The database stores keys for a Kerberos realm.
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 *
systemctl start krb5kdc.service
systemctl start kadmin.service
Step 1: Install Kerberos client
Step 2: Register service and client principals on the Kerberos server
kadmin -p root/admin -q "addprinc db2instance1/FQDN_GKLMserver@REALMNAME"
For example:
kadmin -p root/admin -q "addprinc sklmdb41/gklmserver@EXAMPLE.COM"
kadmin -p root/admin -q "addprinc db2instance1@REALMNAME"
For example:
kadmin -p root/admin -q "addprinc sklmdb41@EXAMPLE.COM"
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"
To run the REST service, you can use the Swagger UI.
Step 3: Configure Guardium Key Lifecycle Manager
This script updates the Kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
Procedure on AIX
Prerequisite Step: Install the Kerberos (Key Distribution Center - KDC) server
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
Step 1: Install Kerberos client
Complete this step on the GKLM server.
For example:
# /usr/sbin/installp -agYXd /path/to/apps/NAS1.4.0.10 all
For example:
For example:
Step 2: Register service and client principals on the Kerberos server
kadmin -p root/admin -q "addprinc db2instance1/FQDN_GKLMserver@REALMNAME"
For example:
kadmin -p root/admin -q "addprinc sklmdb41/gklmserver@EXAMPLE.COM"
kadmin -p root/admin -q "addprinc db2instance1@REALMNAME"
For example:
kadmin -p root/admin -q "addprinc sklmdb41@EXAMPLE.COM"
kadmin -p root/admin -q "ktadd -k /etc/filename.keytab db2instance1/FQDN_GKLMserver@REALMNAME"
kadmin -p root/admin -q "ktadd -k /etc/onprem.keytab sklmdb41/gklmserver@EXAMPLE.COM"
To run the REST service, you can use the Swagger UI.
Step 3: Configure Guardium Key Lifecycle Manager
This script updates the kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
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:
The new Active Directory server is displayed.
Step 1: Install Kerberos client
Step 2: Register service and client principals on the Kerberos server
- 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'.
setspn -U -S db2instance1/FQDN_GKLMserver@REALMNAME user_name
For example:
setspn -U -S sklmdb41/gklmserver@EXAMPLE.COM db2serv
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
To run the REST service, you can use the Swagger UI.
Step 3: Configure Guardium Key Lifecycle Manager
This script updates the Kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
- 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.
This script updates the Kerberos configuration (krb5.conf) file, which is needed to connect to the KDC server.
To run the REST service, you can use the Swagger UI.
To run the REST service, you can use the Swagger UI.
WAS_HOME/profiles/KLMProfile/logs/server1/SystemOut.log
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: |
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. |
Was this topic helpful?
Document Information
Modified date:
03 July 2023
UID
ibm16428967