Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

SAML Configuration

If I create the SAML configuration and also configure my Azure Atlassian Cloud app for just 1 user in my Azure AD domain, will all of my remaining Atlassian users who have not been assigned to the Enterprise app still have the normal Atlassian access. I want to test SSO with 1 user without breaking access for all.

1 answer

1 vote
Dave Meyer Atlassian Team Sep 14, 2019

Hi @Kevin Dietz,

Unfortunately this won't work – once you enable SSO for your organization, it will apply to all accounts on any domains you have claimed.

What we recommend is first verifying a subdomain (like test.yourdomain.com, or just another domain entirely), then setting up a user in Azure AD on that subdomain, then go ahead and configure SAML SSO with Azure AD and test it out with that dummy user. Then you can simply claim your production domain on the Atlassian side and your SAML SSO configuration with Azure AD will automatically apply.

We know this is a bit clunky and we are planning work in the future to simplify the testing process.

Hi @Dave Meyer ,

We are using a test cloud instance to test our AD integration ,Even if we use our production domain to verify in that test instance,  the production users wont get affected right. Since they dont have access to the test Environment. Correct me if I am wrong.

Dave Meyer Atlassian Team Feb 24, 2020

Hi @ramani_chandran ,

No that's not correct. Regardless of whether you have one or more products linked to your organization, your SSO configuration applies to all Atlassian cloud tenants and services because it's tied to users' Atlassian account, based on the domain you have verified. The domains you verify are not scoped to any single instance.

Hi @Dave Meyer ,

Thanks for your reply. Can you please correct my understanding.

we are using a trial free version of cloud ( tenant - jiratest.atlassian.net ) and i have verified a domain called ex. abc.com.au and claimed all the accounts under that domain. so here the AD integration will be tested for jiratest.atlassian.net tenant only. So still the users will get affected right, since they are part of that domain.

 

  

Dave Meyer Atlassian Team Feb 25, 2020

Hey @ramani_chandran ,

It's only based on the domain, not based on the tenant. So if you have only verified ex.abc.com.au and configured SSO, it will apply to all users with an @ex.abc.com.au email address, regardless of whether they are accessing jiratest.atlassian.net, jiraprod.atlassian.net, or even this site (Atlassian Community). When you verify the actual abc.com.au domain, your SSO configuration will start applying to all @abc.com.au users across all those sites as well. Does that make sense?

Yes @Dave Meyer that makes sense. Thanks for your inputs.

Hi Dave,

Another one question came up in my mind, If a user with email abc@vodafone.com.au  is accessing the test tenant url (jiratest.atlassian.net) in which the production domain(vodafone.com.au) is verified, but he wont be having access to that test tenant right. Then can you please advise in which way the user get affected in terms of authentication.

Note: we planned to integrate our trial cloud instance with our organization ADFS.

Dave Meyer Atlassian Team Mar 06, 2020

Hi @ramani_chandran ,

It's important to understand that when you verify your domain and configure SSO, this applies across all tenants. The domain verification is not specific to any one tenant.

The reason we've designed our system this way is to help you get full visibility into Atlassian usage in your organization. If users are working in tenants that you don't happen to manage or know about, you can be assured that they will still be covered by your SSO configuration and that you'll have some visibility into what tenants they're accessing.

So naturally another consequence is that enabling SSO does not affect which tenant a given user actually has access to. So if the user already has access to the test tenant in your case, then enabling SSO will change how they log in, but they will still have access. Conversely, if they do not have access, then enabling SSO will not grant them access.

We do support granting automatic user access from identity providers via our user provisioning feature, but this is currently only supported for Azure AD, not AD FS. So I expect you would be adding and removing users to your site directly (https://confluence.atlassian.com/cloud/invite-and-remove-users-744721624.html)

Hope this helps.

Dave

Hi @Dave Meyer ,

Thanks again. gives more clarity.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Atlassian Access

What's new in Atlassian Access - Webinar

Based on your valuable feedback, we have released several new features to help you gain administrative flexibility with authentication policies, visibility into shadow IT with automatic product disco...

48 views 0 2
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you