This SHOULD be basic functionality not something we should even vote on to get implemented. 

For anyone reading this, you can add the secondary Domain Controller to the database itself and failover works. I have this working in confluence 7.19.14. We use a Postgres database and the following command within psql works to update the value as desired:

SELECT attribute_value FROM cwd_directory_attribute
SET attribute_value = 'ldaps://dc1.domain.local:636 ldaps://dc2.domain.local:636'
WHERE attribute_name = 'ldap.url';

Edit: Make sure to either restart confluence or reboot the server. Do a test to see that its working (shutdown DC1 and test, shutdown DC2 and test, shutdown both and make sure it fails)

Edit2: For those looking to be a little more adventurous. Assuming (or not) that you have nginx as your proxy for confluence, you can setup ldap proxy so that confluence connects to itself at ldaps://localhost:636 and then that gets proxied to an upstream of DC1 or DC2 depending which server is up (this is built in to nginx).

Every time our dc gets in trouble I wish all the Atlassian tools had this feature :|

Or if the instance could be more tolerant when waiting for the dc to reply so that we can actually use the name rather than the ip address.

I know that Crowd has this feature, but to me it makes little sense to have-yet-another-product just for this.

Perhaps I can try to manually add the configuration to the db to see what happens.

Please Atlassian, add this feature to your server products (not juts the data center).

missing basic enterprise features like this one .....

Another 12 months, and then some...

??

Hi,

it's longer then 12 months from report, any progress?

It seems like the LDAP backend of Confluence already supports multiple servers.

Please see my response here: https://community.atlassian.com/t5/Jira-questions/Multiple-read-only-LDAP-user-directories/qaq-p/324128#M219840

As far as I can tell, only the UI needs to be adapted, and the ldapUrl field needs to be re-parsed correctly.

Entering multiple host names, separated by a space (and the protocol in front) will be be accepted and failover will actually work:

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

But when I open the LDAP server "Edit" page again, the following exception occurs:

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)

Can you prioritise this issue please, Atlassian? It really looks like there isn't a lot that needs to be done here...

Sometimes I don't understand why such critical single point of failures like this still exist.  It would be simple to enable support for several LDAP servers, so that each could be polled if the previous failed (the reason I logged this 9 years ago ).

This could be patched to provide the feature, but customers would not want to rely on 3rd party patches.

You the customer could architect your environment to provide an agnostic entry point for LDAP with an F5 providing TCP fail-over between multiple DNS resolved hosts.  For those without such hardware, even a simple software TCP proxy would resolve this, and was the solution I implemented oh so many years ago.

It would be awesome if Atlassian got their developers to tackle blindingly obvious product deficiencies like this during their code competitions, rather than to drive innovative development of new shiny things - even if they are very shiny!