I'm trying to get a COM elevation moniker working and am now stuck on three different paths. On all three paths my goal is to access a COM object from WScript, using something like Set myObj = GetObject("Elevation:Administrator!new:MyApp.MyClass"); I know that my moniker syntax is correct because I can get another object instantiated that I found in the registry using this from my vbs script (which I used just to see if GetObject would work with the moniker.)
1. I started with an in-proc COM server that I set up with LocalizedString, Elevation/Enabled=1, and DllSurrogate for the AppID in the registry. This was a brand-new COM object built with ATL from Visual Studio 2008. I just created an ATL Simple Object with the wizard. I hand-edited the registry to set it up. I could not get this to work. I keep getting 80080017 CO_E_ELEVATION_DISABLED.
2. I tried a LocalServer EXE, again, brand-new in Visual Studio's ATL wizard, with a new ATL Simple Object. I set up the registry by hand, and worked out the bugs until I finally got a COM elevation moniker to work. Only, this is on 32-bit Vista, and when I move the EXE to 64-bit Server 2008, it no longer works. I get 800C000D from GetObject in the vbs script, where on Vista 32-bit the same call works.
3. Even though the vbs script on Vista instantiates the COM object, I can't actually use it, because although it is elevated, I seem to drop the security token. This COM object is in turn creating an instance of a COM object which runs in a Windows service. That COM object checks the thread token of the incoming request to see if it has admin privileges (specifically, if it has SERVICE_CHANGE_CONFIG). The vbs script calls the elevated COM object, which calls the COM object living in the service, and by the time it gets into the service, the thread token no longer has admin privileges, because I do *not* see SERVICE_CHANGE_CONFIG (after impersonate client, open thread token TOKEN_QUERY).
What I am trying to do is get the UAC prompt to come up when I access the service automation interface (for configuration). I cannot, as I understand it, use the COM elevation moniker on the COM class in the Windows service (and I tried, and it didn't work either). So, what I am trying now is either an in-proc (with DllSurrogate) or out-of-proc EXE COM server which I can instantiate with the COM elevation moniker, to get the UAC prompt and the admin security token, which then itself would call the COM interface in the service.
I would rather not just launch my vbscript with RunAs (although this does work directly, in that I can connect directly to the service COM object, which sees SERVICE_CHANGE_CONFIG, without using an intermediary COM object). I would rather have the UAC dialog come up automatically when the user accesses the configuration automation interface.
Can you help with the error code 800C000D on Windows Server 2008 64-bit, and also tell me why I seem to lose the security token on the path into the service COM object?
I don't care to follow-up on the in-proc COM server (DLL) to front the service COM object, unless DllSurrogate has some advantages over an out-of-proc EXE server.
vbscript GetObject(COM elevation moniker: COM-object-A) --> LocalServer COM-object-A elevated --> Windows service COM object wanting to see admin privileges on the incoming thread token.
On Vista, this path is complete, but the Windows service does NOT see admin privileges, despite the acceptance of the UAC prompt during elevation of the moniker.
On Server 2008, the first arrow is broken -- I get HRESULT 800C000D on the GetObject script call.
I've figured out most of the above, but I am still stuck on Server 2008 64-bit, unable to get the COM elevation moniker to work. I get 80080015 CO_E_MISSING_DISPLAYNAME, despite having LocalizedString in the registry for the CLSID. If I could get help with just this one issue, I would appreciate it greatly.
I am posting my progress on the other problems listed above in a reply below. (I am interested in why my in-proc DLL does not work, but I don't need that solved -- an EXE server is fine. It's not due to lack of _MERGE_PROXYSTUB in the build of the DLL, for what that's worth.)Read more...