IBM Security Directory Server, Version 6.3.1

Directory server and DB2 database

To use IBM® Security Directory Server as a repository in your organization for identity and access management, you must configure a DB2® database with the directory server. A directory server stores a representation of the directory in a DB2 database.

To implement a directory representation, directory server uses database tables. You can use commands to list the database tables that are associated with a directory server. It is not necessary to access a directory server with DB2 commands, this information might be useful to database administrators.

The IBM Security Directory Server tables can be grouped into the following categories:

In the examples, the ldapdb2 DB2 database name is used. To view the table that is associated with the database, you must use the database instance owner credentials. For your environment, substitute the database instance owner and database name as per your configuration. You must switch the user context to the DB2 instance owner to run the commands. For example, to log in with the ldapdb2 DB2 instance owner credentials, run the following command:

On AIX®, Linux, and Solaris systems
su - ldapdb2
On Windows systems
db2cmd
set DB2INSTANCE=ldapdb2

To connect to the database, run the following command:

db2 connect to ldapdb2
LDAP entry table
The LDAP entry category consists of a single table, the LDAP_ENTRY table.
The LDAP_ENTRY table contains the LDIF definition of each LDAP entry. One of the columns in the table is the EID (Entry ID) column. All other tables of the database use the EID column to identify the LDAP entry that is referenced from the LDAP_ENTRY table. Directory server uses the LDAP_ENTRY table in the following ways:
  • To retrieve the requested attribute values for a ldapsearch command.
  • To evaluate the one level scope on a ldapsearch command.
The one level scope is evaluated by using the EID (Parent EID ) column of the LDAP_ENTRY table. To include indexes on the distinguished name (DN), the LDAP_ENTRY table includes a DN_TRUNC column and a full non-searchable DN column.
To describe the LDAP_ENTRY table, run the db2 describe command. The show detail parameters are optional.
db2 describe table ldap_entry show detail
To find the EID of a particular DN, run the following command. The dn_trunc value must be in uppercase.
db2 "select eid from ldap_entry where dn_trunc = 'CN=USER1,O=SAMPLE'"
To find the DN entry name of a particular EID, run the following command:
db2 "select dn_trunc from ldap_entry where eid = 100"
To find the LDIF definition of a particular DN, run the following command:
db2 "select ENTRYDATA from dap_entry where dn_trunc = 'CN=USER1,O=SAMPLE'"
To find the DN entries for the first 10 rows in the LDAP_ENTRY table, run the following command:
db2 "select dn_trunc from ldap_entry fetch first 10 rows only"
To find the DN entries for the next 10 rows in the LDAP_ENTRY table, run the following command:
db2 "select dn_trunc from ldap_entry where eid > 10 fetch first 10 rows only"
To find all LDAP suffixes, run the following command:
db2 "select dn_trunc from ldap_entry where peid = -1"
To find the DN entries of all the immediate child entries (one level search) of the LDAP entry with DN O=SAMPLE, run the following command:
db2 "select dn_trunc from ldap_entry where peid in \
(select eid from ldap_entry where dn_trunc = 'O=SAMPLE')"
Subtree tables
The subtree category consists of the LDAP_DESC table and the LDAP_GRP_DESC table. You can evaluate the subtree scope on a ldapsearch command with the LDAP_DESC table. This table contains a list of parent and child LDAP entry relationships in two columns:
  • A Descendant EID or DEID column
  • An Ancestor EID or AEID column
