rpcrt4: Implemented NTLM authentication for rpcrt4 connections.

[Kai Blin]

* Mike McCormack <mike at codeweavers.com> [16/05/06, 09:56:40]:
 
> You are probably aware of this, but for others who are interested, 
> rpcrt4 seems to work something like:
> 
> 1. Client sends NTLMSSP_NEGOTIATE to server on first outgoing packet
> 2. Server sends NTLMSSP_CHALLENGE to client on first incoming packet
> 3. Client sends NTLMSSP_AUTHORIZE to server after receiving challenge
> 4. Client attaches authorization context to further packets
[...]
> This scheme currently only works for NTLM authentication, and may need 
> slight modification for other authentication schemes, but that's all I'm 
> interested in at the moment.

Sure. Stupid use of Negotiate all over the place. :)

> Initially I was using the dcom98 version of secur32 for testing, as the 
> builtin doesn't support SECURITY_NETWORK_DREP as yet.  Now I'm using a 
> hacked up builtin secur32 that generates the required NTLM exchange 
> independently of ntlm_auth.

What's the difference between SECURITY_NETWORK_DREP and
SECURITY_SERVER_DREP? Just the endianess?

> I'm hoping to submit a patch for secur32 that works as above but falls 
> back to ntlm_auth for exchanges its not capable of (ie. most of them).
 
Which exchanges would that be? The server side of the authorization? I
don't handle much besides authentication using ntlm_auth.

Everything else the NTLM provider should do needs to be tackled not
using ntlm_auth anyway. As I was doing using GENSEC.

Cheers,
Kai

-- 
Kai Blin, (blin at gmx dot net)
In this world there are only two tragedies.  One is not getting what one
wants, and the other is getting it.
		-- Oscar Wilde