nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Crowd fallback

unknown

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?

thanks

Accepted answers

MatthewC

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

https://confluence.atlassian.com/display/CROWD/Using+Crowd+in+a+Cluster+is+Not+Supported

Feature Request

https://jira.atlassian.com/browse/CWD-1053 - remember to vote for this, not that it will make much difference.

and a short paper from Go2group

http://www.go2group.com/en/services/atlassian-services/atlassian-crowd-a-simple-clustering-solution/

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

All comments

Jobin Kuruvilla [Adaptavist]

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.

MatthewC

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

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

https://confluence.atlassian.com/display/CROWD/Using+Crowd+in+a+Cluster+is+Not+Supported

Feature Request

https://jira.atlassian.com/browse/CWD-1053 - remember to vote for this, not that it will make much difference.

and a short paper from Go2group

http://www.go2group.com/en/services/atlassian-services/atlassian-crowd-a-simple-clustering-solution/

MatthewC

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 ;-)

Harry Chan5

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.

unknown

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?

twong_atlassian

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.

unknown

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.

Bryan_Karsh

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

crowd

crowd-administration