nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What happens to accounts after Access is installed?

Jean Dupree

Hi everybody, my group is looking at Jira on the cloud and we are thinking of moving over, but haven't taken any steps yet. One thing is we want to know what happens to ur accounts - if we make Atlassian IDs to play around with a cloud site and migrate some data to see how it all works and then install Access, what happens to our accounts? Do they just change to become Access or managed accounts? Should we expect anything with our permissions to change or any other changes? Having a hard time understanding what the implications are of adding access and what happens to our accounts?

Accepted answers

Garrett Gifford

@jena - When you setup your domain it will pull all accounts in the Atlassian environment new and old.

Rob Horan

I'm going to post my experience with Atlassian Access and server to cloud migration - I'm not sure if this answers the question or if its spam, but hopefully this will help.

First - I don't mean to preface that to make it sound like it was a bad thing. Far from it. The setup of Atlassian Access was, for the most part, a pleasant surprise in terms of its ease. Granted, a good portion of the work that was done for this particular migration, was taken care of by the people I was performing the migration for, but only because I did not have direct access to their ADFS environment - so all of the information gathering on the ADFS side had to be done from their side. That said, together we were able to cut right through it with truly minimal effort. I could not have been happier in that regard.

Once it was set up, creating multiple access policies (for example, to include some users in SSO and exclude others) could not be simpler. Want to have a user in your organization that is not bound by SSO in case your identity provider is down? Super easy.

Here's where things got confusing. This migration involved a Jira site migration (due to JSM) and Confluence via the migration assistant.

The checklist for Jira site import involves generating an XML backup and performing a number of validation and cleanup steps, some of which are cleaning up users and groups. WELP... because we were going with Access (I think) Atlassian told us to generate a CSV file of users and groups from Jira and wipe those sections entirely from the XML backup. Atlassian then imported the users and groups to the client's site, where we could then review the upload prior to the site import. Truthfully, I loved this process, and think it should be included in the instructions as the primary method of user migration.

Two semi-minor frustrations with the checklist:

There are no checklist instructions for Windows. All of the CLI commands you need to run are Linux (or *NIX) specific. You're not SOL if you don't have a Linux or MacOS machine to work on, but there is ZERO guidance provided as to how you get around this. Short answer: you'll need a tool like CYGWIN or Git Bash. My experience with both is limited, but I performed this migration with CYGWIN and it worked just fine.
If you are using MS SQL Server for your Atlassian server applications, the scripts you get are GUARANTEED to fail, and once again, zero guidance is provided on how to fix them. Once you figure out what you need to do, adapting the scripts isn't hard, but you know... knowing what to do is what separates a DBA from a fry cook in this situation. My lessons learned here?
1. Jira table names seem to require a jiraschema. prefix.
2. Confluence table names seem to require a dbo. prefix.
3. Table and column names are case sensitive, and at least for these databases, had to be converted to uppercase.

Here's where the biggest downside comes in, and to be crystal clear, its a fault in the identity provider - and from what I understand, technically ADFS is NOT an identity provider. (it is an STS - that's as far as my knowledge goes at the moment, this is far from being my realm of expertise) If you have ADFS and you are considering a migration to the cloud, give serious thought to upgrading to Azure or incorporating Okta into your environment. I say this because Atlassian Access can ONLY work with ADFS for SSO. It's an ADFS limitation, but the bottom line is you miss out on multi-factor authentication, and much much worse, you lose out on any user provisioning since ADFS does not support the industry standard SCIM provisioning.

What does this mean? It means Atlassian Access will, for all intents and purposes, be equivalent to the local directory for Jira and Confluence. It means forget about using AD groups to manage your permissions and group memberships in your products. When you migrate, you'll get a snapshot of your AD users and groups, but after that IT'S UP TO YOU TO MAINTAIN ALL OF IT, MANUALLY. All user and group additions, removals, and any other user management activity is manual. There is no sync with AD.

Second major downside to Access - and it's fully documented BUUUUUUUUT - here are the rules:

