Permissions issue with WMI custom performance markers inside IIS7 application

Question

I'm having issues getting my permissions in order to allow my application (running in an IIS7 AppPool) to delete/add Performance Counter Categories and their data. I have code like so:

if (!PerformanceCounterCategory.Exists(CategoryName))
{
    var counters = new CounterCreationDataCollection();
    var opsIn = new CounterCreationData
    {
        CounterName = "Test Counter",
        CounterHelp = "Test Counter Help",
        CounterType = PerformanceCounterType.RateOfCountsPerSecond32
    };
    counters.Add(opsIn);

    PerformanceCounterCategory.Create(CategoryName, "Service Layer Instrumentation",
                                      PerformanceCounterCategoryType.SingleInstance,
                                      counters);
}

The intent is to create performance counters on a system that doesn't yet have them created, so I'm not bound to a static installer behavior (I want to be able to alter counters without a lot of fuss). So far, when this works, it works well.

When I run this code in an executable, as admin, there are no problems. However, when I run it inside an IIS service, the AppPool does not have the correct permissions to execute the category alterations. I know for a fact that it's possible to get the WMI permissions to work correctly, because I did it once before for a demo with a test server... but that was months ago, I was tired, and it was last minute. The whole thing's a blur. I'm unable to reproduce my results now that I'm going back trying to formalize the install process to include the necessary security changes.

Google is only marginally helpful, and I distinctly recall having to hodgepodge together instructions from several pages before the thing worked. Does anyone have a recommendation for the complete instructions to enable Performance Counter Category editing for an IIS app pool?

Is this a BAD question or miscategorized? I am concerned because there haven't been any replies :) — ianschol, Sep 21 '12 at 18:15
I'm not trying to collect these points but if I understand, you're having WMI auth problems right? Could you add the WMI code? If you don't have all/enough, then see here: http://stackoverflow.com/questions/11769129/trying-to-copy-file-from-one-xp-pc-to-another-using-wmi-since-rpc-and-unc-are-n — Lizz, Sep 24 '12 at 05:54
Yup, WMI auth problems. The code above *is* the WMI code, I am creating a WMI Performance Counter Category and adding Performance Counters to it. This is the permission I'm having issues with (using the counters is not a problem). I'm not using WMI for system information at all, which is part of my problem - almost all the information out there is using it for that, not for the performance counter behavior ;) — ianschol, Sep 24 '12 at 18:09
From what I know of WMI authentication code, this doesn't show any. Have you tried simple WMI authentication code to ensure you don't get any errors? The link I put above includes such code. I would suggest a simple deletion of a test file. If that works, then there's likely a specific WMI function needing more authentication. — Lizz, Sep 25 '12 at 05:06

score 1 · Answer 1 · answered Sep 25 '12 at 08:49

1

You should create your performance counters outside ASP.NET. Creating a performance counter category requires permissions that the default AppPoolIdentity account does not have. The ASP.NET account can read the custom performance counters once they have been created. ( Do not run ASP.NET as SYSTEM or as an administrative account because doing so poses a security risk )

You could create your counters in a setup process.

answered Sep 25 '12 at 08:49

Cybermaxs

24,378
8
83
112

If I create counters in a setup process, they cannot be changed without using that setup process again. I do not want to be locked into categories with no ability to change them at runtime. – ianschol Sep 25 '12 at 17:03
If I read your answer correctly, it is impossible to do what I want without opening up a security risk because ASP.NET must run as admin to do so - is that accurate? Why does ASP require admin access to alter WMI perf counter categories? That seems inappropriate. It makes me feel like I should aggressively pursue a platform other than WMI. – ianschol Sep 25 '12 at 17:12

score 1 · Answer 2 · edited May 23 '17 at 12:09

It is only possible to change performance counter categories with Administrator privileges.

See: Performance counter throws SecurityException

The MSDN documentation includes an additional reason to create them during installation:

It is strongly recommended that new performance counter categories be created during the installation of the application, not during the execution of the application. This allows time for the operating system to refresh its list of registered performance counter categories. If the list has not been refreshed, the attempt to use the category will fail.

score 1 · Accepted Answer · answered Sep 27 '12 at 01:10

If you do not want to run your performance counter code in a separate process then you can do the following below by elevating permissions.

http://msdn.microsoft.com/en-us/library/bd20x32d(v=vs.71).aspx

The above link explains performance counters in ASP.NET applications, and how ASP.NET by default does not have permission to create custom performance counters and can not read performance counters. Below is a quote from the article.

If you are using a PerformanceCounter component in an ASP.NET application, the default settings of the ASPNET user account restrict access to performance counters. The ASPNET user account, by default, can write to but not read from performance counters, and it cannot create new categories. You can use impersonation with the ASPNET account to allow creation of new categories. The impersonation identity must have sufficient privileges to create categories. If your application needs performance counters that can be specified before deployment, they can be created by the deployment project. For more information, see ASP.NET Web Application Security.

You can impersonate asp to run as a separate account that you could grant privileges too. Sample code from the ASP.NET impersonation article is below, of course you can encrypt this user name and password also. The article explains how to encrypt the username and password.

http://msdn.microsoft.com/en-us/library/aa719560(v=vs.71).aspx

This seems like the best option. The server in question is walled off from the outside world, so at the very least I can present both scenarios (use impersonation for dynamic counter creation vs counter creation at install time only) to my PM. WMI support is a business objective so I wasn't keen on trying to ditch it. Thanks! — ianschol, Sep 27 '12 at 19:15

Permissions issue with WMI custom performance markers inside IIS7 application

3 Answers3