Hello,
We have been using OKTA to create users in our Jira Software internal directory, we wanted to use an app called SAML single sign-on with OKTA to manage users. In our Dev environment we installed and configured the app, by doing this it created a new directory which we named Test and synced the users from OKTA to the the test directory, we then made test the first directory and the Internal directory is second. We worry that since both directories have the same users, we would run into issues with user log-in. We were hoping if anyone can provide some guidance, if this is OK or should we look into wiping the internal directory.
Thank you,
Ian
It can cause issues if you don't understand how the server works with the directories.
It's not quite as simple as this, but think of each user account, wherever they are from as having a unique identifier inside the Jira data, as well as an identifier in each directory that might not be unique in Jira.
This is usually easier with an example. Imagine we have two directories, three people and four accounts:
Account | Directory | Jira ID |
Alice | d1 | alice-46 |
Bob | d1 | bob-31 |
Bob | d2 | bob-12 |
Charlie | d2 | charlie-82 |
I don't need to explain how Alice and Charlie are going to work, but Bob matters.
If you need to work with Bob, you'll find Bob only appears in Jira once, because it's the same in both directories. Jira reads the directories until it finds the first Bob, and stops.
Bob in d1 (bob-31) "masks" or "shields" Bob in d2 (bob-12)
If your admins reverse the order of the directories, they're going to cause Bob problems. Imagine Bob creates an issue before the change, while logged in as Bob (bob-31). After the change, Jira will be showing Bob as the reporter, but because Bob is now logged in as Bob (bob-12), if they ask "Reporter = Bob", they won't find the issue, because it's reported by Bob (bob-31)
Hi Nic,
Thank you for your quick response, We create Jira accounts using the person's AD username which translates to the SAM Account name in OKTA, We use the username to associate the accounts in Jira. Using your example with Bob, being listed in n both directories, Bob will have the same username for example (Bob1), I definitely have seen that switching the directories using Bob as an example he was still associated with the tickets he created or was assigned to and also the activity feed on the public profile was retained. Do you foresee any issues with this?
Thank you,
Ian
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The situation that @Nic Brough -Adaptavist- describes is only possible if a username for a pre-existing user record that was used and "left traces" in Jira has been later renamed to match another pre-existing username that also have been used and "left traces" in Jira.
This kind of renaming on itself is not an easy feat, as Jira won't let you create two simultaneously "active" records with the same username.
This does not apply to your situation. At least not right away.
The way you've described it, OKTA connector has created a new user directory in Jira and populated it with usernames from OKTA backend directory. By definition at this moment none of these "OKTA users" have logged in yet and not touched Jira.
Re: "not right away" applies if a user has an account in OKTA with one username, and in Jira they previously used a different username. If such users exist – their Jira username needs to be changed to match their OKTA one (see the "no easy feat" above). You will need to disable OKTA directory temporarily, rename the user in the internal one, then re-enable the OKTA one – so OKTA username "masks" the internal one, effectively merging two user records.
Again, my original suggestion to identify anyone who exists in Internal directory and doesn't exist in the OKTA one (based on the username) with our UserManagement for Jira app will help here.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello, @Ian
When a user has authenticated and is presented Jira (either by direct login or via OKTA SAML app) for authorisation, Jira performs a search for the user in all directories starting from the top, stopping as soon as it finds the user record and then uses that. This applies to group membership – it's the groups in the directory where the user was found that will matter.
See this article: Managing multiple directories
Despite somewhat scary tone, the presence of multiple directories won't be a problem, merely a potential cause of confusion (for humans).
I represent TechTime, an Atlassian Platinum Solution Partner in Aotearoa – New Zealand.
Assuming that your internal directory may contain users not present in the OKTA one, if you want to clean your internal directory up, feel free to use our UserManagement for Jira app on evaluation license.
You should be able to filter users by OKTA directory in Bulk User Actions, export to CSV, then use this CSV file as a filter for users in Internal directory.
Don't delete the users, as this will not work if they have touched anything in Jira.
However, you can create a temporary Delegated Authentication directory, and move users in bulk from the internal one to this temporary one, then disable (and eventually delete) the temporary directory completely.
If you need help, please don't hesitate to reach out to our 24x7 support
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi
JIRA is using Directory order to managed them so it will go through each directory to find the user. You should not have issue with a user in multiple directory, but group management is managed at the directory level so you may have to copy group membership from the local to the new directory.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.