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.
