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 :-)