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
As usually Active Directory is read-only for all incorporated mortals... still Jira users do need to be able to use and manage groups.
As the Jira administrators time is very limited, it's i not possible to manage these groups (inability to rename them being just agravating factor).
As an workaround I managed to trick the Active Directory to get a limited number of groups inside Jira by adding them to AD mailing list that I own. This means that by (de)subscribing mailing lists from my Meta-Jira-Groups mailing list I can add and remove AD groups one by one.
The great thing about this is that each of this groups has its own managers so the management of these groups is externalized to the real owners, falling back to IT but never to Jira admins (great!).
Now the big problem is that we still need to be able to manage same groups inside jira, while having few managed on AD.
How can we do this?
I think in your case the best option is use the Delegated Authentication Directory:
A Delegated Authentication directory combines the features of an internal Crowd directory with delegated LDAP authentication. This means that you can have your users authenticated via an external LDAP directory while managing the users and groups in Crowd.
I hope it helps.