Managing the number of billable users in Atlassian Access

[Tom Lister]

We are migrating DC to Cloud and have an estimated 1400 users for Jira/Confluence.

We want to user Atlassian Access synced to our LDAP but we have 13000 potential users.

Re the info here:
https://support.atlassian.com/security-and-access-policies/docs/understand-authentication-policies/#What-is-a-nonbillable-policy

My reading of the section on syncing users with Atlassian Access is that our Access bill will be for all 13000 users in our Worldwide LDAP. We can't make synced users non-billable even if they don't use our apps.

Could someone confirm if that is the case? Are there any workarounds?

Tom

[Ed Letifov _TechTime - New Zealand_ · Accepted solution]

Hello, @Tom Lister 

For the sake of others who will search and stumble on this thread – Atlassian Access does not support "connection to LDAP" and does not support "sync with LDAP".

In the context of User Provisioning, it supports connecting to an Identify Provider that supports SCIM protocol (not all of them can!), so the IdP can push users and groups it decides to push to Atlassian Access. Azure AD can be this IdP, and it is possible to limit what records are pushed to Access from Azure AD, so you don't have to push everyone, only those who actually need to access Atlassian services.

Please note this group of people may be wider than those who need to access "your apps" – since even Atlassian-own services require an Atlassian Account, and once your email domain is verified in Access, you'll be managing everyone who is in Atlassian Cloud (as a whole) with this domain, whether they are using the apps you pay for or logging into someone else's Cloud Jira, or just logging in into this Community.

In your Access bill you will pay for every managed account that is not deactivated (even if your CEO hasn't logged in into their Trello board for years) unless they are *manually* loaded into the non-billable policy (either by typing up to 20 emails or loading up to 1000 records via CSV import).

As such this statement is not entirely true:

• Active but NOT provisioned with Jira/Confluence but maybe have... Trello (not managed) do not count.

In the context of Atlassian Access bill, Trello users do count unless they fall under some rather hairy exceptions for legacy accounts. These won't be billed in your "site" bill for Jira/Confluence – but they will be billed in your Atlassian Access bill. Same with users only using Bitbucket Cloud – they won't show up on your Jira/Confluence site bill, but will show up on your Bitbucket *and* Access bills.

Unfortunately, whether a user is loaded into non-billable policy or not is absolutely unclear to someone managing one of the applications. So you may end up with someone who was loaded into non-billable policy months ago, being given access to a critical application today – the very one that Atlassian Access was probably purchased to protect with security controls (e.g. 2FA and password strength or SAML SSO with your IdP). Since the non-billable policy doesn't allow security controls to be enforced (it's like saying "these are not my users at all despite using an account from my company) – the very use of it is a security concern on itself (read: "do not use!" if you can)

To be precise even further on the AD/LDAP topic – Atlassian Access does not support AD for SSO either, so this statement is not correct as well:

When it comes to SSO, you "CAN" use AD/LDAP

What is supported for SSO is here: 

https://support.atlassian.com/security-and-access-policies/docs/configure-saml-single-sign-on-with-an-identity-provider/#Set-up-SAML-single-sign-on

Access supports ADFS and Azure AD – neither of which is "AD/LDAP". Sure, they can be backed by your on-premises AD as well as other user sources – but if all your have is on-premises AD, the statement that you can just connect to it is misleading.

[Tom Lister]

Thank you @Ed Letifov _TechTime - New Zealand_ 

that is by far the clearest explanation I’ve read. Atlassisn docs are a maze.

I undetstand the SSO comment and we have Azure AD connected to our company LDAP. I haven’t found in the Atlassian docs how to limit which users we sync with in Azure.

Is this filter settable on our connection only or set for Azure as a whole? We are thinking to use OU properties. Although this may complicate our user on boarding slightly.

due to budget constraints, anyone who is not our Jira users will be treated as not my users. 

Tom

[Ed Letifov _TechTime - New Zealand_]

@Tom Lister 

1) "Anyone who is not our Jira users will be treated as not my users" – I am yet to meet a Security Team that would accept this. They have to assess the risk of user that was declared "not your user" today causing a problem tomorrow. Do run this by your security team!

