[PATCH][WIP] Make the Samba AD DC multi-process

[Andrew Bartlett]

On Thu, 2016-12-01 at 12:48 +0100, Stefan Metzmacher wrote:
> Hi Andrew,
> 
> > 
> > > 
> > > > 
> > > > > 
> > > > > Attached is a WIP set of patches to make Samba connect to ldb
> > > > > faster,
> > > > > for the @ATTRIBUTES load, used until we can read the full
> > > > > schema.
> > > > > 
> > > > > This avoids some O(n^2) behaviour for the 600 attributes in
> > > > > the
> > > > > default
> > > > > schema, which was taking 5% of the time to run a simple
> > > > > ldbsearch.
> > > > > 
> > > > > Please consider, but don't push until I run the beachmarks.
> > > > 
> > > > Attached is some work in progress to do this, and to allow the
> > > > LDAP
> > > > and
> > > > NETLOGON server to be multi-process. 
> > > > 
> > > > This breaks the RPC protocol by not checking the assoc_group
> > > > when
> > > > we
> > > > accept a bind to the NETLOGON rpc server in the AD DC.
> > > > 
> > > > It also breaks the current link between the lsarpc services and
> > > > netlogon, which currently allow a bind on either pipe to access
> > > > these
> > > > services. 
> > > > 
> > > > I've tried to make that all as generic as possible.
> > > > 
> > > > Please comment.  I don't plan to push this without coming back
> > > > to
> > > > the
> > > > list. 
> > > 
> > > It will take some time to go through this...
> > > 
> > > One comment on hash_computer_name() now:
> > > - what's the point of doing such complex logic
> > >   using hmac_sha256?
> > > - I'd just use tdb_jenkins_hash()
> > 
> > We didn't want to have the alternate comment:
> >  - 'Why do you use an insecure hash that an attacker could target
> > to
> > cause a DoS?'
> > 
> > The idea was just to make it relatively hard for an unauthenticated
> > attacker to deterministically bump a real device from the pool.
> 
> I don't understand that, the attacker can just use the same string,
> which comes in plaintext over the net. That's much easier to an
> attacker.
> than trying to find a hash collision. You can't prevent the DoS that
> may happen for our clients.
> 
> The only reason we're using a hash at all is to reduce the DoS
> against
> us, when the anonymous clients request challenges for millions of
> computer names.
> 
> I also can't see how a "secure" hash algorithm truncated to 14 bits
> and be more secure than a non-secure algorithm truncated to 14 bits.
> 
> As your motivation is performance improvement we should avoid
> very expensive hash calculations, which are designed for security
> related topics.
> 
> So please let us simplify this and just use tdb_jenkins_hash(),
> which seems to fast and collision free enough for our most
> performance
> critical
> fileserver workloads.

That seems reasonable, I'll change the hash.

Andrew Bartlett