User Deactivation is a strategic theme in 2022 for Atlassian on premise users
The Atlassian on premise landscape in 2022 is more volatile and uncertain than it ever was. Server is shrinking at an accelerated pace, while Data Center still hosts most enterprises in spite of rising prices and the lack of new features.
Licensing has become a touchy subject. The budget pressure as the economy has slowed down in 2022 is of an entirely different magnitude, even compared with the worst times of the pandemic.
Having a robust process for deactivating inactive users has become more important than ever.
In this guide we will look at:
- What are the different goals for deactivating users
- What are the typical infrastructure requirements of on premise customers
- What are the most advanced solutions and alternative paths for each scenario
Goals for deactivating inactive users
Why do you want to deactivate users? There are several benefits of cleaning up your directories. Don’t mix them up. Selecting one main objective will help you find the right solution and park alternatives that wouldn’t be as effective.
There are three main reasons to deactivate inactive users:
Security and prevention of latent access
Don’t wait until a former employee sets up a competing business using thousands of your company’s spreadsheets. Automating the process for off-boarding employees is the C in the ABC of user lifecycle management.
According to a Gartner press release from 2016, there are three best practices for cutting down software spending: optimizing software configurations, recycling software licenses, and using Software Asset Management tools.
Our recommendations in this article belong to the first two categories.
Optimizing the standard configuration in Atlassian Data Center
Every admin knows that the default configuration is designed to make it difficult to deactivate Atlassian users. The number one approach is to deactivate manually user by user. If you want to unsync users, you will need an Active Directory and an LDAP sync – an option that belongs in the 1990s.
Recycling and reusing licenses.
If you book a table at a restaurant, you make sure to have seats for that fancy dinner. But if you don’t show up, someone else will get them. And it’s fair (assuming no overbooking). The restaurant only has a certain capacity and can’t afford to build an additional dining room just because folks are not showing up.
Software licenses shouldn’t be that different. They will be assigned to users that need the application in theory, but there should be a controlled process for reusing those seats if there’s nobody there. And you certainly shouldn’t be buying more seats when you have empty tables.
I didn’t know that recycling is also an important concept in software maintenance… and that e-waste is a thing. You never stop learning! In fact, we do have some powerful tools to recycle Atlassian licenses that I’ll be going over in the Options section.
Centralization and maintenance
Software developers pride themselves on the elegance of the code that they write. A CEO prides herself on directing the boat with fierce execution through a clear strategy. IT operations specialists pride themselves on automating their work and having a clean house (apologies for over-simplifying).
Having a clean user directory is hard to do when you have to manually curate and make sure that there are no fake active users. Instead, the solution is to have a clear mandate to establish a model of centralized identity architecture, with single accounts for every user that are connected to each corporate application.
How are users hosted
Your options are not in the vacuum. They depend on your existing infrastructure. You have to answer two simple questions: Where are your users hosted? And how are you provisioning them?
In other words: how mature is your organization in the transition from a local server to a centralized directory hosted in the cloud?
In very simplistic terms, there are three possible infrastructures: to host users in the Atlassian application, to host them in your legacy Windows Server, or to host them in the cloud.
Atlassian local hosting
Simply using the local user directory in Jira and Confluence can work for small numbers, but as soon as you start getting into hundreds of users, you will have to consider something else. This starting point also involves two subcases: using Jira as a directory for other Atlassian applications, and using Crowd to do federated identity management. There is a degree of centralization here, but only with regard to Atlassian applications – which will still be siloed from the rest of your stack.
Windows Server has been the home to almost any organization directory since the early days of the internet around 1998. It’s a centralized scenario where corporate applications can be connected and users can be synced (and unsynced), but it works best behind the firewall. Again, LDAP syncs against Active Directory are the only user synchronization supported for Atlassian on premise customers. It’s different on the cloud, where Access can do most of the things that you would expect.
Cloud Identity Provider
The bread and butter of an admin today is not deciding which starting point amongst these three is preferable. The mandate in 99% of the cases is to implement a cloud Identity Provider so that the provider takes care of every risk for you. The exception? Some government entities and similarly paranoid organizations that prefer to work without internet access and internet risk. And then the real job is to make it work. Admins have to connect legacy systems, directories that are scattered both geographically and technologically, hybrid stacks… It’s never a small project when the organization is large. Fortunately, Atlassian users are only a tiny part in this complexity, and ensuring that you can accurately authenticate, sync and unsync is already most of the scope.
Mapping your options to deactivate inactive users
TL; DR. The best method to deactivate users depends on what you have and what you want to achieve.
Now that you know where you stand, let’s go over the options.
Options With User Deactivator
User Deactivator in a nutshell: find inactive users based on the actual activity date and deactivate them, either in bulk or with scheduled jobs. Read more in the product page.
Infrastructure requirements: Local application
Objective: Clean up former employees
When your only current way to provision users is to create them manually, deactivating them in bulk is already a great improvement. User Deactivator’s bulk operations allow to do this quite granularly, specifying groups and directories where the operation should be performed.
How to deactivate users in bulk: Read the documentation
Automatically deactivate inactive users
Infrastructure requirements: Local application, Active Directory
Objective: Save licenses
A user that hasn’t accessed Jira or Confluence in 3 months will not access in the foreseeable future.
This statement is wrong sometimes: John may need to check some info in Confluence on day 93. But statistics are in your favor when you do this at scale. Out of every 10 inactive users that you deactivate, perhaps 1 or 2 will need access soon, and 5 will never need access again. Recycling those licenses in the mean time is just common sense.
Oh! And if you have our SAML SSO installed in your instance, regaining access will be seamless through the IdP.
Infrastructure requirements: Server tier locked, Data Center nearing upgrade
Objective: Save licenses
Server customers are locked in their current tier. If they reach their limit, they will have to stop creating new accounts.
Data Center customers have large volumes of users and often lack a proper control of who needs a license and who is consuming without that need. The result? Jumping to the next tier without actually needing it.
In both cases, recycling is the answer.
Regardless of infrastructure, the most sophisticated automation for recycling licenses is what we have called the License Optimizer. This feature decouples the group that provides application access from the group that lists which users have a license and basically allows to dynamically reassign licenses to those users who actually need them.
How does the License Optimizer work? Read the documentation
Options with User Sync
User Sync in a nutshell: Synchronize your users from your cloud Identity Provider into your Atlassian on premise application. Read more in the product page.
Infrastructure requirements: Cloud IdP
Objective: Clean former employees, centralize accounts
This is the ideal. Whenever an employee leaves, their account is deactivated in the the cloud directory, and access to all applications shuts down.
This is the maturity level where you want to be – admitting that the Atlassian division is fine with giving away their control to central IT.
With the example of Azure AD, there are three possibilities that will trigger a user deactivation:
- Deleting the user altogether. In our experience, this is infrequent in most European countries but happens more often in American companies, where “letting employees go” is easier and more common.
- Disabling the user. This can be done editing the user and activating the toggle to block their sign-in
- or Removing the user from the required group. This is possibly the option that can be done in bulk with less effort on the Azure AD side.
Once the user doesn’t show in the next synchronization, User Sync gives 4 different options:
- Deleting the user
- Disabling or deactivating the user
- Anonymizing the user
- Doing nothing.
Infrastructure requirements: Just in Time provisioning
Objective: clean former employees, save licenses
Just in Time provisioning is ironically bad for deprovisioning. On the one hand, no user is created until they try to login. That prevents the creation of numerous accounts that will never be used.
On the other hand, JiT can’t deactivate users. Which means that any directory will slowly turn into a cemetery of inactive users.
To solve that without manual labor, you can create a Cleanup connector with User Sync. Note that this connector does not really sync to the IdP: it simply checks the last activity date for every user, finds those who weren’t active for long enough, then applies one of the 4 cleanup behaviors.
There are some other fringe options, more and less sophisticated. You can use an Excel spreadsheet to modify any users (be careful, it can be messy). You can also use groovy code.
To summarize, here’s an overview table with the different options mapped to both goals and infrastructure requirements.