Also considering that new users from your organisation are only added automatically to the default authentication policy in Access – you are facing an admin nightmare to maintain users. You will either have to manually load your new users via CSV import into the SSO policy (when it's not the default one – these are the very users that your IdP just pushed to Access via SCIM) or all others into the non-billable one (when the SSO one is the default one). 

Do note, if you don't push all 13k to Cloud, you don't necessarily have to pay for 13k users... Only if they somehow are already in the Cloud...

2) Re: Setting up Azure AD side – in Azure AD you install an app to connect to Atlassian Access. With any app you have two options – either you make it available to every user in Azure AD or you map groups, thus making the app available to the members of these groups only. This translates into "all" vs. "only these users" being pushed to Access side.

Unfortunately push of the groups will happen only if you map groups. Having groups come in from Azure AD usually is very useful – the holy grail for security is to add a user to a group in Azure AD and then everything just flows from there.

Here is an answer I've written previously on how we (TechTime, a Platinum Solution Partner in New Zealand) recommend setting it up with Azure AD – see: Integrate Azure AD with Atlassian Cloud 

Our clients usually want to have tight control over who from the organisations is allowed into Atlassian systems, so usually use groups with explicit membership both for SSO and User Provisioning. You may tweak this to your original problem statement to avoid managing 13k users by having all users allowed (i.e. no group mapping) on SSO side, and only specific groups of "your users" on the User Provisioning side. 

This won't stop the billing for those of the 13k that are already in the Cloud, but at least you won't have to manage them in a list (or, considering the 1000 records limitation of CSV import – in 13 lists!)

Also this may be relevant in the context of the original question about Access billing: https://community.atlassian.com/t5/Confluence-questions/What-is-the-difference-between-site-access-and-product-access/qaq-p/1306257#M221166

[Tom Lister]

Hi @Ed Letifov _TechTime - New Zealand_ 

Welcome to my world!

Did I mention a 3rd of our Jira users are external partners in domains we have no control over?

I have will spent some time on the various useful links supplied in these answers.

[Ed Letifov _TechTime - New Zealand_]

You didn't :) Our customers in this case get a Google Workspace, register a different domain there (since it has to be functional emails) and require all partners to use that to login.

[Zaid Al-Tamimi]

Hi, i'd like to join the party :-).

I'm interested in the following case>

we are probably gonna have to choose between Service Now and Jira Service Management and the Atlassian Access is very much the blocker for having JSM.

I've read the discussion and one thing is missing or I did not find it there. How about my internal customers who would only be accessing the customer portal or sending an email to JSM? Will those be billable for Atlassian Access? So I just need user privisioning from Azure AD and no product license needed.

thanks

Z.

[Dirk Ronsmans]

@Zaid Al-Tamimi ,

Users without product access (so customers) will not be billed in your Atlassian Access. 

As soon as they do have product access on any Atlassian product they will begin counting. But the Customer is a specific exception for Atlassian Access so you don't get billed for hundreds/thousands of accounts who might not log in or only once in a blue moon.

[Zaid Al-Tamimi]

sounds good, thanks!

[Mike Rathwell]

Hi @Tom Lister . I am going to take a swipe at this and see if we can find the thing as I keep stubbing my toes on this one as well.

AFIK you are only billed for active users. Also... if you have different domains you could put in the sweep that might help. This last is a "I dunno but maybe" and this is how I've been doing it with Okta... I set up and provision ONLY the humans that are in a group for Jira and/or Confluence and push THOSE groups to make them active which... makes them active in Access. 

Note that active/managed does not necessarily mean billable. Just looking in one of my environments I see among the synced/managed accounts:

• Provisioned active Jira/Confluence count
• Deactivated do not count
• Active but NOT provisioned with Jira/Confluence but maybe have... Trello (not managed) do not count.

