use the LDAP browser to view one of the users in the group, and then find the "MemberOf" attribute for the group you want to map against. Use this as the string in the group mappings list.
The user(s) already had the 'memberOf' attribute of the AD Security group (CN=Security Group,OU=Department,OU=Geographic Site,OU=Support,OU=Department,OU=Top Site,DC=Domain,DC=Org) as I described previously. The string is already listed in the connector mappings with the 'memberOf' Directory Services attribute.
It only worked if I move the AD Security group to a higher level OU so the DN is now: CN=Security Group,OU=Department,DC=Domain,DC=Org.
I have used different MEE Groups in the mappings so I do not believe this is a Database problem. I think it is either the Connector gets confused or it is the OU permissions.
if you log onto the ldap browser with the same credentials you use in the connector, you'll see what it can see. I'm not sure why the group position would matter, the connector is not following the structure of your AD, it's just retrieving the users based on the search you set and then looking through their attributes.
Are you using search groups mode, or an object filter? If you're using search groups, then obviously the connector won't see those users unless they match the search.
You could set MemberOf to be a substring-searched attribute, then you'd just need the CN to score a match?
I am using Search Groups Mode and have the 'memberOf' for the substring search atribute. The CN match should be good know matter where I place the AD Security Group in my OU directory. I think now that it is an AD problem. I used a very long CN with duplicate OU names inside the string and it works perfectly in my test environment.