AD groups setting - Help with which option to chose ?

[sn]

hi all,

we use LDAP for user authentications and JIRA groups for permissions in JIRA. we want to move to AD groups for authentications and group membership and auto-disabling the users when they leave.

Our AD groups have everyone within the company and we want to have users only with certain permissions added to our JIRA groups. EX - we do not want business users to have the "Release" function.

when a new user is on board, they will send an email to the network team with the details on what level of access they would need. if they need Confluence, JIRA, Bamboo access, they will specify the AD group and users will be added to those groups. when they leave, they should be disabled from all these groups.

1) From my understanding, I would need the "Read Only" because we want to control the licenses. our JIRA is only internal to IT and not intended for all of the company. so, if we chose Read Only, with Local Groups, user will be automatically added to certain groups.

I think we need "Read Only"

am I on the right path here ?

2) Nested Groups - we want to enable this option. so, As per our permission scheme,  SU group in JIRA gets all of the standard permissions. so, we will have a group "IT_JIRA_SU" in AD and map it to SU in JIRA.

and if a user needs "Release" permission ( this permission is mapped to "PA" group in JIRA). I will have another group IT_JIRA_PA" in AD and this group will be nested within the parent "IT_JIRA_SU". when user needs all standard permissions + release permission, they can be added to both these groups in AD.

would this work or am I overlooking anything here ? please suggest.

thanks !

[Daniel Eads]

Using AD groups can definitely lessen the time needed to manage user permissions! Let's see if we can clarify things.

1. The difference between "Read Only" and "Read Only, with Local Groups" is simply if you can use groups that are created and managed in Jira. I personally prefer to have Local Groups enabled for flexibility in Jira even if all the changes are being done in AD. At some point you may find Jira administrators need to make changes but don't have permissions to change groups in Active Directory. This is up to you though - in your current situation it sounds like you would be fine with either. 
   
   I just want to clear up the point you mentioned about licenses - the directory type will not have any impact on how licenses are assigned. You are going to be using an AD group to add users to Jira no matter if local groups are enabled or not. Having local groups however might help you if you use multiple AD groups to allow users to log in. As an example, maybe IT_JIRA_SU and IT_JIRA_PA have permission to log in to Jira. With local groups enabled, you can add users from both these AD groups into jira-users. Then you can use jira-users as a shortcut in Jira for "everyone who can log in" instead of needing to add multiple AD groups all over the place.
   
   
2. This will work as you described. Jira flattens the groups out during sync, so a user in the PA group you described will show up as a member of PA and SU in Jira.

Cheers!
Daniel

[sn]

Thank you Daniel ! I have a follow-up question though

The difference between "Read Only" and "Read Only, with Local Groups" is simply if you can use groups that are created and managed in Jira. I personally prefer to have Local Groups enabled for flexibility in Jira even if all the changes are being done in AD. At some point you may find Jira administrators need to make changes but don't have permissions to change groups in Active Directory. 

a follow up q - so, Even if we opt for "Read Only, with Local Groups" , we can still follow the process of creating those groups in AD and have users added to them through AD but additionally we  will have ability to create a group in JIRA or manage membership in JIRA they will be updated in AD automatically..

If I chose Read Only then I can create groups only through AD and once the groups from AD flow to JIRA then I can associate them with permission schemes ?

Am I understanding this correctly ?

[Daniel Eads]

Sounds mostly right - just want to clarify this:

additionally we  will have ability to create a group in JIRA or manage membership in JIRA they will be updated in AD automatically..

Changes you make in Jira will never make it back to Active Directory with either Read Only option. So to be super specific: you can created Jira groups with "Read Only, with Local Groups" but no group membership changes you make in Jira (no matter if it is a Jira or AD group you're trying to change) will go back up to Active Directory.

The "Read Only" part of the connection type indicates that Jira will not make any changes to Active Directory, even if you have local groups.

[sn]

ok. understood. appreciate the quick response Dan!

Having local groups however might help you if you use multiple AD groups to allow users to log in. As an example, maybe IT_JIRA_SU and IT_JIRA_PA have permission to log in to Jira. With local groups enabled, you can add users from both these AD groups into jira-users. Then you can use jira-users as a shortcut in Jira for "everyone who can log in" instead of needing to add multiple AD groups all over the place.

1) How can i achieve the above ?

Like i mentioned all users in the company will be in the AD and hence everyone with valid SSO can login. 

2) So, can we restrict users from logging in ? or more specific how can we limit our licenses. 

As of now, we have set 'jira-users' as default group. Any user who has an active SSO and is in LDAP will be able to login to JIRA and added to this group by default. That group is not associated to any permissions. This was to put a check and limit it to IT. But that is consuming our licenses. 

EX- 'jira-users' are 60 users and 'SU' group has 45 users. 'SU' is the group that will provide any general permissions in JIRA. If we make 'SU' as default then any user within the company can login and have permissions to work on projects. Admins will not be required to add permissions so, we can never put a 'check'.

Please provide guidance.

thanks !

[Daniel Eads]

Check out this document for the how-to on setting application access based on groups (will help with licensing) 

In addition, I'd recommend using an LDAP filter on the AD user directory in Jira. You can filter what group(s) you want Jira to sync users from AD from, which will:

1. Make your user syncs run a little faster
2. Prevent people who aren't in those groups from using licenses even by mistake/misconfiguration

Just make sure you document this well so you're not confused later when troubleshooting some users that aren't syncing to Jira! (They'll need to be members of the AD groups you're filtering on). We've got documentation to help with the LDAP search filter too.

[sn]

sorry about the delayed response Daniel. thank you for the information.

another follow-up question - when the AD groups are initially created and the existing users from JIRA groups are added to the newly created AD groups then do we have to create those groups again in JIRA and map or can we just use the original JIRA groups and sync users  from AD-->JIRA using the filters ( for existing users) ?

[sn]

@Daniel Eads

hi dan - Before creating another ticket, i thought i will try adding a response here to get some information.

My understanding is when we move to AD groups the terminated users will be automatically deactivated in JIRA. and this is one of the main reasons we want to move the security to AD.

Currently, we have LDAP as the first directory then we have JIRA Internal Directory. Internal directory is where all the group specific information is stored. 

when a new user is added, unless they are active in LDAP, they cannot login to JIRA.

but when a user leaves the company, they have to be manually deactivated in JIRA. I'm assuming this is because of the user being in the Internal directory as well.

To make this an automatic process of when some leaves the company, they should be deactivated in JIRA, what/how should the configuration change.

thanks in advance !