Foro de TI tranquilo

Hola,

versión de WAPT: 1.3.13.
Servidor ejecutando Debian.
Máquina de desarrollo ejecutando Windows 10.

Utilizo un script de PowerShell en uno de mis paquetes. Necesito conectar una unidad de red inicialmente, y estoy usando el comando NewPSDrive.

Este script funciona perfectamente cuando lo ejecuto manualmente en una consola de PowerShell, pero falla cuando lo ejecuto desde WAPT.
El comando es bastante básico:

New-PSDrive -Name Z -Root "\\server.domain.fr\myfolder$" -PSProvider Filesystem.
Sin embargo, cuando lo ejecuto a través de WAPT, obtengo un mensaje de error: New-PSDrive: La raíz de la unidad especificada "\\server.domain.fr\myfolder$" no existe o no es una carpeta.

He intentado comprender las diferencias entre ejecutar el script en una consola y ejecutarlo a través de WAPT. He comprobado con una prueba de conexión: el recurso compartido responde correctamente. También agregué una prueba que verifica si ya hay una unidad Z: mapeada, lo cual no es el caso.

La única diferencia que veo es cuando hago que muestre el nombre de usuario: es MyPC\administrator cuando lo ejecuto manualmente, y NT AUTHORITY\System cuando se ejecuta a través de WAPT. Sin embargo, no sé si el problema podría estar relacionado con eso.

Después de publicar bastantes mensajes en los foros de PowerShell, sin ninguna respuesta hasta ahora, pensé que tal vez otros usuarios de WAPT ya se habían encontrado con este problema.

PD: El archivo setup.py del paquete en cuestión (aunque no hay mucho que deba ser relevante):
def install():
print('instalando cdburnerXP')
run_powershell(r'./cdburn.ps1')

Gracias de antemano
.

Hola,

Wapt está diseñado para no depender de fuentes externas (como una unidad de red).
De hecho, en ese caso, la seguridad del paquete Wapt se ve comprometida. Además, si la red no está disponible durante la instalación, esta fallará (por ejemplo, durante un WaptExit).
Wapt no fue diseñado para esto.

¿Por qué no incluir el código fuente del software directamente en el paquete Wapt? ¡

Especialmente para CDBurner!

Le recomiendo que vuelva a leer la documentación sobre la creación de paquetes Wapt:
https://www.wapt.fr/fr/doc/CreationPaquets/index.html

Hola,

entiendo para qué sirve WAPT y cómo usarlo en modo "normal". Ya lo estoy haciendo y todo va bien, no se preocupen.

Pero ya tenemos una infraestructura para instalar software automáticamente, que utilizan otros programas (mdt, etc.).
Nuestra idea es evitar tener que mantener varios repositorios para cada actualización.
escenario de uso clásico de WAPT. Sospecho que ya existe un paquete de cdburnerxp en los repositorios de WAPT, pero no satisface nuestras necesidades en el caso de este software.

el

Hola Eric,

Erict escribió: ↑6 de febrero de 2018 - 17:20 Entiendo para qué sirve Wapt y cómo usarlo en modo "normal". Ya lo estoy haciendo y todo va bien en ese aspecto, no se preocupe.
Pero ya tenemos una infraestructura para la instalación automática de software, utilizada por otro software (mdt...).

La forma correcta de integrar WAPT y MDT es empaquetar normalmente en el modo WAPT, instalar waptagent al final del procedimiento MDT y llamar a una instalación wapt-get de su paquete de máquina directamente después.

Erict escribió: ↑6 de febrero de 2018 - 17:20 Nuestra idea es evitar tener que mantener varios repositorios para cada actualización.
En resumen, responde a una necesidad local, aunque es cierto que no nos encontramos en el escenario de uso clásico de WAPT. Soy consciente de que ya existe un paquete cdburnerxp en los repositorios de WAPT.

Lamento ser tan directo, pero es una pésima idea. No se garantiza la disponibilidad de un recurso compartido de red al instalar WAPT (por ejemplo, waptexit no lo comprueba).

erict escribió: ↑06 feb 2018 - 17:20 , pero no satisface nuestras necesidades, en el caso de este software.

