Hint on how Win2K etc choose raw NTLMSSP vs SPNEGO

[Steven French]

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: sfrench at us.ibm.com