negotiate protocol taking more than 700mS in recent versions of Samba

Simo simo at
Thu May 5 21:52:17 UTC 2016

On Fri, 2016-05-06 at 06:39 +1200, Andrew Bartlett wrote:
> On Mon, 2016-05-02 at 08:40 -0700, Richard Sharpe wrote:
> > 
> > Hi folks,
> > 
> > While running some FSCT testing we found that NegProt was taking
> > more
> > than 700mS, most of it in gensec.
> > 
> > It seems that we are generating a keytab with keys for all the enc
> > types.
> > 
> > Our initial solution was to cache the result from the first such
> > call,
> > however, this needs to be done carefully because of machine account
> > password changes.
> > 
> > Are there any better approaches?
> A cache of of the keytab on disk would be very good.  To avoid the
> cache coherency issues and in particular to support ctdb replication
> of the machine account pw, I suggest keying off the arcfour-hmac-md5
> key.
> That is, md4(unicode(pw)) is cheap, so just fetch the keys from the
> keytab, and ensure they match the old and new passwords with that.

I would not do this, it is really not future proof, a lot of pressure
is on vendors (including Microsoft) to drop old hashing schemes that
are not secure anymore, as well as drop RC4 everywhere.

I do not know if when MS will finally drop NTLM support (which is the
only reason arcfour-hmac-md5 exists at all), but it is coming.

A kvno is all that should be needed to verify the key version number,
we just need to add it to secrets.tdb

> This, combined with some patches our team at Catalyst were exploring
> to use a krb5 ccache should save us a *lot* of time in make test, as
> over the whole test we spend about 10% of the CPU time in sha1()!

Using ccaches is a good idea, especially if you use libkrb5/libgssapi
interfaces and do not assume any particular format.


More information about the samba-technical mailing list