000012366 - How to configure RSA ClearTrust for LDAP failover

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000012366
Applies ToRSA ClearTrust 5.5.3 Authorization Server (AServer)
RSA Access Manager 6.0.x
iPlanet Directory Server
Microsoft Active Directory
IssueHow to configure RSA ClearTrust for LDAP failover
Want to improve robustness of RSA ClearTrust set up in the event of LDAP store instability
Stability of a single LDAP data store is in question

NOTE: If implementing LDAP failover, it is highly recommended to apply the latest patch to RSA ClearTrust or Access Manager and apply the latest hot fixes, as there are some bugs with the LDAP failover functionality on older versions of ClearTrust. Please contact RSA Security Customer Support for the latest hot fix for your platform.

LDAP failover in ClearTrust is configured solely in the ldap.conf file located in the /conf directory of your ClearTrust server installations. Within ldap.conf, you must define a failover group, which is a collection of logical groupings of user, policy, and administrative stores. Each of these groupings is tied to a collection of multiple LDAP stores, each of which has a block of connection-specific parameters which are contained further on in the ldap.conf file.

#Create logical names for the LDAP stores

#Create logical names for failover groups
cleartrust.data.ldap.failover_group: user_failover, policy_failover, admin_failover,group_failover

#Assign stores to failover groups
cleartrust.data.ldap.failover_group.user_failover: ctrust1, ctrust2
cleartrust.data.ldap.failover_group.policy_failover: ctrust1, ctrust2
cleartrust.data.ldap.failover_group.admin_failover: ctrust1, ctrust2
cleartrust.data.ldap.failover_group.group_failover: ctrust1, ctrust2

#Assign failover groups to specific datastore types 
cleartrust.data.ldap.authentication_store :user_failover
cleartrust.data.ldap.groupstore :group_failover
cleartrust.data.ldap.userstore :user_failover
cleartrust.data.ldap.policystore : policy_failover
cleartrust.data.ldap.adminstore     : admin_failover
#Note: there may be others if using aux stores or FIM

 This section ties the logical stores ("ctrust1" and "ctrust2")  to the physical LDAP stores. The stores' connection parameters are defined.

cleartrust.data.ldap.directory.ctrust1.hostname :[hostname for the machine]
cleartrust.data.ldap.directory.ctrust1.port:[port for the machine]


cleartrust.data.ldap.directory.ctrust2.hostname :[hostname for the machine]
cleartrust.data.ldap.directory.ctrust2.port:[port for the machine]


Note here that the arbitrary logical names chosen for each store ("ctrust1", for example) later become part of the parameter names that define the connection (cleartrust.data.ldap.directory.ctrust1.hostname, etc). Due to the number of LDAP connection-specific parameters being quite extensive, please refer to the comments in ldap.conf for the specific connection parameters used to define a connection.

Keep in mind that for Microsoft Active Directory LDAP installations that require a separate bind connection, and you must define a normal and bind connection for each additional failover store. For example, if there are 2 LDAP servers, you will have 4 "blocks" of connection parameters - 2 normal and 2 bind.

PLEASE NOTE: In instances where you are configuring multiple authentication servers for failover to go against multiple LDAP stores, you must point both servers to the same LDAP store when defining the primary store.  This is done by listing the identical server group as the first in the comma-delimited list, e.g. cleartrust.data.ldap.failover_group.user_failover: ctrust1, ctrust2.  This indicates that the ctrust1 LDAP store is the primary store for the user store failover group, and to another LDAP store as the secondary for both aservers. It is important to note that ClearTrust LDAP failover is not intended as a method for load balancing.  This is why alternate configurations between aservers (such as having each auth server use a different store as its primary store) is not ever recommended, as the configuration is a risk for data integrity issues due to latency between datastores.

Legacy Article IDa28321