Hi Sam ,

Thanks. I didn't really observe in Confluence, but in JIRA user auth section not stick to one IP as per Wireshark IP flow. Each user login picking different domain controller and fyi , we are using Delegate LDAP auth option 

Again the reason of our settings is not really for Load balancing & it's just for better authentication experience because our IT performing domain controller reboot quiet often without informing stake holders .

Tx,

Vivek

Hi Vivek,

My organisation had a DNS round robin and we used domain controller hostname in the LDAP configuration on Confluence. We observed that Confluence cached the IP address on the first attempted connection to the domain controller. So when that lucky domain controller goes down, you lose access to confluence. Even if you have 200 other domain controllers available to serve requests.

The only viable option at the time was to use a 3rd party load balancer. But this was back on version 3.7 from memory, it's possible things have changed since then.

Cheers,

Sam

At this moment JIRA -LDAP integration is bit mess and i never saw any enterprise application depending one one domain controller. For not it's a risk to move to AD/LDAP authentication 

Here is what we did in our JIRA/Confluence environment 

Instead of targeting to one single domain controller we just mention full domain name in the hostname and that way all our domain controller in our company(we have almost 200 Domain controllers Globally) serves. So this way no risk of losing authentication and only one problem i found is due to Round robin domain performance against each user vary (example...one user may authenticate against server in US & other users in EMEA, APAC)

Will continue using same unless Atlassian provide option to add 2-3 AD servers for authentication in same user directory.

Tx,
Vivek 

We were having the same problem; multiple Active Directory servers available and not wanting a single point of failure on the LDAP.

After a bit of work it seemed like the simplest solution was to operate HAProxy on the Confluence server loopback interface with multiple TCP back-ends.

I can confirm that this works really well with almost instant failover and will scale to any number of LDAP servers.

We've documented the procedure here: http://kb.vorboss.net/KB15060205-tcp-failover-using-haproxy-on-debian

Hi Renan,

Last time I tried this configuration all my users ended up with duplicated groups listed from Active Directory (this was back on Confluence 3.5 though). If any thing has changed that would prevent group duplication then I guess that might be a viable option.

Current behavior:
Confluence doesn't have a formal "failover" feature, however with the possibility to have multiple directories and define their order, a "primary" and a "failover" directory can be added one after the other. If the connection to the first one fails, the second one will attempt to authenticate too.

I had hoped that the new 'crowd' ldap stack would have had this feature but alas no, so my issue stands. You have two options, use a local software TCP failover solution or adopt something like an F5 based solution which a significant expense... It still sounds like my original suggestion has merit, but most 'enterprise' users likely have hardware based solution or just make do. Its a world of compromises, in my last role I adopted the software solution which was effective at providing the necessary resilience, evn though yes, it introduced a potential single point of failure in itself.

This ticket has been opened since 2007, having a single point of failure is just not acceptable for an enterprise wiki solution, what is Atlassian plan to address this? and the schedule? Thanks.

Ah... that's because Confluence uses Atlassian user which is too sophisticated. I had been thinking of osuser.xml in JIRA where we have:

  <provider class="com.opensymphony.user.provider.ldap.LDAPCredentialsProvider">
    <property name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</property>
    <property name="java.naming.provider.url">URL1</property>
    ...

In the above case, the "SERVER1" is not parsed by JIRA at all - but passed straight through to LdapCtxFactory, which my testing a few ago for my own application demonstrated that it DOES support fail over (at least clean fail for situations such as 'Connection refused'... server timeouts might be another issue). In my application, I do precisely this - I put "URL1 URL2" into my .properties file, and this gets passed through to LdapCtxFactory via java.naming.provider.url.

I think the conclusion here for me - is that Confluence could easily support basic failover by taking advantage of the built-in LdapCtxFactory functionality. But, it would need to translate <host>...</host> appropriately to work as "well" as osuser.xml is expected to work...

You're an ideas man!

I just tried adding many host names to atlassian-user.xml, restarted confluence, logged in ok. Then to test fail over I blocked the first server with "iptables -A OUTPUT -d <1st server> -j DROP". Tried to login... "Sorry, your username and password are incorrect. Please try again." so no cigar.