Radically trim down winbind?

[Uri Simchoni]

On 11/03/2016 10:45 PM, Volker Lendecke wrote:
> Hi!
> 
> While looking at problems with our winbindd_domain_list and trust
> enumeration I just had an idea: Just discard everything that can't
> reliably work. The two main things are:
> 
> 1. Enumerating users and groups: I can see one scenario where this could
>    possibly work, and that is on a DC for the local domain. Everything
>    else is just prone to fail, because we don't have the privileges to
>    enumerate things or we can't reach DC's or a thousand other reasons
>    like timeouts in huge domains.
> 

IMHO user/group enumeration is a toy feature, can't really work with
Enterprise domains due to their size. Users of small domains might find
it useful but we can refer them to a simple ldap query that does the same.

> 2. Querying group memberships without a pac/info3 struct. Again, the only
>    scenario might be on a dc for the local users. For everything else
>    we *must* rely on the DC to give us the group membership info after a
>    successful login. I can't count the number of times I have explained
>    to users (and Samba Team people, just this week.... :-) that all bets
>    are off regarding wbinfo -r without wbinfo -a or an smb login. The
>    problem here is -- it works sometimes with incomplete information and
>    it's very hard to figure out the exact circumstances when it works
>    and when it does not.
> 

There is one application to querying group memberships without logon
that I know of, and that's "force user". You want all files in some
share to be owned by some AD user (for access and quota reasons), but
you don't want the application that stores the file via SMB to cache the
credentials of that user. I have a real use case for that, haven't heard
complaints, but it's probable that a partial result is sufficient (even
a token that contains only the forced user's sid, because the forced
user owns all files in the share).

Other than that, there are cases where you need to do getgrouplist(),
but that occurs *some* time after a successful logon. Since netsamlogon
cache never expires, that seems to work without the fallback methods.

> So an idea would be to really delete the code that enumerates anything but
> passdb users, and anything that tries to query group membership info without a
> netsamlogon_cache.tdb entry. For passdb we can look at the local database.
> 
> Thoughts? Too extreme?
> 
> Volker
> 

Can you explain the "all bets are off" (i.e. when doesn't ldap
tokenGroups work)? If it's difficult to specify the exact circumstances,
can you provide an example of a setup you encountered (I'll need to
understand it myself and then explain to others why a solution that
seemed to work needs to be re-architected)?

Thanks,
Uri.