-
Bug
-
Resolution: Unresolved
-
Low
-
2
-
Severity 3 - Minor
-
Issue Summary
If a customer syncs the same account via both Azure AD for nested groups and SCIM in the same organization and that account's email is updated in their identity provider, the email update will generally be synced via SCIM (due to automatic push from the IdP) before it is synced via the Azure AD for nested groups integration (due to the scheduled sync interval). If this occurs for a managed account, the email update via the Azure AD for nested groups integration will unlink the account and remove all synced memberships because the account is already synced as a claimed account by an organization — even though it's the same organization.
Steps to Reproduce
- Configure two identity provider directories in the same organization, both connected to the same Azure tenant:
- One via SCIM (manual configuration)
- One via Azure AD for nested groups (automatic configuration)
- Sync an account on a verified domain via both integrations.
- After both integrations have finished syncing, update the email of the synced user in Azure to a different value on the same verified domain.
- Almost immediately after saving the change, the synced account's email is updated to the new value in Atlassian via SCIM.
- Wait for the next automatic sync cycle for the Azure AD for nested groups integration to complete.
Expected Results
The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value and the account remains synced via both integrations with memberships to groups synced via each integration intact.
Actual Results
The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value, but because the account is already synced with the new email via their sync record for the SCIM integration the account is unlinked from the sync record for the Azure AD for nested groups integration, removing all memberships to groups that are synced via the Azure AD for nested groups integration.
Workaround
Currently, there is no known workaround to avoid this behavior. A workaround will be added here when available.
For accounts already in this state, you can contact Support to relink the affected account(s) to the Azure AD for nested groups integration.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[ACCESS-1881] Updating the email of a managed account synced via both SCIM and Azure AD for nested groups unlinks the account from the Azure AD for nested groups integration
| Support reference count | Original: 1 | New: 2 |
| Labels | Original: guard-s8 | New: RIBS-SHORT guard-s8 |
| Labels | New: guard-s8 |
| Was this caused by a recent change? | Original: Yes, existing functionality was broken [ 19030 ] | New: No [ 19032 ] |
| Status | Original: Needs Triage [ 10030 ] | New: Gathering Impact [ 12072 ] |
| Support reference count | New: 1 |
| Description |
Original:
h3. Issue Summary
If a customer syncs the same account via both Azure AD for nested groups and SCIM in the same organization and that account's email is updated in their identity provider, the email update will generally be synced via SCIM (due to automatic push from the IdP) before it is synced via the Azure AD for nested groups integration (due to the scheduled sync interval). If this occurs for a managed account, the email update via the Azure AD for nested groups integration will unlink the account and remove all synced memberships because the account is already synced as a claimed account by an organization — even though it's the same organization. h3. Steps to Reproduce # Configure two identity provider directories in the same organization, both connected to the same Azure tenant: ** One via SCIM (manual configuration) ** One via Azure AD for nested groups (automatic configuration) # Sync an account on a verified domain via both integrations. # After both integrations have finished syncing, update the email of the synced user in Azure to a different value on the same verified domain. ** Almost immediately after saving the change, the synced account's email is updated to the new value in Atlassian via SCIM. # Wait for the next automatic sync cycle for the Azure AD for nested groups integration to complete. h3. Expected Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value and the account remains synced via both integrations with memberships to groups synced via each integration intact. h3. Actual Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value, but because the account is already synced with the new email via their sync record for the SCIM integration the account is unlinked from the sync record for the Azure AD for nested groups integration, removing all memberships to groups that are synced via the Azure AD for nested groups integration. h3. Workaround Currently, there is no known workaround to avoid this behavior. A workaround will be added here when available. Once an account is in this state, you can [contact Support|https://support.atlassian.com/contact/] to relink the affected account(s) to the Azure AD for nested groups integration. |
New:
h3. Issue Summary
If a customer syncs the same account via both Azure AD for nested groups and SCIM in the same organization and that account's email is updated in their identity provider, the email update will generally be synced via SCIM (due to automatic push from the IdP) before it is synced via the Azure AD for nested groups integration (due to the scheduled sync interval). If this occurs for a managed account, the email update via the Azure AD for nested groups integration will unlink the account and remove all synced memberships because the account is already synced as a claimed account by an organization — even though it's the same organization. h3. Steps to Reproduce # Configure two identity provider directories in the same organization, both connected to the same Azure tenant: ** One via SCIM (manual configuration) ** One via Azure AD for nested groups (automatic configuration) # Sync an account on a verified domain via both integrations. # After both integrations have finished syncing, update the email of the synced user in Azure to a different value on the same verified domain. ** Almost immediately after saving the change, the synced account's email is updated to the new value in Atlassian via SCIM. # Wait for the next automatic sync cycle for the Azure AD for nested groups integration to complete. h3. Expected Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value and the account remains synced via both integrations with memberships to groups synced via each integration intact. h3. Actual Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value, but because the account is already synced with the new email via their sync record for the SCIM integration the account is unlinked from the sync record for the Azure AD for nested groups integration, removing all memberships to groups that are synced via the Azure AD for nested groups integration. h3. Workaround Currently, there is no known workaround to avoid this behavior. A workaround will be added here when available. For accounts already in this state, you can [contact Support|https://support.atlassian.com/contact/] to relink the affected account(s) to the Azure AD for nested groups integration. |
| Description |
Original:
h3. Issue Summary
If a customer syncs the same account via both Azure AD for nested groups and SCIM in the same organization and that account's email is updated in their identity provider, the email update will generally be synced via SCIM (due to automatic push from the IdP) before it is synced via the Azure AD for nested groups integration (due to the scheduled sync interval). If this occurs for a managed account, the email update via the Azure AD for nested groups integration will unlink the account and remove all synced memberships because the account is already synced as a claimed account by an organization --- even though it's the same organization. h3. Steps to Reproduce # Configure two identity provider directories in the same organization, both connected to the same Azure tenant: ** One via SCIM (manual configuration) ** One via Azure AD for nested groups (automatic configuration) # Sync an account on a verified domain via both integrations. # After both integrations have finished syncing, update the email of the synced user in Azure to a different value on the same verified domain. ** Almost immediately after saving the change, the synced account's email is updated to the new value in Atlassian via SCIM. # Wait for the next automatic sync cycle for the Azure AD for nested groups integration to complete. h3. Expected Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value and the account remains synced via both integrations with memberships to groups synced via each integration intact. h3. Actual Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value, but because the account is already synced with the new email via their sync record for the SCIM integration the account is unlinked from the sync record for the Azure AD for nested groups integration, removing all memberships to groups that are synced via the Azure AD for nested groups integration. h3. Workaround Currently, there is no known workaround for this behavior. A workaround will be added here when available |
New:
h3. Issue Summary
If a customer syncs the same account via both Azure AD for nested groups and SCIM in the same organization and that account's email is updated in their identity provider, the email update will generally be synced via SCIM (due to automatic push from the IdP) before it is synced via the Azure AD for nested groups integration (due to the scheduled sync interval). If this occurs for a managed account, the email update via the Azure AD for nested groups integration will unlink the account and remove all synced memberships because the account is already synced as a claimed account by an organization — even though it's the same organization. h3. Steps to Reproduce # Configure two identity provider directories in the same organization, both connected to the same Azure tenant: ** One via SCIM (manual configuration) ** One via Azure AD for nested groups (automatic configuration) # Sync an account on a verified domain via both integrations. # After both integrations have finished syncing, update the email of the synced user in Azure to a different value on the same verified domain. ** Almost immediately after saving the change, the synced account's email is updated to the new value in Atlassian via SCIM. # Wait for the next automatic sync cycle for the Azure AD for nested groups integration to complete. h3. Expected Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value and the account remains synced via both integrations with memberships to groups synced via each integration intact. h3. Actual Results The email of the user's sync record for the Azure AD for nested groups integration is updated to the new value, but because the account is already synced with the new email via their sync record for the SCIM integration the account is unlinked from the sync record for the Azure AD for nested groups integration, removing all memberships to groups that are synced via the Azure AD for nested groups integration. h3. Workaround Currently, there is no known workaround to avoid this behavior. A workaround will be added here when available. Once an account is in this state, you can [contact Support|https://support.atlassian.com/contact/] to relink the affected account(s) to the Azure AD for nested groups integration. |