Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Integration of Okta with Jira

Jonathan Kimrey
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 28, 2020

I've been doing some testing on how we can integrate Okta with Jira and there are some aspects that are confusing me that I'm hoping to get clarity on.

 

We are running Jira server 8.6.1 and currently have the following user directories:

  • LDAP #1 (Microsoft Active Directory - Read Only with Local Groups) sync'd every time the user logs in.  User Name Attribute = sAMAccountName
  • LDAP #2 (Microsoft Active Directory - Read Only with Local Groups) sync'd every time the user logs in. User Name Attribute = sAMAccountName.  Note - the users in directory #1 and directory #2 are unique for the majority (but not all).  
  • Jira Internal Directory

 

As mentioned, the goal is integrate Okta authentication, allowing SSO.  In our AD groups, one of the customized fields contains a unique ID for each user.  When we turn on Okta integration, Okta will pass this custom field value as the username.

The plan is, at that point, to change the User Name Attributes in both directories from sAMAccountName to this custom field in AD.  So the value being passed from Okta will match the username set in Jira.

 

The other issue we must address before integrating Okta is converting users from the Jira Internal Directory to one of the LDAP AD groups.  The Internal Directory users were created with unique username/passwords that do not match those in the AD groups.  The same users are in the AD groups, however, so we need to get them (with history/items/etc) moved to the appropriate AD user.  Once that has been completed then we would make the change noted above - changing the User Name Attribute to the custom field.

 

In both instances we need to insure that the items/history/etc is still there for each user.

 

Any suggestions on how to handle these requirements?

 

We have done some research already and it appears that for converting the local users to one of the AD groups can be accomplished by:

  • Temporarily disabling the AD group that contains the equivalent local user.  Disabling is necessary so that the local user name can be renamed to match the AD username.
  • Renaming the local user to match the AD user.
  • Re-enabling the AD Group (which remains a higher priority than the local user group).

I know that in doing this, the groups the local user was assigned to will not transfer over - for that we can export the information from the table and use the CLI tool to update the AD user.

Is the above method the best way to handle the requirement of getting the local users moved to the AD users?  Other than the groups, should everything else transfer successfully?

 

Once that has been completed, we would then change the User Name Attributes in both AD groups to the custom field.  I would assume that since we have "User Unique Attribute" set to objectGUID, Jira would recognize that it was the same user and nothing would be lost.

 

I'm still somewhat confused on what happens from an internal perspective, however, as I see additional rows being created on the app_user and cwd_user tables.

 

Any advice/suggestions would be greatly appreciated.


Thanks

 

0 answers

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
SERVER
TAGS
AUG Leaders

Atlassian Community Events