What happens to accounts after Access is installed?
2 answers
2 accepted
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?
- Jira table names seem to require a jiraschema. prefix.
- Confluence table names seem to require a dbo. prefix.
- 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.
- I believe the Community and Atlassian University counts here too.
- 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.