Advanced DBA Certification Guide and Reference for DB2 Universal Database v8 for Linux, UNIX, and Windows

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

NOTE

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:

• IBM SecureWay Directory Version 3.1 is an LDAP Version 3 server available for Windows NT, AIX, and Solaris.

  Table 4.7. Supported LDAP Environments

  LDAP-Supported Client	IBM SecureWay Directory	Microsoft Active Directory	Netscape LDAP Server
  IBM LDAP Client	Supported	Not Supported	Supported
  Microsoft LDAP/ADSI Client	Supported	Supported	Supported

• IBM SecureWay Directory is shipped as part of the base operating system on AIX and iSeries (AS/400), and with OS/390 Security Server.

• DB2 supports IBM LDAP client on AIX, Solaris, Windows NT, Windows 98, and Windows 2000.

• Microsoft Active Directory is an LDAP Version 3 server and is available as part of the Windows 2000 Server operating system.

• The Microsoft LDAP Client is included with the Windows operating system.

NOTE

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."

db2set DB2LDAP_CLIENT_PROVIDER=IBM

Support for Windows Active Directory

DB2 exploits the Active Directory as follows :

1. The DB2 database servers are published in the Active Directory as the ibm_db2Node objects. The ibm_db2Node object class is a subclass of the ServiceConnectionPoint (SCP) object class. Each ibm_db2Node object contains protocol configuration information to allow client applications to connect to the DB2 database server. When a new database is created, the database is published in the Active Directory as the ibm_db2Database object under the ibm_db2Node object.

2. When connecting to a remote database, DB2 client queries the Active Directory, via the LDAP interface, for the ibm_db2Database object. The protocol communication to connect to the database server (binding information) is obtained from the ibm_db2Node object, under which the ibm_db2Database object is created.

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:

regsvr32 %DB2PATH%\bin\db2ads.dll

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

NOTE

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:

1. The machine that runs DB2 must belong to a Windows 2000 domain.

2. The Microsoft LDAP client is installed. Microsoft LDAP client is part of the Windows 2000 operating system. For Windows 98, or Windows NT, you need to verify that the wldap32.dll exists under the system directory.

3. Enable the LDAP support. For Windows 2000, the LDAP support is enabled by the installation program. For Windows 98/NT, you must explicitly enable LDAP by setting the DB2_ENABLE_LDAP registry variable to YES, using the db2set command.

   db2set DB2_ENABLE_LDAP=YES

4. Log on to a domain user account when running DB2 to read information from the Active Directory.

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:

1. Enable the LDAP support. For Windows 2000, the LDAP support is enabled by the installation program. For Windows 98/NT, you must explicitly enable LDAP by setting the DB2_ENABLE_LDAP registry variable to YES, using the db2set command.

   db2set DB2_ENABLE_LDAP=YES

2. The LDAP server's TCP/IP host name and port number. These values can be entered during unattended installation using the DB2LDAPHOST response keyword, or you can manually set them later by using the db2set command:

   db2set DB2LDAPHOST=<hostname[:port]> where hostname is the LDAP server's TCP/IP hostname and [:port] is the port number. If it is not specified, DB2 will use the default LDAP port (389). db2set DB2LDAPHOST=newschemadirectory.service.dntteam.com:389

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

3. The LDAP user's distinguished name and password. These are required only if you plan to use LDAP to store DB2 user-specific information.

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:

• Create 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 LDAP server is LDIF2DB.

• Use the Directory Management Tool (DMT), available only for the IBM SecureWay LDAP Directory Server Version 3.1, to create the user object.

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

NOTE

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

For example:

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.

NOTE

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.

NOTE

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:

• If TCP/IP is configured, the computer name must be the same as the TCP/IP hostname.

• If APPN is configured, use the partner-LU name as 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:

• A TCP/IP hostname and service name or port number parameters.

• A NetBIOS workstation name.

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:

CLIENT

Specifies that authentication takes place on the node from which the application is invoked.

SERVER

Specifies that authentication takes place on the node containing the target database.

SERVER_ENCRYPT

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.

DCS_ENCRYPT

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.

DCS

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).

KERBEROS

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.

NOTE

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 is dropped.

• The owning instance is deregistered from LDAP.

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:

• Schedule a refresh that is run periodically.

• Run the REFRESH command during system bootup .

