try at Atlassian Marketplace
A DC Migration Walkthrough: Retaining Knowledge Base Access for Deactivated Users

A DC Migration Walkthrough: Retaining Knowledge Base Access for Deactivated Users

A migration to Data Center saved up to 50% of the licensing cost - but broke access to its Knowledge Base. This guide shows how to solve it.

Table of Contents


As teams evolve and organizations grow, one aspect of Atlassian tools that can become increasingly complicated is user license management. The larger the team, the harder it can be to keep track of who needs access to what. That’s where SAML Single Sign-On can serve as a lifesaver.

Other customer implementations

However, implementing SSO with Azure AD and managing Jira, JSM, and Confluence licenses often present unique challenges. Today, we’ll explore a detailed case study featuring a customer who is migrating from Server to Data Center and experienced some interesting challenges. As in every article in this series, the article details the real solution provided by our support team.

The Migration to Data Center

Deactivation Policies

Licensing cleanup before and after migration
Licensing cleanup before and after migration

Like many Atlassian customers, our client was on the edge of migrating from Server to Data Center. One of their main goals was to review license utilization and reduce the company’s Jira licenses in half.

For this, they took two bold steps:

  • Revoked the license group (gcp_Jira_Licence) for Application Access from all inactive users.
  • Users who had not logged into their Atlassian products for the past 30 days would be automatically cleaned up. The Cleanup Inactive User Connector was set up for this.

User reactivation with SAML SSO

Inactivated users regain access seamlessly with SAML
Inactivated users regain access seamlessly with SAML

Note that these two steps didn’t prevent deactivated users from accessing Jira or Confluence in the future. With SSO in place, the standard functionality is that deactivated users are automatically reactivated when they try to log in again (unless they have also been offboarded from the IdP, for example if they quit the company).

The Challenge

Deactivated users can't access Knowledge Base articles from Jira Service Management
Deactivated users can’t access Knowledge Base articles from Jira Service Management

However, this deactivation policy led to unexpected issues:

  1. Many deactivated users who logged back into Jira via SSO couldn’t access Knowledge Base articles in JSM because they also lacked a Confluence license.
  2. The cleanup process removed users from both AzureAD groups and local groups of SEIBERT MEDIA’s Extranet app, which allows to collaborate privately with external users in. After cleanup, reactivated users could not gain access again to key Extranet Confluence Spaces unless manually provisioned.

Understanding the Existing Infrastructure

Before implementing the solution, let’s understand the existing infrastructure from the customer’s perspective:

  • Atlassian products: Jira, Jira Service Management, and Confluence
  • Cloud IdP: Azure AD for SAML Authentication
  • resolution apps: SAML SSO for authentication and provisioning into the above products
  • Provisioning Method: User Sync Provisioning via REST API

Two key advanced features of the SAML SSO app were utilized:

  • Groovy Script: Groovy code was used to add several custom behaviors, ensuring that the groups are properly restores after a successful SAML SSO login. For example, the Application Access Group for JSM is assigned to the user only if: a) they are members of the JSM group in Azure and
    b) if it is a SAML SSO login.
  • Cleanup Inactive Users Connector: As described above, the Cleanup Inactive Users Connector was set to deactivate users who hadn’t logged into any of the Atlassian products for the last 30 days.

In addition to that, our support team utilized the Confluence API to manipulate Confluence permissions and create a functional bridge from the SSO login into JSM to Confluence.


It became clear that a nuanced approach was required, one that would make license management flexible yet robust. The solution had multiple components to address the key challenges faced by the customer:

  1. Unlicensed View Permission: To allow users to see Knowledge Base articles even without a Confluence license, we had to manipulate permissions at both a global and space-specific level.
  2. Refined Cleanup Process: To ensure that cleanup did not disrupt critical user accesses, especially for extranet spaces, a more selective cleanup process was needed. In particular, it was important to preserve groups considered critical for the user experience of reactivated users.
  3. User Update: Users are updated via the User Sync Connector, if and only if they successfully log in. This includes both the license group and the Azure group attributes.

Step-by-Step Guide to the Solution

Enabling an Unlicensed View Permission

