I don't think that it is the bit about the bits. As a quick test to prove that from the Linux cifs vfs, I turned on the extended_security flag (this can done e.g. by "echo 1 > /proc/fs/cifs/ExtendedSecurity") and mounted to a Win2K ActiveDirectory enabled DomainController. I do not set the mysterious smb_flags2 bit 4 but with this config parm enabled I do have bit 11 on to indicate extended security (flags2 is 0x8801 on the negotiate request) and yet I get SPNEGO style negotiate protocol response not the "raw ntlmssp" negotiate response. By the way the cifs vfs does not parse the SPNEGO response fully (yet) but it does work fine with the raw ntlmssp. On the other hand with the exact same code, same flags, going to a Win2K client (Professional) or WinXP I get raw ntlmssp response. It is not the flags2 bit 4 that is the hint to use raw vs. spnego.
> > Richard, > > In your note below is the Win2K server a member of a domain or standalone > > and is it currently able to talk with its Kerberos KDC? What you describe > > would make sense (i.e. for the server to use "raw NTLMSSP" and not use > > SPNEGO) if there were no Kerberos vs. NTLMSSP security choice to negotiate > > (the server would probably not be able to offer Kerberos if it is not part > > of a domain or if it could not contact its KDC so why even bother with > > SPNEGO in that case). > > > > Very interesting puzzle. > > OK, you are right. My guess was wrong. > > Here is another guess. The traces that I have that go directly to NTLMSSP > do not have bit-4 in the Flags2 field set, but do have bit-11 (EXT_SEC) > while the trace that I have that has bit-11 set, and uses SPNEGO, has > bit-4 set. > > This bit is undocumented. I bet it is the bit that says, don't use raw > NTLMSSP :-) Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: [EMAIL PROTECTED]
