Radically trim down winbind?

[Volker Lendecke]

On Sat, Nov 05, 2016 at 08:16:05AM +1300, Andrew Bartlett wrote:
> What about keeping the group memberships part, but only for the local
> domain, just keep punting the problem to the server by ONLY asking for
> the tokenGroups attribute on the user as the only method?  Then drop
> the other winbindd_ads fallbacks (I don't understand why we think we
> need fallbacks here). 

What's the meaning of the limitation in

https://msdn.microsoft.com/en-us/library/ms680275(v=vs.85).aspx

saying that it won't work without a GC? Can we detect that and do a
proper fallback? Isn't that a level of uncertainty that we might want
to avoid? And, can we be sure that we as a machine will always have
the permission to read that attribute?

> Keeping this for the single domain case would I hope cause less
> disruption.
> 
> One of the other tools we have in our playbook is the Samba RODC.  We
> haven't really put it to great use yet (and it needs work).  You
> mention elsewhere in the thread that the DC case is different (we have
> the data), and perhaps we can smarten it up enough so that if you
> really want to enumerate all users, you make yourself an RODC.

The DC case being different was an initial reaction. However, looking
at it again I'm not so sure anymore it is so vastly different.

We will always have the possibility to look at named users with
"getent passwd <username>" just as in the member case. Listing them I
think we have the same problem: Size and associated load on winbind
and the LDAP server. Will the Samba DC always give us the tokenGroups
of the local domain users? We need to keep the group membership
calculation in one place. And if the DC can give us a reliable path
into the component that does it (preferably over a socket....), we
might do it.

Volker