El uso de paquetes "autónomos" de WAPT es una condición esencial para garantizar una tasa de implementación exitosa...

Para responder a tu pregunta específica (aunque probablemente te esté creando más problemas), la cuenta que se usa al montar una red como cuenta LocalSystem (NT Authority\System) es la cuenta Kerberos del equipo (p. ej., MYCOMPUTER$). Por lo tanto, debes otorgar permisos de lectura al grupo "equipos del dominio" en el recurso compartido que contiene los instaladores. Este es un problema exclusivo de Windows; es extraño que nadie haya podido responderlo en tu foro de PowerShell... (bueno, solo estoy bromeando)

Pero bueno, repito, no es buena idea. Lo repetiré una vez más, para que no me acusen de animar a la gente a hacerse daño: ¡no es buena idea!

El hecho de que no tengamos la solución no significa que te animemos a crear paquetes WAPT correctamente, es solo que si se trata de iniciar un script de PowerShell que necesita hacer un montaje de red, en ese caso también puedes usar GPO, tendrá el mismo error (u otras herramientas de implementación que también tienen muchos errores al seguir el mismo modelo).

Dicho esto, si tu problema es con Python y la creación de archivos setup.py para WAPT, tienes docenas de paquetes que te servirán de inspiración. Y si quieres progresar más rápido y convertirte en cinturón negro de tercer grado en empaquetadores de WAPT, ¡Alexandre y Simon ofrecen una formación rápida y eficaz!

Denis

Muchas gracias por su respuesta tan completa.
He tomado nota de todo lo que ha comentado sobre el uso de WAPT. De hecho, estamos probando sus capacidades para ver cómo podríamos usarlo en relación con las GPO, MDT y el sistema que usamos actualmente para implementar sistemas y software en estaciones de trabajo, así como para las actualizaciones.
Tenemos que proceder gradualmente, ya que no podemos cambiarlo todo a la vez, y han surgido muchas preguntas.
WAPT parece prometedor, más fácil de poner a disposición de los compañeros que, por ejemplo, abrir la posibilidad de crear GPO para todos.
En resumen, estamos en la fase de pruebas y planificación de cómo integrarlo gradualmente, ya sea junto con algunas de nuestras herramientas existentes o como reemplazo de las mismas. El enfoque elegido es integrarlo en la infraestructura actual y ampliar su uso según sea necesario si resulta útil o conveniente.
La flexibilidad de su producto lo permite, y esa es precisamente una de las razones por las que lo elegimos.

Gracias de nuevo por su ayuda y trabajo en esta herramienta
.

Hola Eric,

Erict escribió: ↑7 de febrero de 2018 - 9:53 a. m. Muchas gracias por su respuesta tan completa.
He tomado nota de todo lo que dijo sobre el uso de WAPT. Actualmente estamos probando sus capacidades para ver cómo podríamos usarlo en relación con las GPO, MDT y el sistema que usamos actualmente para implementar sistemas y software en estaciones de trabajo, así como para actualizaciones.
Tenemos que proceder gradualmente, ya que no podemos cambiarlo todo a la vez, y están surgiendo muchas preguntas.
WAPT parece prometedor, más fácil de poner a disposición de los colegas que abrir la posibilidad de crear GPO para todos, por ejemplo.
En resumen, actualmente estamos probando y considerando cómo integrarlo gradualmente junto con y/o como reemplazo de algunas de nuestras herramientas existentes. Nuestro enfoque elegido es integrarlo en nuestra infraestructura actual y ampliar su uso según sea necesario si resulta útil o tiene sentido.
La flexibilidad de su producto lo permite, y esa es precisamente una de las razones por las que lo elegimos.

Si el objetivo es simplemente instalar un MSI o EXE que se ejecute correctamente y silenciosamente, simplemente ejecute el siguiente comando con el paquete, luego realice una carga de compilación (dos minutos como máximo para un paquete pequeño)...

Código: Seleccionar todo

wapt-get make-template moninstalleur.msi

El aumento de la carga de trabajo por tener ambos sistemas funcionando en paralelo durante el período de prueba no debería ser demasiado significativo...

