Разрешения при публикации в WMI в учетной записи службы сети

Question

Я добавляю публикацию WMI в службу Windows на основе .NET. 3.5, которая работает под учетной записью «Сетевая услуга».

Согласно document I came across on MSDN, учетная запись «сетевой службы» должна иметь разрешения публикации WMI. ("По умолчанию доступны следующие пользователи и группы, которым разрешено публиковать данные и события: ... Network Service, ...")

Однако, когда служба называет Instrumentation.Publish (myStatusClassInstance), он генерирует исключение 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 пытается генерировать код на лету, и при работе в сетевой службе он нацелен на каталог, в котором услуга сети не имеет права доступа.

Какое лучшее исправление/обходное решение для этого? Могу ли я переопределить целевой каталог-gen-gen в app.config или в коде? Я не хочу возиться с разрешениями файловой системы при развертывании службы ...

Обновление: Я думаю, что это «функция», где старый код FX сталкивается с новыми настройками безопасности в Win7. Внутренне управляемые классы WMI извлекают каталог установки WMI из реестра и используют это как выходной путь для сгенерированного кода. К сожалению, многие пользователи не могут (или должны) писать материал в% SystemRoot% ... ... Я подал ошибку подключения (#530392), чтобы узнать, может ли MSFT принести ясность и/или предоставить исправление или обходное решение ,

Обновление 2: Я предполагаю, что для обычных учетных записей пользователей это не проблема, потому что виртуализация UAC будет запускать и хранить файлы в другом месте. Однако, по-видимому, учетная запись «сетевой службы» не покрывается виртуализацией UAC .. (?)

Обновление 3: Добавлена ​​550pt баунти. Простые ограничения: .net-система 3.5, основанная на Windows, служба, работающая как сетевая служба, должна иметь возможность публиковать данные через WMI с помощью System.Management.Instrumentation на Win7 и Win2008 [RTM & R2] с настройками/настройками по умолчанию и без использования изменение внутренних/частных членов структуры с использованием рефлексии. «Готовые», но чистые решения приветствуются. Будет открыт второй связанный баунти-Q в качестве заполнителя для другого 550pt, если SO разрешит.

Bounty обновление: я намерен удвоить награду за эту Q через второй вопрос рука об руку, которая будет служить в качестве наемного заполнителем:
https://stackoverflow.com/questions/2208341/bounty-placeholder (< - Видимо, это было не разрешено, так вопрос о заполнении залога был закрыт полицией этического контроля.)

Обновление 4: Все становится лучше и лучше. Я заметил, что installutil записывал недостающие файлы в c: \ windows \ syswow64 ... и т. Д., Поэтому я понял, что я использую 32-разрядную версию installutil для установки службы, но служба работает как 64-битный процесс. Очевидным побочным эффектом было то, что код, сгенерированный при запуске installutil, заканчивался под syswow64 (32-разрядный системный каталог), в то время как служба искала его в 64-разрядном системном каталоге (system32). (< - вне темы, но мне очень нравится, как MSFT удалось переключить имена там ... :)).

Поэтому я попытался установить службу с 64-разрядной версией installutil. Это провалилось с ошибками разрешения в пути% sysroot% \ wbem \ framework ... etc .... Затем я перекомпилировал службу как x86 и зарегистрировал ее снова, используя 32-разрядную версию installutil. Это привело к совершенно новое исключение:

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 

... все ближе ...

Answer 1

Я считаю, что проблема не с публикации данных, но с регистрации, что типа в WMI впервые ,

Если вы изучите код System.Management.Instrumentation в reflector или какой-либо другой дизассемблер, вы увидите, что сборка, которая собирается опубликовать, не была зарегистрирована, тогда код попытается зарегистрировать сборку и сохранить сборку info в специально названном подкаталоге в папке установки WBEM.

Я подозреваю, что если вы запустили код для публикации данных WMI в качестве администратора, он зарегистрирует сборку, а затем учетная запись сетевой службы будет иметь права на нормальную публикацию.

Answer 2

Вы проверили свою сборку с помощью installutil? Это должно дать вам журнал проблем установки. (Но поскольку вы не можете запустить его как учетную запись сетевой службы, это может не показать проблему, с которой вы столкнулись.)

Кроме того, вы уверены, что эта услуга должна быть запущена под учетной записью сетевой службы?

Из-за риска уязвимости при работе с службами Windows в привилегированных учетных записях Microsoft сделала эти специальные учетные записи с некоторыми ограничениями, которые были усилены в Vista и Win7. С Vista Microsoft ограничила количество сервисов, работающих под этим аккаунтом, в пользу менее привилегированных (см. this article). Учетная запись сетевой службы (ака «NT AUTHORITY \ NETWORK SERVICE») может получить доступ к сети (действуя как учетная запись локальной машины PCNAME $), но она уменьшила права на локальном компьютере (в отличие от учетной записи Local System).

Вы проверили разрешения безопасности WMI для филиала, используемого вашей сборкой? Запустите wmimgmt.msc и выполните поиск ... Когда я быстро проверил некоторые случайные ветви, я мог видеть, что учетная запись сетевой службы не имеет прав на запись.

Наконец, я бы предложил использовать Sysinternals' ProcMon, что позволит вам фильтровать только этот процесс и посмотреть, есть ли какие-либо ошибки, связанные с доступом, в настройках файла или реестра. На протяжении многих лет этот инструмент решал многие проблемы.

Answer 3

Не уверен, что если вы подняли его или кого-то еще, но, пожалуйста, посмотрите: 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

Это может помочь вам понять основную причину проблемы лучше