RpcImpersonateClient (and ImpersonateNamedPipeClient)

[Luke Kenneth Casson Leighton]

On Thu, Jan 20, 2005 at 09:08:27AM -0800, Juan Lang wrote:
> Hi Luke, you said:
> > that's where you'd need the cooperation of samba / samba tng:
> > it's got "SIDs" behind it, and "SIDs" means a SAMR server
> > and a NETLOGON server and an LSARPC server (and in the
> > case of windows 2000 interoperability, access to an Active
> > Directory Server).
> 
> Another possibility is that we implement our own version of a SAM.  Right
> now we just return a fake Administrator SID every time we're asked for
> one.  But if we absolutely needed to, we could implement a local version
> and it needn't even be a separate process.  The NT SAM registry is pretty
> well reverse engineered here:

> http://neworder.box.sk/files/nullak_ntsecurity/index.php
 
 hah, coooool!  that's so hilarious.

 okay, yep - the bit here:

 	\HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\%RID%\V
	(variable length, 424+)

 that's just a SAMR_USER_INFO_21 structure - been there, done that.
 
 see here:

	http://viewcvs.samba-tng.org/cgi-bin/viewcvs.cgi/tng/source/include/rpc_samr.h?rev=1.18&content-type=text/vnd.viewcvs-markup


 by the way - does anyone understand the SamrQueryAliasMembers function
 and the SamrQueryUserAliases function?

 these are the _weirdest_ functions i ever heard about and i really
 haven't understood them well.

 
> > you can always still implement RpcImpersonateClient as a stub.
> 
> Yah.  I think that's more likely than that we go whole-hog on it.  

 _great_ because if you do that, i'm likely to rip that off whole-sale
 for use behind a DCE/RPC interface - using samr.idl (from which samr.h
 has been generated) - see:

	 http://hands.com/~lkcl/samr


> From
> experience, it's often more important to get things like parameters and
> error codes just the way Windows programs expect than it is to make a
> function "really work."  By implementing a stubbed or local-only version,
> we can figure out all this stuff, and maybe make a full-blown version
> later.

 see below, because if you implement "stub" versions, and
 the intercommunications (in this case DCE/RPC), it will be
 possible to "drop in" a replacement like samba tng's services
 or even if the samba team will cooperate, a samba 3 or even
 a samba 4 server.

 at run-time.

 because that's what DCE/RPC gives you: binary-level separation and
 network-defined interface points.

 it's just so utterly cool.

> and later,
> > it _does_ mean careful design because i doubt very much whether people
> > will be happy to have samba tng as a dependency on Wine.
> 
> Agreed.  The focus for the Wine folks is generally, does this get my app
> to work?  Unless it's fixing an app, not too many folks are likely to get
> real excited by anything.
> 
> Feel free to point out what we've been missing.  Patches speak louder than
> anything here :)

 would you be _really_ ready for a couple of hundred thousand lines of
 code??? virtually the _entire_ samba tng project _and_ the freedce
 project???
 
 *lol* :)

 no, but seriously, as you can see by the thing sparked off by
 rob's RpcImpersonateClient question, there's a whole _truck_
 load of code needed that sort of "hangs together".

 combine that with the fact that you (wine) _must_ conform
 _exactly_ to the required APIs at both a header-file level,
 IDL file level, binary level, pretty-much-everything level,
 if one group implements one part (behind, say, samr.h to
 produce samr.dll) then that's _exactly_ what's needed for
 samba tng.
 
 and also the corrolololorary is that if you can get the
 rpcrt4.dll working _properly_ - i.e. wire-compatible with
 DCE/RPC / MSRPC, then you won't _need_ to do any work on
 producing a samr dll, you can just communicate directly with
 samba tng's samr server.

 plus various other combinations along the same lines that
 would do everyone's heads in to enumerate.

 l.