This chapter provides an overview of IBM Tivoli Directory Server (ITDS) and provides a roadmap to the rest of the book, which focuses primarily on the installation, configuration, and operation of TDS.

The IBM Tivoli Directory Server implements the Internet Engineering Task Force (IETF) LDAP V3 specifications. It also includes enhancements added by IBM in functional and performance areas. This version uses IBM DB2 Universal Database as the backing store to provide per-LDAP operation transaction integrity, high performance operations, and online backup and restore capability. The IBM Tivoli Directory Server interoperates with the IETF LDAP V3 based clients.

Figure 4-1 provides a high-level overview of what the various components of ITDS are and how clients might interact with it.

The base components of IBM Tivoli Directory Server are:

The major features of ITDS include:

IBM Tivoli Directory Server is a powerful, security-rich and standards-compliant enterprise directory for corporate intranets and the Internet. Directory Server is built to serve as the identity data foundation for rapid development and deployment of your Web applications and security and identity management initiatives by including strong management, replication and security features.

With IBM Tivoli Directory Server you can choose your authentication strategy, you can use simple user ID and password authentication, or you can implement the more secure digital certificate-based authentication structure. IBM Tivoli Directory Server also includes a Simple Authentication Security Layer (SASL) plug-in interface, including Challenge-Response Authentication Mechanism MD5 (CRAM-MD5) and Kerberos authentication if required.

The fine grained access control features in IBM Tivoli Directory Server extend to the attribute level, enabling self service and delegated administration while also offering protection of access control list (ACL) values within the directory, preventing unauthorized users from changing the security assigned to objects within the directory.

Development and deployment of your enterprise directory with IBM Tivoli Directory Server is enhanced through the inclusion of the IBM default schema, a flexible server plug-in framework and the client SDK which includes support for 64-bit AIX and Java TM access via a standard J2EE interface.

IBM Tivoli Directory Server is a component of the IBM Tivoli Identity Manager solution that can help you get users, systems and applications online and productive fast, reduce costs and maximize return on investment. IBM Tivoli Identity Manager provides identity lifecycle management (user self-care, enrollment and provisioning), identity control (access and privacy control, single sign-on and auditing), identity federation (sharing user authentication and attribute information between trusted Web services applications) and identity foundation (directory and workflow) to effectively manage internal users as well increase number of customers and partners through the Internet.

ITDS, released in October 2003, introduced a number of new features well as enhancements to existing capabilities. These features and enhancements include:

IBM Tivoli Directory Server supports the Microsoft Windows Server 2003 operating system, Standard and Enterprise editions.

In previous versions, both Secure Sockets Layer (SSL) and non-SSL packages were provided on all operating system platforms. For IBM Tivoli Directory Server Version 5.2, non-SSL packages are provided only on AIX.

IBM Tivoli Directory Server has been ported to 64-bit architecture on AIX only. Solaris, HP-UX, Linux zSeries, Linux Intel, Linux iSeries and pSeries®, and Microsoft Windows remain 32-bit servers. The Web Administration Tool remains a 32-bit application. The 32-bit server will no longer be available on AIX; however, the client SDK will still be available as a 32-bit application. The 64-bit architecture increases the ability to cache a large number of directory entries.

Note that AIX Version 5.1 or later is required for the 64-bit AIX Server.

To move up to 64-bit server support, you must migrate your database. However, you do not need to unload and reload your data. See the chapter on “Migration from previous releases” located in Installation and Configuration Guide, SC32-1338.

IBM Tivoli Directory Server 5.2 provides support for DIGEST-MD5 Simple Authentication and Security Layer (SASL) authentication, as well as Transport Layer Security (TLS) support as defined in RFC 2829.

TLS allows clients to connect to the server on a non-secure port and issue a TLS start command. If GSKit is installed, the server honors the request and begins a secure connection with the client. RFC 2830 specifies how LDAP should support TLS.

RFC 2831 defines how HTTP Digest Authentication (Digest) can be used as an SASL mechanism for any protocol that has an SASL profile. (RFC 2222 defines SASL.) DIGEST-MD5 is intended to be both an improvement over CRAM-MD5 and a convenient way to support a single authentication mechanism for Web, mail, LDAP, and other protocols.

RFC 2596 defines a mechanism that allows the directory to associate natural language codes with values that meet certain natural language requirements. IBM Tivoli Directory Server 5.2 supports a single language code option and language tag support discovery.

A subtree can now be searched from a null base. This provides a shorthand way to retrieve all entries in the directory. In earlier releases, multiple searches were required for each suffix to search the entire directory.

IBM Tivoli Directory Server 5.2 allows the administrator to identify attributes that must have unique values. This ensures that there are not two directory entries with the same attribute values. For example, no two users can have the same user ID or e-mail address if these attributes have been configured to enforce uniqueness.

In previous releases, IBM Tivoli Directory Server required that the administrator user ID be used to perform server tasks such as replication configuration and starting and stopping the server. For the 5.2 release, there is an administration group that contains IDs of users with administrative rights and privileges. This avoids the use of a single administration ID shared by a number of administrators. The root administrator can add or remove members from the administration group.

