I have an installation with 100 Jira user licenses and 2000 Confluence user licenses. Right now, we are using the same AD group for authentication for both applications because we have not started widespread use of Confluence yet. (we are currently using 71 of the 100 Jira licenses)
I need to separate these groups out without losing the ability for some users to go back and forth between Jira and Confluence as the same user without re-authenticating. Is it as simple as creating a different AD group for the Confluence users? Will I have any issues with duplicate users if some members belong to both groups?
I'm sure you will get a few different answers to this one...so here is one option. We had to do this about 2 years ago for the same reason. There were a couple things we did to get it to work with seamless 'back and forth' as you mention. The other reason we did it this way, was because of the requirements of the Security team for that organization - they wanted all permissions to be managed in the AD groups.
Also recommended, is that you spin up test instances and then configure and test whatever method you choose before rolling it out to your production instances. Be sure to test logging in as a member of each of the different groups below, and also as a JIRA 'internal' and Confluence 'internal' user' in your certifcation test.
1) Created the group structure in AD as below, then in the User Directory configuration, we enabled the Nested Groups option.
jira-users (members: sally, joe, tom, john)
jira-admins (members: susan, sam)
wiki-users (members: sally, joe, tom, john, etc.)
wiki-admins (members: susan, sam)
2) map these groups to JIRA and Confluence (in Global Permissions)
3) added the context path of JIRA and WIKI to each instance. After doing this we had no issues going back and forth. For example:
Here are the links to the context path documents.
Another tip: we named the groups starting with WIKI in AD, becuase in the filter, we were picking up CONFerence rooms that were listed in AD. And the security team didn't want the filter and groups to be that long, so we changed it to something shorter and not starting with CONF.
Hope some of this helps.
Sorry forgot this other link:
and, another step to make sure you update the BASE URL for each instance to include the new context path.
Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG