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

[Stefan Metzmacher]

Am 05.05.2016 um 20:39 schrieb Andrew Bartlett:
> 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.
> 
> 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()!

See the patches for https://bugzilla.samba.org/show_bug.cgi?id=12782
the most important once in master:
https://git.samba.org/?p=samba.git;a=commitdiff;h=a59c9cba31a801d90db0
https://git.samba.org/?p=samba.git;a=commitdiff;h=40c42af11fda062fef9d
https://git.samba.org/?p=samba.git;a=commitdiff;h=5f0038fba612afd7fc15

I've added code that stores the calculated hash values in secrets.tdb
for a domain member. It should be fairly easy to use
secrets_fetch_or_upgrade_domain_info()
in fill_mem_keytab_from_secrets() instead of using
secrets_fetch_[prev_]machine_password().

It should also be possible to adopt this for the ad dc.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170702/ff6f8fe7/signature.sig>