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; } } }

How do I bypass SSO during log in?

Viktor Berke

Hi everyone,

When you create an organization in Atlassian, you are _required_ to create an Atlassian cloud account. All good. Actually, no, it's not all _that_ good, because you have to do this in private mode, otherwise Atlassian creates an account for you with the wrong email (your currently logged in Google account) without asking you, ever.

So, you register an account that will be the super administrator for your company, e.g. admin@foobar.com. You enroll in Jira Service Desk + Confluence + Access trial, good. Then you verify your domain, foobar.com, which is again more painful than should be. It wants you to set the @ (root) TXT record for verification, which I swear I've never seen anyone else do, and for a reason: that normally goes for SPF records. So you can't verify via DNS unless you're willing to kill some of your email flow. So you do the verification via HTTPS, whatever.

Then you set up SAML using Azure AD, where the order in which you should do things is kinda messed up in the Atlassian portal, but you eventually figure out using the Azure docs. Whatever.

Then you properly enroll your first user in your site, and all seems to be fine.

... then you try to log in as admin@foobar.com again. Guess what: it redirects you to Azure AD login. Which is great except there's no password for admin@foobar.com, since it's a _group_. Before you ask, why, because IT staff comes and goes, it's senseless to assign god mode to any one person. That's common practice. It's also senseless to assign super admin rights to your everyday user as then you'll never possibly face any permission issues that your co-workers might face. Much like we stopped logging into Windows as "Administrator" and instead, elevate rights only when necessary. Again, common practice.

So now the _only_ way I can access the admin sites is by going to "Can't log in" and clicking on the recovery link. Which expires in an hour. I know my Atlassian password, I just never get to enter it, because it immediately redirects me to Microsoft Online, based on my email domain.

Is there a better way to do this, without adding unrestricted admin rights to all IT staff? The only other way I can think of is changing the admin account's email address to one of our alternative domain names, but that seems plain stupid to me.

Suggestions?

Accepted answers

unknown

Hi Viktor,

There are some assumptions here that might not be true in 100% of the time. Let me try and explain:

When you are using any Atlassian Cloud product, you are already logged in with an Atlassian Account. When you decide to create an organization, the creator of that organization will be placed as an org admin. If you are already logged in with an account, it will be that one. This has nothing to do with Google.

Furthermore, for the domain verification, we usually recommend the DNS approach. Adding a TXT record to your domain does not have any negative implications on the email delivery. We added the HTTPS method as an alternative, but if you have another verification method in mind, let me know so I can create a feature request.

When you finished the integration with an IDP, you will not be able to log in with group accounts, as they do not represent actual accounts in that identity provider.

Finally, we advise any admins that attempt to verify a domain and integrate with an SSO provider to add a separate Atlassian account as a temporary admin. This user must have the email address in a different domain, that will not be claimed in the process. For more details, please see:
SAML single sign-on

I hope this clears some of the confusion.

Claudiu

All comments

unknown

Hi Viktor,

There are some assumptions here that might not be true in 100% of the time. Let me try and explain:

When you finished the integration with an IDP, you will not be able to log in with group accounts, as they do not represent actual accounts in that identity provider.

I hope this clears some of the confusion.

Claudiu

Viktor Berke

Hi Claudiu,

Thanks for the answer, and thanks for removing the SPAM label as well I want to clarify a few things.

If you are already logged in with an account, it will be that one. This has nothing to do with Google.

I meant that if you don't have an Atlassian account but you're logged into Google, the Atlassian site automatically creates an account with your Google address. Without asking. It's just an annoyance, but you can work around it by using private mode.

Adding a TXT record to your domain does not have any negative implications on the email delivery.

In fact, it does, since having SPF records is required with most cloud email providers. For example, we use Office 365, this is their instructions:

Set up SPF in Office 365 to help prevent spoofing

In order to use a custom domain, Office 365 requires that you add a Sender Policy Framework (SPF) TXT record to your DNS record to help prevent spoofing.

This essentially renders DNS verification impossible for Atlassian products. I've seen several other products that used DNS validation and none required the TXT record to be set. Instead, they always use some prefix. The first thing that comes to mind is Let's Encrypt, which uses _acme_challenge. for verifying your domains. MailJet uses mailjet._domainkey. Relying on the root record is begging for apocalypse as it can conflict with virtually anything else that needs it. I.e. it provides no benefit but it can cause trouble.

Finally, we advise any admins that attempt to verify a domain and integrate with an SSO provider to add a separate Atlassian account as a temporary admin. This user must have the email address in a different domain, that will not be claimed in the process.

Yes, I missed this part of the docs:

must not use an email address from a domain you have verified for this organization. This ensures that the account will not redirect to SAML single sign-on when you log in.

So apparently the only solution is to use one of our other domains for the admin account. Although this one shouldn't be impossible to solve either, as most services allow for mixing local and directory accounts. Oh well.

Thanks for the info anyway,

Viktor

unknown

Thank you for your reply. I read the SPF documentation of Office 365, but this does not make the DNS verification impossible.

The key element here is that you can add multiple DNS TXT records for one domain and they will not eliminate or conflict each other. Take a look at atlassian.com for example. If you are on Mac, open a terminal window and type in

dig atlassian.com txt

If you are on Windows, open a command prompt and type

nslookup -q=TXT  atlassian.com

Notice that there are plenty of TXT records. This means that the domain atlassian.com is claimed by multiple entities, each with their own scope. These entries do not affect each other.

Viktor Berke

You're actually absolutely right. I let Azure's UI mislead me ("there's already a record set with the same name"). But it's possible to add a new line on the existing record set, you just have to click below it. Sorry for that!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

sso

atlassian-guard

active-directory

access

saml