Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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

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?

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.

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
Community showcase
Published in Marketplace Apps & Integrations

Jira issue check and more advanced commit verifications for Bitbucket DC

Pre-receive hooks that verify the Git commit message, the modified files, and implement similar code change controls used to be requirements of large enterprises working in regulated industries only....

0 views 0 0
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you