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. It also provides the client and servers with access to
these resources. Each database server provides 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.
Because of this, each client does not have to store catalog information locally
on each machine. Client applications search the LDAP directory for information
required to connect to the database. After information is retrieved from the
LDAP directory server, it is stored or cached on the local computer based on the
dir_cache database manager configuration parameter and the
DB2LDAPCACHE registry variable. The
dir_chache database manager configuration parameter is used to store database, node, and DCS
directory files in memory cache. The directory cache is used by an application
until the application closes. The
DB2LDAPCACHE registry variable is used to
store database, node, and DCS directory files in a local disk cache.
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 by default, grants read access to everyone for database and node entries in LDAP. Read and write access is only granted to the directory administrator and the owner or creator of the object for database and node entries, as well as user profiles. A user cannot access the profile of another user if that user does not have directory administrator access.
DB2 supports IBM LDAP client on AIX, Solaris, HP-UX 11.11, Windows, and Linux. The table below shows the LDAP client and server configurations supported by DB2.
Table 5. Supported LDAP client and server configurations
|Supported LDAP client and server configurations||IBM Tivoli® Directory server||Microsoft® Active Directory server||Sun One LDAP server|
|IBM LDAP Client||Supported||Supported||Supported|
|Microsoft LDAP/ADSI Client||Supported||Supported||Supported|
|Adapted from Table 1, found under Supported LDAP client and server configurations in the IBM DB2 10.1 Information Center for Linux, UNIX, and Windows (http://pic.dhe.ibm.com/infocenter/db2luw/v10r1/topic/com.ibm.db2.luw.admin.dbobj.doc/doc/r0006009.html)|
DB2 server instances must be registered in LDAP to publish the protocol
configuration information used by the client applications to connect to
the DB2 server instance. You must specify a node name when registering an
instance of the database server. The node name is used by client applications
when they connect or attach to the server. You can catalog another alias
for the LDAP node by using the
CATALOG LDAP NODE command.
REGISTER command is shown below for registering a server:
db2 register db2 server in ldap as ldap_node_name protocol tcpip
The protocol clause refers to the communication protocol to use when connecting to this database server. The ldap_node_name must be unique in LDAP for each computer.
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
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
When registering a remote DB2 server in LDAP, if TCP/IP is configured, the computer name must be the same as the TCP/IP hostname.
During the creation of a database within an instance, the database is automatically registered in LDAP. Registration allows remote client connection to the database without having to catalog the database and node on the client computer. When a client attempts to connect to a database, if the database does not exist in the database directory on the local computer, the LDAP directory is searched.
If the name exists in the LDAP directory, the database is still created on the
local computer, 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
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
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 "My LDAP database"
To register a database in LDAP from a client application, call the db2LdapCatalogDatabase API.
When using the IBM Tivoli directory, defining an LDAP user before you can store user-level information in LDAP is a requirement. You can create an LDAP user by creating an LDIF file to contain all attributes for the user object, then run the LDIF import utility to import the object into the LDAP directory. The LDIF utility for the IBM Tivoli Directory Server is LDIF2DB.
Here is an example of the LDIF command to import an LDIF file using the IBM LDIF
LDIF2DB -i newuser.ldif .
When you use the Microsoft LDAP client, the LDAP user is the same as the operating system user account. However, when you use the IBM LDAP client, before you use the DB2 database manager, you must configure the LDAP user distinguished name (DN) and password for the current logged-on user.
To configure the LDAP user distinguished name (DN) and password, use the db2ldcfg utility:
db2ldcfg -u userDN -w password --> set the user's DN and password -r --> clear the user's DN and password