Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

migrate all old data and users to new one instance with SAML SSO with mathing users

it August 30, 2020

Good afternoon. We are planning to migrate from the current confluence instance to the new one (data-centr). We have such a problem.
We want to migrate all the data, history, ownership of spaces and so on from the old confluence to the new one.
To do this, from the standard tools, We found a restore from backup exported to XML.
But, we also want to connect our SAML SSO IdP to a new instance, and after doing some tests, we came across the fact that confluence stores a list of internal users, and when connecting SSO, duplication of users begins.
Is it possible to solve this problem with some standard tools?
In other words, we want to transfer the existing data and users from our self-hosted confluence to the new license, configure the SSO and get a match of users. Because when you configure SAML SSO - ID of users seems to change from internal to another.
Can you recommend something for this type of migration, some standard ways.
From the documentation that I read, I didn't find a similar problem.

Or maybe we just configured something wrong, then we would like to get some information about why our IdP causes doubling of internal confluence users, I think it's abnormal and must be the way to connect SSO without this.

1 answer

0 votes
Daniel Eads
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
September 17, 2020

Hello, welcome to the Community!

I see you've asked two questions, so first I'll answer this and try to assist separately with the second one.

After doing the import, you can add a second user directory to Confluence and set it as higher in the list than the Confluence internal directory. As long as the usernames match, the other directory will take over. It looks like from your other question, you're looking at using Crowd as the external directory.

If the usernames you've imported into the internal directory don't match what's in your LDAP or Crowd server, that's when things get dicey. For example, if "John Doe" is "john" in the internal directory but "jdoe" in LDAP, the users won't match up properly.

Hopefully that answers this portion of the question!

Cheers,
Daniel

Suggest an answer

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

Atlassian Community Events