Summary: I believe that the IBM LDAP authentication plug-in version 1.2 for DB2 version 9 on Solaris 10 does not correctly failover to a new LDAP server on the IBMLDAPSecurity.ini file keyword LDAP_HOSTS when a prior server on the LDAP_HOSTS list becomes unresponsive.
Configuration details: Using DB2 version 9 Fixpack 4, Solaris 10 and LDAP plug-in version 1.2 (Solaris files dated 2007.08.20).
Within the IBMLDAPSecurity.ini file located in the [instance home]/sqllib/cfg directory there is a configuration keyword LDAP_HOST. This keyword is a string listing the sequence of LDAP servers to try when DB2 LDAP authentication is attempted. Here is the actual list from our server when our problem occurred:
LDAP_HOST = 10.50.1.43 10.50.50.101 10.50.60.37 10.235.1.43 10.235.173.67 10.235.173.170 10.235.44.34 10.222.71.55 10.222.68.55
I would expect DB2, in this case, to first use LDAP server 10.50.1.43 . If DB2 were unsuccessful in connecting to LDAP server 10.50.1.43, it should then attempt 10.50.50.101, and so on down the list until a LDAP server was successfully connected and authentication data returned.
On Friday December 12th we began receiving connection authentication errors, with this message in db2diag.log:
2008-12-12-13.43.54.823238-360 I4731A312 LEVEL: Error PID : 16761 TID : 1 FUNCTION: DB2 Common, Security, Users and Groups, secValidatePasswordPlugin, probe:20 DATA #1 : String, 96 bytes db2ldapGetUserDN: LDAP search failed with ldap rc=81 (Can't contact LDAP server) user='abcdpapl'
Where user id abcdpapl is the application user.
Subsequent research by systems engineers determined that the first three servers on our LDAP_HOST list were failing: 10.50.1.43 , 10.50.50.101, and 10.50.60.37. But all the other servers on the list, 10.25.*.* in particular, were functioning. In fact we were only able to get DB2 authentication by LDAP working again by reordering the LDAP_HOST list to put the 10.235.*.* servers to the top of the list and recycling the DB2 instance. DB2 is clearly ignoring every entry on the list after the first, and not failing over.
I have opened a PMR and am waiting for IBM engineers to give me a final decision on whether this is a defect and that the DB2 LDAP 1.2 plug-in is not working as designed.
UPDATE 2008.12.18: My IBM contact tells me today that this is going to have to be considered a design change request (DCR), not a defect. As he explains it, “In this case, we successfully bound to the first LDAP server. Had that bind failed, we would have proceeded to the next server from the LDAP_HOST list. Instead, we started getting search errors, specifically RC=81. The IBM LDAP Authentication Plug-in is not currently designed to bind to another server and try the search again. Arguably it should be, but this becomes a Design Change and not a defect. You will need to make that request through your IBM Representative. DB2 Service does not have the ability to open Design Change Requests.”
I have submitted a DCR through my IBM representative, but I expect resolution to this will not happen soon.
Background on the DB2 LDAP Plug-in
DB2 security plug-ins were introduced in 2005 with DB2 version 8.2 but LDAP was not initially supported. The LDAP Authentication Plug-in has been available for DB2 LUW since 2006; and has since been released in 3 versions: 1.0, 1.1 and 1.2. LDAP Plug-in 1.0 was not officially supported under version 8, but only implemented officially for version 9 (though it would work under 8.2). With 1.1 the LDAP Plug-in began to be supported officially for DB2 both version 8 and 9. With LDAP Plug-in 1.2, released concurrent with DB2 9 Fixpack 3, came support for Open LDAP server. If you use the DB2® Version 9.1 Fix Pack 6 (or later) fix pack image to install a DB2 database product, the LDAP security plug-ins are included in the installation.
The LDAP security plug-ins are also available for download here.
Citations
- Private correspondence with IBM engineer
- Information Center
- Information Center
- Chris Eaton in IT Toolbox
- DeveloperWorks
