nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Azure AD - failback to normal accounts?

RMA_ojk3q4

We are looking at implementing SSO via Atlassian Access -> Azure AD SAML for all the users.

We are currently using Jira Core / Jira Software and Trello.

The one question raised is what happens if the SSO link goes down, can we resort to non SSO authentication?

Doing a test, it appears to automatically redirect you to the SSO without having an option of doing the non SSO method?

Any help is appreciated.

Accepted answers

Dave Meyer

Hi @RMA ,

A couple points I would make in response to your question:

Once a user has logged in, they will have a session cookie, so in the case of an SSO outage most users would be unaffected.
We consider login and authentication (including SSO) our most critical service after our infrastructure itself, so we strive for extremely high availability. Here's the incident history for Atlassian Access so you can see for yourself: https://access.status.atlassian.com/history
In the case that SSO were to be unavailable for an extended period of time (either because of an error on the Atlassian side or an outage in Azure AD, which is hopefully just as reliable), then yes, you can disable SSO for all users. If you do, login will revert to a standard email address + password. For users that have only ever logged in through SSO, they would need to go through the Reset Password flow to set a local Atlassian password.

Hope this helps.

Dave

All comments

Dave Meyer

Hi @RMA ,

A couple points I would make in response to your question:

Once a user has logged in, they will have a session cookie, so in the case of an SSO outage most users would be unaffected.
We consider login and authentication (including SSO) our most critical service after our infrastructure itself, so we strive for extremely high availability. Here's the incident history for Atlassian Access so you can see for yourself: https://access.status.atlassian.com/history
In the case that SSO were to be unavailable for an extended period of time (either because of an error on the Atlassian side or an outage in Azure AD, which is hopefully just as reliable), then yes, you can disable SSO for all users. If you do, login will revert to a standard email address + password. For users that have only ever logged in through SSO, they would need to go through the Reset Password flow to set a local Atlassian password.

Hope this helps.

Dave

RMA_ojk3q4

Thanks Dave,

On point 3, would we need an account that is not SSO enabled to be able to log in?

So it should not be part of our normal domain? Like a personal email address?

This is if the session cookie expires and somehow the connection between the Azure AD and Atlassian Access fails.

Thank you!

Dave Meyer

@RMA yes, we recommend this as a precaution. Usually not because we are worried about the SAML connection failing, but we do see people make mistakes during the initial SAML configuration setup and end up locked out. So it's a good idea no matter what