I've recently been trying to use the IIS AppPool identity instead of Network Service or Local System.
As such I came across the ugly error
The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID {6E46607A-7347-471B-A98C-BC9E49B07248} and APPID Unavailable to the user IIS APPPOOL\MyAppPool SID (S-1-5-82-476059244-1685105758-59475158-1390954050-72429515) from address LocalHost (Using LRPC) running in the application container Unavailable SID (Unavailable). This security permission can be modified using the Component Services administrative tool.
As you may notice my APPID was missing from this error, I searched the registry and found out which component it was (also by debugging).
It's a VC++ out-of-process OLE/COM server which processes requests from our web server. (Yay, 1990's called). I'm not entirely sure why this involves DCOM, there's nothing 'distributed' about it by design, maybe more by accident or an artefact of VS2008's default MFC/OLE server templates?
On using the power of Google, I followed the typical route of changing the dcomcnfg setting for this component to allow my IIS AppPool\MyAppPool user the local activation permission (I tried them all actually!), and confirmed that w3wp.exe is running as the same identity.
I also made sure that this exe was readable/executable by that user.
However the error still persisted.
Only by setting the same permissions machine-wide (via the My Computer node, instead of the individual component node), did the component load properly. This feels like a big security risk. Is it?
In the failing case, I tried using process monitor to spot any registry keys or file access problems, or to identify what other components might require access. But nothing reared its head.
Given that setting the DCOM permission system wide fixes the problem - It does feel to me that there's another DCOM component or service that needs permissions being set, but I can't find out which.
So a) Is there a way to further diagnose this problem? Sniff out decisions being made by DCOM? Is there a central DCOM broker that needed the permissions set also? Debugging/Process Monitor doesn't seem to help. b) Is it ok to set the AppPool local activation policy machine wide?
Many thanks to anyone who helps me make the right decision.
Q1. Is it bad practice to give your App Pool account local DCOM activation permissions, computer-wide?
A1: Yes, it's bad. According to the book Secure DCOM Best Practices
It isn’t a good idea to loosen these permissions from the default values
Q2: Why is the component still failing?
A2: This was a combination of problems:
Process monitor DID pick up an issue that my AppPool identity was not able to read the registry key HKEY_CLASSES_ROOT\WOW6432Node\AppID\{C33D7656-D310-4684-9482-A486787E4E3B}. Enabling read permission for my AppPool identity got me one step further.
The event log message about an Unavailable AppID was a clue. There was no AppID REG_SZ entry for the class being requested. So the security settings were not being picked up. I needed to ensure the following key existed: HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{6E46607A-7347-471B-A98C-BC9E49B07248} with String Value AppID={C33D7656-D310-4684-9482-A486787E4E3B}
As per MSDN documentation AppID, and What is AppID