PSEXEC, acceso a errores denegados

Mientras estoy usando PSEXEC.exe, obtengo un error de ‘Acceso denegado’ para sistemas remotos.

Alguna idea sobre como resolver esto?

Hola, estoy colocando aquí un resumen de varias fonts en línea para varias soluciones para “se deniega el acceso”: la mayoría de la información se puede encontrar aquí (incluidos los requisitos necesarios) – Ayuda sysinternal

  1. como alguien mencionó agregar esta clave reg, y luego reiniciar la computadora:

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

    Lee este artículo de la base de conocimientos para saber qué hace esto y por qué es necesario.

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

    netsh advfirewall establece estado de todos los perfiles apagado

  3. si el usuario objective tiene un PW en blanco y no desea agregar uno, ejecute el objective:

    [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 la ejecución del objective:

    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 “Invitado solamente – …” ejecutar desde el símbolo del sistema elevado gpupdate \ force volver a ‘Classic – ..’ ejecutar nuevamente desde el símbolo del sistema elevado gpupdate \ force

  5. Este resolvió mi problema:

    ejecutar en el objective desde el símbolo del sistema elevado “net use” buscar en el gráfico de salida y para los recursos listados en la columna remota (solo eliminé los desconectados; puede probarlos todos) ejecutar “net use [remote path from before list] / delete “luego ejecute ‘net use \ target \ Admin $ / user: [nombre de usuario]’ ingrese solicitud de solicitud de contraseña (si PW está vacío solo presione enter), viola debería funcionar.

buena suerte, espero que esto ahorre tiempo a alguien.

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í .

PsExec tiene los derechos de acceso que tiene su iniciador. Se ejecuta bajo el control de acceso de Windows regular. Esto significa que quien lanzó PsExec (ya sea usted, el progtwigdor, 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 debes hacer son:

  1. Asegúrese de que el iniciador de PsExec sea familiar para 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 comando para especificar un usuario que sea conocido por la máquina de destino (-u usuario -p contraseña)

Si esto no resolvió su problema, asegúrese de que la máquina objective cumple con los requisitos mínimos, que se especifican aquí .

Esto ayudó en mi caso:

 cmdkey.exe /add: /user: /pass: psexec.exe \\  

Puedes probar el comando

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

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

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

  1. Uso runas para ejecutar el script en una cuenta de administrador
  2. Utilizo el parámetro -s en psExec para ejecutar en una cuenta de sistema
  3. Dentro de PsExec, inicio de sesión nuevamente con una cuenta de administrador
  4. Puede usar & para ejecutar comandos múltiples
  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 secuencia de comandos 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" 

Intente configurar esta clave en la máquina de destino (remota) y reinicie la máquina:

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System] "LocalAccountTokenFilterPolicy"=dword:00000001 

Ver: http://forum.sysinternals.com/topic10924.html y http://www.brandonmartinez.com/2013/04/24/resolve-access-is-denied-using-psexec-with-a-local- cuenta de administrador /

Acabo de agregar el parámetro “-с”. Hace que Psexec copie ejecutable a máquina remota. Entonces funciona sin errores de acceso.

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

Tuve un caso en el que AV ponía en cuarentena a Psexec: tenía que inhabilitar el escaneado en acceso

Encontré otra razón por la que fallaron PSEXEC (y otras herramientas PS): si algo (… por ejemplo, un virus o troyano) oculta la carpeta de Windows y / o sus archivos, PSEXEC fallará con un error “Acceso denegado”, PSLIST dará el error “Objeto de rendimiento del procesador no encontrado en” y se le dejará en la oscuridad en cuanto a la razón.

Puede RDP en; Puede acceder al admin $ share; Puede ver el contenido de la unidad de forma remota, etc., pero no hay indicación de que el / los archivo (s) o carpeta (s) que se está ocultando sean el motivo.

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 textualmente, solo pensé en hacer correr la voz antes de que nadie se quitara el pelo tratando de entender por qué el contador de rendimiento tiene algo que ver con ejecutar PSEXEC.

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 \ Progtwigs \ Progtwigs y características \ Actualizaciones instaladas

Funcionó justo después de eso.

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

[HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Policies \ System] “LocalAccountTokenFilterPolicy” = dword: 00000001 Ver: http://forum.sysinternals.com/topic10924.html

Tenía una versión un poco más vieja que no funcionó. Lo usé para hacer un poco de trabajo de USMT a través de Dell kace, trabajé muchísimo 🙂

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 mi problema:

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

Todavía uso psexec , incluso en win 10. Reemplace psexec.exe en la carpeta win32 Windows 10 con la versión anterior para que funcione -> 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 ayuda también:

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

No podría acceder a máquinas remotas a menos que tuviera el UAC deshabilitado.

Eso tiene que 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 que UAC está habilitado, asegúrese de ejecutar cmd como administrador .

Intereting Posts