usar remote not management installed instalar has enable disabled computer como been advfirewall windows-7 permissions wmi uac

windows 7 - remote - Problema de permisos al publicar en WMI en una cuenta de servicio de red



wmi ports windows firewall (3)

Estoy agregando la publicación de WMI a un servicio de Windows basado en .NET Framework 3.5 que se ejecuta bajo la cuenta de ''servicio de red''.

De acuerdo con un documento que encontré en MSDN , la cuenta de "servicio de red" debería tener permisos de publicación WMI por defecto. (" De forma predeterminada, los siguientes usuarios y grupos pueden publicar datos y eventos: ... Servicio de red , ... ")

Sin embargo, cuando el servicio llama a Instrumentation.Publish (myStatusClassInstance), arroja una excepción 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 parece que System.Management.Instrumentation intenta generar código sobre la marcha, y cuando se ejecuta bajo servicio de red apunta a un directorio donde el servicio de red no tiene permisos.

¿Cuál es la mejor solución / solución para esto? ¿Puedo anular el directorio objetivo de code-gen en app.config o en el código? No quiero tener que juguetear con los permisos del sistema de archivos al implementar el servicio ...

Actualización : creo que esta es una ''característica'' donde el código FX anterior choca con la configuración de seguridad más nueva en Win7. Internamente, las clases administradas de WMI recuperan el directorio de instalación de WMI del registro y lo utilizan como ruta de salida para el código generado. Desafortunadamente, a muchos usuarios no se les permite (ni se supone que) que escriban cosas en% SystemRoot% ... ... Archivé un error de conexión ( # 530392 ) para ver si MSFT puede aportar alguna claridad y / o proporcionar una solución o solución alternativa

Actualización 2: supongo que para las cuentas de usuario normales esto no es un problema, porque la virtualización de UAC activará y almacenará los archivos en otro lugar. Sin embargo, aparentemente la cuenta de "servicio de red" no está cubierta por la virtualización de UAC .. (?)

Actualización 3: Se agregó una recompensa de 550 puntos. Restricciones simples: el servicio de ventanas basado en .NET Framework 3.5, que se ejecuta como servicio de red, necesita poder publicar datos a través de WMI utilizando System.Management.Instrumentation en Win7 y Win2008 [RTM & R2] con permisos predeterminados / configuraciones de seguridad y sin recurrir a modificando los miembros internos / privados del marco mediante la reflexión. Soluciones "listas para usar" pero limpias bienvenidas. Se abrirá un segundo Bounty-Q relacionado como marcador de posición para otro 550pt si SO lo permite.

Actualización de Bounty: tengo la intención de duplicar la recompensa por esta Q a través de una segunda pregunta de la mano que servirá como un marcador de posición de recompensa:
https://stackoverflow.com/questions/2208341/bounty-placeholder (<- Aparentemente esto no estaba permitido, por lo que la pregunta sobre el marcador de posición de la recompensa fue cerrada por la policía de etiqueta de SO.)

Actualización 4: Esto se pone mejor y mejor. Me di cuenta de que installutil estaba escribiendo los archivos que faltaban en c: / windows / syswow64 ... etc ..., así que me di cuenta de que estaba usando la versión de 32 bits de installutil para instalar el servicio, pero el servicio se estaba ejecutando como un Proceso de 64 bits El efecto secundario obvio era que el código generado cuando installutil se ejecutaba terminaba bajo syswow64 (el directorio del sistema de 32 bits), mientras que el servicio lo buscaba en el directorio del sistema de 64 bits (system32). (<- fuera del tema, pero realmente me gusta cómo MSFT logró cambiar los nombres allí ... :)).

Así que intenté instalar el servicio con la versión de 64 bits de installutil. Eso falló miserablemente con errores de permiso en la ruta% sysroot% / wbem / framework ... etc ... Luego volví a compilar el servicio como x86 y lo registré nuevamente usando la versión de 32 bits de installutil. Eso dio lugar a una excepción completamente nueva:

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

...acercarse...

¿Ha inspeccionado su conjunto con el installutil ? Eso debería darle un registro de los problemas de instalación. (Pero dado que no puede ejecutarlo como la cuenta de servicio de red, es posible que no muestre el problema que está teniendo).

Además, ¿está seguro de que este servicio se debe ejecutar bajo la cuenta de servicio de red?

Debido al riesgo de vulnerabilidad al ejecutar servicios de Windows en cuentas con privilegios, Microsoft ha creado estas cuentas de servicios especiales con algunas limitaciones, que se han fortalecido en Vista y Win7. Desde Vista, Microsoft ha limitado el número de servicios que se ejecutan bajo esta cuenta a favor de los menos privilegiados (consulte este artículo ). La cuenta de servicio de red (también conocida como "NT AUTHORITY / NETWORK SERVICE") puede acceder a la red (actuando como la cuenta de máquina local PCNAME $), pero tiene derechos reducidos en la máquina local (a diferencia de la cuenta del sistema local).

¿Ha comprobado los permisos de seguridad de WMI para la rama que está utilizando su ensamblado? Ejecute wmimgmt.msc y cave in ... Cuando hice una comprobación rápida de algunas ramas aleatorias, pude ver que la cuenta de servicio de red no tenía derechos de escritura.

Por último, sugeriría usar ProcMon de Sysinternals , que le permitiría filtrar a ese proceso y ver si hay algún error de acceso denegado en la configuración de archivo o registro. Esta herramienta me ha solucionado muchos problemas a lo largo de los años.

Creo que el problema no es publicar datos, sino registrar ese tipo en WMI por primera vez.

Si examina el código System.Management.Instrumentation en el reflector , o algún otro desensamblador, verá que si el ensamblado que está a punto de publicarse no ha sido registrado, entonces el código intentará registrar el ensamblaje y guardar el ensamblaje información en un subdirectorio especialmente nombrado en la carpeta de instalación WBEM.

Sospecho que si ejecuta código para publicar primero los datos de WMI como administrador, registraría el ensamblado y luego la cuenta de servicio de red tendría los permisos para hacer la publicación normal.