3.3. Creating and Maintaining Database Links

Chaining means that a server contacts other servers on behalf of a client application and then returns the combined results. Chaining is implemented through a database link, which points to data stored remotely. When a client application requests data from a database link, the database link retrieves the data from the remote database and returns it to the client.
Section 13.5, “Monitoring Database Link Activity” covers how to monitor database link activity.

3.3.1. Configuring the Chaining Policy

These procedures describe configuring how Directory Server chains requests made by client applications to Directory Servers that contain database links. This chaining policy applies to all database links created on Directory Server.

3.3.1.1. Chaining Component Operations

A component is any functional unit in the server that uses internal operations. For example, plug-ins are considered to be components, as are functions in the front-end. However, a plug-in may actually be comprised of multiple components (for example, the ACI plug-in).
Some components send internal LDAP requests to the server, expecting to access local data only. For such components, control the chaining policy so that the components can complete their operations successfully. One example is the certificate verification function. Chaining the LDAP request made by the function to check certificates implies that the remote server is trusted. If the remote server is not trusted, then there is a security problem.
By default, all internal operations are not chained and no components are allowed to chain, although this can be overridden.
Additionally, an ACI must be created on the remote server to allow the specified plug-in to perform its operations on the remote server. The ACI must exist in the suffix assigned to the database link.
The following table lists component names, the potential side-effects of allowing them to chain internal operations, and the permissions they need in the ACI on the remote server:

Table 3.2. Components Allowed to Chain

Component Name Description Permissions
ACI plug-in This plug-in implements access control. Operations used to retrieve and update ACI attributes are not chained because it is not safe to mix local and remote ACI attributes. However, requests used to retrieve user entries may be chained by setting the chaining components attribute, nsActiveChainingComponents: cn=ACI Plugin,cn=plugins,cn=config. Read, search, and compare
Resource limit component This component sets server limits depending on the user bind DN. Resource limits can be applied on remote users if the resource limitation component is allowed to chain. To chain resource limit component operations, add the chaining component attribute, nsActiveChainingComponents: cn=resource limits,cn=components,cn=config. Read, search, and compare
Certificate-based authentication checking component This component is used when the SASL-external bind method is used. It retrieves the user certificate from the database on the remote server. Allowing this component to chain means certificate-based authentication can work with a database link. To chain this component's operations, add the chaining component attribute, nsActiveChainingComponents: cn=certificate-based authentication,cn=components,cn=config. Read, search, and compare
Referential Integrity plug-in This plug-in ensures that updates made to attributes containing DNs are propagated to all entries that contain pointers to the attribute. For example, when an entry that is a member of a group is deleted, the entry is automatically removed from the group. Using this plug-in with chaining helps simplify the management of static groups when the group members are remote to the static group definition. To chain this component's operations, add the chaining component attribute, nsActiveChainingComponents: cn=referential integrity postoperation,cn=plugins,cn=config. Read, write, search, and compare
Attribute Uniqueness plug-in This plug-in checks that all the values for a specified uid attribute are unique (no duplicates). If this plug-in is chained, it confirms that the uid attribute values are unique even on attributes changed through a database link. To chain this component's operations, add the chaining component attribute, nsActiveChainingComponents: cn=attribute uniqueness,cn=plugins,cn=config Read, search, and compare

NOTE

The following components cannot be chained:
  • Roles plug-in
  • Password policy component
  • Replication plug-ins
  • Referential Integrity plug-in
When enabling the Referential Integrity plug-in on servers issuing chaining requests, be sure to analyze performance, resource, and time needs as well as integrity needs. Integrity checks can be time-consuming and draining on memory and CPU. For further information on the limitations surrounding ACIs and chaining, see Section 6.1.4, “ACI Limitations”.
After modifying the components allowed to chain, restart the server in order for the modification to take effect.
3.3.1.1.1. Chaining Component Operations Using the Console
  1. In the Directory Server Console, select the Configuration tab.
  2. Expand Data in the left pane, and click Database Link Settings.
  3. Select the Settings tab in the right window. To add a component to the Components allowed to chain list, click Add.
    The Select Components to Add dialog box displays. Select a component from the list, and click OK.
  4. To delete a component from the list, select it, and click Delete.
  5. Click Save.
  6. Restart the server in order for the change to take effect.
