On Mon, Nov 18, 2019 at 03:12:35PM -0000, Jamal Mahmoud wrote:
> On Fri, Nov 15, 2019 at 10:58:17AM -0000, Jamal Mahmoud wrote:
>
> 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
Hi Sumit,
After adding in the ad_enable_gc=false, it doesn't seem to stop the errors we are
getting, the last problem we got (today) was a logged in user had only his uid and the
primary GID, not sure if this is a different issue but i'm starting to get the feeling
that there is something misconfigured on our SSSD client setup.
Although, since I rolled this out, the machines with the new config did not get the
"non-POSIX POSIX group in the cache" problem we've been discussing, so it
may be solved, or coincedentally the specific error hasn't come up again.
As an aside, I've noticed that when the backend fetches new data for the cache,
sometimes it will just update the ts_cache and sometimes it will update both the cache and
the ts_cache. What determines this behaviour? I'm asking because when the cache
fetches and updates, it actually fixes the problem when it updates the cache but when it
only changes the ts_cache the issue remains, i've added a couple of examples to
explain:
Updates both cache and ts_cache
[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.
Updates only the ts_cache:
[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
Realistically it should see that the incoming data is different to the cached data no?
Hi,
we use the timestamp LDAP attribute which stored the last modification
time to decide if it is sufficient to just update the timestamp cache or
if the data cache should be updated as well. In AD this attribute is
called 'whenChanged' and the comparison between stored in new value is
just a comparison of the strings, if they differ the data cache will be
updated as well.
What you describe might have two reason. If you add a member to a group
on a Domain Controller (DC) A but SSSD is connected to DC B it might
refresh the group after the new member is added but before the new data
is replicated to DC B. This is somewhat expected and if the data is
finally replicated to DC B and the cached group is expired again the
data cache will be updated.
The second reason might be that 'whenChanged' is handled even more
differently then we thought. 'whenChanged' itself will not be replicated
from DC A to DC B but DC B should update 'whenChanged' when the new data
from DC A is added to the DC B with the current time. So it is expected
that 'whenChanged' for the same object is different on every DC but is
should change whenever the data is updated. That's e.g. the reason we
just do a string comparison, 'whenChanged' should just be different to
update the data cache and we do not care if the numerical values are
larger or smaller.
Sorry for the heavy message, please let me know if you need any specifics and I'll be
glad to provide. Really appreciate the time you're giving to help us out.
I wonder if you can try to monitor the replication in your environment
by adding a new member to a group on a Domain Controller and check the
group object on another Domain Controller in regular intervals (e.g.
every 2s) with ldapsearch, especially the 'member' and the 'whenChanged'
attributes. This should help to understand if replication just takes
long or if 'member' and 'whenChanged' are no updated together on the
other DC.
Thanks
bye,
Sumit
Kind Regards,
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...