On Wed, Oct 29, 2008 at 09:37:05AM -0700, Bill Wesse wrote: > Adam, thank you very much for your persistence. > > I apologize for responding against the two issues with the same > answer. In order to make sure I don't commit another mix-up, I have > superseded SRX080803600053 with SRX081029600208. > > I did a careful backtrack on the question/response history, and > noticed something that surprised and disappointed me: in the below > partial RESPONSE text, we are essentially claiming that our own XP > Client is sending an invalid NTLM SSP token. > > I think we confused how gss_ntlmssp.cap was generated (XP <-> 2003) > with how raw_ntlmssp.cap was generated (which, as you noted, had the > security blob stripped).
No, you had this part correct. raw_ntlmssp.cap contains an unmodified SESSION_SETUP_ANDX request generated by an XP client. (However, in order to generate it, I stripped the security blob from the server's NEGOTIATE response. If the server includes a security blob in the NEGOTIATE response, XP clients always use SPNEGO. With no security blob, they use raw NTLM SSP without SPNEGO or GSS. In the past, I have seen some servers in the field generate NEGOTIATE responses with no security blob, but I don't recall what OS or version they were running.) The gss_ntlmssp.cap traces was taken using a custom client configured to always generate a GSS InitialContextToken for the very first security blob exchanged. This is the behavior one would expect from a client that performed GSS authentication according to RFC 2743. -- Adam Simpkins [EMAIL PROTECTED] _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol