Atlassian Update – 15 November 2018 Hi, Thank you for providing input and feedback on this suggestion. We have reviewed it and wanted to let you know that requested functionality is available in Crowd. For those of you who aren’t familiar with Crowd , it offers one place to manage your users, groups and directories and easily integrate your identity infrastructure across all self-hosted Atlassian products. For more context please check relevant Crowd suggestion: https://jira.atlassian.com/browse/CWD-422 We are not planning to invest in similar capabilities in Jira Server in any foreseeable future and we encourage you to consider using Crowd or Crowd Data Center for most efficient user management across your self-hosted Atlassian products. Best regards, Gosia Kowalska, Jira Server Product Management
Some users have indicated that they would like automated failover if an LDAP server becomes unreachable.
Some details on how LDAP connectivity will work in JIRA ATM:
When you add an LDAP directory, JIRA will "synchronise" with that LDAP server.
That is, it will cache all the Users, Groups and memberships in its local DB.
The only thing we don't keep a local copy of is passwords (for security reasons).
This means that when a user from LDAP logs into JIRA, they will authenticate against LDAP but all following read operations are done locally.
(If you have Read/Write LDAP then obviously we need to talk to the server for write operations).
So, if an LDAP user is already logged into JIRA and the LDAP server goes offline, that user will still be able to use JIRA normally including "seeing" all users from that LDAP server.
In addition, users in other directories will still be able to log in and use JIRA.
So, firstly, an offline LDAP server is not as catastrophic as some may imagine.
Secondly, this implies the following (manual) workaround for failover:
If you add an LDAP directory, then you should still keep your internal directory.
In the internal directory you ought to have at least one admin account.
If the LDAP server goes offline, the local admin can log in and manually change the LDAP hostname.
Alternatively, you could set up 2 LDAP directories with the two hostnames. If the first LDAP goes down, the local admin can simply swap the order of the directories so that the "slave" directory has precendence.