Distributed directories
A distributed directory is directory environment in which data is partitioned across multiple directory servers. To make the distributed directory appear as a single directory to client applications, one or more proxy servers are provided which have knowledge of all the servers and the data they hold.
Proxy servers distribute incoming requests to the proper servers and gather the results to return a unified response to the client. A set of backend servers hold their portions of the distributed directory. These backend servers are basically standard LDAP servers with additional support for the proxy server to issue requests on behalf of user that might be defined in a different server, or belong to groups that are defined on different servers.
The IBM® Tivoli® Directory Server v6.0 and later (distributed platforms) provides such a distributed directory with proxy servers, backend servers, and tools for setting up such a directory. Such a directory is capable of scaling up to several millions of entries.
IBM Directory Server for IBM i Support for Distributed Directories
The IBM Directory Server for IBM i is capable of acting as backend server within an IBM Tivoli Directory Server distributed directory. The IBM i directory server cannot act as the proxy server, nor does it include the tools required to set up a distributed directory. A proxy server could then run on another platform while the actual data resides on one or more IBM i directory servers or a mixture of IBM i and Tivoli-platform directory servers.
In order to partition existing directory data from an IBM i directory server to be used in the distributed directory topology, the data needs to be exported into an LDIF file from the IBM i directory, the distributed directory setup tool provided by Tivoli on Tivoli platforms needs to be executed using the LDIF file, and the data needs to be reloaded on the IBM i and Tivoli directory servers that are participating as backend servers for the distributed directory. This processing is no different for IBM i servers or Tivoli platform servers and the users already have the distributed directory setup tool because they own the proxy server on a Tivoli platform.
Controls and Extended Operations to Support Distributed Directories
Since users and the groups to which they belong can be distributed across multiple servers, the IBM Tivoli Directory Server has defined a set of controls and extended operations to support group membership and access control in a distributed directory, A mechanism for providing an "audit trail" back to the originating client is also provided.
Audit Control
The Audit Control is the mechanism that the proxy server uses to send the unique identifier of the client request initiated by the proxy server to the backend servers. In addition to a unique identifier, the originating client IP is also sent along in the Audit Control. This unique identifier is what is used to match up audit entries on the proxy server with audit entries on the backend servers. If a request is passed through multiple servers, the IP information for each server is appended, providing a trail through each server back to the original client.
Group Membership Evaluation Extended Operation
This extended operation allows an authorized client (the proxy server), to send information about a user to a backend server and request a list of the groups (static, nested, or dynamic) that the user is a member of on the backend server.
Group Membership Control
This control allows an authorized client (the proxy server) to send a list of groups to be used for access control. Access control is evaluated using this list of groups rather than the list of groups the server would normally determine, which is based on group information stored local to the server. In typical use, this list of groups is the list of groups that the proxy server gathers from each of the backend servers by using the Group Membership Evaluation extended operation.
Auditing support for distributed directories
- Audit Control: Following a request back to the originating client is useful. IBM i audits the "audit control" by adding a “routing” field to the existing DI security auditing journal entry. While the contents are not verifiable, they come from a client that is authorized to use proxy authorization and thus should be a trusted client.
- Group membership control: The presence of the group control is audited in two parts: A single character “group membership assertion” field has been added to the DI security auditing journal entry. The server can also be configured to optionally audit the list of groups provided by the client. When this option is configured, the server also audits a "XD cross reference" field in the DI journal entry, and creates one or more XD security auditing journal entries with a matching "XD cross reference" field and the list of groups (up to 5 groups per journal entry)
Refer to the Security reference topic in the related links below for more details on IBM i Security Auditing. You can also refer the The Internet Engineering Task Force Web site and search for rfc4648 to learn more about configuring auditing for the directory server.
For more information about distributed directories and setting up distributed directories, refer the Distributed Directories topic in the Tivoli Software Information Center.