He estado luchando con algo desde hace bastante tiempo. El jefe quiere un directorio en nuestro servidor de archivos, en el que colocará los archivos de instalación del programa, que todos puedan leer y solo él pueda modificar.
Quiere que las estaciones de trabajo de los clientes tengan un script que lea el directorio y muestre al usuario qué archivos hay allí. Luego, el usuario, que es un usuario de dominio normal (sin la capacidad de instalar nada), podrá hacer clic en instalar y lo instalará.
La idea detrás de esto es tener un administrador local en la estación del usuario y hacer que el script conozca la contraseña del administrador local y luego instalar el programa en la computadora del usuario con esas credenciales de administrador local.
Este es un tema muy problemático porque no veo cómo puedo protegerlo sin almacenar la contraseña del administrador local dentro del script, lo cual es algo muy malo.
Intenté pensar en cifrar la contraseña de alguna manera y convertir el script en un ejecutable, pero no veo la manera en que un usuario que sabe un poco sobre computadoras no pueda descompilar el ejecutable. Si uso el cifrado PowerShell, sería adecuado para una máquina y un solo usuario.
Luego pensé en otra forma: hacer una llamada desde la estación de trabajo del cliente al archivador y luego hacer que el archivador use psexec para volver al usuario, pero esto se está volviendo demasiado espagueti.
Luego pensé en hacer una llamada desde la computadora del usuario al archivador y luego desde el archivador al usuario usando el comando invocar, pero necesito permitir WinRM a todos los clientes.
Estoy usando PowerShell para esto. Quizás alguien aquí haya hecho algo similar y pueda aconsejarme sobre cómo hacerlo de forma segura.
La primera opción funcionó muy bien, así que me gustaría seguir con ella si es posible, pero tengo que descubrir cómo proteger esto y no simplemente poner las credenciales en un script de PowerShell que se encuentra en la computadora del usuario.
Respuesta1
Veo dos enfoques.
- Consigue un jefe diferente. Obviamente no tiene idea de lo complicada que es realmente la tarea que exige, siempre son los detalles, y dudo que haya echado un vistazo a ellos. Las instalaciones de Windows son extremadamente difíciles de dominar en detalle.
¿Seguir leyendo? Bueno. Se puede hacer.
- El punto clave es ejecutar su script como una "tarea programada" en segundo plano. Cuando configura una nueva "tarea programada" por máquina, se le solicita un nombre de usuario y una contraseña que debe usar esta tarea. Aquí ingresa las credenciales de su cuenta de instalación. La contraseña no se puede recuperar posteriormente, por lo que puede considerarse segura. Esta "tarea programada" ahora tiene todos los derechos administrativos, y si usa una cuenta de usuario de dominio (otorgue derechos de administrador en los clientes y solo derechos de usuario en el servidor), su secuencia de comandos puede acceder fácilmente a los archivos de instalación a través de la red y activar la instalación.
Sin embargo, tenga en cuenta que muchos programas de instalación son bastante tontos: instalarán el programa para que lo utilice el usuario que lo instala (es decir, su usuario instalador) y no para el usuario que inició sesión en primer plano. Algunos instaladores pueden parametrizarse para instalarse en "todos los usuarios", lo que probablemente sea suficiente, para otros tendrá que hacer su script más inteligente para que pueda agregar "todas las configuraciones requeridas, licencias (!), íconos, lo que sea que necesite un programa". para funcionar" en el perfil del usuario de primer plano una vez finalizado el instalador del software.
No existe absolutamente ninguna forma legítima de que una cuenta de usuario realice la tarea. Si hubiera alguna manera de que un usuario pudiera elevar sus privilegios a administrador sin conocer una contraseña de administrador o sin que un administrador le otorgara derechos administrativos, cualquier usuario podría hacer cualquier cosa en cualquier momento, lo que es casi equivalente a ejecutar todas las cuentas de usuario como administradores todo el tiempo.
Ahora necesita algún script adicional, GUI web, lo que quiera, que le permita al usuario elegir entre el software en el servidor, probablemente verificar si el usuario tiene permisos para instalar el software y probablemente si la computadora del usuario cumple con los requisitos para el instalación (¿Hardware? ¿Espacio libre en disco?...) para tener éxito. Luego tendrás que almacenar esa información en una ubicación donde tu instalador en segundo plano pueda leerla. Una lista simple en el servidor será suficiente.
Finalmente, el script en segundo plano accederá periódicamente a esa lista y activará los instaladores.
Hecho.
Déjame decirte que lo que tienes en mente es programar una instalación de distribución de software automatizada. Hay herramientas comerciales disponibles que lo hacen, incluso una de ellas está integrada en Windows Active Directory y es gratuita. No sé cuántos años y dinero han invertido los desarrolladores en cada uno, para llegar a un punto en el que sus instaladores dominan muchas (¿la mayoría? ¿todas? ¿algunas?) de las muchas variantes de instalación utilizadas por varios programas de Windows. Al principio pueden parecer costosos por cliente, pero dudo que pueda superar cualquier solución comercial en términos de costo, confiabilidad, características, documentación y soporte comunitario con cualquier cosa que pueda crear en Powershell.
Respuesta2
Esto suena como un trabajo para la implementación del software de políticas de grupo. Esto soluciona el problema de los usuarios que carecen de derechos administrativos.
Porpublicaciónun paquete, pondrá el software a disposición de los usuarios en el Panel de control (en lugar de simplemente instalarlo automáticamente).
Desde la perspectiva de los usuarios finales:
Configuración
- Ver la guía de Microsoftaquí(artículo antiguo pero aún relevante). Siga el "Publicar un paquete" en lugar de "Asignar un paquete".
- Delegue los permisos apropiados para el GPO y el recurso compartido del "repositorio de software". Podrías crear un grupo de seguridad específicamente para esto llamadoAdministradores de software opcionales, por ejemplo, y agrega a tu jefe como miembro.
Asegúrese de que la ACE se aplique aEste objeto y todos los objetos descendientes.:
ConcederModificarPermisos NTFS en la carpeta Software para administradores de software opcionales:
- Instale la consola de administración de políticas de grupo en la máquina de su jefe ejecutando este comando de PowerShell elevado:
Add-WindowsCapability -Nombre "Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0" -En línea
De aquí en adelante, su jefe está listo para comenzar a copiar los instaladores al recurso compartido de software y modificar el GPO de implementación del software en consecuencia (aunque inicialmente necesitará orientación). ¡Y todo ello sin privilegios de administrador de dominio o máquina local y una experiencia (razonablemente) sencilla para todos los involucrados!
Incluso podría facilitar las cosas a los usuarios finales y a su jefe al ofrecer accesos directos directamente a donde necesitan ir. La instalación de la consola de administración de políticas de grupo también podría automatizarse si es necesario ampliarla a más usuarios administrativos o si su jefe deambula por varias máquinas.