@Brennan Norwood

You've just saved me such a headache by forcing full sync rather than incremental, thank you!

Hi aaragon1349470489,

All of the groups were imported from LDAP. I completely agree that the mismatch should disappear, but it wasn't until disabling the incremental sync as I mentioned above. It was broken for a number of days while I searched for an answer, and as soon as a Full Sync ran instead of the incremental one, the problem was gone.

Hi @Brennan Norwood!

Are some of them local groups? Or all of your groups are imported from the LDAP.

I think the problem appears only with local groups. It stands to reason that if all groups are imported from ldap, the mismatch will disappear using full sync.

For anyone who is still experiencing this issue, we were able to resolve this by disabling the Incremental Sync option in the Active Directory sync settings. Doing this triggered a full sync instead of an incremental sync, and the group memberships for the users which were having the problem re-appeared. 

We have a fairly small organization (~200 Users), so we made the decision to leave the incremental sync off as it took no more time to complete. In theory you should be able to re-enable it after the full sync, and it would be happy again.

Dear Atlassian,
Why is this marked as Won't Fix ? We had a situation where the AD group had to be moved to different OU. This caused the user group information to be lost.

we are currently experiencing same odd problems
There was a problem with our LDAP Servers, one or two of the LDAP knots went down (3 Servers behind 1 Load Balancer), so we had to connect the systems to a special LDAP knot (instead of the LDAP Load Balancer) afterwards, most users lost their local group memberships in confluence, jira and stash as well.
We have approx >20k Users on our systems thus we need a solution for the future, that if a user is not found by the LDAP Connector the Atlassian Application must not delete the Group Memberships. Something like a deactivation or a checkbox like "in case of LDAP connection loss do not delete group memberships".
We now have loads of User Tickets caused by access problems/ missing group memberships - this is definetely not enterprise like -
Out SAP Netweaver Portal for example, was affected by the LDAP server dowtime as well, so we did the same workaround : creating a new LDAP connection the only LDAP knot that has kept running - and no one loses their group memberships.

I think that a much better approach in this case would be to just disable the missing user, without trying to remove it.

On real production systems with big directories (>5.000 users), this may happen more often than you may think.

When deleting a user from the directory, we remove their group memberships as well. This stops orphan data from being left around and stops users inheriting old group memberships upon being re-added (See https://jira.atlassian.com/browse/JRA-25611 for a resolved bug related to this as well).

We feel it's better to have a user decrease permissions than incorrectly inherit elevated permissions. Additionally it seems likely that if a user is disappearing from a remote directory, there is a larger problem at play beyond JIRA.