Para los que no tenemos más remedio que administrar redes windows, esta utilidad tiene muy buen aspecto para evitar tener a mucha gente trabajando con privilegios de administrador y que no se organicen motines en los departamentos de desarrollo. sudowin se comporta exactamente igual que el sudo de unix y preserva que las acciones se ejecuten bajo el perfil del usuario pero 'escalando' privilegios y solicitando una contraseña de administrador previa a la ejecución.
Comentarios
En Windows de serie tienes el runas desde la línea de órdenes, que es diferente que sudo pero hace lo mismo, y la entrada "Ejecutar como..." del menú contextual.
Un script interesantes para quienes trabajan en windows como recomienda microsoft (con cuentas limitadas) es MakeMeAdmin. Permite tener permisos de administrador sin tener que cambiar de usuario y de grupo, con el mismo usuario limitado que estemos usando.
http://blogs.msdn.com/aaron_margosis/archive/2004/07/24/193721.aspx
Leo pero la descripción está equivocada: con runas puedes escalar privilegios con el mismo "truco" que usa MakeMeAdmin, que lo hace sólo tirando de runas.
Una lista de sudoers está también implementada de serie con las políticas de seguridad y directivas de grupo en Windows: puedes limitar la ejecución de un programa por usuario, grupo y con los privilegios que quieras.
Las únicas ventajas que le veo al sudowin son que si sólo conoces sudo de Unix no tienes que aprender una cosa nueva y que parece que utiliza archivos de texto para configurarlo.
#4 Distintas son pero hacen (o pueden hacer) lo mismo. Usando runas puedes incluir tu usuario en el grupo que quieras de forma temporal, usando el mismo truco que usa MakeMeAdmin para hacer parte de Administradores. De todas formas, que conste que he meneado
Sudowin está bien: la interfaz gráfica es maja, es más cómodo que andar con consolas y permite preparar un entorno fácil más seguro en un equipo local (cuenta sin privilegios en el grupo sudoers y en sudoers.xml un allowAllCommands="true") pero no creo que haga nada nuevo.
Sobre tu aventura con Visual Studio .NET, no quiero insultar pero una pregunta estúpida: en las directivas locales, ¿qué grupos tenían permitida "Depurar programas"?, ¿sólo los Administradores?... En caso negativo yo hubiera escrito un wrapper tirando de CreateProcessAsUser
Para #5, si por ruindows te refieres a Windows... Sobre eso que dices de la escalada de privilegios, la falta de permisos del sistema de archivos y la falsa separación de usuarios, ¿tienes algún argumento?, ¿te lo crees?, ¿hablas por hablar?
Juas, depurar en remoto con el VisualStudio, menuda aventura...
Es algo que no me cabe en la cabeza. Los sistemas operativos son de MS (XP y 2003), el entorno de programación es de MS (VS03 y VS05) y el servidor web también (era un webservice sobre IIS6)... pues había que hacer unos malabares de permisos y usuarios increíbles para poder depurar desde remoto. Es más ni el servicio técnico oficial de MS sabía muy bien como hacerlo correctamente...
No, no hace lo mismo jorginus. Leete el texto introductorio de esta utilidad. Realmente imita (salvando las distancias) al sudo de UNIX incluyendo el fichero sudoers donde editas a los usuarios a los que les dejarás usar el sudo y sobre los comandos que permitirás esta actividad. Es mucho más potente y versatil que el runas de windows y que este script de microsoft que envías.
Yo sigo pensando que son cosas distintas jorginus. Con runas no usas el 'profile' del usuario en curso sino del que suplantas, Con Makemeadmin si usas tu profile pero lo que hace es abrirte un shell con privilegios de administración local y no te limita los programas que puedes ejecutar. Por otro lado, con directivas y políticas limitas lo que quieres que un usuario pueda ejecutar pero a veces no se trata de poder o no poder ejecutarlo sino de que tengas privilegios de administración mientras lo ejecutas. Nosotros tuvimos un problema hace años con las primeras versiones del Visual Studio .NET: para ejecutar las funciones de Debug necesitabas que el usuario que ejecutara el Visual Studio tuviera privilegios de administración local sobre la máquina donde estaba el IIS. Pusimos una consulta a microsoft (pagada aunque no nos la cobraron porque no pudieron resolverla) y nos dijeron que ajo y agua: que le dieramos administración local a todos los desarrolladores o que no depuraran (Por cierto, ignoro si ese problema está ya resuelto o siguen arrastrándolo...)
No discutais, si con la pantomima de sistema de usuarios que tiene ruindows no existe separacion real entre usuarios y se pueden escalar permisos facilmente. Hasta que no sean capaces de sacar un sistema de ficheros con permisos de usuario reales el sistema de usuarios de ruindows es puro vaporware.
Yo también uso RunAs
http://blog.elgura.com/index.php?p=209&more=1&c=1&tb=1&pb=1
#8 Ya no me acuerdo que fue exactamente lo que se hizo en aquel caso jorginus. Te hablo de algo que ocurrió hace ya más de cuatro o cinco años. Lo que si te puedo decir es que el resultado fue ese: Microsoft nos dijo que o le dábamos privilegios de administración local sobre la máquina donde estaba el IIS a los desarrolladores o que se olvidaran de depurar. Si metimos al grupo de desarrolladores en las directivas locales de depuración de programas y en un grupo especial de usuarios llamado Debugger Users que crea (o creaba, ya te digo que no se si después de tantos años la estrategia de la herramienta ha cambiado) Visual Studio
En cuanto a las herramientas, estamos de acuerdo. Seguro que internamente hacen lo mismo y para tu consóla o tú casa te da igual una que otra, pero para desplegarlo como solución genérica en una empresa yo creo que sudowin es mucho más cómodo y fácil de mantener que ninguna de las otras dos alternativas. Es mi opinión, al menos.
Siempre podremos utilizar también "runas".