Extended Security negotiation on NT4
eglass1 at comcast.net
Thu Jun 10 00:08:01 GMT 2004
> >IIRC the extended security bit == SNPEGO which was
> >introduced in win2k.
> Not exactly right. The extended security bit can be set without
> using SPNEGO (when using NTLMSSP). This is the normal sitation in
> plain Win2K and WinXP (no active directory).
> Anybody have any other idea on NT4 extended security?
I *believe* extended security essentially plugs the tokens into the
"Negotiate" SSPI provider; this is basically SPNEGO, but will accept raw
tokens too (i.e., unwrapped NTLM as well as tokens wrapped w/the
126.96.36.199.4.1.3188.8.131.52 mechanism). This would seem to be reflected in
the Negotiate HTTP auth mechanism as well (which uses the Negotiate SSPI
provider, and will also accept raw NTLM tokens). This is mentioned
the relevant part being:
"A server that uses the Negotiate package is able to respond to client
applications that specifically select either the Kerberos or NTLM
security provider. However, a client application must know that a
server supports the Negotiate package to request authentication using
Negotiate. A server that does not support Negotiate cannot always
respond to requests from clients that specify Negotiate as the SSP."
Which *seems* to indicate that this is intended for backward
compatibility of some sort. This would also seem to imply, however,
that you could possibly supply a raw (non-SPNEGO-wrapped) Kerberos token
as well, and I don't think that works.
It would be worth poking about, though.
More information about the samba-technical