El archivo ejecutable iniciado por un servicio de Windows con la cuenta del sistema local no puede acceder a los recursos compartidos de red

Question

Tengo un ejecutable que se inicia con un servicio de Windows, este programa se ejecutará en el equipo de un cliente y deberá conectarse a un recurso compartido remoto para realizar una tarea en particular. Este recurso lo especifica el cliente a través de una interfaz de usuario, por lo que no lo sabemos de antemano, lo que significa que no puede ser "codificado", o el recurso compartido asignado de antemano.

Anteriormente, requeríamos que el cliente iniciara sesión en su máquina y ejecutara el ejecutable en el inicio de sesión, pero siempre hemos querido permitir que nuestro programa se ejecute dentro de un servicio y no requiera un inicio de sesión, principalmente para facilitarlo para el cliente y evitar cualquier cierre de sesión accidental que cierre nuestro software. Entonces, esto también significa que no sabemos qué cuentas de usuarios locales existen en la máquina de un cliente, por lo que tenemos que iniciar el servicio utilizando la cuenta del sistema local.

Ahora tenemos, como se mencionó anteriormente, un servicio de envoltura para iniciar el ejecutable y realizar varias tareas. Esto parece funcionar bien en la mayoría de los casos y accede a la multa subyacente de la red: el propósito de nuestro software principalmente consiste en capturar paquetes, etc.

Sin embargo, cuando el software intenta conectarse a un recurso compartido de Windows (nombre UNC) no puede conectarse. Mientras que si el ejecutable se inició manualmente, se conecta bien.

Las sugerencias que, en general, he visto para resolver este tipo de problemas parecen indicar que se debe usar una cuenta de usuario ya que la cuenta del sistema no puede acceder a los recursos compartidos de red, pero en nuestro caso esto no es posible. ¿Hay alguna otra forma en que podamos hacer que esto funcione?

Editar: olvidé mencionar que esta aplicación podría (y generalmente se ejecutará) en Win2K, no en XP, y creo que tengo razón al decir que la cuenta de la red local no está disponible antes de XP?

Answer 1

Si puede cambiar su servicio de Windows para que se ejecute bajo la cuenta del Servicio de red, entonces su ejecutable podrá acceder a los recursos compartidos de red (esta es una de las razones por las que se creó la cuenta del Servicio de red).

Las cuentas del sistema local y del servicio local no tienen credenciales de red y, por lo tanto, no se pueden autenticar en la red. Esto es por diseño.

Editar: IIRC, la cuenta de servicio de red se introdujo en Server 2003 y se agregó a uno de los paquetes de servicio de XP.

Si no puede confiar en que la cuenta del Servicio de red esté disponible, entonces podría considerar crear una cuenta de dominio dedicada, almacenar las credenciales de la cuenta en algún lugar, leerlas desde su servicio y luego iniciar sesión y hacerse pasar por ese usuario antes de acceder a la red. compartir. Alternativamente, el servicio de Windows podría ejecutarse directamente como cuenta dedicada, en cuyo caso se requeriría el inicio de sesión como servicio " privilegio.

Answer 2

Cuando tiene un servicio que se ejecuta bajo NT AUTHORITY \ LOCALSYSTEM (que es el nombre de la cuenta de servicio), aparece como la cuenta DOMAINNAME \ COMPUTERNAME $ (note el signo de $) en el resto de la red. Es decir, aparece como la cuenta de la COMPUTADORA en el directorio activo. Simplemente otorgue su archivo y comparta los permisos a DOMAINNAME \ COMPUTERNAME $ y usted debe ser bueno.

Answer 3

¿Por qué no puedes usar otra cuenta? Hay una cuenta de servicio de red integrada en Windows, específicamente para servicios que necesitan acceso a la red.

De todos modos, tenga mucho cuidado al hacer que un servicio inicie un archivo ejecutable.

Si el acceso de escritura a la carpeta con el archivo exe no está deshabilitado, un usuario puede reemplazarlo con (por ejemplo) cmd.exe . La próxima vez que el servicio intente iniciar su exe, voilà: ¡Un shell de comandos con derechos de sistema!