Description of problem:
I have a Satellite system that consumes a rather interesting LDAP tree for obtaining its users.

The config is roughly:
type: POSIX
baseDN: ou=users,dc=redhat,dc=com
groupBaseDN: dc=redhat,dc=com
usergroup_sync: true

Now, the groups come from two sub-trees (and that's why the above group base is so broad): ou=Groups,dc=redhat,dc=com and ou=adhoc,ou=managedGroups,dc=redhat,dc=com.

The first one is a rather normal thing full of posixGroups like this:
dn: cn=desingh,ou=Groups,dc=redhat,dc=com
memberUid: desingh
gidNumber: 105596
cn: desingh
objectClass: top
objectClass: posixGroup

The second one is dynamically generated from an external app, and looks like this (abbreviated):
dn: cn=satellite-qe,ou=adhoc,ou=managedGroups,dc=redhat,dc=com
uniqueMember: uid=desingh,ou=users,dc=redhat,dc=com
owner: uid=desingh,ou=users,dc=redhat,dc=com
description: Groups consists members from Satellite QE team
cn: satellite-qe
objectClass: groupOfUniqueNames
objectClass: top

Now, as you can see, the user "desingh" is member of both these groups.

In Satellite, I have an external usergroup "satellite-qe" that is linked to cn=satellite-qe,ou=adhoc,ou=managedGroups,dc=redhat,dc=com.
When I hit "refresh" in the UI (or run the "ldap:refresh_usergroups" cronjob), the user "desingh" is listed as being a member of this external group and everything is fine.

However, once the user logs in, an additional group sync is performed and the user is loosing this additional group (and all permissions inherited by it).

This seems to be because the "group_list(user)" method doesn't find the qe group:
irb(main):012:0> l = AuthSource.find_by(name: 'Red Hat')
=> #<AuthSourceLdap id: 4, type: "AuthSourceLdap", name: "Red Hat", ...
irb(main):013:0> l.ldap_con.group_list('desingh')
=> ["desingh"]

I think this is because the underlying library is only looking for "memberuid", but not "uniquemember" relationships (https://github.com/theforeman/ldap_fluff/blob/master/lib/ldap_fluff/posix_member_service.rb):
  def find_user_groups(uid)
    groups = []
    @ldap.search(:filter => Net::LDAP::Filter.eq('memberuid', uid), :base => @group_base).each do |entry|
      groups << entry[:cn][0]
    end
    groups
  end

However, the "other way round" (find all members of a group), *does* support looking up by uniquemember, resulting in this discrepancy:
  def select_member_method(search_result)
    if @use_netgroups
      :nisnetgrouptriple
    else
      %i[member memberuid uniquemember].find { |m| search_result.respond_to? m }
    end
  end

Given support for groupOfUniqueNames was explicitly introduced in https://github.com/theforeman/ldap_fluff/commit/14f0d0fdeb3205d4e9b6b5afc6a2b5ccc74e2f6b, I would think this is a bug and find_user_groups should be able to find the same data.


Version-Release number of selected component (if applicable):
6.11

How reproducible:
100%

Steps to Reproduce:
1. setup ldap source
2. setup a group based on groupOfUniqueNames
3. let a user of such a group log in
4. refresh the group
5. let the user login again

Actual results:
User not member of group

Expected results:
User member of group

Additional info: