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 gr...@domain.com
> [sysdb_store_group] (0x1000): The group record of gr...@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 gr...@domain.com
> [sysdb_set_entry_attr] (0x0200): Entry
> [name=gr...@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@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@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.fedorahosted.org
