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:
This is how that group looks in the DB:
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:
We will try this out with this LDAP user:
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:
Following that, we can add this user to the local group via UI:
Once you hit "Save," something magical happens. The query we ran in Step 1 that returned only 1 row, now returns 2:
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:
And synchronise the directory. After the sync — surprise surprise! — No memberships from LDAP is synchronised:
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.":
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:
After a cache flush in Confluence Admin >> Cache Statistics
, and a full directory sync, the local group now looks like this:
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.