我有一个使用 OLE 自动化编码器的 DCOM 客户端和服务器应用程序。它们在同一台 PC 上运行时工作正常，但当服务器位于不在同一域中的不同 PC 上时，我得到 E_ACCESSDENIED (0x80070005)。
服务器 PC 配置了 dcomcnfg，以将对任何 DCOM 对象的所有访问权限授予我在客户端上指定其登录名和密码的用户。 ServerApp 及其类型库在服务器 pc 上注册。
类型库也在客户端 PC 上注册。我直接在 ClientApp 中指定服务器名称，因此据我所知，客户端 PC 上不需要 dcomcnfg 配置。
带有服务器名称、登录名、域和密码的 CreateInstanceEx() 工作正常。它返回 IUnknown 并同时在服务器 PC 上启动 ServerApp。
但是当我尝试为服务器支持的接口(interface)使用 QueryInterface() 时，我得到 E_ACCESSDENIED。
分析安全事件日志，有两条记录:
首先，我在 ClientApp 中指定凭据的用户成功登录网络。当我调用 CreateInstanceEx() 时会发生这种情况。
接下来，我在客户端 PC 上登录的用户 尝试登录失败。由于两台 PC 不在一个域中，因此服务器 PC 不知道该用户。
现在，为什么这个用户会登录到服务器，尤其是当我调用 QueryInterface 时？
研究 CreateInterfaceEx 参数，似乎存在某种模拟机制。但目前还不清楚谁冒充谁。涉及三个用户凭据:
ServerApp 在服务器 PC 上运行的用户(在 dcomcnfg 中配置)。
ClientApp 在连接时指定凭据的用户。
ClientApp 在其凭据下在客户端 PC 上运行的用户。
无论您怎么看，如果涉及#3，那就是一个用户太多了。如果 DCOM 无论如何都要在服务器 PC 上识别/模拟 #3，为什么我需要指定 #2 的凭据？到什么程度？
DCOM 模拟 #2 似乎是合乎逻辑的，因为这是我明确指定为我的凭据的内容。但是为什么第二次登录尝试呢？
谁能解释一下模拟究竟是如何工作的，以及是否有办法忽略它并以 dcomcnfg 中指定的用户身份运行？
最佳答案
回答我自己的问题。经过大量探索，很明显 DCOM 有两种不同的识别情况:
- 对象创建授权(CoCreateInstanceEx)
- 方法调用授权。
由于未知原因，#2 没有继承#1 的设置。默认情况下，它使用客户端进程的凭据，因此会出现奇怪的登录。
有两种方法可以为 #2 指定凭据。第一个是 CoSetProxyBlanket 。它仅为指定代理 (marshaller-unmarshaller) 设置凭据:
CoCreateInstanceEx(IID_IObject1, /*login, pass*/, obj1); //Success!
//Logged in and recevied IObject1 proxy in obj1
obj1->DoSomething();
//IObject1 proxy in obj1 now tries to login under process credentials.
//Failure! E_ACCESSDENIED
CoSetProxyBlanket(obj1, /*login, pass*/); //Success!
//IObject1 proxy is now authorized.
obj1->DoSomething(); //Success!
obj1->QueryInterface(IID_IObject2, obj2); //Success!
obj2->DoSomethingElse(); //Failure!
//This different proxy for IObject2 have not yet been authorized.
CoSetProxyBlanket(obj2, /*login, pass*/);
//etc.
重要的是要注意，虽然 CoCreateInstanceEx 要求模拟级别至少为 IMPERSONATE，但 CoSetProxyBlanket 似乎对除 IDENTIFY 之外的任何东西都不起作用。
另一种选择是使用 CoInitializeSecurity 为整个过程设置默认凭据。然后你不必在每个代理上调用 CoSetProxyBlanket:
CoInitializeSecurity(/* login, pass */);
CoCreateInstanceEx(IID_IUnknown, /*login, pass*/, obj); //Success!
obj->DoSomething(); //Success!
在客户端上使用 CoInitializeSecurity 时，您也必须指定 asAuthSvc，即使 MSDN 说您不需要。
这种方法的缺点显然是，如果您有来自不同 PC 的多个 DCOM 对象，您将必须在此调用中指定所有凭据，并且每次您打开一个不同的代理。
当您从 DLL 运行时它也不可靠(如果进程具有不同的默认安全性怎么办？)。因此，最好在每次调用返回之前实现一个 CoSetsProxyBlanket 的 QueryInterface 包装器。
关于windows - DCOM 中的模拟是如何工作的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6123301/