On Fri, Nov 15, 2019 at 10:58:17AM -0000, Jamal Mahmoud wrote:
Hi Sumit,
Thank you for getting back to me.
> Now it would be important to know if the group is defined in the same
> domain your client is joined to or if it is coming form a different
> domain.
>
> In the latter case (group is coming from a different domain) the cache
> attributes 'isPosix: FALSE' and 'gidNumber: 0' are expected because
SSSD
> will filter out those groups because they are not valid in the domain
> the client is joined to. My guess is that using the group as primary
> group for some users might use a code path that skips the filter so that
> it is added to the cache as proper group first but later on another
> lookup uses the filter and removes the gidNumber and sets isPosix to
> FALSE. To solve this you should switch the scope of the group to
> 'Global' or 'Universal'.
>
> In the former case (group is from the domain the client is joined to) it
> would be good to know if you are using UIDs and GIDs stored in AD or if
> you use SSSD's id-mapping scheme (ldap_id_mapping = False / True
> respectively).
>
> bye,
> Sumit
The group we are using is defined in the same domain and for the most part it does in
fact return the correct GIDs for the group. We have set ldap_id_mapping to false as we are
using POSIX attributes on our AD users and groups.
Ok, do you know if the LDAP attributes uidNumber and gidNumber are
replicated to the Global Catalog in your environment? By default they
are not.
You can check this manually as well with ldapsearch on the Global
Catalog port 3268:
ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b
'DC=your,DC=ad,DC=domain' samAccountName=groupname
If gidNumber is missing in the Global Catalog object please try if
setting
ad_enable_gc = False
in the [domain/...] section of sssd.conf makes the group lookup more
reliable.
bye,
Sumit
I noticed that whenever the backend fills the cache with the wrong data, any updates do
not actually modify the cache entry, we get this:
[sdap_save_group] (0x0400): Storing info for group group(a)domain.com
[sysdb_store_group] (0x1000): The group record of group(a)domain.com did not change, only
updated the timestamp cache
But occasionally, seemingly out of chance it does modify the entry, fixing the problem
and setting the group to isPosix: TRUE when we get this:
[sdap_save_group] (0x0400): Storing info for group group(a)domain.com
[sysdb_set_entry_attr] (0x0200): Entry
[name=group(a)domain.com,cn=groups,cn=domain.com,cn=sysdb] has set [cache, ts_cache] attrs.
Not sure if any of that means anything towards the issue, just trying to give as much
information as I can!
Do let me know if there is anything more you need,
Thanks,
Jamal
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...