User removed from confluence-administrators by Anonymous

[Michael VanHorn]

One of our administrative users was suddenly removed from the confluence-administrators group, seemingly by the system itself (the other administrators didn't do it).

According to another post in the forum, it could be one of the installed apps that did it.  There are dozens of System apps installed; how do I tell what they do and if they did this? How do I prevent this in the future? 

[Michael VanHorn · Accepted solution]

For anyone interested, the fix according to the Confluence documentation is to disable Just-In-Time user provisioning while adding a configuration for an LDAP server under "Usr Directories" and setting the LDAP directory as "Read Only, with Local Groups". The user will still get automatically created, but groups retrieved from the server won't be consulted as being the same groups that are in Confluence (that is, user groups in Confluence will be un-connected from any groups that exist in LDAP or on the authentication server). 

[Ed Letifov _TechTime - New Zealand_]

@Michael VanHorn can you give a link reference? Asking because the way this is phrased right now it makes no sense.

What I mean: "JIT" usually refers to functionality of the SSO app e.g. https://confluence.atlassian.com/enterprise/jit-user-provisioning-1005342579.html

It basically performs a re-sync of user data every time user logs in based on IdP login response (e.g. SAML LoginResponse). It could also create a previously non-existent user but only in the local directory. It will attempt to pull an existing user from AD/LDAP before creating a new one.

If you have AD/LDAP integration in the backend – this has it's own re-sync settings that could be triggered on successful login.

If there are local groups that match AD/LDAP groups by name exactly – on re-sync the user will be added to these i.e. they will be "connected" (using your language).

Disabling the front-end SSO JIT doesn't disable this backend user directory re-sync.

So the answer is effectively incomplete. Not that it's wrong for your specific setup — but for the sake of the next person struggling with this: there could be other config options that need to be tweaked.

Also you previously claimed that your LDAP does NOT have confluence-administrators group — are you saying it did, and it was "connected" to the local group and this particular user was not a Confluence admin in LDAP?

[Jason Krewson]

So it sounds like what I was talking about was correct then for this issue?

Just curious as this explanation makes it sound like the identity provider removed this account and what you wrote is the solution for disabling that functionality. 

Anyway great to hear you found the cause and the fix!  

[Ed Letifov _TechTime - New Zealand_]

@Jason Krewson 

Essentially yes – though it's implied that it was the front-end SSO JIT that removed it, but I think the picture is incomplete — if a group with the same name does exist on IdP/AD/LDAP side disabling JIT in SSO app is not enough.

One needs to make sure the backend user directory doesn't perform re-sync as well: https://confluence.atlassian.com/doc/connecting-to-an-ldap-directory-229838241.html search for "Update group memberships when logging in"   

[Arkadiusz Wroblewski]

@Ed Letifov _TechTime - New Zealand_ 

For me also, this topic doesn't make sense. Well, I say another. Good that he can solve that himself, but when we know more about intention, it will be easier to point out the mismatch between the formulated question and the content afterwards.

Well, at the end, the most important thing is that  @Michael VanHorn  get that solved. Anything else doesn't matter. That's why we are here. To help each other and learn from each other

Best,

Arkadiusz 🤠 

Have a good day folks ☀️

[Michael VanHorn]

@Ed Letifov _TechTime - New Zealand_  @Arkadiusz Wroblewski  @Jason Krewson 

Now that I understand what Confluence is doing, let me re-state the salient points.

1. There is no group in the SSO provider (which pulls information from the LDAP server) called confluence_administrators (or, for that matter, confluence_users). We are using SSO for *only* authentication (usernames and passwords, plus 2FA). The SSO provider does provide group membership information, but we ignore this. Or, rather, we want to ignore this, and maintain Confluence groups locally inside Confluence. There is no group information coming from the SSO provider (or the LDAP server) that is meaningful to our installation of Confluence. Using the terms that the support chat bot put it (below), the IdP is NOT "the absolute source of truth for the user's profile".

2. The SSO provider did NOT remove the user from the group. Confluence did this. I had added the user to the confluence_administrators group (locally, inside Confluence). At some point, Confluence re-checked the user's information it received from the SSO and determined that the user wasn't in a group called confluence_administrators (which makes since, since there isn't such a group as far as the SSO provider knows) and removed the user from the local group. Again, this is not an action being taken by the SSO provider (or the LDAP server behind it); neither of those services has any capability of doing that. This action was taken by Confluence.

3. As I still haven't had time to implement the solution (shown below), we still do not have  a user directory configured in Confluence. When I eventually get to do this, the directory server that I configure will be the LDAP server which is the same LDAP server from which the SSO provider pulls its information. 

Below is the information I was given by the Confluence support chat bot which explains how to keep JIT user provisioning enabled while ignoring the group information coming from your SSO provider. Basically, without a user directory configured, Confluence uses group information from the SSO provider, and, unfortunately, there is no way to disable this behavior. If there was a way to disable it, this would be a lot simpler. Instead, you need to configure a user directory. Once a user directory is configured, Confluence will ignore any group information it gets from the SSO provider and instead reference the user directory for group information. But, there is the capability to tell Confluence to ignore the group information from the directory server and thus maintain group information only locally. And that is the solution for our installation.

--- chat ---

In Confluence Data Center, you cannot disable group mapping independently while *Just-in-Time (JIT) provisioning* is enabled, as this feature is designed to make your identity provider (IdP) the absolute source of truth for the user's profile [01].

## Disable JIT Provisioning
The "Groups" attribute is a mandatory field because the **Create users on login to the application** option is checked. When this is active, Confluence expects to synchronize the user's full state—including group memberships—every time they log in [02].

To stop Confluence from using groups from your authentication server, you must disable JIT provisioning:
1. Go to **Administration** (cog icon) > **General Configuration** > **Authentication Methods**.
2. Edit your SSO configuration.
3. Uncheck **Create users on login to the application**.
4. **Save** the configuration [03].

*Note: Disabling this means new users will no longer be automatically created upon their first login via SSO.*

## Use a User Directory for Local Management
If you need users to be created automatically but want to manage their groups locally within Confluence, you should use a **User Directory** connector instead of JIT provisioning.

1. **Obtain System Administrator Permissions**: The **User Directories** menu is only visible to *System Administrators*. If you cannot see it under *General Configuration*, you likely only have *Confluence Administrator* rights [^04^].
2. **Configure an External Directory**: Add your LDAP or Active Directory server under **User Directories**.
3. **Set Permissions to "Read Only, with Local Groups"**: This specific setting allows Confluence to sync user accounts from your server while ignoring the external groups, letting you manage memberships manually in Confluence [04].

By using this method, you can keep SSO for authentication while maintaining full control over groups locally.

Sources
1. https://confluence.atlassian.com/enterprise/jit-user-provisioning-1005342579.html
2. https://jira.atlassian.com/browse/CONFSERVER-60263
3. https://confluence.atlassian.com/enterprise/working-with-jit-provisioning-1005342571.html
4. https://support.atlassian.com/confluence/kb/microsoft-entra-id-single-sign-on-button-for-confluence-is-not-showing-on-login-page

--- chat ---

[Ed Letifov _TechTime - New Zealand_]

Yeah OK, @Michael VanHorn this is a classic example of AI support :(

So...

1) To clear the confusion: yes, the group was removed by the process inside Confluence. Specifically the group re-sync inside JIT provisioning functionality of the default SAML SSO app on DC. Yeah, the IdP didn't literally "reach out" into your Confluence to remove the group but effectively it did — with JIT enabled the SSO app takes groups being sent by IdP as gospel.

2) Disabling JIT will stop this, but as the AI bot correctly puts it — it will also stop new users being created just-in-time when they show up for the very first time.

3) The read-only user directory with local groups technically has nothing to do with this — this is basically trying to address the creating users issue when JIT is disabled.

