CreateProcessWithLogonW () - problemas necesidad de lanzar subprocesos con el mismo usuario

Question

Tengo un ejecutable de Windows que se inicia desde dentro de un servicio llamando CreateProcessWithLogonW () con un conjunto de datos de usuario specfied.

Esto funciona muy bien y el proceso se inicia como se esperaba. Sin embargo, cuando este proceso intenta poner en marcha otros procesos en sí, en la actualidad simplemente utilizando CreateProcess (), estos comienzan luego mueren enseguida -. Que son ejecutables que requieren acceso de escritorio

Después de leer en el artículo de Microsoft en CreateProcess () - http://msdn.microsoft.com/en-us/library/ms682425 (VS.85) .aspx

Creo que se puede ver por qué esto está ocurriendo y tiene sentido hasta cierto punto. CreateProcess () conoce el proceso de llamada se hace pasar por un usuario por lo que usa su proceso padre, que en este caso es la cuenta del sistema local. Pero, por supuesto, nada se ejecute en la cuenta de sistema local no tiene el acceso que necesitamos, por lo que el proceso iniciado muere.

Por extraño que cuando estaba previamente utilizando LogonUser () y CreateProcessAsUser () para iniciar el ejecutable inicial dentro del servicio, que funcionaba bien. Pero tenía que cambiar esto a CreateProcessWithLogonW () debido a problemas con no tener los privilegios adecuados.

¿Alguien sabe de una solución a esto? He visto a hablar de esto en otro lugar en la web, pero no con cualquier solución definitiva. Parece como si, posiblemente, necesito el token del usuario estoy iniciando la sesión con CreateProcessWithLogonW en () con lo que puedo utilizarlo para poner en marcha los otros procesos más adelante? Pero no tengo manera de apoderarse de este modo, se puede recuperar con este ser para el usuario actual de alguna manera?

Cualquier ayuda sería muy apreciada, gracias:)

Answer 1

¿Usted posee el código puesto en marcha utilizando CreateProcessWithLogonW (y que a su vez llama CreateProcess)? Si no entonces es posible que tenga que realizar IAT (o API) de enganche en ella (es decir, en tiempo de ejecución), como para sustituir cualquier llamada a CreateProcess con un procedimiento adecuado que también utiliza CreateProcessWithLogonW o CreateProcessWithTokenW. Ver APIHijack , desvíos .

Una vez hecho esto, el proceso hijo puede requerir el acceso a HKCU. Si no lo está haciendo esto, usted debe cargar el perfil de cada usuario suplantado, una vez por usuario, antes de llamar a CreateProcessWithLogonW.

  

Por defecto, CreateProcessWithLogonW   no se carga el usuario especificado   Perfil En el registro HKEY_USERS   llave. Esto significa que el acceso a   información en el HKEY_CURRENT_USER   clave del Registro puede producir resultados   que son consistentes con una normal de   inicio de sesión interactivo. Es tu   responsabilidad de cargar al usuario   sección del Registro en HKEY_USERS antes   llamando CreateProcessWithLogonW, por   usando LOGON_WITH_PROFILE, o por   llamando a la función LoadUserProfile.

Answer 2

Hemos resuelto el problema mediante un código que he encontrado de hace mucho tiempo. La sección de "copyright" de uno de los módulos de fuente contiene lo siguiente:

/////////////////////////////////////////////////////////////
// CreateProcessAsUser.cpp
// 
// Written by Valery Pryamikov (1999)
// 
// Command line utility that executes a command under specified user identity 
// by temporarily installing itself as a service.
//
// Based on Keith Brown's AsLocalSystem utility (http://www.develop.com/kbrown)
// Uses some code from Mike Nelson's dcomperm sample utility 
//   and from tlist sample (Microsoft Source Code Samples)
//
// Use:
//  CreateProcessAsUser.exe [-i[nteractive]]|[-s[ystem]]|
//       [-u"UserName" -d"DomainName" -p"Password"]|[-a"AppID"] command
//  Command must begin with the process (path to the exe file) to launch
//  -i        process will be launched under credentials of the 
//            "Interactive User" (retrieved from winlogon\shell process)
//  -a        process will be launched under credentials of the user 
//            specified in "RunAs" parameter of AppID.
//  -s        process will be launched as local system
//  -u -d -p  process will be launched on the result token of the 
//            LogonUser(userName,domainName,password,LOGON32_LOGON_BATCH...)
//
// either (-s) or (-i) or (-a) or (-u -d -p) parameters must supplied
// 
// Examples:
// CreateProcessAsUser -s cmd.exe
// CreateProcessAsUser -a"{731A63AF-2990-11D1-B12E-00C04FC2F56F}" winfile.exe
//
/////////////////////////////////////////////////////////////

Tal vez esta información dará lugar a golpes dentro de sus búsquedas de Google - Me trató de algunos intentos rápidos pero se quedó con las manos vacías. Descompusimos las partes internas en un conjunto de API que arrojó los resultados que necesitábamos.

Answer 3

¿No hay una opción para los servicios que les permita interactuar con el escritorio? Si no puede configurar esa opción para su servicio es una posibilidad, que sería probablemente la solución más simple.

Answer 4

Estoy asumiendo que este proceso es un servicio; que no se especifica en la pregunta, pero parece lógico teniendo en cuenta que se está ejecutando como la cuenta del sistema local.

Cuando estás quedarse atascado no está en CreateProcess, Está en CreateService . Si desea que su servicio sea capaz de interactuar con el escritorio, se tiene que especificar SERVICE_INTERACTIVE_PROCESS como una de las banderas a la dwServiceType argumento. Este ajuste es heredado por procesos secundarios del servicio.

También puede modificar configuración de un servicio existente mediante el uso de la herramienta Servicios, seleccione Propiedades para el servicio, haga clic en el "Log On" ficha, y seleccione la casilla de verificación "Permitir a los servicios interactuar con el escritorio".