psexesvc couldn access-denied psexec windows-scripting

access-denied - couldn - psexec windows 7



PSEXEC, acceso denegado errores (17)

Mientras estoy usando PSEXEC.exe obtengo el error ''Acceso denegado'' para sistemas remotos.

¿Alguna idea de cómo resolver esto?


Acabo de añadir el parámetro "-с". Hace que Psexec copie el ejecutable a máquina remota. Así funciona sin errores de acceso.


En Windows Server 2012 R2 tuve problemas para ejecutar desde la cuenta de usuario

psexec -u administrator -p password //machinename -h -s -d -accepteula cmd.exe

Pero funciona bien si ejecuta sin parámetros -h -s . Es por eso que uso esto para resolver mis problemas:

psexec -accepteula -u administrator -p password //machinename %PathToLocalUtils%/psexec.exe -h -s -d cmd.exe


Encontré otra razón por la cual PSEXEC (y otras herramientas de PS) fallan: si algo (... digamos, un virus o un troyano) oculta la carpeta de Windows y / o sus archivos, entonces PSEXEC fallará con un error de "Acceso denegado", PSLIST dará el error "El objeto de rendimiento del procesador no se encuentra en" y quedará en la oscuridad en cuanto a la razón.

Puede RDP en; Puedes acceder al admin $ share; Puede ver el contenido de la unidad de forma remota, etc., etc., pero no hay ninguna indicación de que el motivo sea el archivo (s) o la (s) carpeta (s) que se oculta.

Estaré publicando esta información en varias páginas que estaba examinando ayer mientras trataba de determinar la causa de este extraño problema, por lo que podría ver esto en otro lugar literalmente, solo pensé en poner la palabra antes de que alguien más se quitara el pelo. por las raíces, tratando de entender por qué el contador de rendimiento tiene algo que ver con la ejecución de PSEXEC.


Encontré que Sophos seguía colocando psexec.exe en la sección de cuarentena. Una vez que lo autoricé, funcionó bien.


Hola, estoy colocando aquí un resumen de muchas fuentes en línea para varias soluciones para "acceso denegado": la mayoría de la información se puede encontrar aquí (incluidos los requisitos necesarios) - ayuda de Sysinternal

  1. como alguien mencionó, agregue esta clave de registro y luego reinicie la computadora:

    reg agregue HKLM / SOFTWARE / Microsoft / Windows / CurrentVersion / Policies / system / v LocalAccountTokenFilterPolicy / t REG_DWORD / d 1 / f

    Lea este artículo de la base de conocimientos para saber qué hace esto y por qué se necesita.

  2. Deshabilite el firewall (nota: esto lo dejará sin protección de firewall)

    netsh advfirewall establece el estado de todos los perfiles desactivado

  3. Si el usuario de destino tiene un PW en blanco y no desea agregar uno, ejecute en target:

    [HKEY_LOCAL_MACHINE / SYSTEM / CurrentControlSet / Control / Lsa] "LimitBlankPasswordUse" = dword: 00000000

  4. Esto no funcionó para mí, pero lo he leído para otros en algunos lugares, en ejecución de destino:

    Inicio -> Ejecutar -> secpol.msc -> Políticas locales -> Opciones de seguridad -> Acceso a la red: uso compartido> y modelo de seguridad para cuentas locales> Clásico: los usuarios locales se autentican como ellos mismos

    Si ya está en ''Classic'':

    mover a "Sólo invitado - .." ejecutar desde el símbolo del sistema elevado gpupdate / force volver a ''Clásico - .. "ejecutar nuevamente desde el símbolo del sistema elevado gpupdate / force

  5. Este resolvió mi problema:

    ejecutar en el destino desde el símbolo del sistema elevado "uso neto", mirar el gráfico de salida y para los recursos compartidos que figuran en la columna remota allí (solo eliminé los desconectados; puede probarlos todos) ejecutar "uso neto [ruta remota desde la lista anterior] / eliminar "luego ejecute ''net use / target / Admin $ / user: [nombre de usuario]'' ingrese la solicitud de contraseña (si PW vacío, simplemente presione enter), la viola debería funcionar.

Buena suerte, espero que esto le ahorre tiempo a alguien.



Lo siguiente funcionó, pero solo después de actualizar PSEXEC a 2.1 desde Microsoft.

[HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / Windows / CurrentVersion / Policies / System] "LocalAccountTokenFilterPolicy" = dword: 00000001 Consulte: http://forum.sysinternals.com/topic10924.html

Tuve una versión un poco más antigua que no funcionó. Lo utilicé para hacer algún trabajo de USMT a través de Dell Kace, funcionó de maravilla :)


No podía acceder a las máquinas remotas a menos que tuviera UAC deshabilitado.

Esto debe hacerse localmente, ya sea desde el panel de control o ejecutando lo siguiente a través de cmd:

reg.exe ADD HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/System /v EnableLUA /t REG_DWORD /d 0 /f

Mientras UAC está habilitado, asegúrese de ejecutar cmd como administrador .


Para cualquiera que pueda tropezar con esto. Hay una actualización de seguridad reciente (diciembre de 2013) de Microsoft Windows en Windows 7 que impide la ejecución remota. Consulte http://support.microsoft.com/kb/2893294/en-us

Desinstalé la actualización de seguridad yendo a Panel de control / Programas / Programas y características / Actualizaciones instaladas

Funcionó justo después de eso.


Para un comando diferente, decidí cambiar la red de público a trabajo.
Después de intentar usar de nuevo el comando psexec, funcionó de nuevo.
Así que para hacer que psexec funcione, intente cambiar su tipo de red de público a trabajo u hogar.


PsExec tiene los derechos de acceso que tiene su lanzador. Se ejecuta bajo el control de acceso de Windows regular. Esto significa que quien haya lanzado PsExec (ya sea usted, el programador, un servicio, etc.) no tiene suficientes derechos en la máquina de destino o la máquina de destino no está configurada correctamente. Las primeras cosas que hacer son:

  1. Asegúrese de que el iniciador de PsExec esté familiarizado con la máquina de destino, ya sea a través del dominio o teniendo el mismo usuario y contraseña definidos localmente en ambas máquinas.
  2. Use los argumentos de la línea de comandos para especificar un usuario que sea conocido para la máquina de destino (-u usuario -p contraseña)

Si esto no solucionó su problema, asegúrese de que la máquina de destino cumpla con los requisitos mínimos, especificados aquí .


Puedes probar el comando

net use //computername/ipc$ /user:adminname password

para obtener permisos de administrador en una PC remota antes de usar psexec.


Sigo usando psexec , incluso en win 10. Reemplace psexec.exe en la carpeta win32 Windows 10 con la versión anterior para trabajar -> uso la versión 2.11.0.0. La versión de Windows 10 que estaba usando solo ejecutaría archivos .bat como proceso de fondo / oculto en la computadora remota. Tomó un día entero para resolver esto.

Agregar la clave de registro desde arriba a la computadora remota también ayuda:

reg add HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f


Tuve un caso en el que AV estaba poniendo en cuarentena a Psexec: tuve que deshabilitar el escaneado en acceso


Yo tuve el mismo problema. Y después de un arduo trabajo, encontré una solución fácil y completa:

  1. Yo uso runas para ejecutar el script en una cuenta de administrador
  2. Utilizo el parámetro -s en psExec para ejecutar en una cuenta del sistema
  3. Dentro de PsExec, vuelvo a iniciar sesión con una cuenta de administrador
  4. Puedes usar & para ejecutar comandos multiples
  5. Recuerde reemplazar [USERNAME], [PASSWORD], [COMPUTERNAME], [COMMAND1] y [COMMAND2] con los valores reales

El código se ve así:

runas /user:[USERNAME] "psexec -e -h -s -u [USERNAME] -p [PASSWORD] //[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2]"


Si desea depurar su script en la otra máquina, ejecute la siguiente plantilla:

runas /user:[USERNAME] "psexec -i -e -h -s -u [USERNAME] -p [PASSWORD] //[COMPUTERNAME] cmd /C [COMMAND1] & [COMMAND2] & pause"


This ayudó en mi caso:

cmdkey.exe /add:<targetname> /user:<username> /pass:<password> psexec.exe //<targetname> <remote_command>


Acabo de resolver un síntoma idéntico, creando el valor de registro HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Policies/system/LocalAccountTokenFilterPolicy y configurándolo en 1. Más detalles están disponibles aquí .