DB2 UDB security, Part 6: Configure Kerberos for authentication on DB2 UDB for Linux, UNIX, and Windows

Using Kerberos for authentication provides a central repository for user IDs (or principals), thus centralizing and simplifying principal or identity management. Learn how to set up a single Kerberos realm environment for DB2® Universal Database™ for Linux®, UNIX®, and Windows® (DB2 UDB) and configure DB2 to use Kerberos authentication.

Kevin Yeung-Kuen See (see@ca.ibm.com), Software Developer, IBM

Kevin See photoKevin See, CISSP, has been a Software Developer at the IBM Toronto Laboratory for the past decade. His experiences include working in the DB2 Security Development team and the DB2 SQL and Catalog Development team. He is an IBM Certified Solutions Developer for XML and Related Technologies and a DB2 Certified Solutions Expert (DBA for OS390, DBA for Linux/UNIX/Windows, Advanced DBA for Linux/UNIX/Windows and DB2 Family Application Development). He is also an ISC2 Certified Information Systems Security Professional. He has written two IBM Developer Works security articles and is co-authoring an upcoming book about DB2 security.



Yung Chung (ychung@ca.ibm.com), Software Developer, IBM

Yung Chung is a Software Developer at the IBM Toronto Lab working in the DB2 Continuing Engineering team. Prior to that, he worked on the DB2 UNIX Development team. Yung received a Bachelor of Science degree from York University and is is an IBM Certified Solutions Expert (DBA for Linux/UNIX/Windows).



Henry Chan (henryc@ca.ibm.com), Software Developer, IBM

Henry Chan is a Software Developer at the IBM Toronto Lab working in the DB2 Continuing Engineering team. Prior to that, he was working in DB2 Security Development team and the DB2 Relational Database Services team and has been with IBM for ten years. He received an Master of Science from University of Alberta and a Bachelor of Mathematics from the University of Waterloo. He is an IBM Certified Solutions Expert (DBA for Linux/Unix/Windows and DB2 Family Application Development).



16 March 2006

Introduction

Kerberos is one of the key Single Sign-On solutions on the market. It is based on an open standard. Kerberos is essentially a secure network authentication protocol that employs a system of shared secret keys and is able to provide robust security against impersonation and reply attacks. With Kerberos, passwords are never flown on the wire, and the server and client may authenticate one another (referred to as "mutual authentication"). However, the solution relies upon a trusted third entity called the Key Distribution Centre (KDC), which has access to all keys.

Another strong incentive for using Kerberos is that it provides a central repository for user IDs (or principals), thus centralizing and simplifying principal or identity management.

Prior to DB2 UDB, Version 8.2, Kerberos authentication method was only supported on the Microsoft® Windows® 2000 platform using Microsoft's native Kerberos support through SSPI interface. With DB2 UDB, Version 8.2, along with the implementation of the security plug-in infrastructure, users are now able to use the Kerberos authentication method on the Linux and UNIX platforms, using the IBM-shipped Kerberos security plug-in library (IBMkrb5).

Learn how to set up the Kerberos environment on Linux and supported UNIX platforms. This article discusses how to configure the NAS kit (IBM Kerberos kit -- the only version of Kerberos officially supported by DB2) on the system for the NAS client and the KDC (NAS server). Furthermore, this article also discuss how to set up Microsoft Windows to use Kerberos authentication for DB2. Then, we show you how to enable DB2 Kerberos authentication. Finally, we discuss the common problems that readers may encounter when setting up the Kerberos environment.

This article assumes you know how to install a package on UNIX and Linux systems and have some basic understanding of Windows domain controller and active directory. After reading this article, you should be able to perform a setup of a single Kerberos realm environment for DB2 and configure DB2 to use Kerberos authentication.


Kerberos overview

Kerberos is a third-party network authentication protocol that employs a system of shared secret keys to securely authenticate a user in an insecure network environment. A three-tier system is used in which encrypted tickets (provided by a separate server called the Kerberos Key Distribution Center, or KDC for short) are exchanged between the application server and client, rather than text userid and password pairs. These encrypted service tickets (credentials) are only understood by the client and the server, so there is minimal security risk, even in the event that the ticket is intercepted on the network.

The basic idea of how Kerberos works is illustrated in the following two diagrams:

Figure 1. Step 1: Acquiring ticket granting ticket
Acquiring ticket granting ticket
Figure 2. Step 2: Acquiring session ticket and performing mutual authentication
Acquiring session ticket and performing mutual authentication

