Security failover among multiple LDAP servers

 

WAS security can be configured to attempt failovers between multiple LDAP hosts.

If the current active LDAP server is unavailable, WebSphere Application Server security attempts a failover to the first available LDAP host in the specified host list. The multiple LDAP servers can be replicas of the same master LDAP server, or they can be any LDAP host with the same schema, which contain data that is imported from the same LDAP Data Interchange Format (LDIF) file.

Whenever a failover occurs, WAS security always uses the first available LDAP server in the specified host list. For example, if there are four LDAP servers configured in the order of L1, L2, L3, and L4, L1 is treated as the primary LDAP server. The preference of connection is from L1 to L4. If, for example, WAS security is currently connected to L4, and failover or reconnection is necessary, WebSphere Application Server security first attempts to connect to L1, L2, and then L3 in that order until the connection is successful.

The current LDAP host name is logged in message CWSCJ0419I in the WebSphere Application Server log file, SystemOut.log. To reconnect to the primary LDAP host, run the WAS MBean method, resetLDAPBindInfo, with null,null as the input.

To configure LDAP failover among multiple LDAP hosts, use wsadmin or ConfigService to include the backup LDAP host, which does not have a number limitation. The LDAP host that is displayed in the console is the primary LDAP host, and is the first item listed in the LDAP host list in security.xml.

The WAS security realm name defaults to the primary LDAP host name that is displayed in the console. It includes a trailing colon and a port number (if one exists). However, the custom property, com.ibm.websphere.security.ldap.logicRealm, can be added to override the default security realm name. Use the logicRealm name to configure each cell to have its own LDAP host for interoperability and backward compatibility, and to provide flexibility for adding or removing the LDAP host dynamically. If migrating from a previous installation, the new logicRealm name does not take effect until administrative security is enabled again. To be compatible with a previous release that does not support logic realm, the logicRealm name has to be the same as that used by the previous installation (the LDAP host name, including a trailing colon and port number). The following example shows how to use wsadmin to add a backup LDAP host for failover:

#---------------------------------------------------------------
# Main
#  This is a bi-modal script: it can be included in the wsadmin
#  command invocation like this:
#     wsadmin -f LDAPAdd.jacl ldaphost 800
#
#  or the script can be sourced from the wsadmin command line:
#     wsadmin> source LDAPAdd.jacl
#     wsadmin> LDAPAdd ldaphost 800
#
#  The script expects some parameters:
#      arg1 - LDAP Server hostname
#      arg2 - LDAP Server portnumber
#--------------------------------------------------------------- if { !($argc == 2)} { puts "" puts "LDAPAdd: this script requires 2 parameters: LDAP server hostname and LDAP server port number" puts "e.g.: LDAPAdd ldaphost 389" puts "" return;
} else { set ldapServer        lindex $argv 0 set ldapPort          lindex $argv 1
LDAPAdd $ldapServer $ldapPort return;
} proc LDAPAdd {ldapServer ldapPort args}
{ global AdminConfig AdminControl ldapServer ldapPort set ldapServer  lindex $args 0 set ldapPort  lindex $args 1 global ldapUserRegistryId if { catch {$AdminConfig list LDAPUserRegistry} result } { puts stdout "\$AdminConfig list LDAPUserRegistry caught an exception $result\n" return
} else { if {$result != {}} { set ldapUserRegistryId  lindex $result 0
} else { puts stdout "\$AdminConfig list LDAPUserRegistry caught an exception $result\n" return;
}
} set secMbean  $AdminControl queryNames type=SecurityAdmin,* set Attrs2  list  list hosts  list  list  list host
$ldapServer list port $ldapPort
$AdminConfig modify $ldapUserRegistryId $Attrs2
$AdminConfig save
}

---

Sub-topics

Configure multiple LDAP servers for user registry failover

Testing an LDAP server for user registry failover

 

Related concepts

Standalone Lightweight Directory Access Protocol registries

 

Related tasks

Updating LDAP binding information