For the 5.2 release, support has been added to reduce the vulnerability of the server to malicious attacks, causing a denial of service. The server can be configured to reject non-responsive clients after some number of attempts. Support has also been added to close connections issued by a specific IP address or DN. An emergency thread is available when some number of items, configurable on the server, are on the work queue. This provides a method for the administrator to access the server during a denial of service attack. The oldest connections can, through configurable parameters, be reused first.

This security enhancement allows an administrator to force a specific bound DN or IP address to unbind. The emergency thread added in the denial of service prevention feature enhances this feature by ensuring that an administrator always has access to unbind bound DNs and IP addresses.

You can now configure "extended" search limits for a defined group of people who are not the administrator or part of the administration group.

The operational attributes creatorsName, createTimestamp, lastModifiedBy, and lastModifiedTime are now preserved so that they are consistent between a master and its replicas. In addition, these attributes are now imported by the ldif2db and bulkload utilities and exported by the db2ldif utility.

The attribute cache improves search performance for certain search filters by allowing configured attributes and their values to be stored in memory. When a search is performed using a filter that contains all cached attributes and the filter is of a type supported by the attribute cache manager, the filter can be resolved in memory; this leads to improved search performance.

The following new features improve the serviceability of IBM Tivoli Directory Server:

The actual input and output from the server can now be logged to allow better analysis of problems. In previous releases, the LDAP client library output the BER data to stderr or a file. The new feature adds the capability to record the same formatted BER data one time to the in-memory trace. The trace facility can then be used to extract this data.

Trace information from the server can now be captured without stopping and restarting the server. The level of tracing and the size available for trace output can also be configured dynamically.

More information has been added to the output of cn=monitor to be used in analyzing server performance. These attributes are intended for directory administrators only. The new information includes counts of completed operations by type (for example, BIND, MODIFY, COMPARE, SEARCH), depth of the work queue, number of available workers, counts of messages added to the server log, audit log, command-line interface errors, and counts of SSL connections. Information is also included about what worker threads are doing and when they started.

Support for the new iSeries and pSeries Linux platforms was added in the IBM Tivoli Directory Server 5.1 FixPak 1. IBM Tivoli Directory Server 5.2 adds more support for iSeries and pSeries. The Web Administration Tool can now be used on these platforms, and translated messages have been added.

Support has been added for specification and evaluation of ACLs for the system and restricted attribute classes. This resolves the following interoperability problems between IBM Tivoli Directory Server and OS/390 versions of the LDAP Server.

In previous releases, during replication the IBM Tivoli Directory Server server rejected any directory entry data that contained ACL specifications with references to system or restricted attribute classes. Replication from an OS/390 server provider to an IBM Tivoli Directory Server server consumer therefore failed.

In previous releases, ACL management code could not be written that would run correctly on both types of servers. A client application written for an IBM Tivoli Directory Server environment might not work properly on an OS/390 server because the ACLs might not allow the application to read system attributes. Conversely, a client application developed for an OS/390 server environment would fail to work properly on an IBM Tivoli Directory Server server if the application attempted to set ACLs on system or restricted attributes.

This feature replaces the limited restricted attribute class ACL support, originally provided by IBM Tivoli Directory Server 5.1 Protection of Access Control Information feature (ibm-slapdACLAccess), with full directory-specific ACL support. The behavior of this feature is consistent with the existing ACL support provided for the other attribute access classes: Normal, sensitive, and critical.

To maintain consistency with the legacy IBM Tivoli Directory Server ACL model, existing version 5.1 directories that contain entries with explicit ACL specification will be automatically migrated to provide legacy default read, search, and compare access for the subject DN group:cn=anybody, as well as any specific access IDs. This is to prevent an unexpected loss of default access after migration. If denial of access is required, it should be explicitly specified in the directory, based on the specific needs and desires of the individual IBM Tivoli Directory Server administrator.

Support has been added for identity assertions, also known as LDAP Proxied Authorization Control. The Proxied Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of as the current authorization identity associated with the connection.

In previous releases, the Java Naming and Directory Interface (JNDI) had dereferencing aliases by default. This sometimes caused performance degradation on the server even if no alias entries existed in the server. A server configuration option has been added to override the dereference option specified in the client search request. Additionally, if no alias objects exist in the directory, the server always bypasses the dereference logic.

Gateway replication uses Gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of Gateway replication is the reduction of network traffic.

Enhancements have been made to the Web Administration Tool, including the following:

There are several resources available publicly on the Web to find out more information about ITDS. The best place to start is the IBM Tivoli homepage for ITDS at:

From here you can download the product and the most recent Fix Packs and patches, access technical documentation, review recent issues (APARs) that have been resolved, and see published Technotes.

An excellent place for getting questions answered about ITDS is the ITDS NNTP group on IBM’s public NNTP service. This group, can be found here:

The rest of the chapters in this book go into particular aspects of ITDS installation, configuration, and management. The topics include: