I assume you are using Active Directory in this instance, in which case the problem is simply that AD doesn't not support LDAP queries for DN values with wildcards (except for memberOf=* type queries where you're looking for anything with the value set).
https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx:
The wildcard character "*" is allowed, except when the is a DN attribute. Examples of DN attributes are distinguishedName, manager, directReports, member, and memberOf. If the attribute is DN, then only the equality operator is allowed and you must specify the full distinguished name for the value (or the "*" character for all objects with any value for the attribute)
The approach I've taken to accomplish what you want to do is to create an "all users" group for the application -- so "All Confluence Users", and then access-level groups like "Confluence Admins", "Confluence Engineers", "Confluence Service Delivery". The process that provisions individuals into groups adds the all users group whenever someone is added to one of the access-level groups (bit of lazy coding, that; I don't want to check if they're already a member and can easily ignore ldap error 20-value already exists); accounts are removed from the all users group when the last access-level group has been removed from their account.
Both adding and removing individuals from the all members group could be done in batch -- and I'd probably do that if groups were manually provisioned in my environment. Anyone matching "(&(!(memberOf={the all users group))(|(memberOf={appgroup1})(memberOf={appgroup2})...(memberOf=appgroupN)))" gets added to my all users group; (&((memberOf={the all users group))(!(|(memberOf={appgroup1})(memberOf={appgroup2})...(memberOf=appgroupN)))) gets removed from my all users group.
My user filter is "(&(memberOf={the all user group}))" while who can actually access what is controlled by the other group memberships.