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

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?

3 answers

Hi, are they in different data centers? Depending on how your network is setup, can't you have a virtual "floating" IP that points to a LDAP server and it fails over to the other as required? That would be 1 way to approach it.

This problem is actually outside of JIRA. This is the same case when a user tries to login to computer connected to an LDAP for authentication. The redundancy should be set outside of the system with the LDAP failing over to redundant systems as mentioned by Harry. 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.

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.

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?

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.

As JIRA /CROWD? don't support mulitple repositories, if you want realtime failover between mirror LDAP/AD servers (been there) then you have two choices, if you are lucky enough to have an F5 you may be able to load balance over a group of mirrors through an F5 managed IP. If you aren't, then you can get good mileage out of a simple software TCP proxy, I did this in my last role with PEN for JIRA and Confluence. If you aren doubly unlucky and run windows, then maybe you can find a similar product.

More on load balancing at loadbalancing.org

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published 8 hours ago in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

100 views 4 5
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you