After allowing the component to chain, create an ACI in the suffix on the remote server to which the operation will be chained. For example, this creates an ACI for the Referential Integrity plug-in:
aci: (targetattr "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com") 
     (version 3.0; acl "RefInt Access for chaining"; allow 
     (read,write,search,compare) userdn = "ldap:///cn=referential integrity 
     postoperation,cn=plugins,cn=config";)
3.3.1.1.2. Chaining Component Operations from the Command Line
  1. Specify components to include in chaining using the nsActiveChainingComponents attribute in the cn=config,cn=chaining database,cn=plugins,cn=config entry of the configuration file.
    For example, to allow the referential integrity component to chain operations, add the following to the database link configuration file:
    nsActiveChainingComponents: cn=referential integrity postoperation,cn=components,cn=config
    See Table 3.2, “Components Allowed to Chain” for a list of the components which can be chained.
  2. Restart the server for the change to take effect. [3]
    service dirsrv restart instance
  3. Create an ACI in the suffix on the remote server to which the operation will be chained. For example, this creates an ACI for the Referential Integrity plug-in:
    aci: (targetattr "*")(target="ldap:///ou=customers,l=us,dc=example,dc=com") 
         (version 3.0; acl "RefInt Access for chaining"; allow 
         (read,write,search,compare) userdn = "ldap:///cn=referential 
         integrity postoperation,cn=plugins,cn=config";)

3.3.1.2. Chaining LDAP Controls

It is possible to not chain operation requests made by LDAP controls. By default, requests made by the following controls are forwarded to the remote server by the database link:
  • Virtual List View (VLV). This control provides lists of parts of entries rather than returning all entry information.
  • Server-side sorting. This control sorts entries according to their attribute values.
  • Managed DSA. This controls returns smart referrals as entries, rather than following the referral, so the smart referral itself can be changed or deleted.
  • Loop detection. This control keeps track of the number of times the server chains with another server. When the count reaches the configured number, a loop is detected, and the client application is notified. For more information about using this control, see Section 3.3.7.5, “Detecting Loops”.

NOTE

Server-side sorting and VLV controls are supported only when a client application request is made to a single database. Database links cannot support these controls when a client application makes a request to multiple databases.
3.3.1.2.1. Chaining LDAP Controls Using the Console
  1. In the Directory Server Console, select the Configuration tab.
  2. Expand the Data folder in the left pane, and click Database Link Settings.
  3. Select the Settings tab in the right window. To add an LDAP control to the list, click Add.
    The Select control OIDs to add dialog box displays. Select the OID of a control to add to the list, and click OK.
  4. To delete a control from the list, select it from the LDAP controls forwarded to the remote server list, and click Delete.
  5. Click Save.
3.3.1.2.2. Chaining LDAP Controls from the Command Line
Alter the controls that the database link forwards by changing the nsTransmittedControls attribute of the cn=config,cn=chaining database, cn=plugins,cn=config entry. For example, to forward the virtual list view control, add the following to the database link entry in the configuration file:
nsTransmittedControls: 2.16.840.1.113730.3.4.9
In addition, if clients of the Directory Server create their own controls and their operations should to be chained to remote servers, add the OID of the custom control to the nsTransmittedControls attribute.
The LDAP controls which can be chained and their OIDs are listed in the following table:

Table 3.3. LDAP Controls and Their OIDs

Control Name OID
Virtual list view (VLV) 2.16.840.1.113730.3.4.9
Server-side sorting 1.2.840.113556.1.4.473
Managed DSA 2.16.840.1.113730.3.4.2
Loop detection 1.3.6.1.4.1.1466.29539.12

For more information about LDAP controls, refer to the LDAP C-SDK documentation at http://www.mozilla.org/directory.


[3] The command to restart the Directory Server on platforms other than Red Hat Enterprise Linux 5 (32-bit) is described in Section 1.3, “Starting and Stopping Servers”.