How do I configure Jira to use several Active Directories in order to obtain authentication redundancy?

Question

I am looking for a solution that would allow me to configure jira to use several LDAP/AD servers.

All servers are supposed to be identical (replicas).

I know that Jira does not allow you to configure alternative/fallback LDAP servers and that configuring several AD is not a solution due to group memebership limitations.

Still, I would like to know if I can trick the system to be more redundant in case of AD going down for some reason.

One thing I am considering is using a special DNS entry for this but I am not sure how I should configure it to make it work well.

Example: haivng ldap-1.example.com and ldap-2.example.com as the AD/LDAP server I could configure a jira-ldap.example.com which solves randomly as ldap-1.example.com and ldap-2.example.com.

Would this be a good idea, or not? What alternatives do we have?

Mikhail T · Answer

The failover is not implemented at the desktop/laptop side (AFAIK)

Renjith, you are quite misinformed. Kerberos clients -- both "original" Unix ones and the Active Directory implementation -- have always allowed you to provide multiple server-entries. Exactly for this purpose -- should one of the servers fail, the entire fleet of workstations can continue to function. It was done this way long before Virtual IPs and GTMs were invented.

DNS client-libraries too support talking to multiple servers -- if it can't reach the first one listed in /etc/resolv.conf, it will try the next one.

For another example, Sun's NIS (a.k.a. Yellow Pages) also allows multiple servers -- and clients could switch from one to another one the fly. Sybase, for yet another example, as well have always allowed for multiple redundant servers behind a single name (they, actually, have their own layer above DNS).

Isn't [it] only fair that way to leave the logic of failover/redundancy at the server side rather than every client connecting to the AD/LDAP to implement such procedures?

No, it is not fair. First, because, it is much easier for a client to try another IP, than for a VIP to function properly. In fact, VIPs are pretty horrible hacks -- they are necessary, because applications programmers tend to be inexperienced and ignorant. To work, a VIP needs to constantly check all of its multiple back-ends so as not to send a client to a failed back-end once in a while -- and it still happens causing an error on the client.

And second, when your clients all share the same code, you don't implement it on "every client" -- only once.

Renjith Pillai · Answer

Not really. Let's take the example of a Windows Desktop/Laptop that connects to the Active Directory. The failover is not implemented at the desktop/laptop side (AFAIK) and this is taken care at the AD/LDAP level to have a redundancy at the AD side (this is also true AFAIK about even *nix based clusters).

Isn't only fair that way to leave the logic of failover/redundancy at the server side rather than every client connecting to the AD/LDAP to implement such procedures?

Mikhail T · Answer

It should be an IP failover, as DNS will still result in requests going to the old IP till the DNS cache expires, I believe.

Why would it? A well-written application could try connecting to all IP-addresses behind the given hostname in parallel and using the one, which respods first. It could also maintain a pool of such connections for reuse the way database-connections are pooled, or the way web-proxies keep open HTTP-connections to the back-end origins they are fronting for.

If implementing such parallel access is too much for a programmer, he could, at least, implement sequentional access -- if a connection to the first IP returned by gethostbyname(), keep trying until the return list is exhausted.