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?
Regards Davor Vusir
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 :-)
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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=adb148603344a42d6edffd...
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?)
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 2015-10-21 09:36, Jakub Hrozek wrote:
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=adb148603344a42d6edffd...
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Davor Vusir -
Jakub Hrozek