On Mon, Oct 19, 2015 at 12:19:02PM +0200, Davor Vusir wrote:
Hello,
two groups with identical cn, but residing in different OUs on the same
level, containing the same user accounts. The first has got RID 307742 and
gidNumber 10307742. The other has got RID 307744 and gidNumber 10307744.
Running "id useraccount" returns the group with the lower gidNumber. After
renaming the second group (adding the number 2), both groups are resolved.
Moving first group (RID 307742/gidNumber 20307742) away from search base and
create a third group with the same name. This group gets RID 307358 and
gidNumber 10307358 returns this newly created group when running "id
useraccount".
Level 9 log shows this difference:
[sssd[be[ad.example.org]]] [sysdb_search_users] (0x2000): Search users with
filter: (&(objectclass=user)(gidNumber=10307742))
[sssd[be[ad.example.org]]] [sysdb_search_users] (0x2000): Search users with
filter: (&(objectclass=user)(gidNumber=10307358))
It is always the group with the lower gidNumber that's beeing checked.
Is SSSD using some name based filter? Or what filter is being used?
Depends on the id_provider being used and it's settings.
Since the RID matches the GID, I assume you're using id_provider=ad with
ID mapping enabled. In that case, there is a different mechanism for
looking up the groups the user is a member of (initgroups) and for
looking up details of the groups.
For initgroups with ID mapping we fetch the list of group SIDs the user
is a member of, convert the SIDs into GIDs and return those as a result
of initgroups/getgrouplist.
For resolving the group GIDs into names (getgrgid) we look up the GID
with an LDAP search, searching for the SID as the search key and using
the ldap_group_search_base (which is often inferred from the AD domain
name).
If multiple groups match, we try to select the "best match", ie the DN
which differs the least from the search base.
I'm not sure if two groups with the same name but different GID would
work, but I think that if it does, it's only by accident. Keep in mind
that then there's no way to make getgrnam() work deterministically..
I hope it makes sense :-)