I think you would be ok but, right now, it's a gut feeling as it were. I, personally, would raise a help me help me ticket with the mothership and pose the question. Kinda feels like it Could Be Bad if you turned that on and then found a rather large bill coming.

Good Luck

[Dirk Ronsmans]

Our own @Jimmy Seddon made a good video on how user provisioning works (https://www.youtube.com/watch?v=qf_SHEgEpHM).

afaik, you set up a connection to your LDAP but you still choose which groups/ou's get synced over.  Those users will then be billed for (only once even if they use multiple products)

[Mike Rathwell]

Brother @Jimmy Seddon would know. You just filled in the blank for the LDAP bit for me, @Dirk Ronsmans as I have mostly been in "AD is evil" shops who had gone the Okta Way.

[Jimmy Seddon]

First thing, I would recommend is doing the 30-day free trial as that will not charge you but you will be able to see what the estimate is going to be.

Second, Know that setting up SSO (single sign-on) and user provisioning (user and groups updates made in your identity provider) are two different things and are supported differently.

User provisioning (syncing all users and groups from AD) doesn't support on premise AD.  https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/

You would need to use Azure Connect to sync AD to Azure AD and you can connect Azure AD to Atlassian Access.

Or you can use one of the other supported methods.  You are charged for only the users/groups that you identify in the connector between your identity provider and Atlassian Access.  So if you decided to only sync the R&D Teams, you won't be charged for Finance.

When it comes to SSO, you "CAN" use AD/LDAP and there is a "non-billable" policy you can define to add users to where you won't be charged for them, however they also can't have any security policies applied to them and they won't have SSO authentication.

I hope that helps a bit.

-Jimmy

[Tom Lister]

Thanks @Jimmy Seddon 

Excellent answers as always.

Are you saying the limit on which users are synced is part of the Azure side set up? And is that for all of Azure or can it be defined just on our connection?

Our Azure AD is set up for company wide SSO. I need to limit it to our 1400 user Jira liicense.

[Tom Lister]

Against advice, we have only got approval for a 1400 user Access license to match pur Jira&Confluence licenses.

[Ed Letifov _TechTime - New Zealand_]

@Tom Lister as per my other answer – on Azure side you install an Enterprise Application "Atlassian Cloud" from the Azure AD Gallery, see here tutorial by Atlassian on the Microsoft side: https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/atlassian-cloud-tutorial

So, effectively, you are not integrating Azure AD with Access instance - you are integrating Azure AD with this application. You can have multiple instances of this application in your Azure, each hooked up to different Access instances.

Azure AD itself can serve 13k users, but when a user tries to go to Atlassian Cloud, based on their email domain they will be identified as a user managed by an Access  instance, and if they are in an authentication policy that forces SAML SSO via Azure – a SAML SSO request will be sent from Access to Azure. It will have an entityID that identifies which application Azure AD should to "look at" – so the settings (mapped groups) on this application will define who is allowed to perform SSO into this Access instance.

When the instance of this application on Azure side wants to push users (every 40 minutes) based on mapped groups it pushes them to the Access instance it is connected to.

The catch here is that domain verification for Atlassian is Cloud-wide. There can only be one Access instance "owning" the domain. In the context of my statement above about multiple instances of the Azure application being hooked up to different Access instances – this only works "...for different email domains".

I would strongly suggest to start Access trial ASAP, and try claiming your domain. With the situation you are describing there is a very high chance someone already claimed it – which means you may have a much bigger problem on your hands.

[Tom Lister]

Hi @Ed Letifov _TechTime - New Zealand_ 

Thank you - we have claimed our domain and our site. 

Due to mostly internal approval issues we are still waiting for licences. I will be putting in the Access trial in the meantime.

[Jimmy Seddon]

@Tom Lister I'd jump back in here but @Ed Letifov _TechTime - New Zealand_ has done such an amazing job of answering this one already!

[Tom Lister]

Thanks to you both @Jimmy Seddon @Ed Letifov _TechTime - New Zealand_