1

I have an application running as a user other than the logged on user. I have a COM server in dllhost.exe that runs under the logged on user's credentials. How can I set COM security on the client so that I am able to talk to the server? I get a E_ACCESSDENIED (0x80070005) when I try to create and instance of the object. Here are the details: I have a COM component that is run under the standard surrogate (dllhost.exe) with AppID{GUID}\RunAs set to "interactive user".

The client is running as a different user and calls CCO. At this point, I can confirm that the DCOM service launches dllhost.exe and creates the server. However, due to difference in credentials of the client and server, CCO returns 0x80070005. I have also tried setting the thread (token) on which the CCO is called to the same credentials as that of the COM server (dllhost), it still fails.

I understand I can use COM cloaking to negotiate the security, however, its not very clear. I want to make sure that it only calls to this component that is impersonated and not for all COM calls in the process. Any help will be appreciated.

Sri
  • 233
  • 2
  • 13
  • Do you have control over the COM object registration? If so you probably want to set the AccessPermission DACL in the AppId registration (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms688679(v=vs.85).aspx) which would ensure you can access the COM object after activation. – tyranid Feb 22 '16 at 13:08
  • I tried to create an instance of the coClass by passing CLSCTX_LOCAL_SERVER | CLSCTX_ENABLE_CLOAKING to CoCreateInstance (thread impersonated as logged in user). This worked and I got a instance of the coClass. However, any call (including QI) results in E_ACCESSDENIED, even on the same thread (still impersonated). – Sri Feb 22 '16 at 13:34
  • @tyranid, Ideally, I'd like t avoid any registry tweaks other than the minimum mandatory settings. I would prefer a programmatic solution if available. I thought CLSCTX_ENABLE_CLOAKING in CCO will do the job, but it looks like its only good enough to create an instance of the object unless I am missing something. Thanks for the tips though, it will be my fallback. – Sri Feb 22 '16 at 14:59
  • Have you set EOAC_DYNAMIC_CLOAKING in the CoInitializeSecurity flags? Or set cloaking on the proxy itself using IClientSecurity? Otherwise the actual call will not be used, the documentation for CLSCTX_ENABLE_CLOAKING seems to indicate that it's only for the activation request and doesn't indicate it binds the cloak to the proxy as well. – tyranid Feb 22 '16 at 17:59
  • @tyranid. Thanks for the suggestions. I've already used the IClientSecurity (CoSetProxyBlanket) and reduced the authentication level. It does work to an extent in the sense that I am now able to make calls to the surrogated coClass. However, when it comes to displaying a UI from the coClass, it fails. I am now looking into solving the UI issue. Simply put, CoSetProxyBlanket works to an extent (without CLSCTX_ENABLE_CLOAKING in CCO), but there are a few bit that still needs resolving. – Sri Feb 23 '16 at 08:48

0 Answers0