Denis

Hola de nuevo,

gracias por la información.
Aunque no forma parte del uso "normal" de WAPT, publico la solución aquí por si le sirve a alguien:
efectivamente, había un problema con las credenciales del usuario del sistema. Nuestra carpeta compartida no requiere autenticación (es de solo lectura), pero aun así es necesario proporcionar un nombre de usuario y una contraseña, aunque sean ficticios.

En cuanto a nuestro posible método de transición entre nuestro sistema actual y WAPT, tenemos buenas razones para hacer las cosas como las hacemos, que serían demasiado largas de detallar aquí (y de todas formas no serían muy interesantes).

Gracias de nuevo.
Saludos cordiales,

ET

Erict escribió: ↑7 de febrero de 2018 - 16:07 Re:

Gracias por la información.
Aunque no forma parte del uso "normal" de WAPT, publico la solución aquí, por si le resulta útil a alguien:
Efectivamente, hubo un problema de credenciales para el usuario del sistema. Nuestro recurso compartido no requiere autenticación (es de solo lectura), pero aun así es necesario proporcionar un nombre de usuario y una contraseña, aunque sean falsos.

En cuanto a nuestro posible método de transición entre nuestro sistema actual y WAPT, tenemos buenas razones para hacerlo de esta manera, que serían demasiado extensas para detallar aquí (y de todos modos no son muy interesantes).

Gracias de nuevo.
Saludos cordiales,

ET

Pido disculpas por ser tan insistente, pero para quienes leerán este post: ¡No debemos seguir este ejemplo!

Si tiene un recurso compartido de red sin autenticación, un simple ataque de intermediario con suplantación de ARP/DNS/NetBIOS redirigirá las estaciones de trabajo de los usuarios a un recurso compartido comprometido, y todo lo que se ejecute se ejecutará bajo una cuenta LocalSystem, omitiendo la mayoría de las comprobaciones de seguridad estándar. En resumen, a menos que tenga 802.1x, pVLAN y protección contra el envenenamiento de caché ARP en toda su red, y no tenga portátiles, está creando una vulnerabilidad de seguridad masiva que permitirá a cualquier script kiddie tomar el control de la red

El modelo operativo WAPT es sólido desde el punto de vista de la seguridad. Preferiría que el nombre WAPT no se asociara con tales métodos...

Además, una simple autenticación mutua mediante Kerberos con la cuenta de la máquina habría evitado al menos este ataque MITM. No soy experto en PowerShell, pero un simple comando "net use" como cuenta LocalSystem permite la autenticación y la asignación de una unidad a un recurso compartido con permisos de lectura para "equipos de dominio":

Código: Seleccionar todo

psexec -i -s cmd
    whoami
    net use f:   \\mondomain.lan\sysvol
    dir f:

Atentamente,

Denis

Hola de nuevo,

no tengo suficientes conocimientos de redes/hacking para comprender completamente las implicaciones de tu comentario, pero se lo pasaré al ingeniero que implementó este sistema para ver qué opina. Dicho esto, sí que tenemos 802.1x, VLANs y un montón de protecciones de red bastante robustas... lo cual no es motivo para hacer cualquier cosa, estamos de acuerdo en eso.

De hecho, por el momento, estamos "modificando" WAPT para hacer cosas para las que no fue diseñado originalmente, y entiendo que prefieras ser muy claro al respecto.

En cuanto a `net use`, creo que lo probé y no arrojó más resultados que `New-PSDrive`, pero volveré a ejecutar la prueba en algún momento (aunque, fundamentalmente, si no me equivoco, no cambia mucho en lo que respecta al problema de seguridad mencionado).

Saludos,
ET

Foro de TI tranquilo

[RESUELTO] Problema con NewPSDrive

[RESUELTO] Problema con NewPSDrive

Re: Problema con NewPSDrive

Re: Problema con NewPSDrive

Re: Problema con NewPSDrive

Re: Problema con NewPSDrive

Re: Problema con NewPSDrive

Re: Problema con NewPSDrive

Re: Problema con NewPSDrive

Re: Problema con NewPSDrive