Using LDAP host virtualization techniques to leverage multiple LDAP servers
 Technote (troubleshooting)
 
Problem(Abstract)
Using single sign-on (SSO) across WebSphere cells, each using their own user registry, results in "realm mismatch" error -- the realm in the token does not match the current realm.
 
Cause
WebSphere Application Server derives the realm name from the LDAP server hostname. This results in a realm mismatch when multiple LDAP servers are used.
 
Resolving the problem
The concept being documented here is that of using a different LDAP server per node or a distributed LDAP (DLDAP). DLDAP would be useful for load balancing and in scenarios where a system must contact a specific LDAP server due to network topology constraints.
The basic idea is to use aliasing to cause WebSphere Application Server treat the LDAP registries all the same, making the realm name the same. Here is one possible set of steps to achieve this:
  1. Alias each local LDAP server as the single authentication and authorization LDAP server per WebSphere Application Server (LDAP.IBM.COM) through local settings in each Servers' "/etc/hosts" file.

  2. Configure the WebSphere Application Server Security/User Registries/LDAP/Host field to point to the virtual "LDAP.IBM.COM" host server. This is the realm name and it is case sensitive, even though the TCP/IP host name is not case sensitive. All servers being configured for SSO must use the same case in this name.

  3. Set the Security/User Registries/LDAP/Ignore Case field to true (otherwise, authorization inevitably fails across enterprise WebSphere Application Server SSO. This is already set if configured via wpsconfig.bat.

  4. Set the Security/Authentication Mechanisms/LTPA/Single Signon/Domain Name to "IBM.COM".

  5. Export the generated LTPA Key from the first WebSphere server and import it into all WebSphere servers and the Domino Address Book Web SSO configuration document, which is then replicated across the participating Domino LDAP servers.

There are related concepts of a Highly Available LDAP (HALDAP) and Load Balancing LDAP (LBLDAP). The LBLDAP can be achieved via an IP Sprayer or any other technique that configures a single node to utilize multiple LDAP servers for load balancing and to make sure that if one LDAP server is unavailable, another can be used. The current LBLDAP registry setups require that WebSphere Application Server not be configured to reuse the LDAP connection. The HALDAP automatically failover all LDAP requests to another available LDAP when current active LDAP fails.

Pending refinement of the customer configuration and documentation, we have assessed the proposed Web SSO solution that leverages a Distributed (Localized) LDAP Registry configuration. This configuration, while using multiple LDAP registries, uses a single LDAP hostname.

As long as a single LDAP hostname (one virtual LDAP host) is used, we will support the use of LDAP host virtualization techniques (such as tcp/ip config, ip sprayer, and routers) in order to leverage multiple LDAP servers. The LDAP servers participating in this virtualization must have the same LDAP schema and/or replicas. This schema defines the LDAP attribute structure, naming conventions, and the filters needed to query LDAP.
 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Security
Operating system(s): Windows
Software version: 5.1.1.2
Software edition:
Reference #: 1192312
IBM Group: Software Group
Modified date: Dec 6, 2004