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 ☀️

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