In part 1 of this series, we described how to configure DB2 Express-C on Linux and how to configure the Centrify DB2 Plugin.  In this article we will focus on testing the installation and an example of how to troubleshoot if things aren't working as expected.



The Centrify Community has some great resources when it comes to IBM DB2 integration with Active Directory using Centrify. But, have you ever wanted to quickly set up DB2 in a test environment to play with these integrations? By following this article, you can!


Leveraging Centrify to provide Active Directory authentication and privelege data access roles for the IBM DB2 application, we have seen this seamless integration across the AIX landscape.  Centrify-ing your DB2 environment removes the need to provision and manage your DB2 users and their  respective DB2 groups at the OS level.  In addition, administrative efficiencies are gained by leveraging existing Active Directory user/group provisioning work flows.


Our Community forums are full of great articles and discussions on how to leverage Centrify Server Suite for IBM DB2 authentication and DB2 Roles for different types of entitlements to the data within.  Just in case you happen to pull this article up first, I'm going to quickly link those other DB2 forum threads for you for quick access.


Robertson's Discussion on Overcoming IBM DB2 Identity and Access Challenges with Centrify and AD


Robertson's HOWTO: Configure IBM DB2 SSO Module for Kerberos/GSSAPI SSO


Robertson's HOWTO: Install, configure and test the Centrify IBM DB2 SSO Module


Alternatively,  Felderi's Discussion on DB2 LUW Transparent LDAP; DB2AUTH=OSAUTHDB


Starting with DB2 v9.7FP1, IBM DB2 implemented transparent LDAP support.  In a nutshell, this allows the DB2 database manager to authenticate users defined in an LDAP directory,  removing the requirement that DB2 users and groups be defined at the operating system level. 


If you are a DB2 shop running DB2 on AIX, the above articles will help you integrate your AIX DB2 environment with Centrify.  If you are a Linux shop, or using a unix variant that leverages the PAM stack, you might want to bookmark this article for future use.


Buried in the discussions above is the key configuration parameters to leverage IBM DB2's native LDAP support.  Here is the link:


Additionally, your Unix server must have the CentrifyDC agent installed and joined to your Active Directory environment.  If you are running a unix variant that has configurable PAM stack, you will have to configure the db2 PAM stack to include the calls to Centrify PAM library.


For example, RedHat Linux DB2 PAM stack:



# lines needed by Centrify Direct Control { CentrifyDC 5.3.0-213 }
auth sufficient
auth requisite deny
account sufficient
account requisite deny
#session required homedir
password sufficient try_first_pass
password requisite deny


# User changes will be destroyed the next time authconfig is run.
auth required
auth sufficient nullok try_first_pass
auth requisite uid >= 500 quiet
auth required


account required nodefgroup accessfile=/etc/security/access.conf
account required
account sufficient
account sufficient uid < 500 quiet
account required


#password requisite try_first_pass retry=3 type=
password requisite try_first_pass retry=3 minlen=9 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=0 difok=3
#password sufficient md5 shadow nullok try_first_pass use_authtok
password sufficient sha512 shadow nullok try_first_pass use_authtok remember=5
password required


session optional revoke
session required
session [success=1 default=ignore] service in crond quiet use_uid
session required


After the DB2 PAM stack has been edited, you will need to restart the DB2 service.


Keep in mind, USERS that need access to the DB2 data need to be Zone Enabled.  This will also allow you to migrate your DB2 shared accounts used by multiple client connections to Active Directory.


Finally, the unix groups that are used to setup DB2 database entitlements can now be migrated and managed through Active Directory.



Organizations can always count with the reliability of IBM hardware, operating systems and utilities for mission critical applications. That’s why Centrify has invested in certifying the product lines with IBM infrastructure.


This post discusses the DB2 SSO Module; this plugin (like the Apache HTTP and Java plugins) leverages the Active Directory integration capabilities and robustness of the Centrify agent to provide additional value and functionality to DB2 implementations.


The DB2 plugin provides the following benefits:

  • No need to keep users local to the UNIX/Linux system to support DB2: When used natively, DB2 users need to have user accounts in the local /etc/passwd file. The DB2 enables AD users to access DB2 so the benefits of Unified Identity, Centralized Administration, Streamlined Authentication and Policy Enforcement are organically attained.

In practical terms: no more getting dinged by auditors when the account of a long-gone user is found active in the /etc/passwd of a DB2 system.

  • Long login names: Support for logins that are longer than 8 characters
  • Single Sign-on (SSO): Centrify enables SSO to DB2 leveraging the GSSAPI
  • Active Directory Group Support: AD group memberships can be leveraged to grant entitlements inside DB2.


This is one of the best Database to AD integration models out there.


This article covers setup, configuration and testing of the DB2 moduleon Linux 64 bit in a lab environment. We will focus on the User/Password and Group Plugin first since they enable a UNIX/Linux admin to set it up without any AD requirements.  In a follow-up post we'll cover the SSO GSSAPI plugin. 


Like any other DBMS, a true production implementation requires planning and understanding of the current environment.


Showing results for 
Search instead for 
Do you mean 

Community Control Panel