Here's the text of the support ticket I logged that was resolved by directing me to this a page. I'm not including the screenshots as they are a bit too sensitive for a public ticket, but if you follow along you can see that this is definitely buggy behavior (especially re. JIRA filter handling):

We are using Crowd 1.4.4 to integrate our AD environment with JIRA 3.12.3, Confluence , and Fisheye installations. We have selected users and groups coming in from our Active Directory infrastructure, with specific filters on both users and groups to limit the objects that are available to Crowd and integrated applications.

The issue we are seeing is that, while the list of groups is correct when querying our directory for groups, we see other groups that should be excluded when looking at a single user and his/her group memberships. It appears as though Crowd 1.4.4 is looking up groups via the memberOf attribute, but not then using SIDs or full DNs to drop groups out of the membership list that do not match the group LDAP filter.

I think this is different from earlier versions of Crowd, and it is creating production problems and exceptions in JIRA due to some group naming conflicts and inconsistent permission handling.
Example

As an example - we have two groups named Telecom, in different OUs, which is valid in AD. One is in an OU that is imported to Crowd; the other is not and should not be in Crowd (screenshot 1 shows that we only have one list - good). We have a user who is a member of the Telecom group that is not included in our Crowd LDAP filter. When we look at the membership list of the Telecom list that is imported into Crowd, we do not see the user (screenshot 2 - also good). However, when we look at the user's record and switch to the Group tab, we do see the Telecom group, hyperlinked even to the Crowd group that does not include him. Additionally, we see other groups in the user's membership list that don't match any Crowd groups by name - they're mailing lists that shouldn't be in Crowd at all. (screenshot 3 - bad).

In this case, we end up with a user who both "is and is not" in the Telecom group. In JIRA, we have a filter that is shared with the Telecom group and shows tickets in our Telecom project. If the user tries to load a dashboard portlet showing statistics for his various filters, JIRA throws an exception because (a) part of the application thinks he is in the Telecom group and should have the filter, but (b) another part of JIRA doesn't think he's in the Telecom group and dies trying to access the issue counts.

I have seen some other issues too where users are getting groups that should not be in Crowd when choosing groups for filter sharing. Perhaps the part of Jira that is evaluating groups vis-a-vis filters is not consistent?

Our Active Directory environment is set up in a similar manner – with a separate OU for Crowd.

It appears that Crowd is now getting group memberships from the memberOf attribute in LDAP (which is a good thing). However, it would be nice to not see all the groups that are outside of the group base DN.

I'll just add that the behavior I was hoping for (I'll avoid the annoying "now the way it SHOULD work" :->) was that, by limiting my groups query to a subset of all groups in the LDAP store, that I'd only ever see those groups from the perspective of Jira/Confluence/Crowd. The feature might well not be defined that way, of course. But the ability to see those other groups seems to lead to inconsistencies and outright errors with the warnings as described.