Journey Through User Management: This Flag Changes Everything

Posted by Foogie Sim on August 23, 2019

User management within Atlassian tools is one of the Atlassian admin's most important, essential responsibilities. As a Senior Support Engineer in Atlassian Support and the original Atlassian Crowd (Atlassian's single sign-on product for its whole suite) subject matter expert, ServiceRocket's Foogie Sim recently discovered a flag that can alleviate or resolve some of the most common issues around your user management operations.

Let's take a look.

The Local Flag and How it Changes Everything You Know About LDAP

If you ever worked in Atlassian Support before, you will realise that one of the most common user management tickets we receive is "why isn't my LDAP membership synchronised?". There are a variety of factors surrounding that (we will probably discuss those in later blogs), but one of the main troubleshooting steps that I've added back in Atlassian Support is to check the "local" flag in the cwd_group table. Let me explain further via a scenario below.

Step 1: Local Group created in Confluence Internal Directory

First, create a local group called "localgroup" in the Confluence Internal Directory:

Screen Shot 1

This is how that group looks in the DB:

Screen Shot 2

If you're curious why the local flag is set to F, it's because this flag is only used for external directories and not necessarily the Confluence Internal Directory. 

Step 2: Add a LDAP user to the local group

There are a few prerequisites to be aware of before adding an LDAP user to a local group. For the purpose of quick demonstration, let's focus on an LDAP connector directory (more on LDAP connectors versus Delegated Authentication in future blogs!), but with Local Groups enabled:

Screen Shot 3

We will try this out with this LDAP user:

Screen Shot 4

Notice that this user's directory is from LDAP Server, and that the user is not in any groups at the moment. But, we can run this query to confirm whether the user is in multiple directories:

Screen Shot 5

Following that, we can add this user to the local group via UI:

Screen Shot 6

Once you hit "Save," something magical happens. The query we ran in Step 1 that returned only 1 row, now returns 2:

Screen Shot 7

The additional row is tied to the LDAP server directory, with the local flag set to T

Alright I get it, that's how it should work. But what's the Implication?

The implication of the local flag set to T, is that right now, if a similar group is created in the LDAP server, that group's memberships in LDAP will be ignored

We can demonstrate this by creating a group with a similar name in LDAP:

Screen Shot 8

And synchronise the directory. After the sync — surprise surprise! — No memberships from LDAP is synchronised:

Screen Shot 9

A common (and expected) follow-up question would be whether this is because the LDAP directory's order is below the Confluence Internal Directory? And the answer is a hearty "No.":

Screen Shot 12

What is the purpose of the flag then?

Technically, you would expect memberships to merge, but that isn't the case here with the flag enabled. So what is the flag meant to do? Here's what happens when you change the flag manually from the database:

UPDATE cwd_group SET local = 'F' WHERE id = 23756816;

The query now returns this:

Screen Shot 7

After a cache flush in Confluence Admin >> Cache Statistics, and a full directory sync, the local group now looks like this:

Screen Shot 11

Notice that ldapuser has lost its membership to this group? And that, is exactly why this flag is so important: it prevents LDAP users from losing their local membership to local groups, if they are not part of the group within LDAP. 

There are a few caveats to this though. First, the local flag will only be set to T if you follow the steps above (i.e. a LDAP user is added to the local group when the group with the same name does not exist yet in LDAP). Secondly, if the group already exists in LDAP prior to the first LDAP user being added to it, then the flag will remain F, and no LDAP user can be manually added to the group via Confluence (it will throw an error)

The same behavior holds true (with some changes such as is_local instead of the local flag, and the Jira Internal Directory instead of the Confluence Internal Directory)

User management in Atlassian tools is an expansive responsibility with a lot of little moving pieces. It's nearly impossible to keep track of every little nuance or quirk, but hopefully by surfacing little nuggets of knowledge like this, we can make your job incrementally easier. 

Check back later for more user management tips. And in the meantime, contact us to learn more about ServiceRocket's comprehensive suite of support, training, and plugin solutions to maximise the value and utility of your Atlassian tools. 

 

Subscribe To
Our Newsletter

Interested in writing for the Software Adoption Blog?

We love connecting with software leaders and writers who can help us fulfill our mission to create entertaining AND educational resources that people can put to use.

Find Out How ➝

Recent Posts

Posts by Topic

see all