Partager via

COM Server and PMIE again.

  • Article

I'm still trying to create a COM out-of-process broker that I can call from Protected Mode IE. Amazing how rusty you get, it you don't do this daily. Here are some of my encounters.

I'm using Visual Studio 2008 with ATL 9.0 to create an ATL server. I add a Simple ATL component and register it (/regserver is the flag. Hope to remember it now.) I hunt for the COM server in DCOMCNFG and change the Identity of the server to run under an administrative user. If I don't specify a different user account, the COM server will be launched under the same credentials as the client. Since the goal is to create a broker that can do things that PMIE can't do, I need to change the account. (Whether I want to use a custom local account in a deployed scenario is different matter. I'd rather use the built-in service accounts so that I don't have to mess with passwords.)

Problem 1. ATL 9.0

Now I create a little vbs script to create the component and call a method on it. Works fine. Let me check the account that the COM server runs under. Aye. Nothing has changed. It is still launched with the client Identity that my little VB script runs under. What gives? It appears that ATL9.0 does not hook up my APPID to the CLSID of the component. So I can configure the identity of the COM server all day long, the CLSID for my component has no idea it has changed (found this with ProcMon of course). So I added the APPID entry under the CLSID of my component. Now it works. Or better, it doesn't. But that is expected. I get an Access Denied (800a0046) when I try to create the component from a standard user client. Reason is that COM gives the server a high MIC level and does not allow access by lower than high MIC clients (by default). That is all outlined here (or look for "CoCreateInstance and Integrity Levels" which will give you a document with a misnomer as title).

In that same doc, it is outlined how you can change the integrity level programmatically. So I set the MIC level to Medium with this SDDL: "O:BAG:BAD:(A;;0xb;;;IU)S:(ML;;NX;;;ME". And now I can create the component again from a standard user application (that runs with medium MIC). I still can't create it from a low MIC process such as PMIE. For that I need to change the ME in the SDDL to LW.

There was another observation.

Problem 2. DCOMCNFG and registry

This is actually a problem with how I called the program snippet from the MSDN documentation. When you change the Launch and Access permissions on the COM server, the security property page for my server in DCOMCNFG will change from "use default" to "customize" for Launch/Act and Access. Since I'm doing this on an x64 machine and my application is 32 bit, I am changing the values in wow6432 (HKEY_CLASSES_ROOT\Wow6432Node\AppID\{MyAppID}). DCOMCNFG gets its information from the HKCR\AppID\{MyAppid} so it doesn't pick up the customized values. If you change values back from "customize" to "use default", DCOMCNFG updates both HKCR\AppID as well as the WOW6432 (again as observed with ProcMon).

Still not there yet. The goal is to create an Out of Process COM component from PMIE. Maybe later. I hit another CreateObject error when I tried calling it from IE. Weird since a low MIC command line app worked fine.

Comments