Introduction

The DirX Directory LDAP server can run in one of two modes:

  • As a plain LDAP frontend to a DSA. In this mode, the LDAP server forwards incoming requests to the DSA via DAP.

  • As a pure LDAPv3 proxy frontend to another LDAP server. In this mode, the LDAP server forwards incoming requests to another LDAP server, which can be a DirX Directory LDAP server or another type of LDAPv3 server (for example, Active Directory).

When configured to run in proxy mode, a DirX Directory LDAP server can be configured to:

  • Redirect incoming LDAPv3 operations to other LDAP servers based on user name or operation type. This feature allows the routing of specific users, groups of users or special operations to specific servers only; for example, all searches for base object Y can be routed to LDAP server Z.

  • Modify the content of incoming LDAPv3 client requests and outgoing LDAPv3 results before sending them on for further processing. This feature allows for adding, replacing or removing unwanted or incompatible data from LDAP requests and results – for example, to hide certain data from LDAP clients – or to provide a transparent naming schema between legacy clients and the DIT.

Running the DirX Directory LDAP server in proxy mode has the following advantages:

  • It creates a central access point for LDAP clients

  • It hides the actual processing server knowledge

  • It hides server outages (the feature implies automatic request forwarding to other available servers in the event of network problems or server outages)

  • It transparently provides load balancing to the caller

  • It provides an additional access control layer to the directory service

The following figure illustrates a typical DirX Directory LDAP proxy (DLP) server configuration within a homogeneous DirX Directory environment:

LDAP Proxy Configuration

As shown in the figure:

  • Configuration information for the DLP server backend consists of the available target servers and rules for backend server operation. Routing rules specify how client requests are selected and forwarded to the configured target servers while rewriting rules specify how client requests or results are selected for modification and what the modifications to be made to that data shall be.

  • The DLP server’s contact DSA is the local DSA. Note that although the DLP server’s contact DSA could be DSA1, DSA2 or DSA3, we do not recommend setting it up this way.

Configuration Elements

Configuration elements for the DLP server include:

  • The LDAP configuration subentry

  • The proxy mode attribute of the LDAP configuration subentry

  • The DLP server configuration file

LDAP Configuration Subentry

Both the LDAP server and the DLP server require the presence of an LDAP configuration subentry in the DSA to configure the settings related to frontend handling, like ports, allowed and denied IP addresses and the like.This information is shared between both modes of operation.See the “DirX Directory Attributes” chapter in the DirX Directory Syntaxes and Attributes reference document for a complete description of attributes defined for the LDAP configuration subentry.

Proxy Mode Attribute

Operation as a plain LDAP server or a DLP server is controlled by the ldapProxyMode attribute in the LDAP configuration subentry. The DirX Directory LDAP server process (dirxldapv3) automatically reads the value of the ldapProxyMode attribute at startup to determine whether to run in server mode or proxy mode. See the “Configuration” chapter in this guide for more information about the ldapProxyMode attribute.

DLP Server Configuration File

When the LDAP server is running in proxy mode - in other words, as a DLP server - the backend to which the client requests are forwarded is another LDAP server instead of a DSA. Therefore, settings in the LDAP configuration subentry that affect the backend for plain LDAP server operation - for example, DAP pool size, unbind delay time, and so on - can still be configured but will not be relevant for the DLP server.

The backend for DLP server operation is configured in the DLP server configuration file, which is a separate JavaScript Object Notation (JSON)-formatted file that defines:

  • The LDAP server to be enabled as a DLP server

  • The LDAP servers to which the DLP server can forward incoming requests

  • The rules for routing these requests to these target servers

  • The LDAP servers to be used as fallback target servers when there is no routing rule match on a request; the DLP server selects from this default set of target servers, called LB-servers.

  • The rules for rewriting incoming requests before they are forwarded to a target server and for rewriting outgoing results before they are returned to the client

See the “Configuration” chapter for more information about the DLP server configuration file and how to specify the DLP server, target systems, LB-servers and rules.

Features and Limitations

The DLP server has the following features:

  • Once the DLP server selects a target server, it forwards all subsequent operations on the same LDAP client connection to this same target server.All results from the target server will be received by the DLP server and returned to the LDAP client unchanged unless result rewriting rules are in effect and have been applied.

  • The DLP server supports anonymous and simple authenticated LDAP users
    via plain and SSL/TLS.

  • The DLP server can act as a TLS gateway for non-TLS clients; that is, it can receive requests from plain clients (without SSL/TLS) and then forward these requests over a secure connection to the target servers.

  • The DLP server supports operation forwarding via plain and SSL connections to LDAP target servers.

  • The DLP server forwards all types of LDAP operations except for LDAP extended operations, which are always executed locally either against the DLP server or the local DSA.Only the RFC3062 extended operation will be forwarded.

  • If LDAP extended operations are to be executed against a target server, the operation must be sent directly to it.

  • The DLP server requires a local DSA to host the DLP server’s LDAP configuration subentry and the schema information used in client requests.

  • The DLP server supports logging and auditing through the DirX Directory LDAP audit interfaces and tools (dirxauddecode). See the logging and auditing chapters in this guide for examples of output returned by these interfaces for DLP server mode.

  • The DLP server supports a DirX Directory Manager interface and DirX Directory LDAP extended operations to query server status and initiate dynamic updates to its configuration without interrupting service. It supports DirX Directory LDAP extended operations to disable and enable the target LDAP servers configured to be available to the DLP server. See the Extended Operations chapter in this guide for reference descriptions of these operations.

The DLP server has the following limitations:

  • The DLP server only accepts LDAPv3 requests. LDAPv2 is not supported.

  • The DLP server can only forward LDAPv3 traffic. It cannot forward any other type of traffic.

  • The DLP server does not support client-based authentication (SASL EXTERNAL)

  • Because the DLP server establishes the same number of backend connections as frontend connections, be careful not to exceed the descriptor limits (usually a maximum of 4,000 LDAP frontend connections).

  • Unlike the DSA backend, which has backend sharing capabilities, each LDAP client will always occupy two descriptors in the DLP server backend.

  • Although the DLP server can establish up to 4,000 client connections on Linux platforms, we recommend limiting the number of possible client connections (since having huge arrays of sockets to multiplex can slow down server responsivity) and configuring multiple DLP servers instead.

The DLP server’s routing mechanism has the following considerations:

  • The possible target servers for a user should share the same knowledge in their DIT; that is, in terms of replication, they should be “full shadows” of each other. Mixing target servers with different knowledge should be avoided.

  • Since DLP server forwarding can be based on the user’s DN, the DLP server requires knowledge of the naming attributes of the DN. As a result, all attributes that may appear in a user’s DN - including those of any non-DirX Directory target servers present in the configuration - should be defined in the DLP server’s local schema.