Lightweight Directory Access Protocol (LDAP) is an industry standard access method to directory services. A directory service is a repository of resource information about multiple systems and services within a distributed environment, and it provides client and server access to these resources. Each database server instance will publish its existence to an LDAP server and provide database information to the LDAP directory when the databases are created. When a client connects to a database, the catalog information for the server can be retrieved from the LDAP directory. Each client is no longer required to store catalog information locally on each machine. Client applications search the LDAP directory for information required to connect to the database.
A caching mechanism exists so that the client searches the LDAP directory only once in its local directory catalogs. Once the information is retrieved, it is stored or cached on the local machine. Subsequent access to the same information is based on the values of the DIR_CACHE database manager configuration parameter and the DB2LDAPCACHE registry variable, as detailed in Table 4.6.
Table 4.6. Cached Information Available by Configuration Parameter and Registry Variable
The DB2LDAPCACHE registry variable is applicable only to the database and node directories.
To ensure that you have the latest entries in the cache, do the following to update and remove incorrect entries from the database directory and node directory:
REFRESH LDAP DB DIR REFRESH LDAP NODE DIR
Supported LDAP Client and Server Configurations
Table 4.7 summarizes the current supported LDAP client and server configurations:
When running on Windows operating systems, DB2 supports using either the IBM LDAP client or the Microsoft LDAP client to access the IBM SecureWay Directory Server. If you want to explicitly select the IBM LDAP client, you must use the db2set command to set the DB2LDAP_CLIENT_PROVIDER registry variable to "IBM."
Support for Windows Active Directory
DB2 exploits the Active Directory as follows :
Property pages for the ibm_db2Node and ibm_db2Database objects can be viewed or modified using the Active Directory Users and Computer Management Console at a domain controller. To setup the property page, run the regsrv32 command to register the property pages for the DB2 objects, as follows:
You can view the objects by using the Active Directory Users and Computer Management Console at a domain controller. To get to the Administration Tool, select Start, Program, Administration Tools, Active Directory Users and Computer
You must select Users, Groups, and Computers as containers from the View menu to display the DB2 objects under the computer objects. If DB2 is not installed on the domain controller, you can still view the property pages of DB2 objects by copying the db2ads.dll file from %DB2PATH%\bin and the resource DLL db2adsr.dll from %DB2PATH%\msg\locale- name to a local directory on the domain controller. Then, you run the regsrv32 command from the local directory to register the DLL.
Configuring DB2 to Use Microsoft Active Directory
To access Microsoft Active Directory, ensure that the following conditions are met:
Configuring DB2 in the IBM LDAP Environment
Before you can use DB2 in the IBM LDAP environment, you must configure the following on each machine:
DB2 objects are located in the LDAP base distinguished name (baseDN). If you are using IBM SecureWay LDAP directory server Version 3.1, you do not have to configure the baseDN because DB2 can dynamically obtain this information from the server. However, if you are using IBM eNetwork Directory Server Version 2.1, you must configure the LDAP baseDN on each machine by using the db2set command:
db2set DB2LDAP_BASEDN=<baseDN> where baseDN is the name of the LDAP suffix that is defined at the LDAP server. This LDAP suffix is used to contain DB2 objects. db2set DB2LDAP_BASEDN=o=phantom.com
Creating an LDAP User
DB2 supports setting DB2 registry variables and CLI configuration at the user level. (This is not available on the UNIX and Linux platforms.) User-level support provides user-specific settings in a multi-user environment. An example is Windows NT Terminal Server, where each logged on user can customize his or her own environment without interfering with the system environment or another user's environment.
When using the IBM LDAP directory, you must define an LDAP user before you can store user-level information in LDAP. You can create an LDAP user in one of the following ways:
An LDIF file containing the attributes for a person object appears similar to the following:
File name: newuser.ldif dn: cn=Jonathan Phan,ou=TestTeamI,ou=TESTTEAM,o=phantom.com,c=us objectclass: ePerson cn: Jonathan Phan sn: phan uid: jphan userPassword: password telephonenumber: 1-555-080-0096 facsimiletelephonenumber: 1-555-080-0099 title: TestTeamI
Following is an example of the LDIF command to import an LDIF file using the IBM LDIF import utility:
LDIF2DB i newuser.ldif
You must run the LDIF2DB command from the LDAP server machine. You must grant the required access (ACL) to the LDAP user object so that the LDAP user can add, delete, read, and write to its own object, using the LDAP Directory Server Web Administration tool.
Configuring the LDAP User for DB2 Applications
When using the Microsoft LDAP client, the LDAP user is the same as the operating system user account. However, when working with the IBM LDAP client and before using DB2, you must configure the LDAP user distinguished name and password for the current logged on user. This can be done using the db2ldcfg utility:
db2ldcfg u <userDN> w <password> set the user's DN and password r clear the user's DN and password
db2ldcfg u "cn=Jonathan Phan,ou=TestTeamI,ou=TESTTEAM,o=phantom.com, c=us" w password
Registration of DB2 Servers after Installation
Each DB2 server instance must be registered in LDAP to publish the protocol configuration information that is used by the client applications to connect to the DB2 server instance. When registering an instance of the database server, you need to specify an LDAP node name . The LDAP node name is used by client applications when they connect or attach to the server. You can catalog another alias name for the LDAP node by using the CATALOG LDAP NODE command.
If you are working in a Windows 2000 domain environment, then during installation, the DB2 server instance is automatically registered in the Active Directory with the following information:
nodename: TCP/IP hostname protocol type: TCP/IP
If the TCP/IP hostname is longer than 8 characters, it will be truncated to 8 characters .
The REGISTER command appears as follows:
db2 register db2 server in ldap as <ldap_node_name> protocol tcpip
The protocol clause specifies the communication protocol to use when connecting to this database server.
When creating an instance for DB2 Universal Database Enterprise Server Edition that includes multiple physical machines, the REGISTER command must be invoked once for each machine. Use the rah command to issue the REGISTER command on all machines.
The same ldap_node_name cannot be used for each machine because the name must be unique in LDAP. You will want to substitute the hostname of each machine for the ldap_node_name in the REGISTER command. For example:
rah ">DB2 REGISTER DB2 SERVER IN LDAP AS SANDIEGO PROTOCOL TCPIP"
The REGISTER command can be issued for a remote DB2 server. To do so, you must specify the remote computer name, instance name, and the protocol configuration parameters when registering a remote server. The command can be used as follows:
db2 register db2 server in ldap as <ldap_node_name> protocol tcpip hostname <host_name> svcename <tcpip_service_name> remote <remote_computer_name> instance <instance_name> db2 register db2 server in ldap as SANDIEGO protocol tcpip hostname 192.168.1.51 svcename 11001 remote sunshine.dnt instance v8inst
The following convention is used for the computer name:
When running in a high availability or failover environment and using TCP/IP as the communication protocol, the cluster IP address must be used.
Using the cluster IP address allows the client to connect to the server on either machine without having to catalog a separate TCP/IP node for each machine. The cluster IP address is specified using the hostname clause, shown as follows:
db2 register db2 server in ldap as <ldap_node_name> protocol tcpip hostname nnn.nnn.nnn.nnn svcename <tcpip_service_name> where nnn.nnn.nnn.nnn is the cluster IP address. db2 register db2 server in ldap as SANDIEGO protocol tcpip hostname 192.168.1.51 svcename 11001
Update the Protocol Information for the DB2 Server
The DB2 server information in LDAP must be kept current. For example, changes to the protocol configuration parameters or the server network address require an update to LDAP. To update the DB2 server in LDAP on the local machine, use the following command:
db2 update ldap ...
Examples of protocol configuration parameters that can be updated include:
To update a remote DB2 server protocol configuration parameters, use the UPDATE LDAP command with a node clause:
db2 update ldap node <node_name> hostname <host_name> svcename <tcpip_service_name> db2 update ldap node SANDIEGO hostname 192.168.1.101 svcename 11002
Catalog a Node Alias for ATTACH
A node name for the DB2 server must be specified when registering the server in LDAP. Applications use the node name to attach to the database server. If a different node name is required, such as when the node name is hard-coded in an application, use the CATALOG LDAP NODE command to make the change. The command would be similar to:
db2 catalog ldap node <ldap_node_name> as <new_alias_name> db2 catalog ldap node SANDIEGO as SANDIEGO
To uncatalog an LDAP node, use the UNCATALOG LDAP NODE command. The command would appear similar to:
db2 uncatalog ldap node <ldap_node_name> db2 uncatalog ldap node SANDIEGO
Deregistering the DB2 Server
Deregistration of an instance from LDAP also removes all the node, or alias, objects and the database objects referring to the instance. Deregistration of the DB2 server on either a local or a remote machine requires that the LDAP node name be specified for the server:
db2 deregister db2 server in ldap node <node_name> db2 deregister db2 server in ldap node SANDIEGO
When the DB2 server is deregistered, any LDAP node entry and LDAP database entries referring to the same instance of the DB2 server are also uncataloged.
During the creation of a database within an instance, the database is automatically registered in LDAP if the server is registered. Registration allows remote client connection to the database without having to catalog the database and node on the client machine. When a client attempts to connect to a database, if the database does not exist in the database directory on the local machine, then the LDAP directory is searched.
If the name already exists in the LDAP directory, the database is still created on the local machine but a warning message is returned, stating the naming conflict in the LDAP directory. For this reason, you can manually catalog a database in the LDAP directory. The user can register databases on a remote server in LDAP by using the CATALOG LDAP DATABASE command. When registering a remote database, you specify the name of the LDAP node that represents the remote database server. You must register the remote database server in LDAP using the REGISTER DB2 SERVER IN LDAP command before registering the database.
To register a database manually in LDAP, use the CATALOG LDAP DATABASE command:
db2 catalog ldap database <dbname> at node <node_name> with "comment" db2 catalog ldap database SAMPLE at node SANDIEGO with "My LDAP SAMPLE database"
The following authentication levels are available when registering the database in LDAP:
Specifies that authentication takes place on the node from which the application is invoked.
Specifies that authentication takes place on the node containing the target database.
Specifies that authentication takes place on the node containing the target database, and passwords are encrypted at the source. Passwords are decrypted at the target, as specified by the authentication type cataloged at the source.
Specifies that authentication takes place on the node containing the target database, except when using DB2 Connect; in that case, authentication takes place at the DRDA application server (AS). Passwords are encrypted at the source, and decrypted at the target, as specified by the authentication type cataloged at the source.
Specifies that authentication takes place on the node containing the target database, except when using DB2 Connect; in that case, authentication takes place at the DRDA application server (AS).
Specifies that authentication takes place using Kerberos Security Mechanism.
Attaching to a Remote Server in the LDAP Environment
In the LDAP environment, you can attach to a remote database server using the LDAP node name on the ATTACH command:
db2 attach to <ldap_node_name>
When a client application attaches to a node or connects to a database for the first time, because the node is not in the local node directory, DB2 searches the LDAP directory for the target node entry. If the entry is found in the LDAP directory, the protocol information of the remote server is retrieved. If you connect to the database and the entry is found in the LDAP directory, then the database information is also retrieved.
Using this information, DB2 automatically catalogs a database entry and a node entry on the local machine. The next time the client application attaches to the same node or database, the information in the local database directory is used without having to search the LDAP directory.
The caching of LDAP information is not applicable to user-level CLI or DB2 profile registry variables. Also, there is an "in-memory" cache for the database, node, and DCS directories. However, there is no such cache for just the node directory.
Deregistering the Database from the LDAP Directory
The database is automatically deregistered from LDAP when:
The database can be manually deregistered from LDAP using:
db2 uncatalog ldap database <dbname> db2 uncatalog ldap database SANDIEGO
Refreshing LDAP Entries in Local Database and Node Directories
LDAP information is subject to change, so it is necessary to refresh the LDAP entries in the local and node directories. The local database and node directories are used to cache the entries in LDAP.
To refresh the database entries that refer to LDAP resources, use the following command:
db2 refresh ldap database directory
To refresh the node entries on the local machine that refer to LDAP resources, use the following command:
db2 refresh ldap node directory
As part of the refresh, all the LDAP entries that are saved in the local database and node directories are removed. The next time that the application accesses the database or node, it will read the information directly from LDAP and generate a new entry in the local database or node directory.
To ensure the refresh is done in a timely way, you may want to:
Searching the LDAP Directory Partitions or Domains
DB2 searches the current LDAP directory partition or current Active Directory domain in the Windows 2000 environment. In an environment where there are multiple LDAP directory partitions or domains, you can set the search scope to improve performance.
For example, if the information is not found in the current partition or domain, automatic search of all other partitions or domains can be requested .
On the other hand, the search scope can be restricted to search only the local machine. The search scope is controlled through the DB2 profile registry variable, DB2LDAP_SEARCH_SCOPE. To set the search scope value at the global level in LDAP, use the gl option, which means "global in LDAP," on the db2set command:
db2set gl db2ldap_search_scope=<value> db2set gl db2ldap_search_scope=global
Possible values include local, domain , or global . The default value is domain , which limits the search scope to the current directory partition.
Setting the search scope in LDAP allows the setting of the default search scope for the entire enterprise. For example, you may want to initialize the search scope to global after a new database is created. This allows any client machine to search all other partitions or domains to find a database that is defined in a particular partition or domain. Once the entry has been recorded on each machine after the first connect or attach for each client, the search scope can be changed to local . Once changed to local , no client will scan any partition or domain.
The DB2 profile registry variable DB2LDAP_SEARCH_SCOPE is the only registry variable that supports setting the variable at the global level in LDAP.
Setting DB2 Registry Variables at the User Level in the LDAP Environment
Under the LDAP environment, the DB2 profile registry variables can be set at the user level, which allows a user to customize their own DB2 environment.
To set the DB2 profile registry variables at the user level, use the ul option:
db2set ul <variable>=<value>
This is not supported on UNIX and Linux platforms.
DB2 has a caching mechanism. The DB2 profile registry variables at the user level are cached on the local machine. If the ul parameter is specified, DB2 always reads from the cache for the DB2 registry variables. The cache is refreshed when:
db2set ur or to reset a registry variable: db2set r registry_variable_name
Enabling LDAP Support after Installation Is Complete
To enable LDAP support at some point following the completion of the installation process, use the following procedure on each machine:
DB2 objects are located in the LDAP baseDN. If you are using IBM SecureWay LDAP directory server Version 3.1, you do not have to configure the base DN because DB2 can dynamically obtain this information from the server. However, if you are using IBM eNetwork Directory Server Version 2.1, you must configure the LDAP baseDN on each machine by using the DB2SET command:
db2setDB2LDAP_BASEDN=<baseDN> where baseDN is the name of the LDAP suffix that is defined at the LDAP server. This LDAP suffix is used to contain DB2 objects.
Removing/Disabling LDAP Support
To disable LDAP support, use the following procedure:
If LDAP support is available at the DB2 Connect gateway and the database is not found at the gateway database directory, then DB2 will look up LDAP and attempt to keep the found information.
Security Considerations in an LDAP Environment
Before accessing information in the LDAP directory, an application or user is authenticated by the LDAP server. The authentication process is called binding to the LDAP server.
It is important to apply access control on the information stored in the LDAP directory to prevent anonymous users from adding, deleting, or modifying the information.
Access control is inherited by default and can be applied at the container level. When a new object is created, it inherits the same security attribute as the parent object. An administration tool available for the LDAP server can be used to define access control for the container object.
By default, access control is defined as follows:
The authorization check is always performed by the LDAP server and not by DB2. The LDAP authorization check is not related to DB2 authorization. An account or auth ID that has SYSADM authority may not have access to the LDAP directory. When running the LDAP commands or APIs, if the bind distinguished name (bindDN) and password are not specified, DB2 binds to the LDAP server using the default credentials, which may not have sufficient authority to perform the requested commands, and an error will be returned.
You can explicitly specify the user's bindDN and password using the USER and PASSWORD clauses for the DB2 commands or APIs.
Security Considerations for Windows 2000 Active Directory
The DB2 database and node objects are created under the computer object of the machine where the DB2 server is installed in the Active Directory. To register a database server or catalog a database in the Active Directory, you need to have sufficient access to create and/or update the objects under the computer object.
By default, objects under the computer object are readable by any authenticated users and updateable by administrators (users that belong to the Administrators, Domain Administrators, and Enterprise Administrators groups). To grant access for a specific user or a group , use the Active Directory Users and Computer Management Console as follows:
The DB2 registry variables and CLI settings at the user level are maintained in the DB2 property object under the user object. To set the DB2 registry variables or CLI settings at the user level, a user needs to have sufficient access to create objects under the User object.
By default, only administrators have access to create objects under the User object. To grant access to a user to set the DB2 registry variables or CLI settings at the user level, use the Active Directory Users and Computer Management Console as follows:
Extending the LDAP Directory Schema with DB2 Object Classes and Attributes
The LDAP Directory Schema defines object classes and attributes for the information stored in the LDAP directory entries. An object class consists of a set of mandatory and optional attributes. Every entry in the LDAP directory has an object class associated with it.
Before DB2 can store the information into LDAP, the Directory Schema for the LDAP server must include the object classes and attributes that DB2 uses. The process of adding new object classes and attributes to the base schema is called extending the Directory Schema .
If you are using IBM SecureWay LDAP Directory v3.1, all the object classes and attributes that are required by DB2 are included in the base schema. You do not have to extend the base schema with DB2 object classes and attributes.
Extending the Directory Schema for Windows 2000 Active Directory
Before DB2 can store information in the Windows 2000 Active Directory, the directory schema needs to be extended to include the new DB2 object classes and attributes. The process of adding new object classes and attributes to the directory schema is called schema extension .
You must extend the schema for Active Directory by running the DB2 Schema Installation program, db2schex , before the first installation of DB2 on any machine that is part of a Windows 2000 domain.
The db2schex program is found on the product CD-ROM. The location of this program on the CD-ROM is under the db2 directory and the common subdirectory. For example:
x:\db2\common where x: is the CD-ROM drive
The command is used as shown: db2schex .
There are other optional clauses associated with this command:
The DB2 Schema Installation program for Active Directory carries out the following tasks :
DB2 Objects in the Windows 2000 Active Directory
DB2 creates objects in the Active Directory at two locations:
Netscape LDAP Directory Support and Attribute Definitions
The supported level for Netscape LDAP Server is v4.12 or later.
Within Netscape LDAP Server Version 4.12 or later, the Netscape Directory Server allows application to extend the schema by adding attribute and object class definitions into the following two files, slapd.user_oc.conf and slapd.user_at.conf.
These two files are located in the <Netscape_install path >\slapd-<machine_name>\config directory.
If you are using iPlan Directory Server 5.0, you must review the documentation that accompanies that product for detailed instructions on how to extend the schema. After adding the DB2 schema definition, the Directory Server must be restarted for all changes to be active.