Inside a KDC, there are two services and a database. The database contains an entry called a principal and the associated encryption key for each registered user. The encryption key is derived from the user's input password when registering with the KDC. The two services are the authentication service (AS) and ticket granting service (TGS). Authentication service, as named, is responsible to authenticate a user before giving the initial credential -- ticket granting ticket (TGT). Ticket granting service is responsible for granting tickets. During Kerberos authentication, the following eight steps are performed (the last two steps will only be performed if mutual authentication is requested):

  1. Client requests a ticket granting ticket by authenticating itself to the Kerberos authentication service (AS) with kinit on UNIX and Linux and by logging into a domain on Windows.
  2. The AS sends back the TGT to the client once the user is authenticated successfully.
  3. With TGT, client requests a service granting ticket (in other words, session key) to access a server.
  4. TGS generates a session key and then sends the key to the client encrypted in the client's private key. In addition, the KDC encrypts the session key, along with some information about the client, in the servers' private key (collectively known as the ticket) and provides it to the client.
  5. The client encrypts an authenticator with the session key and sends that, together with the ticket, to the server.
  6. The server decrypts the ticket and extracts the session key.
  7. If the server is requested to do so, it will use the session key to decrypt the authenticator, extract the timestamp from within the authenticator, encrypt the timestamp with the session key, and send it to the client. The return of this encrypted token constitutes the initiation of mutual authentication.
  8. The client uses the session key to decrypt the token, and if the timestamp matches that from the authenticator, mutual authentication is considered successful.

Steps to configure the NAS kit on UNIX/Linux systems

Step 1: Set up KDC server

The guide assumes that you are using the NAS server kit for the KDC server.

For AIX, you can get the NAS server kit from the AIX 5.2 installation bonus CD. Note that NAS server is only available for AIX platforms only.

Table 1. Steps to set up the NAS server - KDC
StepDescription
1.Install the Network Authentication Service 1.3 server from CD.
2.Configure the KDC server using the following command:

/usr/krb5/sbin/config.krb5 -S -d domain -r realm

where realm is the realm you will be using.

For example:

config.krb5 -S -d torolab.ibm.com -r DB2SEC3.TOROLAB.IBM.COM


config.krb5 creates a krb5.conf file under /etc/krb5.

A sample krb5.conf is shown below:
[libdefaults]
default_realm = DB2SEC3.TOROLAB.IBM.COM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc

[realms]
DB2SEC3.TOROLAB.IBM.COM = {
kdc = witch.torolab.ibm.com:88
admin_server = witch.torolab.ibm.com:749
default_domain = torolab.ibm.com
}

[domain_realm]
.torolab.ibm.com = DB2SEC3.TOROLAB.IBM.COM
witch.torolab.ibm.com = DB2SEC3.TOROLAB.IBM.COM