This section doesn’t contain any features of resolution’s apps for Data Center. Instead, it implies two simple cURL scripts run against the Confluence Server API. You can check more REST API examples with Confluence.

  • First Step: Enable Unlicensed Global View Permission: This requires executing a specific CURL script:
## Enable Unlicensed Global View Permission 
curl -X "POST" "https://<YOUR-CONFLUENCE-HOST/rest/knowledge-base/1.0/permissions/global/unlicensedaccess" \ 
-H 'Content-Type: application/json; charset=utf-8' \ 
-u 'admin:<YOUR ADMIN PASSWORD>' \ 
-d $'{ 
"enablePermission": true 
  • Second Step: Enable Unlicensed Space View Permission: Similarly, enabling space-specific permissions requires the following script:
## Enable Unlicensed Space View Permission 
# Space key must be set in body curl 
-X "POST" "https://<YOUR-CONFLUENCE-HOST>/rest/knowledge-base/1.0/permissions/space/unlicensedview" \ -
H 'Content-Type: application/json; charset=utf-8' \ 
-u 'admin:<YOUR ADMIN PASSWORD>' \ 
-d $'{ 
"enablePermission": true, 
"spaceKey": "<YOUR_SPACEKEY>" 

For Refined Cleanup Process:

Where: User Sync Configuration >
  1. Go to Specific Settings in the Cleanup Inactive User Connector: Here, select Azure Directory as the directory for this connector.
  1. Define ‘Days Since Last Login’: Set a suitable threshold for inactivity, beyond which users will be considered for cleanup.
  2. Change Cleanup Type: Opt for ‘Keep Users without modification.’
  3. Toggle ‘Remove Group Memberships’: This ensures that only certain memberships are removed.
  4. Regex for Preserving Critical Groups: Use a regex to specify which groups should be exempt from the cleanup. This will allow users to access the Extranet App, even without a general license.

Changing User Provisioning Method:

Where: SAML SSO > Identity Providers > User Creation and Update

Finally, it’s time to create a Connector that will assign users the access group ONLY after they have successfully logged in.

  1. Select Update Method: Choose ‘Update with UserSync-Connector’ and specify the Azure UserSync connector.

Using a Groovy Script for Customized Group Mapping:

  1. Go to Provisioning Settings: Here, navigate to ‘Attribute Mapping → Groups’ and click Edit.

Insert Groovy Code: Use the following Groovy script to map your local group names to the corresponding IdP group names.

def grps = con?.GROUPS ?: [] 

def idpGroupName_1 = "mmk-jira" 
def idpGroupName_1_transform_to_group = "jira-core-users" 

// When saml is not empty, this 
// is a single user update during saml login 
boolean isLogin = !saml?.isEmpty() 

if(isLogin) { 

if (grps.contains(idpGroupName_1)) { grps.addAll(idpGroupName_1_transform_to_group) 
if (grps.contains("jira-servicedesk-users")) { 
return grps 

else { 
return grps
For the solution to work effectively, the customer must be using the latest versions of SAML SSO and User Sync (version 6.7.0). Find them in the Marketplace


Jira license management can be complex, but it doesn’t have to be a maze. In this case, we’ve seen that it was possible to proactively and regularly deactivate inactive users to optimize licensing in Data Center, while still ensuring that deactivated users can access Confluence and third-party apps that are critical for collaboration. SEIBERT MEDIA’s Extranet is a great example, since it provides a private environment for collaboration with customers.

A tailored approach that leverages SAML SSO can not only solve your immediate problems but also provide a scalable solution for future challenges. The combination with User Sync provisioning simplifies user management, guarantees access to users while saving licenses, and enhances security and convenience.

If you have any questions or need further assistance in implementing this solution, don’t hesitate to reach out to re:solution’s dedicated support team.

Spread the word!

This piece is part of a new series that showcases solutions to some of the most challenging problems that our enterprise customers have to face. They are based in real customers, real Atlassian environments, and real implementations, and are written for the technical folks with whom we love to work.

Reach out to us for help with implementing this solution or if you’d like us to cover any specific challenge in this series.

Subscribe to our newsletter:

Related articles: