RpcImpersonateClient (and ImpersonateNamedPipeClient)

Luke Kenneth Casson Leighton lkcl at lkcl.net
Thu Jan 20 11:45:02 CST 2005

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:

	(variable length, 424+)

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


 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:


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


More information about the wine-devel mailing list