For full documentation see here: https://confluence.atlassian.com/doc/connecting-to-an-ldap-directory-229838241.html

It's interesting that the bot didn't include this page but included all other rubbish.

I am actually not 100% sure about the default SSO behaviour but most 3rd party SSO apps will attempt to pull a user that previously didn't exist in Confluence — from the backend User Directory when they login for the first time, which is effectively equivalent to JIT in the situation that both IdP and Confluence are looking at the same LDAP.

So, based on your requirements, I would suggest NOT checking "Enable Incremental Synchronization" in the directory at all — users will be pulled on first login only, and not regularly.

Some explanation: a regular sync implies you have something in the backend directory to "latch onto" e.g. a group like "confluence-users" signifying entitlement to use Confluence so you'd pull "all confluence users" into Confluence regularly. IN your case, you say all your groups are inside Confluence only, so regular pull of a subset of users is impossible unless it's ALL users from the backend directory — and it is very rare that you'd want this, as you could run into licensing problems in Confluence then.

If you want to ignore the groups information coming from LDAP — you will need to disable re-sync functionality in the directory setup, so it doesn't try to overwrite the user's local groups on every login, and if you really want this to be a hard "no groups from LDAP whatsoever" — also supply a bogus "Additional Group DN" for groups, so literally nothing is pulled from LDAP for groups.