[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
default = FILE:/var/krb5/log/krb5lib.log
3.Start the KDC server by issuing the command:

/usr/krb5/sbin/start.krb5

You should see two daemon processes kadmind and krb5krbc running:

root 1183858 1 0 21:42:34 - 0:00 /usr/krb5/sbin/kadmind
root 1974404 1 0 21:42:34 - 0:00 /usr/krb5/sbin/krb5kdc

Step 2: Set up NAS client

Note: DB2 supplied IBMKrb5 security plug-in only supports NAS client.

Table 2. Steps to set up NAS client
LinuxAIXSolaris
1. Download and install the NAS client packageDB2 requires Red 7 Hat Enterprise Linux Advanced Server 3 (Intel 32-bit only) with IBM Network Authentication Service (NAS) V1.4 or higher. See Resources for a link to download the NAS client. You can obtain the NAS client kit from the AIX 5.2 installation bonus CD.DB2 requires Solaris Operating Environment 8 or higher with IBM Network Authentication Service (NAS) client v1.3 or higher. See Resources for a link to download the NAS client.
2. Set up krb5 configuration fileIssue the following commands to set up the client:

/usr/krb5/sbin/config.krb5 -C -r realm -d domain -c KDC -s kadmin_server

For example:

/usr/krb5/sbin/config.krb5 -C -r DB2SEC3.TOROLAB.IBM.COM -d torolab.ibm.com -c witch.torolab.ibm.com -s witch.torolab.ibm.com

where witch.torolab.ibm.com is the KDC server running on AIX.

config.krb5 creates the configure file krb5.conf under /etc/krb5/.

The following is a sample configuration file:

[libdefaults]
default_realm = DB2SEC3.TOROLAB.IBM.COM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 arcfour-hmac aes256-cts des-cbc-md5 des-cbc-crc

[realms]
DB2SEC3.TOROLAB.IBM.COM = {
kdc = witch.torolab.ibm.com:88
admin_server = witch.torolab.ibm.com:749
default_domain = torolab.ibm.com
}

[domain_realm]
.torolab.ibm.com = DB2SEC3.TOROLAB.IBM.COM
witch.torolab.ibm.com = DB2SEC3.TOROLAB.IBM.COM

[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
default = FILE:/var/krb5/log/krb5lib.log
Solaris NAS does not ship with the config.krb5 executable. Therefore, it requires you to manually edit the configure file at /etc/krb5/krb5.conf. Please ensure that the edited file is /etc/krb5/krb5.conf and not /etc/krb5.conf. You must also add the default realms, domain_realm and more, to the file.

Solaris only supports Single DES. Please ensure the krb5 configuration on both the NAS client and NAS server are modified to take this into consideration.

Step 3: Create server principals (service principals) in the KDC

In order to use NAS, please ensure that you add /usr/krb5/bin and /usr/krb5/sbin into the PATH of environment before any other Kerberos in your system. You may already have other Kerberos software installed when you install Red Hat Linux.

Table 3. Steps to create a server principal
StepDescription
1.Issue the command /usr/krb5/sbin/kadmin on the DB2 server machine to start any kadmin session using the admin principals.
For example:

/usr/krb5/sbin/kadmin -p admin/admin -s witch.torolab.ibm.com

Output:

Authenticating as principal admin/admin with password.
Password for admin/admin@DB2SEC3.TOROLAB.IBM.COM: ********
kadmin>

2.After the kadmin prompt, issue: addprinc principal_name

For example:

kadmin> addprinc db2inst1/spline.torolab.ibm.com

The server principal name for the DB2 UDB instance is assumed to be <instance name>/<fully qualified hostname>@REALM. This principal must be able to accept Kerberos security contexts and it must exist before starting the DB2 UDB instance since the server name is reported to DB2 UDB by the plugin at initialization time.
3. Create an entry for the server principal in the keytab file. You are required to run the kadmin as root from the DB2 server machine. Otherwise, you may need to copy the keytab file to the DB2 server machine.

Under the kadmin prompt, issue:

ktadd server_principals

For example:

kadmin: ktadd db2inst1/spline.torolab.ibm.com

Output:

Entry for principal db2inst1/spline.torolab.ibm.com with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5/krb5.keytab.

Entry for principal db2inst1/spline.torolab.ibm.com with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/etc/krb5/krb5.keytab.

Entry for principal db2inst1/spline.torolab.ibm.com with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/etc/krb5/krb5.keytab.

Entry for principal db2inst1/spline.torolab.ibm.com with kvno 3, encryption type DES cbc mode with RSA-MD5 added to keytab WRFILE:/etc/krb5/krb5.keytab.


The default keytab file is local under /etc/kerb5/krb5.keytab, and it is only readable by the root. You have to change the permission of the file to readable by the DB2 instance ID. If you want to change the local of the keytab file, you can use the NAS environment variable KRB5_KTNAME and add KRB5_KTNAME to db2envlist registry variable.

Step 4: Create Kerberos users (client principals)

The principal may be found in either a 2-part or multi-part format (that is, name@REALM or name/instance@REALM). As the "name" part will be used in the authorization ID (AUTHID) mapping, the name must adhere to the DB2 database naming rules. This means that the name may be up to 30 characters long and it must adhere to the existing restrictions on the choice of characters used.

Create the user principal by using addprinc under kadmin. For example:

kadmin: addprinc boss/db2inst

Step 5: Set up DB2 to use Kerberos authentication

See "Steps to configure DB2 to enable Kerberos authentication" on how to set up DB2 to use Kerberos authentication.

Step 6: Authenticate yourself to the KDC for both the DB2 client and server

To start DB2, log into the DB2 server machine and issue kinit to get the ticket for the instance ID, and then issue db2start.

For example:

kinit db2inst1/db2inst1
db2start

To connect to the DB2 server, you must use the user principal as the user name. For example: db2 connect to sample user boss/db2inst using password

Or you can issue kinit first, before obtaining the credentials. Then you can connect to DB2 without using a password. For example:

kinit boss/db2inst1
db2 connect to sample

Steps to configure the Windows client and domain controller to enable Windows native Kerberos environment

Setting up DB2 clients and servers on Windows 2000 and above to use Kerberos is trivial. All domain users are equivalent to Kerberos principals and Active Directory acts as the KDC.

Step 1: Set up KDC

Basically, you will need to set up a Windows 2000 or above server as the domain controller that has the active directory enabled. The command to upgrade a Windows server to a domain controller is dcpromo. See "How to promote and demote domain controllers in Windows 2000" in Resources for more details.

Requirements:

  • Windows 2000 Server Edition or Windows 2003 Server Edition with the Active Directory enabled

Setup:

  • Enable the Active Directory
  • It is recommended that the domain name be in uppercase to facilitate compatibility with non-Windows Kerberos

Step 2: Configure Kerberos configuration file

Microsoft Active Directory uses DNS for Kerberos name mapping, thus there is no configuration file.

Step 3: Create Kerberos users (client principals) and server principals (service principals) in the KDC

To add users and service principals in Active Directory, use the GUI tools on the Active Directory Server machine. Click on Manage user accounts and group settings to bring up the "Active Directory Users and Computers" menu screen. Then, right-click on the Users folder and create a new user. For example: "see." Next, create another user, for example: "db2serv," for the service principal.

Step 4: Set up server key table (keytab) file

DB2 does not use the keytab file on Windows. The system automatically handles storing and acquiring the credentials handle for a service principal.

Step 5: Set up DB2 to use Kerberos authentication

See "Steps to configure DB2 to enable Kerberos authentication" on how to set up DB2 to use Kerberos authentication.

Step 6: Authenticate yourself to the KDC for both the DB2 client and server.

To authenticate to the Active Directory KDC, all you have to do is to log onto the domain.

Requirements:

  • Windows 2000 or above workstation that is a part of a Windows 2000 or above domain

Setup:

  1. Make sure your machine is a member of a domain. Log into the machine as a domain user.
  2. On the server, start the DB2 service as a domain user. It may be started as the SYSTEM account if the client and server are both Windows machines that are part of the same domain.

Carrying on the example, log into the DB2 client machine using the domain account "see," and log into the DB2 server machine using the domain account "db2serv." Then, start the DB2 service on the DB2 server using that domain account using the following steps:

  1. Go to Control panel > administrative tools > services
  2. Right-click on DB2 - <instance name> service, then go to properties, and select the Logon tab. Make sure the domain user has been specified and not Local System Account.

Steps to configure DB2 to enable Kerberos authentication

There are quite a few new database manager configuration parameters introduced for handling security plug-ins like Kerberos. A good description of each of these new parameters can be found in the DB2 documentation or in the article "Understand the DB2 Universal Database security plug-ins" (developerWorks, December 2005).

Table 4. Steps to enable Kerberos authentication in DB2
Steps on the clientSteps on the server
1.Update the database manager configuration parameter CLNT_KRB_PLUGIN with the name of the Kerberos plug-in (IBMkrb5).
  • On Windows platforms, this is set by default because Kerberos is natively supported by the underlying operating system.
  • If blank, DB2 assumes that the client is incapable of using Kerberos.
  • The default Kerberos plug-in provided by DB2 is named IBMkrb5.
  • For platforms supporting Kerberos, the IBMkrb5 library will already be present in the client plug-in directory.
Either update the database manager configuration parameter SRVCON_GSSPLUGIN_LIST with the server Kerberos plug-in name (IBMkrb5) or leave it blank (default).
2.Optional: Catalog a database indicating that the client will use the Kerberos plug-in for authentication. For example, db2 catalog db testdb at node testnode authentication kerberos target principal service/host@REALM. Update the database manager configuration parameter SRVCON_AUTH to KERBEROS or KRB_SERVER_ENCRYPT

OR

Update the database manager configuration parameter SRVCON_AUTH to NOT_SPECIFIED and set AUTHENTICATION to KERBEROS or KRB_SERVER_ENCRYPT.

The IBMkrb5 library can be found in:

  • UNIX/Linux 32-bit - sqllib/security32/plugin/IBM/client and sqllib/security32/plugin/IBM/server
  • UNIX/Linux 64-bit - sqllib/security64/plugin/IBM/client and sqllib/security64/plugin/IBM/server
  • Windows 32-bit and 64-bit - sqllib\security\plugin\IBM\client and sqllib\security\plugin\IBM\server

Note that the Windows 64-bit library is called IBMkrb564.dll.

Authorization ID Mapping

Authorization ID (Authid) is derived from the first part of the principal name. For example: the authid for see/admin@db2sec.torolab.ibm.com will be SEE. So, the first part of the principal acts like a userid, thus it must follow the userid naming conventions for DB2:

  • Character strings that represent names of database manager objects can contain any of the following: a-z, A-Z, 0-9, @, #, and $.
  • User IDs and groups may also contain any of the following additional characters when supported by the security plug-in: _,!, %, (, ), {, }, -, ., ^.
  • User IDs and groups containing any of the following characters must be delimited with quotations when entered through the command line processor: !, %, (, ), {, }, -, ., ^.
  • The first character in the string must be an alphabetic character, @, #, or $; it cannot be a number or the letter sequences SYS, DBM, or IBM.
  • Authentication IDs cannot exceed 30 characters on Windows 32-bit operating systems and 8 characters on all other operating systems.
  • Group IDs cannot exceed 30 characters in length.

On Windows platforms, the IBMkrb5 assumes the "@" character to be the domain separator. Thus "@" cannot be used as part of the username.

The principal name is in one of the following two formats: name@REALM or name/instance@REALM. Since the first part of principal name is used for authorization id derivation, it is possible for two principal names from the different Kerberos realms to be mapped to the same authid. For example, see/admin@db2sec.torolab.ibm.com and see/admin@krb5.torolab.ibm.com will be mapped to the same authid SEE. It is also possible for two principal names from the same name but different instances to map to the same authid. For example, see/admin@db2sec.torolab.ibm.com and see/project@db2sec.torolab.ibm.com will be mapped to the same authid SEE.

Thus, it is recommended that a unique namespace for the name within all the trusted realms is maintained, meaning all principals with the same name (first part of the principal name), regardless of the realm or instance, should belong to the same user.

Restrictions and limitations on using Kerberos for DB2 authentication

If the initial credentials expire, DB2 will not automatically renew them. However, on Microsoft Windows platforms, the credential renewal is done automatically by the operating system.

Equivalent operating system accounts must be created for each principal using DB2, unless a customized group plug-in is used to handle the group membership lookup.

Currently, DB2 does not implement support for credential delegation and changing password on the connect statement for Kerberos.

Kerberos has a list of weakness of its own:

  • Kerberos does not address password-guessing attacks
  • Denial-of-service attacks are not addressed
  • The concepts of groups or Access Control Lists (ACLs) are not part of the Kerberos protocol specifications
  • Private, long-term keys must remain secret by each principal. Otherwise, an attacker with the key will be able to completely masquerade as the principal.
  • Complete reliance and trust must be placed upon the KDC
  • If the KDC is compromised, the entire realm is no longer secure. Therefore, securing the KDC is of paramount importance.
  • Kerberos assumes that the clocks of all the machines in the realm are closely synchronized within the limit of the allowed time skew
  • Secret keys are temporarily stored on the users workstation and can be a target of an attack
  • Session keys are decrypted and reside on the user workstations (cache or key table) and can be a target of an attack

Common problems that customers have encountered

Problem 1: (Linux or UNIX platforms)
Problem description
Issued db2start and got the following error:
09/01/2004 09:32:16 0 0 SQL1365N db2start or db2stop failed in processing the plugin "". Reason code = "10".
SQL1032N No start database manager command was issued. SQLSTATE=57019

This error appears in the db2diag.log:
FUNCTION: DB2 Common, Security, Users and Groups, secLoadServerGSSPlugin, probe:21
DATA #1 : String, 95 bytes
gss_acquire_cred: Miscellaneous failure. A file or directory in the path name does not exist.


But after issuing kinit, the db2start ran fine.
Solution or workaround
This error occurred during the server plug-in initialization and indicates that the NAS client wasn't able to locate the keytab file. If the KRB5_KTNAME environment variable is not set, then the NAS client assumes that the keytab file is /etc/krb5/krb5.keytab. In order for the server to accept Kerberos credentials, the credentials of the service principal must be stored in the default keytab file.

For customers running on Windows, using the Windows Active Directory as the KDC, the steps to generate the service key and adding it to the keytab file requires some extra work. See the resources link for the Microsoft Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability in Resources for more details.
Problem 2: (Linux or UNIX platforms)
Problem description
The db2diag.log file contained the following entry:
FUNCTION: DB2 Common, Security, Users and Groups, secLoadServerGSSPlugin, probe:21
DATA #1 : String, 86 bytes
gss_acquire_cred: Miscellaneous failure. No principal in keytab matches desired name
Solution or workaround
Ensure the keytab file is in the right location, as with solution #1. Then verify that the principal is in the keytab by using the klist -k. If it is missing from the list, appropriately add the principal using ktadd -k command. Make sure the principal name is in the right format listed in the "Authorization ID mapping" section.
Problem 3: (Linux or UNIX platforms)
Problem description
Prior to V8 Fix pack 12, using the IBM-shipped Kerberos plug-in on Linux or UNIX platform, start and stop database manager commands (for example, db2start or db2stop) work fine only if issued by the instance owner no matter which Kerberos credentials (service or admin user) it has. The administrator log file has the following entry:

ADM13001E Plug-in "IBMkrb5" received error code "-1" from the DB2 security plug-in API "db2secGetDefaultLoginContext" with the error message "gss_acquire_cred: Miscellaneous failure. Credentials cache permissions incorrect".
Solution or workaround
The reason it failed is because db2start or db2stop is set to run as (setuid) the instance owner. So, the db2start process will run as the instance owner. During db2start, it will try to access the credential cache file. Since the credential cache file is owned by the userid that issued the kinit. Thus, db2start results in "credentials cache permissions incorrect" error because the instance owner does not have access to the file.

The workaround is to change the permission of the cache file to be readable by the instance owner after the SYSADM performs the kinit command.
Find the location by the cache file location by using the command klist. For example:
spline: /export/home/newton>klist
Ticket cache: /tmp/krb5cc_1943
Problem 4: (All platforms)
Problem description
A remote client catalogued a database without specifying authentication Kerberos, but the database manager configuration parameter "authentication" or "srvcon_auth" is set to krb_server_encrypt (in other words, Kerberos server encrypt). When a user attempts to connect to a database from the remote client specifying a userid and password (userid and password for the KDC) intending to use Kerberos authentication, the connect failed with sqlcode -30082 reason code 24 (USERNAME AND/OR PASSWORD INVALID).
Solution or workaround
Setting the database manager configuration parameter "authentication" or "srvcon_auth" to krb_server_encrypt means that the database server can accept server_encrypt or kerberos as authentication method. This failure was due to the fact that the remote client attempted to connect with userid and password, and if the database is not catalogued with specific authentication type, DB2 client will send out to the server a request to use server_encrypt authentication method by default. Since the server actually accepts the server_encrypt authentication method in this case, it will think that the client has sent over a userid and password to be validated by the operating system of the database server. This will cause an unexpected failure if the userid and password are not defined on the underlying operating system of the database server. The solution is to explicitly catalog the authentication type (KERBEROS) in the database alias on the client.
Problem 5: (Windows platform)
Problem description
On a Windows platform, the connection failed with sqlcode -30082 and reason code 6. The db2diag.log or administrative log (Windows event log) indicated "Logon failed" or "Logon denied".
Solution or workaround
Check the following conditions:
  • Expired account
  • Invalid password
  • Expired password
  • Password change forced by administrator
  • Disabled account
Problem 6: (Windows platform)
Problem description
On a Windows platform, the connection failed. In the db2diag.log or administrative log (Windows event log) indicated "The Local Security Authority cannot be contacted".
Solution or workaround
Check if the domain account name is also defined locally. If so, use the fully qualified user name in the connect string, such as see@TOROLAB.IBM.COM.
Problem 7: (Windows platform)
Problem description
On a Windows platform, the connection failed. In the db2diag.log or administrative log (Windows event log) indicated an invalid target principal name.
Solution or workaround
This can be due to the fact that the client and the server machines are in different domains and the service is started under the local system account. If this is the case, there is a workaround:
  • Explicitly catalog the target principal name using the fully qualified server host and domain names (for example, host/myhost.domain.ibm.com@DOMAIN.IBM.COM)
  • Start the DB2 service under a valid domain account

Summary

In this article, you got an overview of Kerberos authentication method. Kerberos is one of the key Single Sign-On Solutions in the IT industry and provides a central repository for user IDs (or principals), thus centralizing and simplifying principal or identity management. You learned to set up the Kerberos environment on all supported platforms as well as how to enable them in DB2. You also learned about some of the restrictions and limitations of using Kerberos for DB2 authentication and common errors encountered when setting up Kerberos environment for DB2.

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=105995
ArticleTitle=DB2 UDB security, Part 6: Configure Kerberos for authentication on DB2 UDB for Linux, UNIX, and Windows
publish-date=03162006