Re: rpcrt4: Implemented NTLM authentication for rpcrt4 connections.

[Kai Blin]

* Mike McCormack <mike(a)codeweavers.com> [15/05/06, 23:04:25]:
> +  r = AcquireCredentialsHandleA(NULL, "NTLM", SECPKG_CRED_OUTBOUND, NULL,
> +                                AuthIdentity, NULL, NULL, &bind->cred, &bind->exp);

Sweet. Glad to see that code in use. :)
> +  /* tack on a negotiate packet */
> +  RPCRT4_AuthNegotiate(Connection, &out);
> +  r = RPCRT4_SendAuth(Connection, Header, Buffer, BufferLength, out.pvBuffer, out.cbBuffer);
> +  HeapFree(GetProcessHeap(), 0, out.pvBuffer);

Should that actually be a Negotiate packet?
If it should, I can add Negotiate to the set of patches I sent Rob.

Cheers,
Kai

-- 
Kai Blin, (blin at gmx dot net)
Your wig steers the gig.
		-- Lord Buckley

rpcrt4: Implemented NTLM authentication for rpcrt4 connections.

[Mike McCormack]

Kai Blin wrote:
> > +  /* tack on a negotiate packet */
> > +  RPCRT4_AuthNegotiate(Connection, &out);
> > +  r = RPCRT4_SendAuth(Connection, Header, Buffer, BufferLength, out.pvBuffer, out.cbBuffer);
> > +  HeapFree(GetProcessHeap(), 0, out.pvBuffer);
>
> Should that actually be a Negotiate packet?
> If it should, I can add Negotiate to the set of patches I sent Rob.

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

Calling RPCRT4_AuthNegotiate() in the above code snippet is step 1 and 
as a side-effect, the Connection->ctx is set to something non-zero, and 
we won't go down that codepath again.

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.

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.

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).

Mike

rpcrt4: Implemented NTLM authentication for rpcrt4 connections.

[Kai Blin]

* Mike McCormack <mike(a)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