Permissions for publishing to WMI in a network service account

Question

I am adding a WMI publication to a Windows service based on the .NET Framework 3.5, which runs under the "network service" account.

According to the document I encountered on MSDN , the “network service” account should have WMI publishing permissions by default. ("By default, users and groups are allowed to publish data and events: ... Network Service , ...")

However, when the service calls Instrumentation.Publish (myStatusClassInstance), it throws a DirectoryNotFoundException;

System.IO.DirectoryNotFoundException was unhandled Message: Could not find a part of the path 'C:\Windows\system32\WBEM\Framework\root\MyWMINamespace\MyService_SN__Version_1.0.3686.26280.cs'. 

.. therefore it looks like System.Management.Instrumentation tries to generate code on the fly, and when working under a network service, it targets a directory in which the network service does not have permissions.

What is the best fix / workaround for this? Can I override the target gen-gen directory in app.config or in code? I do not want to bother with file system permissions when deploying the service ...

Update . I think this is a “feature” when older FX code encounters newer security settings in Win7. Internally managed WMI classes extract the WMI installation directory from the registry and use this as the output path for the generated code. Unfortunately, many users cannot (or should) write material in% SystemRoot% ...... I filed a connection error ( # 530392 ) to find out if MSFT can provide clarity and / or provide a fix or workaround.

Update 2: I assume that for regular user accounts this is not a problem because UAC virtualization will run and store files elsewhere. However, apparently, the "network service" account is not covered by UAC virtualization .. (?)

Update 3: Added 550pt reward. Simple limitations: Windows based .net framework 3.5, a Windows service running as a network service must be able to publish data through WMI using System.Management.Instrumentation on Win7 and Win2008 [RTM and R2] with default settings / settings and without use, changing internal / private members of the structure using reflection. Ready-made but clean solutions are welcome. A second linked bounty-Q will be opened as a placeholder for another 550pt, if SO permits.

Bounty Update: I intend to double the bounty for this Q through a second question in hand that will serve as a bookmark placeholder:
https://stackoverflow.com/questions/2208341/bounty-placeholder (<- Apparently, this was not resolved, therefore the issue of filling in the deposit was closed by the ethical etiquette police.)

Update 4:. It is getting better and better. I noticed that installutil wrote the missing files in c: \ windows \ syswow64 ... etc., so I realized that I am using the 32-bit version of installutil to install the service, but the service works like a 64-bit process. The obvious side effect was that the code generated when installutil was run ended under syswow64 (32-bit system directory), while the service looked for it in the 64-bit system directory (system32). (<off off, but I really like how MSFT managed to switch the names there ... :)).

So I tried to install the service with the 64-bit version of installutil. This failed with permission errors in the% sysroot% \ wbem \ framework ... etc .... path. Then I recompiled the service as x86 and registered it again using the 32-bit version of installutil. This led to a whole new exception:

 System.Exception: The code generated for the instrumented assembly failed to compile. at System.Management.Instrumentation.InstrumentedAssembly..ctor(Assembly assembly, SchemaNaming naming) at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly) at System.Management.Instrumentation.Instrumentation.GetInstrumentedAssembly(Assembly assembly) at System.Management.Instrumentation.Instrumentation.GetPublishFunction(Type type) at System.Management.Instrumentation.Instrumentation.Publish(Object instanceData) at SomeService.InstanceClass.PublishApp(String name) in e:\work\clientname\SomeService\SomeService\WMIProvider.cs:line 44 at SomeService.SomeServiceService..ctor() in e:\work\clientname\SomeService\SomeService\SomeServiceService.cs:line 26 at SomeService.Program.Main() in e:\work\clientname\SomeService\SomeService\Program.cs:line 17 

... nearer...

Answer 1

I believe that the problem is not the publication of data, but the registration , which first appears in WMI.

If you look at the System.Management.Instrumentation code in a reflector or some other disassembler, you will see that the assembly that you want to publish has not been registered, then the code will try to register the assembly and save the assembly information in a specially named subdirectory in the WBEM installation folder .

I suspect that if you run the code to publish WMI data as an administrator, it will register the assembly, and then the network service account will have the rights to normal publication.

Answer 2

Have you checked your build with installutil ? This should give you a log of installation problems. (But since you cannot run it as a network service account, this may not show the problem you are having.)

In addition, are you sure that this service should run under the Network Service account?

Due to the risk of vulnerabilities when working with Windows services in privileged accounts, Microsoft made these special accounts with some restrictions that were strengthened in Vista and Win7. With Vista, Microsoft has limited the number of services running under this account in favor of less privileged ones (see this article ). The network service account (the so-called "NT AUTHORITY \ NETWORK SERVICE") can access the network (acting as the local machine account PCNAME $), but it reduced the rights on the local computer (unlike the local system account).

Have you checked the WMI security permissions for the branch used by your assembly? Run wmimgmt.msc and dig ... When I quickly checked some random branches, I could see that the Network Service account did not have write permissions.

Finally, I would suggest using ProcMon Sysinternals , which will allow you to filter only this process and see if there is any Access Denied errors in the file or registry settings. This tool has solved many problems for me over the years.

Answer 3

Not sure if you picked it up or anyone else, but please look: http://connect.microsoft.com/VisualStudio/feedback/details/530392/wmi-publishing-fails-on-permission-error-please -provide-a-way-to-override-codepath-in-system-management-instrumentation-schemanaming-in-app-config-web-config

This may help you better understand the root cause of the problem.