ntlmssp errors against El Capitan's SMB Server

[Jeremy Allison]

On Tue, Aug 30, 2016 at 03:54:33PM -0400, Simo wrote:
> 
> This is not how spnego is supposed to work, once a mechListMIC is
> returned by one of the parties and it checks out then you do not add
> another one on the way back.
> 
> Whether the client or the server send a mechListMIC depends on the
> mechanism selected and how many round trips it implies.
> 
> Going by memory but IIRC:
> If kerberos is used usually it's the server that send the mechlistMIC
> as the last leg is done at the server. In case of NTLM the client needs
> to send back one more token so it is the client that generates the
> mechlistMIC.
> 
> I may be wrong on some minor detail or the directions :-)

https://www.rfc-editor.org/rfc/rfc4178.txt

does imply that mechListMIC's are exchanged.

However:

5.  Processing of mechListMIC

makes my brain hurt :-). Especially:

"Acceptors that wish to be
      compatible with legacy Windows SPNEGO implementations, as
      described in Appendix C, should not generate a mechlistMIC token
      when the MIC token exchange is not required."