Manage Atlassian Licenses like a pro

by Richard White on 25 Aug 2023

We all know that Atlassian Data Center costs can get expensive quickly. Gone are the days of unlimited Server licenses and relatively inexpensive upgrades, where maybe it didn't matter how many users were active in Jira and Confluence. Along with this growth in price has come a surge in demand for apps that actively optimize or manage licensed users. We all want to ensure we are not spending money on something sitting unused. It can also be a significant security risk for users to have access to systems that they do not need.


As a Solution Partner, we regularly receive requests from customers wanting to rationalize their Atlassian product licenses or to investigate what savings might be possible, so this article is an attempt to show some of the best practices, some of the pitfalls of standard approaches, and apps that help with the process. (I work for TechTime, a NZ based Platinum Atlassian Solution Partner, and also the maker of the leading User Management apps on the Atlassian Marketplace: User Management for Jira, User Management for Confluence and User Management for Bitbucket)

Investigating inactive users

Imagine a typical scenario in which Jira Software is connected to an external user directory, but groups are managed within Jira. When users log in for the first time, they are automatically added to a group in Jira that gives them access, like "jira-software-users". A few years later, our user changes to another team or leaves the company and no longer uses Jira. However, they are still active in Jira and are still counting towards the overall license cost of Jira. Repeat this with a few hundred different Jira users over a few years, and suddenly you are paying for a license tier much higher than the number of users using Jira.

Jira, Bitbucket and Confluence all provide manual ways to view the time users last logged in and to remove their access to the product manually:

Jira: On the Users List page - you can view all of the last login details - but can't sort by the last login date or export the results - so you have to go through every page to find users. This gets extremely annoying if you have more than a few users.

Confluence: You have to navigate to the view user page for each user individually - no way to see it in the table view or export without direct SQL access. It is practically impossible to manage for more than a few users.

Bitbucket: The "Users" page lists the "Last Authenticated" date but doesn't provide the ability to sort by this column, filter the results, or export the results. It's pretty difficult to manage in bulk.

The default Jira user list makes it tricky to find inactive users (Confluence and Bitbucket are even harder!)

So as soon as you have more than a few dozen users - this will immediately become a very time-consuming task. Our User Management apps have functionality designed to simplify this process (also available on a free evaluation license).

The User Insights page of our app helps you understand the number of users who have not logged in and the number who have not logged in recently. Clicking on the numbers will show which users have never logged in (or have not logged in recently). From the "Bulk User Actions" screen, you can also export those users to CSV for further investigation.


Get a quick overview of user level through "User Insights"

After seeing the numbers, many customers have realized they are paying for more people who are not using Atlassian products than those who are actively using them. Not only are they paying for way more than they are using, it could be considered a security risk to have so many people with access to a system that they do not need - especially if they are external users.

Once you understand the scale of the problem for your user base - it's time to start thinking about what you can do about it.

Manually removing access

For instances with a small user base, it may be practical for an admin to regularly remove access from users who no longer use Jira or Confluence. Each product makes it relatively straightforward to do this - so long as you do it one user at a time.

Suppose your product is configured to sync groups directly from an external directory. In that case, the correct solution may be to maintain the external directory better so that users are removed from groups as their access needs change. For example, add a step to your standard off-boarding process to deactivate Active Directory users or to remove them from certain Active Directory groups.

However, once you have more than a few dozen users, these manual processes can take up a lot of time. It is time to start automating.

Automating the process

It does not take long for manually removing user access to become highly time-consuming for the unfortunate admin stuck with the task. Manually removing 100s of users from several groups every month does not sound like a fun afternoon. Heaps of solutions are available for removing user access in bulk, depending on the complexity of your set-up and whether you already have specific apps installed.

Jira

Confluence

Bitbucket


Of course, maintaining separate scripts is complex and will require maintenance over time. Our marketplace app User Management handles this use case (and many others) as part of its "Scheduled User Actions". User Management can support a full "floating license" implementation, with full audit logs and 24x7 support. To automatically remove inactive users, you can configure a scheduled user action to:

  • Act on users who haven't logged in within a period (from 1 minute to 365 days)
  • Remove all application access groups
  • Generate an audit log and email it to the admin user.

Implementing this process via User Management also has many other small quality-of-life improvements. For example, we never remove the admin user's license - so you don't have to worry about being accidentally locked out of Jira due to an overly aggressive removal of application access. We also log every action we take and can email or save regular reports of which users are deactivated.

Automatically re-adding access when required

