I had similar question about DCOM/RPC authentication. Having studied for several days, i got conclusion:
- 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.
- 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.
- 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".
- 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.
- 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.
- 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.