10 respuestas
No es posible en el propio script, ya que es la apertura de este script la que solicita las credenciales.
La teoría sería llamar al script con un segundo de la siguiente manera:
runas /user:user_name /pass:12345 "mon.cmd"
lo cual no funciona, la seguridad sigue pidiendo la contraseña; una forma de sortear esto es guardarla una vez por todas en la primera utilización:
runas /user:user_name /savecred "mon.cmd"
No hay otra solución más que pasar por una utilidad de terceros, por ejemplo, se puede intentar con PsExec:
https://docs.microsoft.com/es-es/sysinternals/downloads/psexec
de hecho vi la solución con pstools, pero eso obliga a instalarlo en todos los puestos de la red y el parque afectado es considerable
no puedo tampoco guardar la contraseña, ya que habría que hacerlo para cada máquina y cada perfil de usuario
¿no existe una opción en la que se recupere la contraseña almacenada en otro archivo y un comando la copie y pegue cuando se solicite? Una especie de robot que escriba en nuestro lugar.
si trabajas en el ámbito de AD, solo necesitarías hacer esto por GPO...
Ahí no habría más problemas...
--
Chouba, Moderador / Mi trabajo es tan secreto que ni siquiera sé lo que hago.
aquí están mis comandos:
xcopy /s "\\monserv\pstools" "%windir%\system32\pstools\" /Y
setx path /m "%path%;%windir%\system32\pstools"
funciona bien utilizando psexec, pero es cierto que hay un pequeño detalle que me gustaría mejorar. La contraseña sigue siendo accesible en el batch, por lo que no es muy segura ya que es la contraseña de administrador del dominio.
de hecho, aquí está el comando del batch destinado a bloquear un programa a través del firewall:
psexec -accepteula -u mondomaine\admin -p mypassword -d cmd.exe /c \\monserv\cmd\vblockbrowsers.bat
¿Hay alguna posibilidad de ocultar la contraseña o hacerla menos visible? o ¿debería poner el archivo .bat como archivo oculto, pero cualquier usuario puede volver a mostrar fácilmente los archivos ocultos?
gracias
¿La solución podría ser convertir el bat en exe?
El problema, por supuesto, es que si hay que dirigirse a varias máquinas, se necesitaría un exe diferente para cada máquina y cada contraseña.
Otras fuentes, como aquí, sugieren integrar el bat en un archivo zip protegido con contraseña o cifrarlo (CERTUTIL, codificador base64...), no he probado nada de esto ya que el bat tratado debe seguir siendo funcional.
Probablemente sea el caso con la solución zip (solo hay que descomprimir sobre la marcha, pero manualmente desde la línea de comandos, ya que programar el batch o hacer un segundo para este fin perdería su interés: será la segunda contraseña la que estará visible).
https://www.developpez.net/forums/d1297398/general-developpement/programmation-systeme/windows/scripts-batch/outils-cryptage-sous-windows/
creo que también voy a intentar un método muy simple: colocar el archivo .bat en una unidad invisible para el usuario, el C: simplemente ya que está oculto para los usuarios (a través de la clave de registro nodrives y noviewondrives).
con la esperanza de que la ejecución se pueda llevar a cabo correctamente.
--
Chouba, Moderador / Mi trabajo es tan secreto que ni siquiera sé lo que hago.
ok. pero la conversión a .exe parece ser la única opción para que nadie pueda ver la contraseña de administrador
me encuentro con un problema extraño, cuando pongo el comando que llama a un .bat funciona bien, pero si inserto el comando en psexec, solicita derechos de administrador
comando ok pero requiere 2 archivos
psexec -accepteula -u mondomaine\admin -p mypassword -d cmd.exe /c \\monserv\cmd\vblockbrowsers.bat
comando no ok
psexec -accepteula -u mondomaine\admin -p mypassword -d cmd.exe /c (^netsh advfirewall firewall add rule name="chrome" dir=in action=block program="C:\program files\google\chrome\application\chrome.exe" enable=yes profile=any ^)
si un usuario lanza este batch se indica "la operación solicitada requiere elevación"
Hola,
No estoy seguro de entender la pregunta. ¿El script no está destinado a ser ejecutado por el usuario en uno de los equipos de destino?
El problema puede estar tanto en PSEXEC como en NETSH: en ambos casos, necesitamos que esté activada en el equipo de destino la compartición administrativa admin$.
En el segundo caso, la mayoría de los comandos de NETSH requieren elevación, que quizás pueda obtenerse a través del interruptor -h de PSEXEC y que de lo contrario, en principio, pasa por PowerShell:
https://ss64.com/ps/syntax-elevate.html
Además, NETSH prohíbe localmente el uso de un nombre de usuario y una contraseña, y requiere en red no solo que la compartición de archivos e impresoras esté activa, sino también que el servicio de acceso remoto al registro esté habilitado.
hola, vuelvo sobre este problema de elevación de derechos con psexec. incluso añadiendo -h en el comando obtengo el mensaje "no se pudo iniciar el servicio psexesvc en A01-1" > A01-1 siendo el nombre de la máquina
después tengo la operación solicitada requiere elevación. sin embargo, todo está bien en admin, el comando se ejecuta correctamente
psexec -accepteula -u mondomaine\admin -p mypassword -h -d cmd.exe /c (^netsh advfirewall firewall add rule name="chrome" dir=in action=block program="C:\program files\google\chrome\application\chrome.exe" enable=yes profile=any ^)
se mantiene misterioso. La única manera de no tener el problema de elevación es tener un segundo archivo .bat que psexec viene a lanzar
Temo que, de hecho, no haya una solución clara, es la serpiente que se muerde la cola: Psexec lanza los comandos requeridos a nivel de administrador con el modificador h, pero necesita ser lanzado como administrador, lo cual funcionará perfectamente en la línea de comandos, pero no en una tarea programada.
Hay una serie de soluciones complejas, como por ejemplo esta:
https://stackoverflow.com/questions/7044985/how-can-i-auto-elevate-my-batch-file-so-that-it-requests-from-uac-administrator
Y un número de otras ideas buscando en Google algo como "psexec batch scheduled task elevation" o "batch elevate to administrator", te dejo hacer tu búsqueda para ver si encuentras inspiración...
Preciso un poco más mi objetivo de ocultar la contraseña de administrador porque la GPO no parece estar considerada en este caso.
La idea es que en un momento preciso, un usuario (profesor) envía un comando a otro puesto de usuario (estudiante) a través de un software de control remoto. Se prevén 2 comandos, uno para bloquear el navegador y el otro para desbloquearlo. Los archivos de scripts que integran psexec están preconfigurados en la aplicación, invisibles para el usuario. Pero no completamente inaccesibles para este último, ya que los scripts están almacenados en un disco compartido. Así que imaginando que, aunque esté muy bien oculto, el usuario encuentre el batch, podría reactivar el navegador. Porque incluso ocultando el disco con el registro a través de la clave "nodrives", el disco tiene que seguir siendo accesible para el usuario, por lo que "noviewondrive" no puede considerarse a priori.
Por eso, aunque en el peor de los casos el script sea detectado, al menos la contraseña de administrador no debe ser recuperable.
Hola,
Psexec tiene un conmutador -s que permite utilizar la cuenta "NT AUTHORITY\SYSTEM"
Esta cuenta es la más poderosa de las cuentas, y no está sujeta al UAC.
Hola,
Sí, también lo vi, pero que el interruptor sea h o s, no estoy seguro del resultado en la tarea programada: aparentemente no es la instrucción psexec la que no se ejecuta por falta de derechos sobre el objetivo, sino el hecho de que nos son rechazados tan pronto como se lee psexec; el servicio psexec no se inicia porque previamente se necesita tener derechos administrativos para ello, lo cual ocurre cuando se ejecuta un batch eligiendo previamente como administrador.