Multiple read-only LDAP user directories

[Mike Beebe]

Hello,

Recently we had a failure of a Microsoft AD server that left our users unable to log in. To alleviate this issue in the future, I was wondering if it's possible to configure two LDAP user directories so that if the first fails, the second one will be able to provide authentication information. This would be for both JIRA and Confluence (vers. 6.3.14 and 4.3.7 respectively). Both LDAP servers contain the same user information, so there shouldn't be a problem with duplicate users and both would be in read-only mode.

Is it possible to do this and would it work as expected?

Thank you,

-- Mike Beebe

[Rodrigo Girardi Adami · Accepted solution]

Hi Mike,

This is not possible at the moment, unfortunately. Confluence and JIRA does not provide failover support for LDAP as we can see in these links:

https://jira.atlassian.com/browse/CONF-8867

https://jira.atlassian.com/browse/JRA-23245

I recommend to vote and comment in those features to increase their priorities.

Cheers,

Rodrigo

[Heidi Fernandez]

Hello Rodrigo, What kind of impact would there be, if we add a secondary LDAP user directory in JIRA?

[Chris Flynn]

This is probably not the answer you are looking for, but I would think the ideal solution would be to make your LDAP servers redundant for all systems.

I also think this is most likely possible they way your are describing it, especially if you have Crowd. But I don't have any experience in this area yet.

[Gregor Riepl]

An important aspect is that LDAP is a stateful protocol and simple load balancing setups may not work as expected. The best solution for making LDAP highly available is client-side failover to one or more hot-standby servers.

We're currently rolling out such a solution, and it's very surprising that Atlassion tools don't have official support for this.

After a little bit of experimentation, I found out that the LDAP backend of Confluence actually supports the feature, but the UI does not handle multiple URLs correctly.

You can enter a list of servers into the ldapUrl field, separated by a space. If you use LDAPS, you need to prepend ldaps:// to each additional entry. Also, don't forget the port, if it is non-standard:

my-ldap-server-1:636 ldaps://my-ldap-server-2:636 ldaps://my-ldap-server-3

This will work and actually fail over to the second or third server if the first one can't be reached.

But after that, it is no longer possible to open the LDAP server configuration page due to incorrect parsing of the ldapUrl field:

Caused by: java.lang.NumberFormatException: For input string: "636 ldaps://my-ldap-server-2:636"
        at java.lang.NumberFormatException.forInputString(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at com.atlassian.crowd.embedded.admin.ldap.LdapDirectoryConfiguration.setLdapUrl(LdapDirectoryConfiguration.java:160)

 I really think Atlassian should add official support for this, as it seems the hard work is already done and only the UI needs to be adapted.

[Craig Castle-Mead]

Hey Gregor,

We've been using the space delimited approach for LDAP server failover for a few years now and has worked fine up until now (Production Crowd using 3.2.0) but in testing 3.3.4 in our UAT environment, we're getting the parsing error above.

Wondering if you're able to confirm which version of Crowd you were getting the parsing error on?

PS. In the process of lodging a premier support request with this upgrade blocker and will provide feedback as I get it.

CCM

[Craig Castle-Mead]

FYI - Premier Support mentioned that https://jira.atlassian.com/browse/CWD-2768 is the reason for the parsing error when there's multiple connectors.

CCM