RpcImpersonateNamedPipeClient

Luke Kenneth Casson Leighton lkcl at samba.org
Thu Feb 10 00:02:27 GMT 2000


hi seiichi!  i'm really glad to hear from you on this issue.

On Wed, 9 Feb 2000, Seiichi Tatsukawa wrote:

> | i think i have a possible reason why microsoft implements DCE/RPC
> | daemons as the SYSTEM cotnext (whatever) and only calls RpcImpNPC
> | if needed. it's because the implementation of this call takes TOO
> | DAMN LONG on nt to be called for every single function call.
> 
> Look, DCE/RPC was developed on the operating system which had no native
> thread support, thus no security context per thread. That system "Unix"
> had (still has) the process-wide security context only. DCE/RPC server
> runtime was multi-threaded, but the client security context (delegation
> and impersonation), obtained by rpc_binding_inq_auth_caller() (or
> rpc_binding_inq_auth_client()), was only used by DCE APIs, not by Unix's
> native APIs (e.g., file-system access, etc.).
>

oo... ok, so... dce api server application writers chose to implement
their own security context?  (not dce/rpc itself, that's different).
 
> It's up to the server application writer to decide whether to use the
> client context or not. MSRPC simply follows this model. (Obviously, MSRPC
> has better integration with OS because Win32 APIs can use the client
> security context once the server thread impersonates the client.)

starting to understand.

thanks.



More information about the samba-ntdom mailing list