On Wed, 16 Sep 2020, Rowland penny via samba wrote:> On 16/09/2020 09:02, Harald Hannelius via samba wrote: >> On Mon, 31 Aug 2020, Jonathon Reinhart via samba wrote: >>> On Mon, Aug 31, 2020 at 9:21 AM Harald Hannelius via samba >>> <samba at lists.samba.org> wrote: >>>> On Wed, 17 Jun 2020, Harald Hannelius wrote: >>>>> On Wed, 17 Jun 2020, Harald Hannelius via samba wrote: >>>>>> On Wed, 17 Jun 2020, Rowland penny via samba wrote: >>>>>>> On 17/06/2020 11:54, Harald Hannelius wrote: >>>>>>>> On Wed, 17 Jun 2020, Rowland penny via samba wrote: >>>>>>>>> On 17/06/2020 11:39, Harald Hannelius via samba wrote: >>>>>>>> >>>>>>>> Sorry, You lost me here. Has this been discussed recently? I'm in the >>>>>>>> middle of so many projects I haven't had time to sit and follow this >>>>>>>> list >>>>>>>> as much as I'd like to. >>>>>>> No, it hasn't been discussed before, it happened to myself a couple of >>>>>>> weeks ago, I added the user to a group and 'id' didn't show the group, >>>>>>> everything else showed the user was a group member. I just put it down >>>>>>> to >>>>>>> one of those things, but the following day, 'id' showed the group, so >>>>>>> I >>>>>>> think it must be a cache problem. >>>>>> >>>>>> I see. >>>>>> >>>>>> I just checked, and all other users who show up correctly in the new >>>>>> group >>>>>> are indeed not logged on to the domain. >>>>>> >>>>>> Could it be that an active session locks the group memberships until >>>>>> the >>>>>> user logs out and in again? This might even be exactly like Windows >>>>>> works >>>>>> if I read correctly. >>>>>> >>>>>>>> I read somewhere that there's some caching going on, but there was no >>>>>>>> real solution on how to purge this cache other than have the client >>>>>>>> log >>>>>>>> out of their computer and on again. I have asked my colleague to do >>>>>>>> this, >>>>>>>> so it might be that waiting until tomorrow won't work. >>>>>>> >>>>>>> I tried all that, it just worked the following day. The only thing I >>>>>>> didn't do, raise the log level. >>>>>> >>>>>> Ok, I'll wait if the logout/login doesn't work. >>>>> >>>>> The user restarted their computer and presto: 'groups username' showed >>>>> the >>>>> new membership on the member-server. >>>> >>>> Googling a problem, and finding one's own e-mail thread as the first hit. >>>> I >>>> had already forgot about this. >>>> >>>> Added a group on the DC, added two members to that group and at least on >>>> of >>>> those are logged on to the domain. The group doesn't show up on a >>>> member-server. >>>> >>>> I will probably have to wait until tomorrow before I'm able to use that >>>> group? >>>> >>>> Are there plans to fix this so one can add groups and edit group >>>> memberships faster? >>>> >>> >>> I too have observed this. >>> >>> Network: >>> - Two Samba DCs (4.9.5+dfsg-5+deb10u1) >>> - File server:? FreeNAS-11.2-U7 (running Samba 4.9.15) >>> >>> My internal ticket notes: >>> >>> - I added `jdoe` to the `cost estimates` folder ACL, and he was able >>> to see the `AAA` subdirectory immediately (because he was on that ACL >>> already) >>> - I added him to the `XXX Finance` group, and it had no effect >>> - The NAS did not believe he was a member of that group: >>> ?? root at nas[~]# id jdoe >>> ?? uid=100041(jdoe) gid=100000(domain users) groups=100000(domain >>> ?? users),100010(xxx program),100016(engineering),100025(aaa >>> ?? program),90000002(BUILTIN\users) >>> - I tried clicking `REBUILD DIRECTORY SERVICE CACHE` in the FreeNAS >>> GUI and it had no effect >>> - I ran `watch id jdoe` and as soon as he authenticated with the NAS >>> (his machine is not yet joined) and hit enter, his membership changed >>> on the NAS: >>> ?? uid=100041(jdoe) gid=100000(domain users) groups=100000(domain >>> ?? users),100010(xxx program),100016(engineering),100025(aaa >>> ?? program),100031(xxx finance),90000002(BUILTIN\users) >>> >>> So apparently re-authenticating triggers group membership update... or >>> something like that. >>> >>> How does a Windows server handle this? >>> >>> Resources: >>> - >>> https://www.ixsystems.com/community/threads/slow-updating-active-directory-user-group-cache.57448/ >>> - >>> https://www.ixsystems.com/community/threads/permissions-cifs-wont-pull-user-or-group-from-the-network.46044/ >>> - >>> https://www.ixsystems.com/community/threads/windows-users-groups-not-refreshing.28883/ >>> - >>> https://www.ixsystems.com/community/threads/ad-group-memberships-wont-update.63404/ >>> >>> Possibly related Samba source code: >>> - wcache_invalidate_samlogon() [1] "Invalidate the getpwnam and >>> getgroups entries for a winbindd domain": Called only from >>> ?- winbindd_dual_pam_auth >>> ?- winbind_dual_SamLogon >>> >>> >>> [1]: >>> https://gitlab.com/samba-team/samba/-/blob/03f79a3bd71bc7a0a401d5f19560e831251d32b7/source3/winbindd/winbindd_cache.c#L3056 >> >> Does anyone have any tips on how to circumvent this problem? I have almost >> daily group membership-changes, and sometimes waiting 24 hours isn't enough >> for the changes in a group to propagate. >> >> I have tried to restart smbd, nmbd and winbindd on the member server to no >> avail. On the test-server that nobody uses the changes show up much much >> earlier. >> >> Is there a way to check if a user is authenticated to the domain at the >> present moment, and then kick out the user? >> >> > On the few occasions that this has hit me, I tracked it down to a time > difference, so have you checked this ?This seems to hit me every time I add someone to a group. All servers are of course hooked up to the NTP-network. -- Harald Hannelius | harald.hannelius/a\arcada.fi | +358 50 594 1020
On 17/09/2020 08:41, Harald Hannelius via samba wrote:> > > On Wed, 16 Sep 2020, Rowland penny via samba wrote: >> On 16/09/2020 09:02, Harald Hannelius via samba wrote: >>> On Mon, 31 Aug 2020, Jonathon Reinhart via samba wrote: >>>> On Mon, Aug 31, 2020 at 9:21 AM Harald Hannelius via samba >>>> <samba at lists.samba.org> wrote: >>>>> On Wed, 17 Jun 2020, Harald Hannelius wrote: >>>>>> On Wed, 17 Jun 2020, Harald Hannelius via samba wrote: >>>>>>> On Wed, 17 Jun 2020, Rowland penny via samba wrote: >>>>>>>> On 17/06/2020 11:54, Harald Hannelius wrote: >>>>>>>>> On Wed, 17 Jun 2020, Rowland penny via samba wrote: >>>>>>>>>> On 17/06/2020 11:39, Harald Hannelius via samba wrote: >>>>>>>>> >>>>>>>>> Sorry, You lost me here. Has this been discussed recently? I'm >>>>>>>>> in the >>>>>>>>> middle of so many projects I haven't had time to sit and follow >>>>>>>>> this list >>>>>>>>> as much as I'd like to. >>>>>>>> No, it hasn't been discussed before, it happened to myself a >>>>>>>> couple of >>>>>>>> weeks ago, I added the user to a group and 'id' didn't show the >>>>>>>> group, >>>>>>>> everything else showed the user was a group member. I just put >>>>>>>> it down to >>>>>>>> one of those things, but the following day, 'id' showed the >>>>>>>> group, so I >>>>>>>> think it must be a cache problem. >>>>>>> >>>>>>> I see. >>>>>>> >>>>>>> I just checked, and all other users who show up correctly in the >>>>>>> new group >>>>>>> are indeed not logged on to the domain. >>>>>>> >>>>>>> Could it be that an active session locks the group memberships >>>>>>> until the >>>>>>> user logs out and in again? This might even be exactly like >>>>>>> Windows works >>>>>>> if I read correctly. >>>>>>> >>>>>>>>> I read somewhere that there's some caching going on, but there >>>>>>>>> was no >>>>>>>>> real solution on how to purge this cache other than have the >>>>>>>>> client log >>>>>>>>> out of their computer and on again. I have asked my colleague >>>>>>>>> to do this, >>>>>>>>> so it might be that waiting until tomorrow won't work. >>>>>>>> >>>>>>>> I tried all that, it just worked the following day. The only >>>>>>>> thing I >>>>>>>> didn't do, raise the log level. >>>>>>> >>>>>>> Ok, I'll wait if the logout/login doesn't work. >>>>>> >>>>>> The user restarted their computer and presto: 'groups username' >>>>>> showed the >>>>>> new membership on the member-server. >>>>> >>>>> Googling a problem, and finding one's own e-mail thread as the >>>>> first hit. I >>>>> had already forgot about this. >>>>> >>>>> Added a group on the DC, added two members to that group and at >>>>> least on of >>>>> those are logged on to the domain. The group doesn't show up on a >>>>> member-server. >>>>> >>>>> I will probably have to wait until tomorrow before I'm able to use >>>>> that >>>>> group? >>>>> >>>>> Are there plans to fix this so one can add groups and edit group >>>>> memberships faster? >>>>> >>>> >>>> I too have observed this. >>>> >>>> Network: >>>> - Two Samba DCs (4.9.5+dfsg-5+deb10u1) >>>> - File server:? FreeNAS-11.2-U7 (running Samba 4.9.15) >>>> >>>> My internal ticket notes: >>>> >>>> - I added `jdoe` to the `cost estimates` folder ACL, and he was able >>>> to see the `AAA` subdirectory immediately (because he was on that ACL >>>> already) >>>> - I added him to the `XXX Finance` group, and it had no effect >>>> - The NAS did not believe he was a member of that group: >>>> ?? root at nas[~]# id jdoe >>>> ?? uid=100041(jdoe) gid=100000(domain users) groups=100000(domain >>>> ?? users),100010(xxx program),100016(engineering),100025(aaa >>>> ?? program),90000002(BUILTIN\users) >>>> - I tried clicking `REBUILD DIRECTORY SERVICE CACHE` in the FreeNAS >>>> GUI and it had no effect >>>> - I ran `watch id jdoe` and as soon as he authenticated with the NAS >>>> (his machine is not yet joined) and hit enter, his membership changed >>>> on the NAS: >>>> ?? uid=100041(jdoe) gid=100000(domain users) groups=100000(domain >>>> ?? users),100010(xxx program),100016(engineering),100025(aaa >>>> ?? program),100031(xxx finance),90000002(BUILTIN\users) >>>> >>>> So apparently re-authenticating triggers group membership update... or >>>> something like that. >>>> >>>> How does a Windows server handle this? >>>> >>>> Resources: >>>> - >>>> https://www.ixsystems.com/community/threads/slow-updating-active-directory-user-group-cache.57448/ >>>> >>>> - >>>> https://www.ixsystems.com/community/threads/permissions-cifs-wont-pull-user-or-group-from-the-network.46044/ >>>> >>>> - >>>> https://www.ixsystems.com/community/threads/windows-users-groups-not-refreshing.28883/ >>>> >>>> - >>>> https://www.ixsystems.com/community/threads/ad-group-memberships-wont-update.63404/ >>>> >>>> >>>> Possibly related Samba source code: >>>> - wcache_invalidate_samlogon() [1] "Invalidate the getpwnam and >>>> getgroups entries for a winbindd domain": Called only from >>>> ?- winbindd_dual_pam_auth >>>> ?- winbind_dual_SamLogon >>>> >>>> >>>> [1]: >>>> https://gitlab.com/samba-team/samba/-/blob/03f79a3bd71bc7a0a401d5f19560e831251d32b7/source3/winbindd/winbindd_cache.c#L3056 >>>> >>> >>> Does anyone have any tips on how to circumvent this problem? I have >>> almost daily group membership-changes, and sometimes waiting 24 hours >>> isn't enough for the changes in a group to propagate. >>> >>> I have tried to restart smbd, nmbd and winbindd on the member server >>> to no avail. On the test-server that nobody uses the changes show up >>> much much earlier. >>> >>> Is there a way to check if a user is authenticated to the domain at >>> the present moment, and then kick out the user? >>> >>> >> On the few occasions that this has hit me, I tracked it down to a time >> difference, so have you checked this ? > > This seems to hit me every time I add someone to a group. > > All servers are of course hooked up to the NTP-network. >I did draft this reply yesterday but then didn't send it as I was not sure if it was appropriate: Outside Samba, but with OpenLDAP and its syncrepl replication, it has the same sort of issue and OpenLDAP blame Micro$oft for a lack of specification to the replication functionality. The observation is that the group memberof attribute for the user record is always one change behind which is kind of weird. To if you add a user to a group, it does not show until a further change is made to the user (including removing the user from the group which then adds it to the group on the replicated version ........ one change behind). One possible workaround was to create a dummy group. Then after making and saving your change to the user, make another change to the user, flipping his membership of the dummy group. The other workaround, if doing an LDAP lookup on the replicate, was to look at the group record and look for the user being a member of it. This group record always replicates correctly. Nick
On 17/09/2020 09:01, Nick Howitt via samba wrote:> > > On 17/09/2020 08:41, Harald Hannelius via samba wrote: >> >> >> On Wed, 16 Sep 2020, Rowland penny via samba wrote: >>> On 16/09/2020 09:02, Harald Hannelius via samba wrote: >>>> On Mon, 31 Aug 2020, Jonathon Reinhart via samba wrote: >>>>> On Mon, Aug 31, 2020 at 9:21 AM Harald Hannelius via samba >>>>> <samba at lists.samba.org> wrote: >>>>>> On Wed, 17 Jun 2020, Harald Hannelius wrote: >>>>>>> On Wed, 17 Jun 2020, Harald Hannelius via samba wrote: >>>>>>>> On Wed, 17 Jun 2020, Rowland penny via samba wrote: >>>>>>>>> On 17/06/2020 11:54, Harald Hannelius wrote: >>>>>>>>>> On Wed, 17 Jun 2020, Rowland penny via samba wrote: >>>>>>>>>>> On 17/06/2020 11:39, Harald Hannelius via samba wrote: >>>>>>>>>> >>>>>>>>>> Sorry, You lost me here. Has this been discussed recently? >>>>>>>>>> I'm in the >>>>>>>>>> middle of so many projects I haven't had time to sit and >>>>>>>>>> follow this list >>>>>>>>>> as much as I'd like to. >>>>>>>>> No, it hasn't been discussed before, it happened to myself a >>>>>>>>> couple of >>>>>>>>> weeks ago, I added the user to a group and 'id' didn't show >>>>>>>>> the group, >>>>>>>>> everything else showed the user was a group member. I just put >>>>>>>>> it down to >>>>>>>>> one of those things, but the following day, 'id' showed the >>>>>>>>> group, so I >>>>>>>>> think it must be a cache problem. >>>>>>>> >>>>>>>> I see. >>>>>>>> >>>>>>>> I just checked, and all other users who show up correctly in >>>>>>>> the new group >>>>>>>> are indeed not logged on to the domain. >>>>>>>> >>>>>>>> Could it be that an active session locks the group memberships >>>>>>>> until the >>>>>>>> user logs out and in again? This might even be exactly like >>>>>>>> Windows works >>>>>>>> if I read correctly. >>>>>>>> >>>>>>>>>> I read somewhere that there's some caching going on, but >>>>>>>>>> there was no >>>>>>>>>> real solution on how to purge this cache other than have the >>>>>>>>>> client log >>>>>>>>>> out of their computer and on again. I have asked my colleague >>>>>>>>>> to do this, >>>>>>>>>> so it might be that waiting until tomorrow won't work. >>>>>>>>> >>>>>>>>> I tried all that, it just worked the following day. The only >>>>>>>>> thing I >>>>>>>>> didn't do, raise the log level. >>>>>>>> >>>>>>>> Ok, I'll wait if the logout/login doesn't work. >>>>>>> >>>>>>> The user restarted their computer and presto: 'groups username' >>>>>>> showed the >>>>>>> new membership on the member-server. >>>>>> >>>>>> Googling a problem, and finding one's own e-mail thread as the >>>>>> first hit. I >>>>>> had already forgot about this. >>>>>> >>>>>> Added a group on the DC, added two members to that group and at >>>>>> least on of >>>>>> those are logged on to the domain. The group doesn't show up on a >>>>>> member-server. >>>>>> >>>>>> I will probably have to wait until tomorrow before I'm able to >>>>>> use that >>>>>> group? >>>>>> >>>>>> Are there plans to fix this so one can add groups and edit group >>>>>> memberships faster? >>>>>> >>>>> >>>>> I too have observed this. >>>>> >>>>> Network: >>>>> - Two Samba DCs (4.9.5+dfsg-5+deb10u1) >>>>> - File server:? FreeNAS-11.2-U7 (running Samba 4.9.15) >>>>> >>>>> My internal ticket notes: >>>>> >>>>> - I added `jdoe` to the `cost estimates` folder ACL, and he was able >>>>> to see the `AAA` subdirectory immediately (because he was on that ACL >>>>> already) >>>>> - I added him to the `XXX Finance` group, and it had no effect >>>>> - The NAS did not believe he was a member of that group: >>>>> ?? root at nas[~]# id jdoe >>>>> ?? uid=100041(jdoe) gid=100000(domain users) groups=100000(domain >>>>> ?? users),100010(xxx program),100016(engineering),100025(aaa >>>>> ?? program),90000002(BUILTIN\users) >>>>> - I tried clicking `REBUILD DIRECTORY SERVICE CACHE` in the FreeNAS >>>>> GUI and it had no effect >>>>> - I ran `watch id jdoe` and as soon as he authenticated with the NAS >>>>> (his machine is not yet joined) and hit enter, his membership changed >>>>> on the NAS: >>>>> ?? uid=100041(jdoe) gid=100000(domain users) groups=100000(domain >>>>> ?? users),100010(xxx program),100016(engineering),100025(aaa >>>>> ?? program),100031(xxx finance),90000002(BUILTIN\users) >>>>> >>>>> So apparently re-authenticating triggers group membership >>>>> update... or >>>>> something like that. >>>>> >>>>> How does a Windows server handle this? >>>>> >>>>> Resources: >>>>> - >>>>> https://www.ixsystems.com/community/threads/slow-updating-active-directory-user-group-cache.57448/ >>>>> >>>>> - >>>>> https://www.ixsystems.com/community/threads/permissions-cifs-wont-pull-user-or-group-from-the-network.46044/ >>>>> >>>>> - >>>>> https://www.ixsystems.com/community/threads/windows-users-groups-not-refreshing.28883/ >>>>> >>>>> - >>>>> https://www.ixsystems.com/community/threads/ad-group-memberships-wont-update.63404/ >>>>> >>>>> >>>>> Possibly related Samba source code: >>>>> - wcache_invalidate_samlogon() [1] "Invalidate the getpwnam and >>>>> getgroups entries for a winbindd domain": Called only from >>>>> ?- winbindd_dual_pam_auth >>>>> ?- winbind_dual_SamLogon >>>>> >>>>> >>>>> [1]: >>>>> https://gitlab.com/samba-team/samba/-/blob/03f79a3bd71bc7a0a401d5f19560e831251d32b7/source3/winbindd/winbindd_cache.c#L3056 >>>>> >>>> >>>> Does anyone have any tips on how to circumvent this problem? I have >>>> almost daily group membership-changes, and sometimes waiting 24 >>>> hours isn't enough for the changes in a group to propagate. >>>> >>>> I have tried to restart smbd, nmbd and winbindd on the member >>>> server to no avail. On the test-server that nobody uses the changes >>>> show up much much earlier. >>>> >>>> Is there a way to check if a user is authenticated to the domain at >>>> the present moment, and then kick out the user? >>>> >>>> >>> On the few occasions that this has hit me, I tracked it down to a >>> time difference, so have you checked this ? >> >> This seems to hit me every time I add someone to a group. >> >> All servers are of course hooked up to the NTP-network. >> > I did draft this reply yesterday but then didn't send it as I was not > sure if it was appropriate: > > Outside Samba, but with OpenLDAP and its syncrepl replication, it has > the same sort of issue and OpenLDAP blame Micro$oft for a lack of > specification to the replication functionality. > > The observation is that the group memberof attribute for the user > record is always one change behind which is kind of weird. To if you > add a user to a group, it does not show until a further change is made > to the user (including removing the user from the group which then > adds it to the group on the replicated version ........ one change > behind). One possible workaround was to create a dummy group. Then > after making and saving your change to the user, make another change > to the user, flipping his membership of the dummy group. > > The other workaround, if doing an LDAP lookup on the replicate, was to > look at the group record and look for the user being a member of it. > This group record always replicates correctly. > > Nick > >That's weird =-O How about writing a script that adds the user to a 'dummy' group and then immediately removes the user from the group. Add user to the correct group and then run the script, wonder if that will work ? Rowland