正确的答案是：

I had similar question about DCOM/RPC authentication. Having studied for several days, i got conclusion:

1. Although DCOM/RPC claim they support several authentication mechanism, but ironically, DCOM/RPC themselves have not provided any inline login dialog(such as showed when access Shared Folder of server). DCOM/RPC client infrastructure have not provided any common way to store authentication settings externally(such as Windows Credential Store), this is very inconvenient.
2. If client user is logged in as a domain user and server is also in the domain or the client user/password are also valid in server's local account db, the identity will be used by default.
3. When DCOM/RPC use Named Pipe as transport, it is built on top of SMB protocol(port 445), the client must first authenticate by run command "net use \\SERVER /user:USER" then input password" or enter \\SERVER in explorer to login to server, otherwise simply "Access Denied".
4. When DCOM/RCP use TCP transport(port 135), The client must set user/password... in COAUTHINFO of DCOM's CoGetClassObject or RPC_AUTH_IDENTITY_HANDLE of RPC's RpcBindingSetAuthInfo, otherwise treated as "ANONYMOUS LOGON" in server side, but most likely, finally cause "Access Denied" due to DCOMCNFG default ACL settings.
5. DCOM component's authentication method and ACL settings can be controlled by DCOMCNFG external utility, at machine-level or component-level, at anytime. But RPC component can not, instead, they can only be defined when create RPC component.
6. DCOM component's ACL settings can be further strengthened by use "Set Limits" in DCOMCNFG utility, "Set Limits" let use control maximum possible permissions forcibly for each DCOM component.