[Arkadiusz Wroblewski]

Hello @Michael VanHorn 

In Confluence Data Center, that kind of audit entry can also appear when the change was made by a system process where Confluence does not have a normal human actor to show.

It fits quite well to that behavior https://jira.atlassian.com/browse/CONFSERVER-54007 

Check your raw backend Confluence application logs from that exact timestamp. Basic Audit logs are useless.

Like don't get distract yourself because of 1000 another things.

Identificate first what are responsible for that and go from then.

Best,

Arkadiusz 🤠 

[Michael VanHorn]

Yes, we are using the University's SAML authentication provider. However, that provider has no authority inside Confluence. I'm not even sure how the provider removing a user in Confluence from a group would even be possible.

So, I'm sure it wasn't the authentication server who removed the user. 

From my reading of the documentation and forum posts, when the Audit Log shows an action having been taken by Anonymous, it means it was the system itself doing something, like an automated task. I have not created any automated tasks.

[Jason Krewson]

When you are using an identity provider you can tie access to groups, those groups can then be removed by that identity provider, removing that users access. This is actually how it is set up where I work right now. So that is why I recommended checking the identity provider logs for the time that this user was removed, it couldn't hurt for sure and maybe it won't tell you why it was deleted, but it could provide some more details on what's going on.

As for what anonymous user means, I am not sure. I did look this up and couldn't find anyone confirming what it actually means. 

[Ed Letifov _TechTime - New Zealand_]

@Michael VanHorn 

The question is marked with Server/Data Center. You say that a SAML authentication provider is used. This implies a use of SSO app — many 3rd party SSO apps do have this functionality to sync user groups on login based on the groups sent by the IdP in the SAML LoginResponse message. Often they also trigger a re-sync via backend AD/LDAP connection. This one in particular will be done as anonymous/system. In 

So in essence @Jason Krewson suggestion is correct — check your IdP and check your backend directory.

[Michael VanHorn]

I am positive there is no group in our authentication server called "confluence-administrators". The only thing we do against that server is authentication.

So I suppose Confluence could be updating that user's information from there server, determines that that user isn't in the confluence-administrators group in the authentication server (since there is no such group), and then removing them from that group in Confluence. 

How do you stop Confluence from thinking that the groups in the authentication server matter?

[Ed Letifov _TechTime - New Zealand_]

@Michael VanHorn this all depends on what exactly is configured.

You should really direct this query + detailed configuration at Atlassian support (at support.atlassian.com – get through the AI chat and eventually there will be a link to submit a ticket), not the free Atlassian Community. Asking for support here is like asking for support on Atlassian-specific Facebook — sure someone may just point you in the right direction, but you should not be sharing specifics with any of us. And this question (I think) will require specifics.

[Jason Krewson]

I'm guessing you checked the logs and that is where you are seeing the removed by anonymous?

Are you connected to an identity provider for authentication?

If so, maybe the user was removed by that and the logs just didn't catch that the identity provider removed the user. You could check in the identity providers logs also, might provide more information on this. 

But it seems whatever removed the user Confluence didn't catch the persons name, maybe an Atlassian ticket would help here but not sure.