Uploaded image for project: 'OpenAM'
  1. OpenAM
  2. OPENAM-11617

Directory Configuration does not work with mix of LDAP/LDAPS server


    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 13.5.0, 13.5.1, 14.0.0, 14.1.1
    • Fix Version/s: None
    • Component/s: sms
    • Labels:
    • Rank:


      Bug description

      In the documentation, like https://backstage.forgerock.com/docs/am/5.1/reference/#server-directory-configuration you can create mutiple Server for the configuration LDAP server Server

      In the LDAP connection table, edit existing LDAP connections by selecting the pen icon to the right of the row you want to modify. To add a new entry, fill the NAME, HOST NAME, PORT NUMBER and CONNECTION TYPE columns using the following hints:

      NAME. The name of the LDAP connection.
      PORT NUMBER. The port number to connect to the LDAP server.
      CONNECTION TYPE. Whether the connection between the LDAP server and AM is SIMPLE (unsecured) or SSL (secured).

      So you can have a define a mix of SIMPLE/SSL ones. This is also seen from the UI. So this should be doable.

      But it seems all the rest uses the first LDAP protocol

      How to reproduce the issue

      1. Setup a normal OpenAM with LDAP configuration server (could be external so you have both LDAP and LDAPS)
      2. Now add one more server to the Directory configration like LDAPS
      (for the above)
      3. Disable the OpenDJ connector for the LDAP one so that only LDAPS
      is used.

      Now when starteing OpenAM, it fails to starts and report the usual Configuration store not found error

      25-Aug-2017 14:36:21.041 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 824171 ms
      com.sun.identity.common.configuration.ConfigurationException: Configuration store is not available.
              at com.sun.identity.setup.AMSetupFilter.doFilter(AMSetupFilter.java:119)
              at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
              at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)
              at org.forgerock.openam.audit.context.AuditContextFilter.doFilter(AuditContextFilter.java:43)
              at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240)
              at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207)

      The boot.json has

        "configStoreList" : [ {
          "baseDN" : "dc=openam,dc=forgerock,dc=org",
          "dirManagerDN" : "cn=Directory Manager",
          "ldapHost" : "dj1.com",
          "ldapPort" : 10389,
          "ldapProtocol" : "ldap"
        }, {
          "baseDN" : "dc=openam,dc=forgerock,dc=org",
          "dirManagerDN" : "cn=Directory Manager",
          "ldapHost" : "dj1.com",
          "ldapPort" : 10636,
          "ldapProtocol" : "ldaps"
        } ]
      Expected behaviour
      Should failover to dj1:10636 (2nd one)
      Current behaviour
      Unable to connect to the SSL DJ. and so cannot start OpenAM

      Work around

      It seems that only the first LDAP in the configuration is used and then all later LDAP connection uses this

      Code analysis

              return LDAPUtils.newFailoverConnectionFactory(
                      getLdapUrls(serverGroupID, sslEnabled),
                      authID, passwd != null ? passwd.toCharArray() : null, heartBeatInterval, heartBeatTimeUnit, false, false, ldapOptions);
          private Set<LDAPURL> getLdapUrls(String serverGroupID, boolean isSSL) {
              Set<LDAPURL> ldapUrls = new LinkedHashSet<>();
              ServerGroup serverGrp = getServerGroup(serverGroupID);
              for (Server server : serverGrp.getServersList()) {
                  ldapUrls.add(LDAPURL.valueOf(server.getServerName(), server.getPort(), isSSL));
              return ldapUrls;

      IsSSL is using the first one and not evaluated using individual LDAP URL.




            • Assignee:
              chee-weng.chea C-Weng C
            • Votes:
              0 Vote for this issue
              1 Start watching this issue


              • Created: