>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 [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