• Use an available administration package to invoke the REFRESH command on all client machines.

• Set DB2LDAPCACHE=NO to avoid LDAP information being cached in the database, node, and DCS directories.

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.

NOTE

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>

NOTE

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:

• You update or reset a DB2 registry variable at the user level.

• The command to refresh the LDAP profile variables at the user level is:

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:

• Install the LDAP support binary files. Run the setup program and select the LDAP Directory Exploitation support from Custom install. The setup program installs the binary files and sets the DB2 profile registry variable DB2_ENABLE_LDAP to YES.

  NOTE

  For Windows 98/NT and UNIX platforms, you must explicitly enable LDAP by setting the DB2_ENABLE_LDAP registry variable to YES, using the db2set command.

• On UNIX platforms only, declare the LDAP server's TCP/IP hostname and (optional) port number using the following command:

  db2set DB2LDAPHOST=<base_domain_name>[:port_number] where base_domain_name is the LDAP server's TCP/IP hostname, and [:port_number] is the port number. The default LDAP port is 389.

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.

• Register the current instance of the DB2 server in LDAP by using the REGISTER LDAP AS command. For example:

  db2 register ldap as <node-name> protocol tcpip

• Run the CATALOG LDAP DATABASE command if you have databases you would like to register in LDAP. For example:

  db2 catalog ldap database <dbname> as <alias_dbname>

• Enter the LDAP user's distinguished name and password. These are required only if you plan to use LDAP to store DB2 user-specific information.

Removing/Disabling LDAP Support

To disable LDAP support, use the following procedure:

• For each instance of the DB2 server, deregister the DB2 server from LDAP:

  db2 deregister db2 server in ldap node <nodename> db2 deregister db2 server in ldap node SANDIEGO

• Set the DB2 profile registry variable DB2_ENABLE_LDAP to NO.

  db2set DB2_ENABLE_LDAP=NO

NOTE

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:

• For database and node entries in LDAP, everyone (or any anonymous user) has read access. Only the Directory Administrator and the owner or creator of the object has read/write access.

• For user profiles, the profile owner and the Directory Administrator have read/write access. One user cannot access the profile of another user if that user does not have Directory Administrator authority.

NOTE

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:

1. Start the Active Directory Users and Computer administration tool. Use Start, Program, Administration Tools, Active Directory Users and Computer.

2. Under View, select Advanced Features.

3. Select the Computers container.

4. Right-click on the computer object that represents the server machine where DB2 is installed and select Properties.

5. Select the Security tab, then add the required access to the specified user or group.

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:

1. Start the Active Directory Users and Computer administration tool. Use Start, Program, Administration Tools, Active Directory Users and Computer.

2. Select the user object under the Users container.

3. Right-click on the user object and select Properties.

4. Select the Security tab.

5. Add the user name to the list by using the Add button.

6. Grant access to Write and Create All Child Objects.

7. Using the Advanced setting, set permissions to apply onto This object and all child objects.

8. Select the check box Allow inheritable permissions from parent to propagate to this object.

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 .

NOTE

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:

• To specify the user distinguished name : b UserDN

• To specify the bind password : w Password

• To uninstall the schema : u

• To force uninstall to continue, ignoring errors : k

NOTE

1. If no user distinguished name and password are specified, db2schex binds as the currently logged user.

2. The user distinguished name clause can be specified as a Windows NT username.

3. To update the schema, you must be a member of the Schema Administrators group or have been delegated the rights to update the schema.

The DB2 Schema Installation program for Active Directory carries out the following tasks :

• Detects which server is the Schema Master.

• Binds to the Domain Controller that is the Schema Master.

• Ensures that the user has sufficient rights to add classes and attributes to the schema.

• Ensures that the schema master is writeable (that is, the safety interlock in the registry is removed).

• Creates all the new attributes.

• Creates all the new object classes.

• Detects errors, and if they occur, the program will roll back any changes to the schema.

DB2 Objects in the Windows 2000 Active Directory

DB2 creates objects in the Active Directory at two locations:

1. The DB2 database and node objects are created under the computer object of the machine where the DB2 Server is installed. For the DB2 server machine that does not belong to the Windows NT domain, the DB2 database and node objects are created under the System container.

2. The DB2 registry variables and CLI settings at the user level are stored in the DB2 property objects under the User object. These objects contain information that is specific to that user.

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.

NOTE

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.