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

Setting up Crowd User Directory Failover


I have an internal Crowd directory.  I am thinking about moving the authentication to Active Directory.  The approach most feasible for me is to use Delegated Authentication.  This will allow to map the existing users to their comments/spaces/items in JIRA and Confluence.

Now if I want to set up a failover.  I am thinking use Delegated Authentication as primary but would I be able to use the internal Crowd directory as secondary?  Not sure how this will work.  I would highly appreciate your advice and comments on this.



1 answer

1 accepted

0 votes
Answer accepted
Marcin Kempa Atlassian Team Feb 12, 2018

Hi @Kashif Pervaiz,


Assuming that your users will have the same usernames in both internal and Active directory you should be able to easily do such migration as the users in Jira and Confluence will map to the same usernames.

When it comes to directory failover, this is also possible assuming that the usernames are the same in both Active Directory and in the internal directory.

In order to achieve this you need to map both directories to application (Jira and Confluence in your case) in Crowd as described here. The order of those directories matters, as Crowd when authenticating a user, checks directories based on their priority on the list. If a given directory is unavailable or doesn't contain the user, Crowd will move on to the next one, and so on. In case of duplicated users, the first one found will be used.

Please note, that since one of those directories will be remote and the other will be local to Crowd the passwords stored in Crowd and Active Directory for users may get out of synch, as when users will be doing password rename they will do that in the first accessible directory, thus in most cases it will happen in Active Directory and the password in Internal directory will not reflect that change.

The preferred way of doing the directory failover would be to have the primary Active Directory and then a secondary replica of this Active Directory server. Then you can map those two directories to applications in Crowd. Here is the documentation about setting up such configuration.


Hope that helps,

Marcin Kempa

Thanks for your detailed response.  Does users in failover directory take up another application license?  I have unlimited user license for Crowd but JIRA and Confluence have a limited user base license.  Should this be ok?  Thanks again for your help.

Marcin Kempa Atlassian Team Feb 13, 2018


Crowd counts each distinct user (no matter which directory the user comes from) that can login to applications defined in Crowd (including Crowd itself). Here you can find out more how it works with some examples.

When it comes to license counting in products, this is slightly different story, as products count users towards the license if they can access the product itself. If you are using connector directory, which synchronize from remote directory like Active Directory at given times, and if in Crowd you allow all users from such directory to login to applications like Jira and Confluence and all of those users are in groups that can access Jira and Confluence, then all of them will consume the licenses in Jira and Confluence and they will consume same number of license seats.

Now if you would like to optimize that, say that you have different numbers of users that use Jira and different number of users that use Confluence and additionally you would only like to count towards license users that actually logged in to those products and not all of your users in Active Directory, then you can use a feature in Crowd called default groups per application, which is described here. Please note that this feature is only available since the latest release of Crowd 3.1

You can also find some information in our public blogpost about Crowd.


I hope that this all makes sense. 

Marcin Kempa

thank you. for sake of completion, i would like to highlight my issue here so it is conclusive for anyone who may want to configure the same.

on my test server when i configured Delegated authentication, because the username was same in DC and Crowd, the same user exists and can log in.  great! but all the local group membership were lost even though i have not checked "synchronise group membership" option.  i do have "synchornise user details" checked.  any direction on this will be helpful.


Marcin Kempa Atlassian Team Feb 14, 2018

Could you elaborate more on this setup and configuration actions you've taken?

Did you create another new delegated directory connected to Active Directory and then all local groups were lost?



Marcin Kempa


Crowd Internal is currently setup for user authentication.  Previously, we were using JIRA Internal Directory.  We had migrated users and groups to Crowd.

I have configured a delegated authority connection and have checked the synchronize user detail and left the synchronize group membership unchecked.  This is the first and only delegated connection.  

I logged in with the user and it completely updated the user groups and the user was not assigned to any group.  I had disabled delegated authentication and user was then part of all the groups previously associated.

Marcin Kempa Atlassian Team Feb 14, 2018



I assume that when you refer to logging in, you mean logging in to one of the applications connected to Crowd. I also assume that the setup for Jira applications in Crowd looks more or less like:


+--- Delegated directory
+--- Internal directory (with users assigned to groups defined in Crowd)


When you login to Jira with a user defined in the Delegated directory (which delegates to your remote Active Directory for authentication)  your user does not have groups that you previously defined for them in the internal directory, however when you disable or remove from assignment of Delegated directory to Jira in Crowd, then your user is again member of groups defined in the Internal Driectory (you see that in Jira that certain groups created locally in Crowd are now assigned to this user). Is that correct understanding of your situation?

Groups in crowd are associated with the directory they were created and are not shared with users from other directories.  You could try to resolve this situation in two ways:

1. Create same local groups in the Delegated directory in Crowd (not in the remote Active Directory but using the Crowd's UI, it will create a group that will be only visible in Crowd and connected applications and such group won't be recreated in the remote Active Directory). Then you can assign your users to those groups to have the same config as in Internal Directory

2. Use memberships aggregation feature (checkbox on the Directory & Groups tab in application config). You can learn more about this here Please note that using this option may have some security implications as described here


Best Regards,

Marcin Kempa

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events