You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I have added my domain name to the atlassian admin organization section. I plan to integrate with Azure AD so my users will authenticate with their Azure AD credentials for all things Atlassian based.
When I verified by domain name a large number of users were pulled in as managed accounts (to my surprise). These users access my customers JIRA or have at some stage signed up for an Atlassian account I assume.
My question is what will be the experience for these users if I fully integrate with my Azure AD.
Welcome to the Community! I'm going to assume that by "fully integrate with Azure AD", you mean also enabling SAML SSO as described in the Azure AD guide for Atlassian Cloud. Let's take a look at your questions:
It's also possible to not add SAML SSO to an Access policy, which would have users continue on with their existing Atlassian passwords separate from your Azure AD setup. You would apply any password policy you wanted to through Atlassian Access then (per our instructions here) and Access would also manage any MFA policies for those Atlassian accounts. The downside of this is that you wouldn't have Single-Sign-On with the other applications you already have set up with Azure AD, and your users would have to manage two different sets of credentials. With SAML SSO enabled, Atlassian Access would hand off password management and MFA to Azure as described here.
Hope that clears things up,
Daniel | Atlassian Support
For point number three - I see what you're saying. Your concern is that your customer has paid for the users in your domain to access the customer's Jira instance already, so you're not sure why there is now a charge to you in Atlassian Access. I definitely understand the confusion!
The Atlassian Access services (password policy enforcement, MFA, SSO, etc) are provided to the individual Atlassian accounts which may connect to one or more Jira/Confluence instances. Each instance those accounts use needs its own user seat (for example, your customer paying for people in your company to use your customer's Jira). If you added a new Jira instance at your company, the users that are in your customer's Jira would still need new seats in your own Jira. However, since Atlassian Access is on the individual user account level, those users would be under the same Atlassian Access subscription no matter how many Jira/Confluence instances they were connected to.
I hope that makes a little more sense! Definitely understand where you're coming from. The Atlassian Access subscription is only something that you would pay for those users, as the authentication (especially SSO) is designed to let you enforce your company's security policies across any Atlassian products the users at your company are connecting to. Nobody else will pay for Atlassian Access for those users. But they will need seats to add those users to Jira/Confluence/etc.
@Senthil Kumar in a SAML-enabled setup, password management is handled by the identity provider (such as Azure AD). Jira and Confluence will redirect users to the login screen for your identity provider. Passwords won't be handled in Jira and Confluence. To change a password with Azure AD configured for SSO, users would need to follow Microsoft's regular steps for password changes in Azure AD.