在网络服务帐户下发布到WMI时出现权限问题 [英] Permissions issue when publishing to WMI under network service account

问题描述

我正在将WMI发布添加到基于网络服务"帐户下运行的基于.net Framework 3.5的Windows服务.

I'm adding WMI publishing to a .net framework 3.5 based windows service that is running under the 'network service' account.

根据我在MSDN上遇到的文档，默认情况下，网络服务"帐户应具有WMI发布权限. ("默认情况下，允许以下用户和组发布数据和事件:... 网络服务，... ")

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

但是，当服务调用Instrumentation.Publish(myStatusClassInstance)时，它将引发DirectoryNotFoundException;

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'.

.. so看起来像System.Management.Instrumentation试图动态生成代码，并且在网络服务下运行时，它的目标是网络服务没有权限的目录.

..so it looks like System.Management.Instrumentation tries to generate code on the fly, and when running under network service it targets a directory where network service has no permissions.

对此的最佳解决方案/解决方法是什么?我可以在app.config或代码中覆盖代码生成目标目录吗?部署服务时，我不想摆弄文件系统权限...

What is the best fix/workaround for this? Can I override the code-gen target dir in app.config or in code? I don't want to have to fiddle around with file system permissions when deploying the service...

更新:我认为这是一个功能"，其中较旧的FX代码与Win7中的较新的安全设置相冲突.在内部，WMI托管类从注册表检索WMI安装目录，并将其用作生成代码的输出路径.不幸的是，许多用户不允许(或应该)在％SystemRoot％下写东西... ...我提出了一个连接错误(

Update: I think this is a 'feature' where older FX code clashes with newer security settings in Win7. Internally the WMI managed classes retrieves the WMI installation directory from registry, and uses that as the output path for generated code. Unfortunately a lot of users are not allowed to (or supposed to) write stuff under %SystemRoot%... ...I filed a connect bug (#530392) to see if MSFT can bring any clarity and/or provide a fix or workaround.

更新2:我猜对于普通用户帐户来说这不是问题，因为UAC虚拟化将启动并将文件存储在其他位置.但是，显然，网络服务"帐户不受UAC虚拟化的保护..(?)

Update 2: I'm guessing that for normal user accounts this is not an issue, because UAC virtualization will kick in and store the files elsewhere. However, apparently the 'network service' account is not covered by UAC virtualization..(?)

更新3::增加了550点赏金.简单的约束:基于.net Framework 3.5的Windows服务(作为网络服务运行)需要能够使用Win7和Win2008上的System.Management.Instrumentation通过WMI发布数据. [R2]具有默认的权限/安全设置，并且无需诉诸使用反射来修改框架内部/私有成员.欢迎使用开箱即用"但干净的解决方案.如果SO允许，将打开另一个相关的赏金Q作为另一个550pt的占位符.

Update 3: Added 550pt bounty. Simple constraints: .net framework 3.5 based windows service, running as network service, need to be able to publish data through WMI using System.Management.Instrumentation on Win7 and Win2008[RTM & R2] with default permissions/security settings and without resorting to modifying framework internal/private members using reflection. 'Out-of-the-box' but clean solutions welcome. Will open a second related bounty-Q as a placeholder for another 550pt if SO allows.

赏金更新:我打算通过第二个并行问题(将用作赏金占位符)将本次Q的赏金翻倍:
https://stackoverflow.com/questions/2208341/bounty-placeholder (<-显然不是允许，因此SO礼节警察关闭了赏金占位符问题.)

Bounty update: I intend to double the bounty for this Q through a second hand-in-hand question that will serve as a bounty placeholder:
https://stackoverflow.com/questions/2208341/bounty-placeholder ( <-- Apparently this was not allowed, so the bounty placeholder question got closed by the SO etiquette police.)

更新4:，这种情况越来越好.我注意到installutil正在将丢失的文件写入c:\ windows \ syswow64 ... etc ...，因此我意识到我正在使用32位版本的installutil安装该服务，但是该服务以64位进程.明显的副作用是，运行installutil时生成的代码最终在syswow64(32位系统目录)下，而该服务在64位系统目录(system32)下寻找它. (<-主题外，但我真的很喜欢MSFT如何在其中切换名称... :)).

Update 4: This gets better and better. I noticed that installutil was writing the missing files to c:\windows\syswow64...etc..., so I realized that I was using the 32-bit version of installutil to install the service, but the service was running as a 64-bit process. The obvious side effect was that code generated when installutil was running ended up under syswow64 (the 32-bit system directory), while the service was looking for it under the 64-bit system directory (system32). (<-- off topic, but I really like how MSFT managed to switch around the names there... :) ).

因此，我尝试使用64位版本的installutil安装服务.由于％sysroot％\ wbem \ framework ... etc ...路径中的权限错误，该操作失败了.接下来，我将该服务重新编译为x86，并使用32位版本的installutil重新注册了该服务.这导致了一个全新的例外:

So I tried installing the service with the 64-bit version of installutil. That failed miserably with permission errors in the %sysroot%\wbem\framework...etc... path. Next I recompiled the service as x86 and registered it again using the 32-bit version of installutil. That resulted in an entirely 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

...越来越近...

...getting closer...

推荐答案

我认为问题不在于发布数据，而在于注册是第一次输入WMI.

I believe the problem is not with publishing data, but with registering that type in WMI for the first time.

如果您检查 reflector 或其他一些代码中的System.Management.Instrumentation代码，反汇编程序，您将看到要发布的程序集尚未注册，然后代码将尝试注册该程序集并将程序集信息保存在WBEM安装文件夹下的一个专门命名的子目录中.

If you examine the System.Management.Instrumentation code in reflector, or some other disassembler, you'll see that wen the assembly that is about to publish hasn't been registered, then the code will try to register the assembly and save the assembly info in a specially named sub directory under the WBEM installation folder.

我怀疑如果您先运行代码以管理员身份发布WMI数据，它将注册程序集，然后网络服务帐户将具有执行常规发布的权限.

I suspect that if you run code to publish the WMI data as an administrator first, it would register the assembly and then the Network Service account would have the permissions to do the normal publishing.

这篇关于在网络服务帐户下发布到WMI时出现权限问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！