The first step in setting up Access is verifying your domain(s).
Once set up, all existing Atlassian accounts with email addresses from your verified domain become managed accounts. THIS IS VERY, VERY IMPORTANT TO REMEMBER
With an Atlassian account, you can use just one account to log in to any Atlassian products, such as Jira (the whole family), Confluence, Bitbucket, Opsgenie, Statuspage, Trello.
- I believe the Community and Atlassian University counts here too.
- More importantly, this can apply to access to cloud products at any organization that the user has access to.
To be counted as a unique billable user for your Atlassian Access subscription, the user needs to have a managed account in your organization with access to at least one Atlassian Access-supported product.
and the part that's likely going to kick your ass up and down the block...
- Trello Free is an Access-supported product.
- Free tiers of the main apps apply.
- Access to another organization's Atlassian Cloud products via an account at your organization also counts.

Soooo.... if you have people in your organization that set up free Trello/Jira/Confluence/etc accounts thinking it wouldn't cost the company a dime, or if people in your organization set up an Atlassian account with their work email address to access Atlassian Cloud products outside of your organization (say if they were performing work for a client on their site) well.... start practicing your Mr. Krabs voice, because each of them is now draining your wallet with a paid Access account.

All comments

Garrett Gifford

@jena - When you setup your domain it will pull all accounts in the Atlassian environment new and old.

Rob Horan

hi @Garrett Gifford - I am looking for similar information - I'm going to be helping a team with their migration and (I believe) my email address, though not part of their organization, is within their AD structure. When they move to Atlassian Access will my Atlassian account suddenly become a managed account under their Access account?

Garrett Gifford

@Rob Horan - If you have the same domain yes. I created a secondary account with admin level permission on Jira just incase.

Also as a side note if a user has an account in Trello / Jira / Confluence they all get pulled in.

Rob Horan

So if their domain is a.com and my account is linked to b.com all of the a.com users will me managed by Access, but my b.com account will remain independent?

Rob Horan

I'm going to post my experience with Atlassian Access and server to cloud migration - I'm not sure if this answers the question or if its spam, but hopefully this will help.

Here's where things got confusing. This migration involved a Jira site migration (due to JSM) and Confluence via the migration assistant.

Two semi-minor frustrations with the checklist:

There are no checklist instructions for Windows. All of the CLI commands you need to run are Linux (or *NIX) specific. You're not SOL if you don't have a Linux or MacOS machine to work on, but there is ZERO guidance provided as to how you get around this. Short answer: you'll need a tool like CYGWIN or Git Bash. My experience with both is limited, but I performed this migration with CYGWIN and it worked just fine.
If you are using MS SQL Server for your Atlassian server applications, the scripts you get are GUARANTEED to fail, and once again, zero guidance is provided on how to fix them. Once you figure out what you need to do, adapting the scripts isn't hard, but you know... knowing what to do is what separates a DBA from a fry cook in this situation. My lessons learned here?
1. Jira table names seem to require a jiraschema. prefix.
2. Confluence table names seem to require a dbo. prefix.
3. Table and column names are case sensitive, and at least for these databases, had to be converted to uppercase.

Second major downside to Access - and it's fully documented BUUUUUUUUT - here are the rules:

The first step in setting up Access is verifying your domain(s).
Once set up, all existing Atlassian accounts with email addresses from your verified domain become managed accounts. THIS IS VERY, VERY IMPORTANT TO REMEMBER
With an Atlassian account, you can use just one account to log in to any Atlassian products, such as Jira (the whole family), Confluence, Bitbucket, Opsgenie, Statuspage, Trello.
- I believe the Community and Atlassian University counts here too.
- More importantly, this can apply to access to cloud products at any organization that the user has access to.
To be counted as a unique billable user for your Atlassian Access subscription, the user needs to have a managed account in your organization with access to at least one Atlassian Access-supported product.
and the part that's likely going to kick your ass up and down the block...
- Trello Free is an Access-supported product.
- Free tiers of the main apps apply.
- Access to another organization's Atlassian Cloud products via an account at your organization also counts.

Jean Dupree

Ha ha ha Mr Crabs, that's great

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

migration

sso

atlassian-guard

active-directory

access

cloud-migration

identity-manager