Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Crowd fallback

Deleted user Jun 05, 2013

I have set up Crowd with Confluence and JIRA but I am worried that if Crowd is unavailable then no one will be able to access Confluence or JIRA.

Confluence and JIRA internal user directories are still active but ordered below the Crowd directory, so Crowd authentication takes precedence. I have set up a separate admin user using the Confluence and JIRA internal directory but it is not possible to login with this account if the Crowd directory is set as primary authentication directory.

After running tests it seems that it is not possible to login if Crowd is not available, I had hoped that Confluence and JIRA would revert to the profiles from the last sync but it seems that they refuse all login attempts if they are unable to sync with Crowd at the designated sync interval.

1. Is it possible to set Confluence and JIRA to use the last sync'd profiles if Crowd is not available for any reason? This would ensure that existing users can still login if any problems occur with the Crowd instance.

2. What is the best approach for reverting to the internal user directory if Crowd is not available?


3 answers

1 accepted

1 vote
Answer accepted
MatthewC Rising Star Jun 05, 2013

rather than mess arond with Jira & Confluence and make them do something they shouldn't, ideally you should be able to rely on Crowd.

It's crazy but for such a critical application, Atlassian don't support any kind of official failover technique. You could get support from one of their partners and pay extra for something that really should be standard. -1 Atlassian I think.

Unlike Jira or Confluence, there's no state or data kept on the disk, it's all in memory, so it should be easy enough to cluster it, assuming you have a HA database.

Official line

Feature Request - remember to vote for this, not that it will make much difference.

and a short paper from Go2group

the other technique is to keep a host all setup and ready to go, if Crowd goes down, start it up automatically and repoint the internal DNS to the new host. J&C should have a "blip" in the ability to authenticate but then pick it up

MatthewC Rising Star Jun 05, 2013

The other problem you're going to have is you run both internal & external directories is keeping them in syn. I think Jobin works at Go2Group, so maybe you can ask him about that paper ;-)

I would agree about relying on Crowd. At this point, nothing from Atlassian really fails over or clusters for HA. If Crowd goes down, restart it and if not you might have more problems.

Deleted user Jun 10, 2013

Thanks for the advice, although I am not sure you have helped to ease my concerns.

I was hoping that I could set up an internal user that could be used to access Confluence or JIRA in case we had any major problems with Crowd - e.g. a 'sysadmin' user that is set up in the internal directory that is not reliant on Crowd being available. This user can also be used if we wish to backup the live system and deploy to a test environment that does not have Crowd set up.

Is it possible to set up an internal user that can access Confluence or JIRA that is not dependant on Crowd authentication?

MatthewC Rising Star Jun 10, 2013

I guess you could create a unique user in a local directory (in Jira/Confluence), using a userID that didn't exist in the main directory (e.g. "backup-admin") then order the directory so that it's first in the check list.

In theory, every login would be checked against this backup directory, the normal users wouldn't be found, so pass through to Crowd server. It's only if users are found in this internal backup directory that the authentication wouldn't pass to Crowd.

I haven't tested it but I think it should work. You could maybe get back in with a backup admin user and change the Crowd config to another server?

It may give you a layer of comfort but not sure how much use it would be. Crowd restarts very quickly and you can get it back up quickly. if you you were to switch to another instance of Crowd, you'd have to logon to the server and start the service, then switch back to Jira/Confluence & change the config. If you keep spare Crowd production server running, you will need a licence for it, if it's a cold standby, you don't need an extra licence.

It is not advised to use both Internal User directory and Crowd directory for the same user.

You can have a separate admin user in internal directory who cn login when Crowd is down but Crowd is ofcourse supposed to be up all the time ;) You will have to plan Crowd maintenance with a downtime for all connected applications.

0 votes

Simon: This is a failing of most SSO/user management consolidation techinques. If crowd is unavailable, then your apps will fail to auth, and then you'll be locked out of your applications.

I usually recommend to my customers the following (assuming JIRA/Confluence w/embedded crowd (version 4.4+ JIRA , 3.5+ Confluence).

Ensure there exists a user in JIRA/Confluence with sysadmin privs in the internal directory. Set up crowd as normal, ensure crowd is top slot in User directories.

Find this user in the cwd_user table, blank the pw hash.

Construct a db script that will update the user with a known pw hash (e.g. 'x61Ey612Kl2gpFL56FT9weDnpSo4AV8j8+qx2AuTHdRyY036xxzTTrw10Wq3+4qQyB+XURPWx1ONxp3Y3pB37A==' which is 'admin') as well as set the crowd directory's active column to 'F' (this is in the cwd_directory table).

If you have SSO set up, you'll have to script up the "de-crowdification" process (e.g. substitute the stock seraph-config.xml in place of the "crowdified" seraph-config.xml).

At the end of the day, you have a secure enough backdoor into systems, scripted such that someone with shell access, such that you can get access to the applications in the event of crowd failure.

Deleted user Jun 13, 2013

Thanks for the advice, sounds like a slightly long-winded way of ensuring access to the service if there are any problems with Crowd, but it does provide a backup strategy should the need ever arise.

Cheers for all the help.

Wouldn't this still require restarting jira and confluence? Or would this just "work"?

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events