>After re-looking at RFC2478 and looking at traces again and talking to
>Diego (:-) at IBM, it looks like the following is occurring:
Yikes! I should never have let that name out of the bottle.
>1. The negProt response includes a negTokenInit with a list of OIDs for
>mechanisms that the server handles.
Don't forget the server's principal name in the mechListMIC
>2. The client sends a sesssetup&X with another negTokenInit with the
>selected mechanism and a token.
Well, not completely true: if kerberos is what the client wants, he still
sends all the mechanisms, but if NTLMSSP is what he wants, he only sends
that OID.
>3. The server send back a sesssetup&X response with a negTokenTarg with
>appropriate things in it, however, unlike the previous negTokenInits, this
>blob is not cloaked in GSSAPI, it is raw SPNEGO!
Sounds right
>4. There will be more negTokenTargs if the previous packet had more
>processing required set.
Also sounds right...and there are two ways it is set, both in the SMB error
and in the NegTokenTarg negResult field.
----------------------------
Jim McDonough
IBM Linux Technology Center
Samba Team
6 Minuteman Drive
Scarborough, ME 04074
USA
jmcd@xxxxxxxxxx
jmcd@xxxxxxxxx
Phone: (207) 885-5565
IBM tie-line: 776-9984
