NTLMSSP in Extended security negotiation...

[Luke Kenneth Casson Leighton]

let me see if i can remember what was implemented:

i think it was only client-side, i did the work very quickly because i
needed to determine some issues for hacking into nt5beta.microsoft.com,
whenever that was up.  whenever it _was_ up :)

- SMbnegprot detection of CAP_EXTENDED_SECURITY, .

- 2-stage SMBsesssetupX which is why there is a cli_sesssetup_x _and_ a
cli_sesssetup()

- use of create_ntlmssp_resp() which is _exactly_ the same code that is
used in the dce/rpc NTLMSSP authentication.

the hacked-up bits are the offsets into the blobs of the
CAP_EXTENDED_SECURITY data.  i did _not_ do any ANS-1 decoding, and the
responses are hacked-up to support only _one_ type of ANS-1 length
encoding (a 16-bit length encoding, to make it easier to do the response).

this hack is quit likely to be the cause of some of the problems with TNG
client-side connections to NT, so a proper ASN-1 encoding / decoding
really _is_ needed.


On Tue, 21 Nov 2000, Jeremy Allison wrote:

> On Tue, Nov 21, 2000 at 03:50:59PM -0000, Mayers, Philip J wrote:
> > Well, obviously not, otherwise I wouldn't have been implementing it in
> > HEAD...
> > 
> > How suitable for rollback into HEAD is the code?
> 
> Take a look at the TNG code so see how easy this would
> be. Much of the TNG code has been moved into HEAD (a lot
> of the client printing RPCs, much of the PDC communication
> code for winbindd) so it may be quite easy.
> 
> Thanks for pointing this out Luke,
> 
> Cheers,
> 
> 		Jeremy.
> 
> 
> -- 
> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------
>