I wrote this which is basically a checklist of what needs doing to get LDAP working for DB2 on SuSE Linux installations. If your looking for how to do this on SLES 11 SP2, then you need to check out DB2 LDAP configuration on SLES11 SP2
, as the ibm boulder site provides several contradictory installation processes. Hopefully this will help someone else and
save them the time that I wasted trawling the ibm site for the correct answer:
This list is mainly focused on the 8 character limit on DB2 (Linux)UW (which is I guess the only reason you might want to use the
security plugins instead as this will allow you to use more than 8 characters to authenticate against DB2.
What I ended up doing with the help of theLDAP admin was creating an LDAP alias of 8 characters for each user, as the
transparent LDAP (for me) seemed to work better than the security plugin approach.
install nss_ldap-32bit-262-11.16.x86_64.rpm,nss_ldap-262-11.16.x86_64.rpm,pam_ldap-32bit-184-147.20.x86_64.rpm and
edit /etc/ldap.conf to contain the necessary config for BASE DN and BIND DN for LDAP server.
nss_map_attribute uniqueMember member
create /etc/pam.d/db2 and make read/write to root only
auth sufficient pam_ldap.so use_first_pass
auth required pam_unix2.so
account sufficient pam_ldap.so
account required pam_unix2.so
password required pam_pwcheck.so
password sufficient pam_ldap.so use_first_pass
password required pam_unix2.so use_authtok use_first_pass
session required pam_unix2.so
use Yast LDAP client screen to restart all the proper processes.
” yast ldap pam disable/enable “
check for presence of LDAP users in the db2cc list.
add a user to the preferred database and exit
login as an ‘LDAP user’ to server
export DB2INSTANCE=db2inst1(or other instance name)
db2 connect to TOOLSDB
####NEXT PART IS ONLY IF YOU OPT TO USE THE SECURITY PLUGIN APPROACH INSTEAD
OF THE TRANSPARENT LOGIN,ETC.###########
copy /opt/ibm/db2/version/cfg/IBMLDAPSecurity.ini /home/db2inst1/sqllib/cfg
db2 update dbm cfg using diaglevel 4
db2 update dbm cfg using SRVCON_PW_PLUGIN IBMLDAPauthserver
***PASTE the IBMLDAPSecurity.ini here ****
; Licensed Materials – Property of IBM
; Governed under the terms of the International
; License Agreement for Non-Warranted Sample Code.
; (C) COPYRIGHT International Business Machines Corp. 2006
; All Rights Reserved.
; US Government Users Restricted Rights – Use, duplication or
; disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
; Sample configuration file for the IBM DB2 LDAP Security Plugin
; The default name and location for this file is
; UNIX: INSTHOME/sqllib/cfg/IBMLDAPSecurity.ini
; Windows: %DB2PATH%cfgIBMLDAPSecurity.ini
; Optionally, the location of this file can be specified via the
; DB2LDAPSecurityConfig environment variable.
; On Windows systems, this variable should be set in the global
; system environment to ensure it is picked up by the DB2 service.
; A semicolon anywhere on a line begins a comment.
; The default values work well for many IBM Tivoli Directory Server
; configurations. Other directory servers may require different
; values; please consult your LDAP server administrator.
; Values known to work with many Microsoft Active Directory
; installations are mentioned below; search for “MSAD”.
; This sample configuration was last updated in August 2007
; SERVER RELATED VALUES
; Name of your LDAP server(s).
; This is a space separated list of LDAP server hostnames or IP
; addresses, with an option port number for each one:
; host1[:port] [host2:[port2] … ]
; The default port number is 389, or 636 if SSL is enabled.
LDAP_HOST = ldapserver-ip
; To enable SSL support, you must have the GSKit toolkit installed.
; Optional; defaults to false (no SSL).
;ENABLE_SSL = true
; SSL_KEYFILE and SSL_PW
; SSL keyring and keyring password
; A keyfile is only required if your LDAP server is using a
; certificate that isn’t automatically trusted by your GSkit install.
;SSL_KEYFILE = /home/db2inst1/IBMLDAPSecurity.kdb
;SSL_PW = keyfile-password
; USER RELATED VALUES
; LDAP object class used for users
; Generally “inetOrgPerson” (“user” for MSAD)
USER_OBJECTCLASS = inetOrgPerson
; LDAP base DN to use when searching for users.
; This is optional. If not specified, user searches will
; start at the root of the LDAP directory. Some LDAP servers (particularly
; MSAD) may require that you specify a value for this parameter.
;USER_BASEDN = o=ibm
USER_BASEDN = cn=users,dc=ldapserver,dc=ldapserverdomain,dc=ldapserver.co.uk
; LDAP user attribute that represents the “userid”
; This attribute is combined with the USER_OBJECTCLASS and USER_BASEDN
; (if specified) to construct an LDAP search filter when a user issues
; a DB2 CONNECT statement with an unqualified userid.
; For example, using the default values in this configuration file,
; db2 connect to MYDB user bob using bobpass
; results in the following search filter:
; For MSAD, this is frequently “sAMAccountName”.
USERID_ATTRIBUTE = uid
; LDAP user attribute that represents the DB2 “authorization ID”
; (typically this is the same as the USERID_ATTRIBUTE).
; Again, for MSAD this is frequently “sAMAccountName”.
AUTHID_ATTRIBUTE = uid
; GROUP RELATED VALUES
; LDAP object class used for groups
; Generally “groupOfNames” or “groupOfUniqueNames” (“group” for MSAD)
GROUP_OBJECTCLASS = posixGroup
; LDAP base DN to use when searching for groups
; This is optional. If not specified, group searches will
; start at the root of the LDAP directory. Some LDAP servers (MSAD)
; require that you specify a value for this parameter.
;GROUP_BASEDN = o=ibm
; LDAP group attribute that represents the name of the group
GROUPNAME_ATTRIBUTE = cn
; Determines the method used to find the group memberships for a user.
; Possible values are:
; SEARCH_BY_DN – Search for groups that list the user as a member.
; Membership is indicated by the group attribute defined
; as GROUP_LOOKUP_ATTRIBUTE (typically “member” or
; USER_ATTRIBUTE – A user’s groups are listed as attributes of the user
; object itself. Search for the user attribute defined
; as GROUP_LOOKUP_ATTRIBUTE to get the groups (typically
; “memberOf” for MSAD or “ibm-allGroups” for ITDS).
; Many MSAD installation use “GROUP_LOOKUP_METHOD = USER_ATTRIBUTE” and
; “GROUP_LOOKUP_ATTRIBUTE = memberOf”.
;GROUP_LOOKUP_METHOD = SEARCH_BY_DN
;GROUP_LOOKUP_METHOD = USER_ATTRIBUTE
; Name of the attribute used to determine group membership, as described
GROUP_LOOKUP_ATTRIBUTE = member
;GROUP_LOOKUP_ATTRIBUTE = ibm-allGroups
; If NESTED_GROUPS is true, we recursively search for group memberships by
; attempting to look up the group memberships for every group that we find.
; Cycles (A belongs to B, B belongs to A) are handled correctly.
; This is optional, and default to false.
;NESTED_GROUPS = true
; MISCELLANEOUS VALUES
; SEARCH_DN and SEARCH_PW
; If your LDAP server does not support anonymous access, or if anonymous
; access is not sufficient when searching for users or groups, then you
; can define a DN and password that will be used to perform searches.
; MSAD does not, by default, allow anonymous search and will require
; a SEARCH_DN and SEARCH_PW.
;SEARCH_DN = cn=root
;SEARCH_PW = rootpassword
; Some LDAP servers generate “referrals”, which tell the client contact
; another LDAP server. By default, the LDAP plugins will honor referal
; requests. In some cases this behavior is not desirable, and this
; may be disable by setting this parameter to false.
; If you notice LDAP error “rc=1 (Operations error)” in the db2diag.log
; in a MSAD environment, should you try setting this to false.
; This is optional, and defaults to true.
;FOLLOW_REFERRALS = false
; Dump some extra information to the db2diag.log to aid in debugging
; LDAP related issues. Most of the additional information will be
; logged at DIAGLEVEL 4 (INFO).
; Optional, defaults to false.
DEBUG = true
may or may not need to add TRUST_ALLCLNTS and TRUST_CLNTAUTH to CLIENT
add the user into the db2cc
[email protected]:/> PATH=$PATH:/home/db2inst1/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:
db2 => connect to SAMPLE user ‘cn=firstname lastname’
Enter current password for cn=firstname lastname:
user must only have one uid otherwise you get AUTHID failures in the DB2 Diag log