Can WebSphere® Portal support the usage of a network dispatcher to forward LDAP requests to multiple LDAP servers? Can WebSphere Member Manager be leveraged to support LDAP failover?
Answer
Implementing clustered LDAP systems in a WebSphere Portal environment for failover purposes can be achieved using either of the following methods:
1) An environment that implements a network dispatcher and clustered LDAP servers can be successfully integrated into a WebSphere Portal environment. The communication between the dispatcher and the LDAP cluster members should be transparent to the portal server and its LDAP interface, WebSphere Member Manager (WMM). Only the network dispatcher host address would be referenced in the
ldapHost="
. . . . .
>
Unless you have configured realm support security for WebSphere Portal, such a setup also requires you to disable the "Reuse Connection" feature of WebSphere Application Server (if dispatcher doesn't support session affinity) and set the dispatcher address as the LDAP hostname. These settings can be accessed using the WebSphere Application Server Administration Console via Security->User Registries-->LDAP.
This is the recommended option for setting up WebSphere Portal to take advantage of LDAP failover.
2) If you are not able to implement a network dispatcher, a second option exists which can be implemented in one of two supported environments:
a) WebSphere Portal 5.1/6.0 on WebSphere Application Server 6.0.2 or later (See the link at the end of this document for details on configuring WebSphere Application Server 6.0.2.x for multiple LDAP servers)
b) WebSphere Portal 5.1.x on WebSphere Application Server 5.1.1.x or 6.x versions less than 6.0.2 using WMM realm support security. WebSphere Application Server does not support LDAP failover until version 6.0.2, but WMM realm support results in WMM handling all LDAP connections and the lack of WebSphere Application Server support is not an issue.
The following details regarding WebSphere Member Manager apply to both of the above supported environments in a) and b).
Starting in Member Manager 5.1, Member Manager can utilize the multiple URLs support in the Java 2 SDK, v1.4.1. This means that Member Manager can be configured to connect to multiple LDAP servers in turn until it is able to create a successful connection. This new feature can be implemented in WebSphere Portal 5.1/6.0 by adding a JNDI environment parameter to the
java.naming.provider.url="
Note that there is a space between each URL and more than two URLs can be defined.
When implementing this feature, Support strongly recommends installing the latest Member Manager Cumulative fix (see links under Related information) and then using the following additional parameter to set a limit on the amount of time (in milliseconds) WMM will wait for an established connection before moving onto the next LDAP in the list:
connectTimeOut="
If the above parameter is not set, then the default behavior is to wait until the connection is established or the underlying network times out. This default behavior can lead to performance issues in WebSphere Portal.
For example:
adminId="cn=root"
adminPassword="xxxxxx"
ldapHost="
ldapPort="
connectTimeOut="500"
java.naming.provider.url="ldap://
...
>
The above example assumes that you have two LDAP servers, a primary and a backup. The backup and primary servers are synchronized to have identical content (including your adminID and adminPassword). You want WMM to use the backup server if the primary server is unavailable.
If you are using an SSL connection for LDAP, this parameter can look like the following:
java.naming.provider.url="ldap://
Note that once you set this parameter, the parameters ldapHost and ldapPort are overwritten by the LDAP addresses and ports specified in this parameter.
If the primary server goes down, and WMM then reverts to the backup server, WMM will continue to use the backup server until the backup server becomes unavailable.
