On Wed, Oct 21, 2015 at 09:12:20AM +0200, Davor Vusir wrote:
> 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
Ah, then if also name is conflicting, maybe you just need a version that
contains:
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=adb148603344a42d6ed...
Previously, the default for AD group name attribute used to be name, we
changed it to sAMAccountName.
You can also set:
ldap_group_name = sAMAccountName
in the domain section (but IIRC you'd have to remove the cache?)
Thank you,
Jakub.
This isn't a big issue at the moment, so we'll wait for the patch to be
incorporated in the normal updates.
Regards
Davor
> 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
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users