Deploying Application Repository
The LDAP directory server is a vital component in the DirX Access system. This section describes the mechanisms supported for ensuring its reliability and availability.
Using LDAP Referrals
Most directory servers allow you to distribute your user data across multiple servers located on different physical machines. This configuration can improve the performance of the directory system, and by extension, the client applications that make use of its data.
A distributed directory system commonly has a network of referrals set up among its component servers. An LDAP referral is a list of one or more URLs, redirecting querying applications to the actual location of the appropriate data. These referrals hide the functional details of the distribution scheme, making your directory appear to other network components as if it were centralized on one machine.
The following diagram illustrates a possible deployment of a DirX Access server and LDAP directory server, including redundant directory servers, DNS lookup and directory referrals.
To configure the DirX Access system to use LDAP referrals, you must set the “Referral enabled” property on DirX Access Manager’s Basic LDAP Configuration page. When multiple URLs are listed in a single referral, the DirX Access server treats them as alternatives, trying each in turn until the operation succeeds. The server uses the complete URLs as provided, including any query string components.
Using X.500 Chaining
X.500 chaining is supported by X.500 compliant servers such as the Atos DirX Directory server. It basically means here that the server itself takes care of gathering all entries satisfying a query, even if they are distributed non-redundantly across several physical machines. As opposed to LDAP referrals, no client-side provisions are required.
Using Connection Pools
DirX Access servers maintain resizable pools of reusable connections to the LDAP directory server. Whenever the server needs a connection, it requests a connection from the pool. If a connection is available, it will be used. If no connection is available, a new one will be created and used unless the maximum number of connections for the pool has been reached. When the server is done with the directory server request, it marks the connection as “idle” and returns it to the pool for later use. Once a connection has been idle for long enough to reach the configured timeout value, the server disposes of the connection unless doing so would bring the pool below its preferred size.
The default Java Naming and Directory Interface (JNDI) pooling settings are:
-
Initial pool size 1.
-
Maximum pool size 256.
-
Preferred pool size 0.
-
Idle pool connection timeout is disabled.
You can change the default connection pool settings by modifying the following lines in the DirX Access server configuration file DirxAccessInstallFolder/Server/instances/TenantId/etc/wrapper.conf and restarting the server, for example:
wrapper.java.additional.5=-Dcom.sun.jndi.ldap.connect.pool.initsize=<initial pool size>
wrapper.java.additional.6=-Dcom.sun.jndi.ldap.connect.pool.prefsize=<preferred pool size>
wrapper.java.additional.7=-Dcom.sun.jndi.ldap.connect.pool.maxsize=<maximum pool size>
wrapper.java.additional.8=-Dcom.sun.jndi.ldap.connect.pool.timeout=<idle pool connection timeout milliseconds>
We strongly recommend that you do not enable idle pool connection timeout because a bug in the Oracle JNDI for LDAP implementation may cause the Server to deadlock under certain circumstances.
Indexing Directory Entries
If LDAP performance needs to be optimized, consider setting indexes for some of the persisted attributes. The list of candidates includes:
-
Naming attribute (typically: cn; see the Subjects | Persistent data page in DirX Access Manager).
-
Login name attribute (typically: cn; see the Subjects | Persistent data page in DirX Access Manager).
-
member (if groups are used).
-
dxaRoleList.
If the DirX Directory server is used in tier 3, a convenient way to set indexes is through DirX Directory Manager’s schema management view (virtual node “Database”).