samba - Jun 2025 - LDAP + SSSD + Winbind group membership updating

Alex Moz via samba wrote:
> Kees van Vloten via samba wrote:
> 
>> This is generic Unix behaviour. The groups of a user are read at 
>> login-time (when pam creates the session) and are not dynamically 
>> updated in the user context during the session. Whether you are using 
>> local groups, winbind or sssd makes no difference, in order to refresh 
>> groups in your context, you must logout en re-login.
>> 
>> But if you do an LDAP-query, query winbind ('wbinfo -r
<user>'), or
>> even 'getent group <user>' for the groups of a user you
will see the
>> changed groups there.
>> 
>> Btw. the behaviour described? in the link above does not reflect what 
>> I am seeing on my machines. 'wbinfo -r <user>' does
return groups for
>> users that have never logged in (with winbind and samba version 
>> 4.21.5).
>> 
>> - Kees.
> 
> ....
> So Winbind sees changes, but it doesn't reflected in the acl until smb 
> is restarted.
> That's the main point, Samba doesn't accept membership changes.
I'm
> trying to find out why.
The thread is old, but this is just for info..

I can't agree with "This is generic Unix behaviour." since
I've managed
to enhance samba's code to make user token refreshing possible during 
the session. So I did what planned. I wrote a small 'token refresh' 
module based on samba 4.22 (thanks AI), built it and it works.

Now the new mechanism refreshes user token and groups membership based 
on user action and time intervals. So it triggers update only when user 
takes action and counter_since_last_update > cache_time. I decided to 
use exist 'winbind cache time' as a cache_time directive. But I got rid 
of winbind. I do not use it (winbindd is disabled). I use SSSD instead.

Time to reflect changes in LDAP to samba share permission depends on 
SSSD cache too. I achieved ~1min of reflect delay with small SSSD cache 
and <3sec delay when use sss_cache -E. I'll try to turn off sssd cache. 
At the same time it should be noted SSSD cache can be used as a mediator 
to relax load on LDAP server as well.

I gonna test it hard, under heavy load with LDAP on the same server. 
Maybe will make a patch for samba after that.

###########

This is just information for those who doubted that it was possible.

On Mon, 09 Jun 2025 12:26:56 +0200
Alex Moz via samba <samba at lists.samba.org> wrote:

> The thread is old, but this is just for info..
> 
> I can't agree with "This is generic Unix behaviour." since
I've
> managed to enhance samba's code to make user token refreshing
> possible during the session. So I did what planned. I wrote a small
> 'token refresh' module based on samba 4.22 (thanks AI), built it
and
> it works.
> 
> Now the new mechanism refreshes user token and groups membership
> based on user action and time intervals. So it triggers update only
> when user takes action and counter_since_last_update > cache_time. I
> decided to use exist 'winbind cache time' as a cache_time
directive.
> But I got rid of winbind. I do not use it (winbindd is disabled). I
> use SSSD instead.
> 
> Time to reflect changes in LDAP to samba share permission depends on 
> SSSD cache too. I achieved ~1min of reflect delay with small SSSD
> cache and <3sec delay when use sss_cache -E. I'll try to turn off
> sssd cache. At the same time it should be noted SSSD cache can be
> used as a mediator to relax load on LDAP server as well.
> 
> I gonna test it hard, under heavy load with LDAP on the same server. 
> Maybe will make a patch for samba after that.
> 
> ###########
> 
> This is just information for those who doubted that it was possible.
> 
I do not think anyone doubted if it was possible, with code, virtually
anything is possible. What was doubted (at least from my perspective),
is it worth doing, the way things are going, then I personally do not
think so, but you are welcome to do whatever you like.

One of the problems is, redhat (one of the big players) obviously does
not really see a future for Openldap, as they removed the
openldap-server package from RHEL sometime ago. I am not saying that
openldap is going to disappear overnight, but I think it is likely to
slowly fade into the background.

Congratulations for making it work for you, whether anyone else will
want to use your setup is another matter.

One possible problem I see is, your Linux servers will now probably 
operate differently from any Windows clients. Your servers will update
group membership (if they use your code), but I doubt if your Windows
clients will.

Rowland

> I do not think anyone doubted if it was possible, with code, virtually
> anything is possible. What was doubted (at least from my perspective),
> is it worth doing, the way things are going, then I personally do not
> think so, but you are welcome to do whatever you like.
> 
> One of the problems is, redhat (one of the big players) obviously does
> not really see a future for Openldap, as they removed the
> openldap-server package from RHEL sometime ago. I am not saying that
> openldap is going to disappear overnight, but I think it is likely to
> slowly fade into the background.
> 
> Congratulations for making it work for you, whether anyone else will
> want to use your setup is another matter.
> 
> One possible problem I see is, your Linux servers will now probably
> operate differently from any Windows clients. Your servers will update
> group membership (if they use your code), but I doubt if your Windows
> clients will.
> 
> Rowland
I don't doubt you doubt.
It doesn't requires any changes on the client side. It refresh only 
session info stored on the server. That's all. And, of course, I tested 
it using windows client connected to fedora server. It's not
"wil"l, It
works.
And it doesn't requires OpenLDAP (why should?). Any LDAP compatible one 
can be used. Miss again.
// Offtop. Redhat promotes they own directory server, related to 389 
Directory Server.