For each LDAP entry, there is a full list of parents for that LDAP entry in the LDAP_DESC table. Parent in this case includes immediate parent and all ancestors. For example, the following command lists all the parents or ancestors of EID 100:
db2 "select * from ldap_desc where deid = 100"
An example output that the command generates:
DEID   AEID
------ -------
100     11
100     17
100     23
100     24
100    100
The output indicates that the EID is four levels deep in the directory information tree.
To find all the parent entries of an entry with the EID value 100, run the following command:
db2 "select dn_trunc from ldap_entry where eid = 100"
DN_TRUNC
---------------------
CN=TESTUSER1,CN=USERS,OU=HRGROUP,OU=MYCITY,O=SAMPLE
The parent entries along with the entry that match the filter is generated.
CN=TESTUSER1,CN=USERS,OU=HRGROUP,OU=MYCITY,O=SAMPLE
CN=USERS,OU=HRGROUP,OU=MYCITY,O=SAMPLE
OU=HRGROUP,OU=MYCITY,O=SAMPLE
OU=MYCITY,O=SAMPLE
O=SAMPLE
You can join DB2 tables in a single command to list all the parents of an LDAP entry with the CN=TESTUSER1,CN=USERS,OU=HRGROUP,OU=MYCITY,O=SAMPLE DN. For example:
db2 "select * from ldap_desc where aeid in \
(select eid from ldap_entry where dn_trunc = \
'CN=TESTUSER1,CN=USERS,OU=HRGROUP,OU=MYCITY,O=SAMPLE')"
The LDAP_DESC table is also used in subtree searches. To find all the child LDAP entries (both immediate and all descendants) for the CN=USERS,O=SAMPLE LDAP entry, run the following command:
db2 "select * from ldap_desc where aeid in \
(select eid from ldap_entry where dn_trunc = \
'CN=USERS,O=SAMPLE')"
An example output:
DEID      AEID
-------- -----------
     12    12
2000042    12
2000043    12
2000044    12
2000056    12
2000057    12
2000058    12
You can use the LDAP_GRP_DESC table to track nested group relationships.
Attribute tables
The attribute tables consist of one table per attribute that is used in the directory server. The purpose of the attribute tables is to improve the performance of the LDAP searches with the search filters, particularly when the attribute is indexed. The attribute tables are named by the attributes they represent. For example, the DB2 table for the cn attribute is named cn.
To describe the cn table, run the following command:
db2 describe table cn
The example output of the command is as follows:
Column name    Data type   Data type   Column  Scale  Nulls
               schema      name        Length  
-------------- ---------- 	------------ ------- ----- ------
EID            SYSIBM      INTEGER          4      0    No
CN             SYSIBM      VARCHAR        256      0    No
CN_T           SYSIBM      VARCHAR        240      0    No
RCN_T          SYSIBM      VARCHAR        240      0    No 
 4 record(s) selected.
The CN column contains the full name for the attribute. The values in column, Column name, with names that end with T are truncated to 240 character attribute name that is used for searching. The column name beginning with R is the attribute name in reverse. This column is used for searching for attributes that are specified with a trailing wildcard.
ACL tables
The ACL tables consist of the SRC, ACLPROP, OWNPROP, ENTRYOWNER, ACLPERM, and ACLINHERIT tables. The SRC table identifies from which LDAP entry a particular LDAP entry obtains the source for or inherits its ACL and owner information. The SRC table is also the attribute table for the aclsource and entryowner attributes.
To describe the src table, run the following command:
db2 describe table src
The example output of the command is as follows:
Column name          Data type Data type name      Column     Scale Nulls
                     schema                        Length     
-------------------- --------- ------------------- ---------- ----- ------
EID                  SYSIBM     INTEGER                   4      0    Yes
ACLSRC               SYSIBM     INTEGER                   4      0    Yes
OWNSRC               SYSIBM     INTEGER                   4      0    Yes
ACLTYPE              SYSIBM     INTEGER                   4      0    Yes

4 record(s) selected.
The ACLPROP and OWNPROP are the attribute tables for the aclpropagate and ownerpropagate attributes. The ACLPERM table is the attribute table for the aclentry attribute. The ACLINHERIT table is the attribute table for the ibm-filterAclEntry attribute.
Replication tables
The replication tables consist of the REPLSTATUS, REPLCHGnnnn, REPLERROR, and several other tables. There is one REPLCHGnnnn table for each replication context. Where, nnnn is EID of the base entry of the replication context. The REPLCHGnnnn implements the replication change table.
The REPLSTATUS table is a pointer to the REPLCHGnnnn table that indicates the last replicated operation.


Feedback