-
Suggestion
-
Resolution: Invalid
NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.
Hi everyone,
Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; however there are not currently any plans to implement this suggestion.
Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.
I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.
Regards,
Otto Ruettinger
Principal Product Manager, JIRA
oruettinger (at) atlassian (dot) com
Original Description
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.
- is caused by
-
CWD-422 Directory Failover option for an application
- Closed
- is duplicated by
-
JRACLOUD-27449 Associate a single user account with multiple User Directories
- Closed
- is related to
-
JRASERVER-23245 Provide a redundant hostname/IP for failover in LDAP
- Not Being Considered
-
FE-5170 Failover Support For LDAP
- Not Being Considered
- relates to
-
CONFCLOUD-8867 Failover Support For LDAP
- Gathering Interest