ntlmssp errors against El Capitan's SMB Server

[Simo]

On Tue, 2016-08-30 at 13:13 -0700, Jeremy Allison wrote:
> 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 heN
> > 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."

This is in 4178 5.b, this is not the case you are looking for, as in
the NTLM case you exchange an odd number of tokens (Negotiate,
Challenge, Auth), while in the kerberos case you exchange an even
number of tokens (initiate token and accept token)

So you need to look at 4178 5.c 
in there you have things like:
	if the
      negState was request-mic in the first reply from the target, a
      mechlistMIC token MUST be included; otherwise, the mechlistMIC
      token is OPTIONAL.

(in this pcacp the state was accept-incomplete)

Also:
      In the case that the optimistic mechanism token is the only
      mechanism token for the initiator's preferred mechanism, the
      mechlistMIC token is OPTIONAL.

(in this pcap NTLM was attempted optimistically and the initiator did
not provide any other mechanism.


All this would still require the mechlistMIC to be produced from the
server because the client did in fact send a mechlistMIC token except
that in Appendix C we have:

   SPNEGO implementations in Microsoft Windows 2000/Windows XP/Windows
   Server 2003 have the following behavior: no mechlistMIC is produced
   and mechlistMIC is not processed if one is provided; if the initiator
   sends the last mechanism token, the acceptor will send back a
   negotiation token with an accept_complete state and no mechlistMIC
   token.  

I think this is the behavior we are seeing.

Simo.