The Ultimate Guide to deactivating Atlassian inactive users (Data Center & Server)

[#1]

Having a robust process for deactivating inactive users is more important than ever. Server customers are locked in their current tiers, and Data Center is becoming a premium option.

In this guide we will look at:

• What are the different goals for deactivating users

• What are the typical infrastructure requirements of on prem customers

• What are the most advanced solutions and alternative paths for each scenario

In the last section, we will be looking specifically at how resolution apps can help Atlassian system admins with best practices like license recycling and centralized identity management.

Disclaimer: Note that I work for resolution, the Gold Marketplace Vendor behind User Sync, User Deactivator and SAML SSO, the main apps discussed in this guide.

Goals for deactivating 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 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 offboarding employees is the C in the ABC of user lifecycle management.

License Savings.

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.

Atlassian Data Center still doesn’t provide a native configuration for syncing (and unsyncing) users from a cloud directory

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 user accounts connected to each corporate application.

Starting points

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.

• Active Directory. 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.

credits: https://xkcd.com/

• 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.

Options

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.

With User Deactivator (link to product)

Bulk Deactivation

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.

License Optimization

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 (link to product)

Unsync Users

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.

Cleanup Connector

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.

Summary table

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. Get in touch with our team at www.resolution.de/support if you want to explore them in detail.

This article is the writeup of a presentation for the ACE Córdoba. I'd like to thank @Marcos Milanesio for the invitation.

Marcos made the question we always get. Does resolution have similar products for cloud? The answer has always been no. At some point in the not so far future, the answer may be yes. In that moment, we will communicate the new products and update our resources.