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

Setting up Crowd User Directory Failover

Kashif Pervaiz

Hi,

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.

Thx,

Kashif

Accepted answers

Marcin Kempa

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

All comments

Marcin Kempa

Hi @Kashif Pervaiz,

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.

Hope that helps,

Marcin Kempa

Kashif Pervaiz

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

Hi,

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

Kashif Pervaiz

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.

cheers!

Welcome!

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

Quick Links

Find more posts tagged with

crowd