proper nt-style authentication (reactos, wine, samba tng)

[Robert Shearman]

Luke Kenneth Casson Leighton wrote:

>that you - the wine team - continue to reinvent an non-interoperable
>version of MSRPC, for binary-level "DCOM" interoperabiltiy ONLY,
>demonstrates quite how just as bloody stupid you are being.  that _can_
>be taken as a compliment, as i genuinely i mean it with the greatest of
>respect.
>  
>

Ok, I want to condense your huge message into a numbered list of things 
you say we need:
1. Type marshaling.
2. IDL compiler.
3. RPC Server.
4. Authentication.
5. Services (lsa, netlogon, samr, etc).

Ok, so we are we at with Wine and ReactOS?
1: We need to implement this anyway because, like you crudely put it, we 
are in the crazy business of getting real code like InstallShield and 
Office 2003 to work.
2. We can either use MIDL and accept the problems that go with it (like 
not generating code that will compile with gcc 4.0) or we can finish 
implementing proxy support in widl.
3. We have support for named pipes in the RPC server, but Wine doesn't 
support remote named pipes and AFAIK ReactOS doesn't either. This is not 
a problem that should be solved by the RPC runtime.
4. Kai and Juan are working on delegating NTLM authentication to Samba. 
We still need to tie this in to the RPC server though. That should be a 
trivial task in comparison. Not sure how this will fit in on ReactOS.
5. Wine isn't really interested in having those types of servers, but it 
would be nice for the client code for those to work. I'm not sure that 
porting them from Samba would be fruitful as they would fundamentally 
need to tie into the registry.

So, what you are suggesting is that we instead port FreeDCE and use it 
for 1-3 (and 4?). This while still having to implement (1) anyway 
because of the applications I mentioned that need it. Then we get to 
test two different MSRPC infrastructures and get to fix bugs in one 
without it fixing any bugs in the other. Just porting FreeDCE seems like 
a lot of work; perhaps more work than implementing the remaining 
features in our own MSRPC infrastructure, even when including the task 
of finishing the IDL compiler. Maybe I am being blind, but it seems to 
make sense just to carry on in the direction we are going with having 
our own MSRPC implementation and being able to "dogfood" our 
implementation (i.e. use it for our own proxies/stubs at the same time 
as letting applications use it).

-- 
Rob Shearman