Hello! Is the following scenario possible to achieve in JIRA/Confluence with or without Crowd: * In Active Directory (AD) we create a group called DepartmentA. * In Internal Directory (ID) we create a group called Users. * In JIRA/Confluence/Crowd we nest AD-group DepartmentA inside ID-group Users. * In JIRA/Confluence/Crowd we manage authorization/authentication via ID-groups * Removing/adding user in AD-group DepartmentA is reflected in ID-group Users. So basically authentication and "lower level" (from JIRA & co.'s point of view) group membership is implemented in AD, but there exists an additional abstraction layer within ID. What i am after is the ability to add several external groups (from AD) inside a single internal group (f.ex. in Confluence). Here is an additional extended example: * In Active Directory (AD) we create a group called DepartmentA. * In Active Directory (AD) we create a group called DepartmentB. * In Active Directory (AD) we create a group called DepartmentC. * In Active Directory (AD) we create a group called ManagersA. * ... * In Internal Directory (ID) we create a group called UsersA. * In Internal Directory (ID) we create a group called ManagersA. * ... * In JIRA/Confluence/Crowd we nest AD-group DepartmentA inside ID-group UsersA. * In JIRA/Confluence/Crowd we nest AD-group DepartmentB inside ID-group UsersB. * In JIRA/Confluence/Crowd we nest AD-group DepartmentC inside ID-group UsersC. * In JIRA/Confluence/Crowd we nest AD-group ManagersA inside ID-group UsersA. * In JIRA/Confluence/Crowd we nest AD-group ManagersA inside ID-group ManagersA (etc) * In JIRA/Confluence/Crowd we manage authorization/authentication via ID-groups * Removing/adding user in AD-group DepartmentA is reflected in ID-group Users. * Removing all AD-groups and users created in steps 1-6 has no effect on ID-groups So my primary interest is in creating a single "failure point" for the case our AD gets reorganized (very likely to happen in near future). If all those DepartmentX/ManagersX-groups (and users!) would get removed from AD, then that would have no effect to the organization described with groups in Internal Directory. When new AD groups are implemented, i'd simply map/nest the relevant ones to the Internal Directory groups that i created in ID before AD reorganization. Does that make sense? Best Regards, J. Arola p.s. This would be so much more easier to draw :-)

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

Confluence/Jira/Crowd - Nesting/mapping LDAP/AD-group in Internal Directory -group

Jukka Arola

Hello!

Is the following scenario possible to achieve in JIRA/Confluence with or without Crowd:

In Active Directory (AD) we create a group called DepartmentA.
In Internal Directory (ID) we create a group called Users.
In JIRA/Confluence/Crowd we nest AD-group DepartmentA inside ID-group Users.
In JIRA/Confluence/Crowd we manage authorization/authentication via ID-groups
Removing/adding user in AD-group DepartmentA is reflected in ID-group Users.

So basically authentication and "lower level" (from JIRA & co.'s point of view) group membership is implemented in AD, but there exists an additional abstraction layer within ID.

What i am after is the ability to add several external groups (from AD) inside a single internal group (f.ex. in Confluence). Here is an additional extended example:

In Active Directory (AD) we create a group called DepartmentA.
In Active Directory (AD) we create a group called DepartmentB.
In Active Directory (AD) we create a group called DepartmentC.
In Active Directory (AD) we create a group called ManagersA.
...
In Internal Directory (ID) we create a group called UsersA.
In Internal Directory (ID) we create a group called ManagersA.
...
In JIRA/Confluence/Crowd we nest AD-group DepartmentA inside ID-group UsersA.
In JIRA/Confluence/Crowd we nest AD-group DepartmentB inside ID-group UsersB.
In JIRA/Confluence/Crowd we nest AD-group DepartmentC inside ID-group UsersC.
In JIRA/Confluence/Crowd we nest AD-group ManagersA inside ID-group UsersA.
In JIRA/Confluence/Crowd we nest AD-group ManagersA inside ID-group ManagersA (etc)
In JIRA/Confluence/Crowd we manage authorization/authentication via ID-groups
Removing/adding user in AD-group DepartmentA is reflected in ID-group Users.
Removing all AD-groups and users created in steps 1-6 has no effect on ID-groups

So my primary interest is in creating a single "failure point" for the case our AD gets reorganized (very likely to happen in near future).

If all those DepartmentX/ManagersX-groups (and users!) would get removed from AD, then that would have no effect to the organization described with groups in Internal Directory. When new AD groups are implemented, i'd simply map/nest the relevant ones to the Internal Directory groups that i created in ID before AD reorganization.

Does that make sense?

Best Regards,

J. Arola

p.s. This would be so much more easier to draw :-)

Accepted answers

All comments

Bruna Griebeler

Hi there!

If I undertood well, the answer is yes.

When you have a group in your LDAP, and this groups is set to import the user into your Confluence (eg), all the changes you made in you LDAP will be reflect in you Confluence as soon as they are synchronized again.

Hope it helps!

Daniel Borcherding

Jukka,

Just to expand on what Bruna said. Group within Confluence exist separately from directories. Both internal and external directory users may be part of the same group. You are limited in group names by what the group is called in AD. There is no way to map an AD group DepartmentA to an ID group called Users from just within Confluence. They must have the same name to be administered using the same set of global permissions. I am including a document that outlines our global permissions structure below.

https://confluence.atlassian.com/display/DOC/Global+Permissions+Overview

You would be able to administer each group (Users and DepartmentA) individually but I don't think that is what you want to do.

Bruna was correct in stating that removing or adding a user to the DepartmentA group in AD would be picked up by an synchronization of Confluence. You can wait the standard one hour for the change to be rolled over automatically or you can trigger a manual synchronization of the directory from the Confluence Admin > User Directories tab. Just hit the "Synchronize" button next to your AD connection.

If you add Crowd to the mix things get more interesting. Crowd supports nested groups. This is a way of aliasing multiple groups or users into another group. First yould would make sure that your Crowd AD conector has "enable nested groups" slected. You would then need to create the "Users" group in that new conector. After creating the group you would click on it from the group list and then click on the "Direct Members" tab. That screen will allow you to nest the DepartmentA group inside it. That way any changes that are made to the DepartmentA group in AD would be mirrored into the "Users" group. You would follow the synchronization steps above to make sure those changes are propogated.

Please let us know what we can furhter help with.

Jukka Arola

I made a slight improvement to the question to better match my situation using vocabulary used in JIRA&co. ("map"=>"nest"). My issue is that i would like to nest a group from Active Directory inside a group in Internal Directory. I think that this is not possible, or at least i could not find a way to implement it in JIRA, Confluence or Crowd.

Jukka Arola

Thank you for your answer, but this is not quite the scenario i'm trying to achieve. I edited my question for better clarity (i hope .

Daniel Borcherding

I think there may be a disconnect here on the functionality you are looking for. What are you trying to achieve? I mentioned above that groups are independent of directories. There should be no need to nest an AD groups inside of internal directories groups. Each directory can have their own independent set of groups. If the group names are the same you can effectively treat both groups as the same from the global permissions screen.

Jukka Arola

What i am after is the ability to add several external groups (from AD) inside a single internal group (f.ex. in Confluence). I'll add an additional example to the question.

Jukka Arola

I managed to get this requirement removed from the project. So now i'm able to use AD-groups directly in JIRA/Confluence authn/z. If it's ok, i'lll leave the question open anyway for now. If you need more clarification about the original requirement, i'm more than happy to provide information!

Welcome!

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

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

confluence

jira

crowd

authentication

active-directory