For a genuinely automated end-to-end process, you can ensure that users are re-adding to application access groups the next time they log in. Having this in place also allows removing users more aggressively (for example, after only a few days without access) - since there is no longer the risk of users who need to use Confluence or Bitbucket being locked out of the application. Some people may refer to the combination of automatic removal and reading of access as a "floating license". As licenses are only ever assigned to users who are currently using them.

SSO

Many SSO apps (including the free SSO included with Data Center applications) support JIT (Just In Time) user provisioning. If configured to sync the correct application access groups automatically on every login, users will be re-added to the right access groups.

External Directories with "default groups" configured

When users from external directories log in for the first time, they can be configured to be added to application access groups by default. Usually, if you manually remove the application access groups, these won't be added the next time they log in. However, User Management apps have a special action, "Remove Application Access", which removes application access groups and resets the internal flag that controls this behaviour. So the default groups will be re-added the next time these users log in. 

Other Scenarios

User Management also has a special "scheduled action" that triggers whenever a selected user successfully authenticates. To combine a scheduled license removal with automatically re-adding the access, you can configure the following:


  1. Create a group that will contain all users who should have access but who have had it removed (for example, "jira-software-access-marker")
  2. Create a scheduled action to remove users from application access groups and add them to a configured marker group based on your desired inactivity period.
  3. Create a scheduled action with an "on login" trigger that only acts on the group you have created, e.g. "jira-software-access-marker", that adds the user to an application access group.
  4. (Optional) - Create an additional scheduled user action that removes users from the marker group after a longer period.


So if the initial inactivity period is set to 30 days and the final inactivity period is set to 90 days, the following will happen to a user who does not log in:

Day 1: Logs in for the last time

Day 31: Removed from the application access group and added to the marker group

Day 91: Removed from the marker group

Key things to be aware of

We highly recommend that the inactivity period you use (i.e. how long before a user's license is removed) is longer than the session timeout configured for the application. The session timeout is how long a user's login may be valid for, so if the inactivity period is shorter than the session timeout, the user may experience strange behaviour due to being currently logged in but no longer having application access. 

If you remove users' licenses very soon after they have logged in, you may unintentionally make your users' experience worse. Here are some examples of functionality that won't work for unlicensed users:

Here are some examples:

Jira

  • Jira version 8.19.x does not allow sending issue notification emails to users without a current license.
  • Jira versions after 8.20.6 require setting a "Dark Feature" flag to send issue notification emails to users without a current license - see https://jira.atlassian.com/browse/JRASERVER-73165.
  • Issue filter subscriptions are not sent to users without a license.


Confluence

  • Cannot @mention users without a current license
  • Notifications about changes to watched pages and spaces will not be sent to users without a current license
  • Notifications about comments and inline comments will not be sent to users who do not have a current license


Bitbucket

  • Users without a license can be mentioned, added to PRs and receive notifications. However, ensure any application access groups are not used in the repository permissions if they are being removed regularly.


Consider if a regular Confluence user goes on holiday and you have configured their access to be removed after one day without logging in. When they return from their holiday - all of the updates to their pages will not have been sent to them, and comments and feedback on their work will never reach them.

It is also worth being aware of the terms of the Atlassian Software License Agreement since Atlassian's license model is not based on concurrent users:

A user is, by definition, an account with the permission to log into the application. A named user with this permission is counted towards the user limit, whether logged in to the application or not. Only one individual, a named person, is permitted per product login. Multiple people cannot share a product login. Our licensing model is not based on concurrent users.

And in section 3.2 (e) of the Atlassian Software Agreement: 

Except as otherwise expressly permitted in this Agreement, you will not: (a) reproduce, modify, adapt or create derivative works of any part of the Software; (b) rent, lease, distribute, sell, sublicense, transfer, or provide access to the Software to a third party; (c) use the Software for the benefit of any third party; (d) incorporate the Software into a product or service you provide to a third party; (e) interfere with any license key mechanism in the Software or otherwise circumvent mechanisms in the Software intended to limit your use; 


 Do you really need a floating license?

I understand the temptation to make the most of your Atlassian license. However, overly aggressive removal of access can make a user's experience with Atlassian products worse than it needs to be. 

Many of our customers find they can significantly reduce their license usage by configuring removal of access after they are confident the user is not coming back. 

Using our User Insights feature, you can investigate the effects of scheduled removal of access after 30 or 90 days and the impact it will have on your license level.

Simulate the effect of automatically removing users after they are inactive

Do you have any wisdom to add?

We would love to hear more from admins who have suffered the pain of administering Atlassian users with the default tools. Are there any other great tips you have to share to make your fellow admins' lives easier?

If you need to get a handle on your licenses or understand your user base - consider a free trial of one of our market-leading user management apps:

Would you be interested in a similar best practices guide for Atlassian Cloud?


Return to blog