-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
3
-
Minor
-
Issue Summary
When verifying a domain, it goes through 3 statuses:
- UNVERIFIED -> VERIFIED_UNCLAIMED -> VERIFIED
The VERIFIED_UNCLAIMED indicates that the domain verification was already done successfully, but no accounts from that domain have been claimed yet.
When syncing users from an Identity Provider, the provisioning service will consider the users from that domain as external users (from unverified domains).
This is particularly problematic when trying to update users' email addresses. Leading to orphaned SCIM records (lost of access) and duplicated accounts.
Steps to Reproduce
- Verify domain A and claim the accounts.
- Verify domain B and don't claim any accounts.
- Sync a user from domain A with email user@domainA.com
- Change the user's email address on the Identity Provider side: user@domainB.com
Expected Results
The original account's email should be updated.
Actual Results
- The original account will be unlinked from the SCIM record, possibly blocking the users from accessing products (via synced groups).
- The SCIM record will now contain the new email address, but without any link to the new (duplicate) account.
- IF the user tries to authenticate with the new email address, a duplicate account will be created.
- If a sync happens and triggers an update to that specific SCIM record (like adding that user to a group or modifying any attributes), the SCIM record will be linked to the new (duplicate) account.
Workaround
The workaround consists of making sure that at least 1 user is claimed, which will move the domain to the VERIFIED status.
If the issue already happened and a duplicate account was created:
Option 1:
- Delete the SCIM record using the endpoint Delete user in SCIM DB
- Modify the duplicate account's email to something else. For example, free_user@domainB.com
- Modify the original account's email to the email released in step 2.
- Resync from the Identity Provider to recreate the record. Depending on the Identity Provider, a full restart of the provisioning service might be required.
Option 2:
Contact Atlassian Support so the support team for assistance.