Hello team, we've noticed duplicate users after on...
# ask-a-descoper
t
Hello team, we've noticed duplicate users after one of our customers has migrated over to SSO and wanted to clarify how we should be resolving this. I believe a new user got created for each employee when they tried logging in through SAML SSO. When speaking with Gilad about this in a previous conversation, they had told us the user should automatically be converted but that wasn't the case here, possibly due to some incorrect attribute mappings. What's unclear to me is who should be doing the resolution here. Whether it's us, our customer, or something we'd need to clean up with Descope? cc: @Aparimeya Taneja
d
We convert the existing user to be an SSO user in case both existing and new users are part of the same tenant and assigned to no more than single tenant. And the new SSO user has the same NameID of the existing user login id
t
Mhm, but that didn't happen here. It created a 2nd record for each user. So I'm trying to get to the bottom of why it didn't and how we resolve it now.
d
Please share a screenshot of these two users from the users table
Screenshot from the table itself and another one when you click edit on that user (make sure tenants are shown there)
t
Yes I will share over DM, didn't want to share that in a public channel.
d
ok
Also send your project id and tenant id
t
@Doron Sharon or whoever can help answer this. We've mitigated the issue going forward by turning on the convert existing user after successful login setting. But to resolve this for our existing tenant, what do you recommend, should we delete the non-SSO users and consolidate that ourselves?
c
@Taejin Hwang - I was writing up a message to your next message as well, I'll drop that here, but I assume that Dorsha has already generally touched on this as well. Yes, since the user is associated with an SSO account that is on
otherdomain
they will need to login with that same account to track as the same user. You could allow for sign up for the other
example
domain, but then the users would not be merged without some sort of additional logic in your flow to merge. Generally we only merge automatically on verified email accounts that are identical. We can't assume aliased or similar named accounts on different domains are the same. But furthermore, once a user has been converted to SSO, they should only be authenticated with SO. https://docs.descope.com/sso/merging-sso-identities-risk
Copy code
But to resolve this for our existing tenant, what do you recommend, should we delete the non-SSO users and consolidate that ourselves?
• You'll need to merge them yourself manually • In the current state, they can log in with either SSO or non-sso methods, but they will be treated as separate accounts.
t
Thank you so much for explaining, we will merge them manually and think a bit more about how we're going to address the domain and aliasing problem when we migrate a tenant to SSO.
❤️ 1