ntlmssp errors against El Capitan's SMB Server

Stefan Metzmacher metze at samba.org
Wed Aug 31 08:20:35 UTC 2016

Hi Jeremy,

> note the 'ntlmssp_state->new_spnego = true' when timestamp != NULL.
> And it looks like the Windows client doesn't check the
> mechlistMIC in this case, so we might need to losen our
> check also.
> This would also fix the smbclient connecting to the Microsoft
> Azure server problem - that server also only does NTLM and
> doesn't send the mechlistMIC in the ACCEPT_COMPLETED reply.
> Attached is a possible patch, but I'm *really* unsure
> if this is safe w.r.t. downgrade attacks.
> Metze, can you take a look at this and let me know what you
> think ?

The problem I see with this is that client doesn't know
if the server processed the mechListMIC.

Which has implications on:

        if (NT_STATUS_IS_OK(status)) {
                bool reset_full = true;

                gensec_security->child_security =

                reset_full = !spnego_state->done_mic_check;

                status =

@Simo: We discussed that the reset_full parameter might not be required,
but I think
these "broken/lazy" servers would be the reason to have it there.

As this problem hopefully only present at the SMB* protocols, which have
their own
signing/encrytion implementations, I'd propose to add a
and allow Jeremy's change only if GENSEC_FEATURE_SMB_STYLE is present.
so adding GENSEC_FEATURE_SMB_STYLE would be a similar way to work around
SMB specific
implementation bugs).

What do you think?


-------------- 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/20160831/aa280e66/signature.sig>

More information about the samba-technical mailing list