On 2015-10-19 19:38, Jakub Hrozek wrote:
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?
Sorry for
not coming back earlier.
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.
id_provider=ad. Yes. But ID mapping is disabled
as all user accounts and
groups have got uid- and gidnumber set.
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).
Yes, I saw that in the log.
If multiple groups match, we try to select the "best
match", ie the DN
which differs the least from the search base.
In this case the groups are located
at ldap_search_base/ou1 respectivly
ldap_search_base/ou2 and the group found is located in ou2.
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 :-)
It does, thank you.
The groups of course have got unique sAMAccountName but same cn (and
different dn). It is interesting that SSSD picks the group with lowest
uidNumber.
Thank you for the explanation.
Regards
Davor Vusir
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users