[Samba] Adding user to group doesn't propagate?

Nick Howitt nick at howitts.co.uk
Thu Sep 17 08:43:38 UTC 2020

On 17/09/2020 09:39, Rowland penny via samba wrote:
> 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
O/T, but I thought about it, but you need to be cute if you want to 
automate it such that adding the user to the dummy group does not 
trigger the script. Otherwise you end up in an infinite loop. It wasn't 
worth it.

More information about the samba mailing list