[PATCH] Remove fstring from wb_acct_info

[Uri Simchoni]

On 11/1/18 8:20 AM, Andrew Bartlett wrote:
> On Thu, 2018-11-01 at 08:00 +0200, Uri Simchoni via samba-technical
> wrote:
>> A bit off-topic, but having been bitten in the past by this issue of
>> winbindd group enumeration and large domains:
>>
>> 1. No matter how optimized the memory layout, if your domain has 100K
>> groups you're going to lose. The sheer number of round-trips required to
>> fetch all those groups would make it unfeasible.
> 
> BTW, I did have to work this out recently: the ratio is 1200 per
> EnumDomainGroups call.  
> 
>> 2. Large domains also tend to have non-out-of-the-box security
>> configuration. The server computer account, which winbindd uses, doesn't
>> always have the best authorization for making those queries.
>>
>> For both those reasons I wouldn't use this API in a product that aims
>> large enterprize domains. Straight ldap searches (with a filter,
>> limiting the number of returned results, possibly with vlv control) are
>> better suited for that.
> 
> Given that the default LDAP page size is also 1000, do we really win?
> 

We win by not trying to enumerate all groups (or users), using a filter
instead, and returning at most 1000 entries.

For the use case of finding a group, even if you can get all groups,
would you let a user browse through hundreds of thousands of results? Or
would you offer some search capability? If you do search, then its best
to go:
- user types something
- user stops typing, or clicks "search" button
- send query with what the user typed as filter. If the query returns
more than 1000, he should narrow it anyway. Tell him to do so.

Your response time is independent of domain size or network latency.

That's what Windows does (tm) :)

For replication use cases (e.g. replicating the AD database to some
application database) there are probably better and more scalable
solutions too - you should be the one to know.

>> I think it was proposed in the past to remove that functionality from
>> winbindd.
> 
> Yes, and we put it back in.  Regardless of the difficulties, people,
> particularly in small setups, do use this. 
> 
> Larger installations are asked to turn it off via the smb.conf, but
> still do ask for it and ask for it to be made faster.  (See Gary's soon
> to be posted server-side efficiency improvements for exactly this). 
> 

It's very handy for small and test setups, I'll give you that.

> Andrew Bartlett
>