-
Bug
-
Resolution: Timed out
-
Low
-
None
-
2
-
Severity 3 - Minor
-
Issue Summary
When updating a managed account that has been linked through SSO to an unmanaged domain any new accounts created for that old managed email won't be able to use SSO.
As the SAML integration will look for the user UPN or other unique immutable identifier sent from the IdP it will still find that SAML link attached to the now unmanaged account and thus the login will fail.
Steps to Reproduce
- Update a managed account that has already logged in through SAML to an unmanaged domain. E.g a@managed.com > a@unmanaged.com
- Create a new account with the managed email that was in use(a@managed.com) or update an existing account to that address.
- Trigger a new login with SSO to that account.
Expected Results
When the Org admin updates the original account email to an unmanaged email the SAML link should be cleared and the login should work.
Actual Results
The link remains associated with the now unmanaged account and the user will receive the following error when trying to log in:
https://id.atlassian.com/login/callback?error=access_denied&error_description=verify-saml-domains:invalid-email-domain-for-primary-user&state=xxxxxx3f0818497a384f24cb5c1d44440bc81at
Workaround
It's possible to work around this bug in three manners:
- Change the email of the original(now unmanaged) account back to one of your verified domains. This will make the account managed again and a new login to the new account should re-do the linking into the new account holding a@managed.com automatically.
This is the preferable approach as it should cause less disruption to the Org users - Verify the unmanaged domain that the account was updated to. Similar to the first approach this will make the account holding the link managed and our system will be able to re-do the linking on a new login. Note that by verifying the new domain all users from this domain will start using your SSO configuration and will be notified.
- Re-do the SAML integration. This will make all new logins create a new SAML link, thus the affected users will have a new link created to their correct account and will be able to log in.
If none of those approaches are feasible for your use case please contact support.
- is duplicated by
-
-
- Closed
-
[ACCESS-728] Users can't login using SSO after having their previous account updated to an unmanaged domain.
| Resolution | New: Timed out [ 10 ] | |
| Status | Original: Gathering Impact [ 12072 ] | New: Closed [ 6 ] |
| Support reference count | Original: 1 | New: 2 |
| Status | Original: Needs Triage [ 10030 ] | New: Gathering Impact [ 12072 ] |
| Assignee | Original: Umer Bukhari [ ubukhari ] | New: Narmada Jayasankar [ njayasankar@atlassian.com ] |
| Support reference count | New: 1 |
| Assignee | New: Umer Bukhari [ ubukhari ] |
| Description |
Original:
h3. Issue Summary
When updating a managed account that has been linked through SSO to an unmanaged domain any new accounts created for that old managed email won't be able to use SSO. As the SAML integration will look for the user UPN or other unique immutable identifier sent from the IdP it will still find that SAML link attached to the now unmanaged account and thus the login will fail. h3. Steps to Reproduce # Update a managed account that has already logged in through SAML to an unmanaged domain. E.g a@managed.com > a@unmanaged.com # Create a new account with the managed email that was in use(a@managed.com) or update an existing account to that address. # Trigger a new login with SSO to that account. h3. Expected Results When the Org admin updates the original account email to an unmanaged email the SAML link should be cleared and the login should work. h3. Actual Results The link remains associated with the now unmanaged account and the user will receive the following error when trying to log in: {noformat:none|borderStyle=solid|borderColor=#6A8EB3|bgColor=#F8F8F8} https://id.atlassian.com/login/callback?error=access_denied&error_description=verify-saml-domains:invalid-email-domain-for-primary-user&state=xxxxxx3f0818497a384f24cb5c1d44440bc81at {noformat} h3. Workaround It's possible to work around this bug in three manners: * Change the email of the original(now unmanaged) account back to one of your verified domains. This will make the account managed again and a new login to the new account should re-do the linking into the new account holding a@managed.com automatically. (i) _This is the preferable approach as it should cause less disruption to the Org users_ * Verify the unmanaged domain that the account was updated to. Similar to the first approach this will make the account holding the link managed and our system will be able to re-do the linking on a new login. Note that by verifying the new domain all users from this domain will start using your SSO configuration and will be notified. * Re-do the SAML integration. This will make all new logins create a new SAML link, thus the affected users will have a new link created to their correct account and will be able to log in. If none of those approaches are feasible for your use case please contact [support|support.atlassian.com]. |
New:
h3. Issue Summary
When updating a managed account that has been linked through SSO to an unmanaged domain any new accounts created for that old managed email won't be able to use SSO. As the SAML integration will look for the user UPN or other unique immutable identifier sent from the IdP it will still find that SAML link attached to the now unmanaged account and thus the login will fail. h3. Steps to Reproduce # Update a managed account that has already logged in through SAML to an unmanaged domain. E.g a@managed.com > a@unmanaged.com # Create a new account with the managed email that was in use(a@managed.com) or update an existing account to that address. # Trigger a new login with SSO to that account. h3. Expected Results When the Org admin updates the original account email to an unmanaged email the SAML link should be cleared and the login should work. h3. Actual Results The link remains associated with the now unmanaged account and the user will receive the following error when trying to log in: {noformat:none|borderStyle=solid|borderColor=#6A8EB3|bgColor=#F8F8F8} https://id.atlassian.com/login/callback?error=access_denied&error_description=verify-saml-domains:invalid-email-domain-for-primary-user&state=xxxxxx3f0818497a384f24cb5c1d44440bc81at {noformat} h3. Workaround It's possible to work around this bug in three manners: * Change the email of the original(now unmanaged) account back to one of your verified domains. This will make the account managed again and a new login to the new account should re-do the linking into the new account holding a@managed.com automatically. (i) _This is the preferable approach as it should cause less disruption to the Org users_ * Verify the unmanaged domain that the account was updated to. Similar to the first approach this will make the account holding the link managed and our system will be able to re-do the linking on a new login. Note that by verifying the new domain all users from this domain will start using your SSO configuration and will be notified. * Re-do the SAML integration. This will make all new logins create a new SAML link, thus the affected users will have a new link created to their correct account and will be able to log in. If none of those approaches are feasible for your use case please contact [support|https://support.atlassian.com]. |
| Description |
Original:
h3. Issue Summary
When updating a managed account that has been linked through SSO to an unmanaged domain any new accounts created for that old managed email won't be able to use SSO. As the SAML integration will look for the user UPN or name sent from the IdP it will still find that SAML link attached to the now unmanaged account and thus the login will fail. h3. Steps to Reproduce # Update a managed account that has already logged in through SAML to an unmanaged domain. E.g a@managed.com > a@unmanaged.com # Create a new account with the managed email that was in use(a@managed.com) or update an existing account to that address. # Trigger a new login with SSO to that account. h3. Expected Results When the Org admin updates the original account email to an unmanaged email the SAML link should be cleared and the login should work. h3. Actual Results The link remains associated with the now unmanaged account and the user will receive the following error when trying to log in: {noformat:none|borderStyle=solid|borderColor=#6A8EB3|bgColor=#F8F8F8} https://id.atlassian.com/login/callback?error=access_denied&error_description=verify-saml-domains:invalid-email-domain-for-primary-user&state=xxxxxx3f0818497a384f24cb5c1d44440bc81at {noformat} h3. Workaround It's possible to work around this bug in three manners: * Change the email of the original(now unmanaged) account back to one of your verified domains. This will make the account managed again and a new login to the should re-do the linking into the new account holding a@managed.com automatically. (i) _This is the preferable approach as it should cause less disruption to the Org users_ * Verify the unmanaged domain that the account was updated to. Similar to the first approach this will make the account holding the link managed and our system will be able to re-do the linking on a new login. Note that by verifying the new domain all users from this domain will start using your SSO configuration and will be notified. * Re-do the SALM integration. This will make all new logins create a new SAML link, thus the affected users will have a new link created to their correct account and will be able to log in. If none of those approaches are feasible for your use case please contact support. |
New:
h3. Issue Summary
When updating a managed account that has been linked through SSO to an unmanaged domain any new accounts created for that old managed email won't be able to use SSO. As the SAML integration will look for the user UPN or other unique immutable identifier sent from the IdP it will still find that SAML link attached to the now unmanaged account and thus the login will fail. h3. Steps to Reproduce # Update a managed account that has already logged in through SAML to an unmanaged domain. E.g a@managed.com > a@unmanaged.com # Create a new account with the managed email that was in use(a@managed.com) or update an existing account to that address. # Trigger a new login with SSO to that account. h3. Expected Results When the Org admin updates the original account email to an unmanaged email the SAML link should be cleared and the login should work. h3. Actual Results The link remains associated with the now unmanaged account and the user will receive the following error when trying to log in: {noformat:none|borderStyle=solid|borderColor=#6A8EB3|bgColor=#F8F8F8} https://id.atlassian.com/login/callback?error=access_denied&error_description=verify-saml-domains:invalid-email-domain-for-primary-user&state=xxxxxx3f0818497a384f24cb5c1d44440bc81at {noformat} h3. Workaround It's possible to work around this bug in three manners: * Change the email of the original(now unmanaged) account back to one of your verified domains. This will make the account managed again and a new login to the new account should re-do the linking into the new account holding a@managed.com automatically. (i) _This is the preferable approach as it should cause less disruption to the Org users_ * Verify the unmanaged domain that the account was updated to. Similar to the first approach this will make the account holding the link managed and our system will be able to re-do the linking on a new login. Note that by verifying the new domain all users from this domain will start using your SSO configuration and will be notified. * Re-do the SAML integration. This will make all new logins create a new SAML link, thus the affected users will have a new link created to their correct account and will be able to log in. If none of those approaches are feasible for your use case please contact [support|support.atlassian.com]. |
Hi everyone,
Thanks for watching and following this ticket. Since this bug hasn't been reported by any customers over the past year, we are closing it as "Timed Out". If your team is still impacted by this issue, please leave a comment for us to re-evaluate and reopen.