Crowd fallback

[Deleted user]

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

[MatthewC · Accepted solution]

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

[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 Chan]

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]

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]

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.

[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.

[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.

[Deleted user]

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"?