You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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,
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.
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.
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.
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 https://confluence.atlassian.com/crowd/effective-memberships-with-multiple-directories-672530810.html. Please note that using this option may have some security implications as described here https://jira.atlassian.com/browse/CWD-4893