¿Son suficientes los derechos locales del "Usuario" o los desarrolladores necesitan un Administrador local o un Usuario avanzado al codificar?

Tenemos un equipo de desarrollo offshore que tiene la mala costumbre de instalar software sin sentido en los escritorios corporativos (que no tiene nada que ver con su función de trabajo) y, por lo tanto, está considerando eliminar sus derechos de administrador local.

¿Es el administrador local o el usuario avanzado local un requisito con VS2010? ¿Cómo se ejecuta sin derechos elevados? ¿Con qué problemas te encontrarás?

Un programador debe funcionar como un usuario limitado con acceso de administrador. Es decir, el programador debe ser el administrador de la máquina, pero mientras trabaja, siempre debe usar una cuenta de usuario limitada.

Si necesita derechos elevados para trabajar, para cualquier cosa que no sea instalar software, está haciendo algo muy malo. Peor aún, si trabaja como un usuario avanzado o deshabilita las indicaciones de UAC o similares, está ignorando los problemas que afectarán a los usuarios finales de su software, obligándolos a ejecutar con los mismos privilegios que usted. Esto está mal.

Esto es cierto, independientemente del sistema operativo en el que se encuentre. Aunque Windows parece ser el único donde aparece.

Para aclarar:

Cuando digo que el desarrollador debe ser un usuario limitado, quiero decir que deben tener derechos de administrador completos para la máquina, pero cuando prueban su código, deben hacerlo en un entorno de usuario limitado. Por ejemplo, el desarrollador podría estar operando la máquina como un usuario con capacidad de administrador, pero ejecuta todas las pruebas en una máquina virtual o en una cuenta de usuario limitada. En Linux, esto significa simplemente que el desarrollador tiene sudoacceso; en Windows, esto puede significar una cuenta de nivel de administrador con UAC y otras características de seguridad totalmente habilitadas.

Este es un problema político o de gestión, no técnico.

Considere crear y comunicar una regla de "no queremos que instale software que no sea relevante para su función de trabajo", para que el jefe pueda hacer el seguimiento correspondiente.

Para ayudar en esto, el administrador del sistema puede solicitar a cada máquina una lista de programas instalados. Si hace esto regularmente, puede escribir un pequeño programa para mostrar lo que se ha instalado, para que pueda obtener una descripción general rápida.

Dicho esto, a menos que dichos programas sean ilegales o moralmente inaceptables, ¿por qué es esto un problema en primer lugar?

Depende de lo que espere que se desarrollen independientemente.

Algunas cosas como la configuración de IIS, la depuración remota, modificar el acceso al GAC, la capacidad de ejecutar su propio MSI definitivamente se vería afectada. Si estas son cosas que espera que los recursos subcontratados hagan de forma independiente, no lo intentaría sin muchas pruebas.

Si sus empleados externos están trabajando en una aplicación de escritorio que pueden depurar localmente, es probable que se salga con la suya con pocos problemas.

Suponiendo que estén utilizando el control de origen, siempre puede programar una nueva imagen periódica de las máquinas.

La mayoría de los lugares en los que he trabajado hacen gran parte del primer caso, y esperan una gran independencia, por lo que todos los desarrolladores son administradores locales y la política corporativa permite medidas disciplinarias si instala software no aprobado en cualquier máquina y causa problemas.

Necesito derechos de administrador para iniciar Apache en el puerto 80 en mi MacBook de desarrollo. Aparte de eso, no hay razón para que no pueda estar en una máquina bloqueada sin derechos de administrador. Y podría usar un puerto no estándar, si realmente lo necesitara. Desde el punto de vista de los recursos empresariales, tiene sentido que los desarrolladores no sean usuarios privilegiados de sus máquinas.

Sin embargo, bloquear a un desarrollador en su máquina debe venir junto con un equipo de administración receptivo y receptivo. Si no puedo instalar cosas yo mismo, necesito a alguien que pueda hacerlo por mí chop chop, y sin pasar por tres rondas de documentos de aprobación al respecto. Si la empresa no está dispuesta a comprometerse con eso, entonces deberían darles a los desarrolladores el funcionamiento completo de su boxen.

Prefiero lo último, obviamente, pero puedo ver la sabiduría de lo primero.

Ejecuto VS 2010 no como administrador la gran mayoría de las veces. Pero si desea agregar o eliminar un servicio, configurar IIS o modificar el registro, necesitará derechos de administrador. Además, algunas de las herramientas de creación de perfiles lo instan a relanzar VS como administrador. Por lo tanto, creo que dar a sus cuentas de personas en el extranjero que no tienen poderes administrativos les impedirá hacer algunas (quizás pequeñas) partes de sus trabajos.

Además, con el auge de UAC, ahora se pueden instalar más y más aplicaciones sin poderes de administración. No colocan cosas en HKLM, no tocan nada en System32, colocan el archivo exe en algún lugar debajo de la carpeta de usuarios \ quien sea, y esto hace que sea mucho más fácil de eliminar, pero puede que no aborde el punto original que están instalando " software sin sentido ", por lo que supongo que te refieres a juegos, reproductores de música, etc.

Si realmente desea evitar las instalaciones locales, tal vez la mejor opción sea la vieja visión de "la red es la computadora" desde los primeros días de Java. Todos trabajan desde un sistema de control de versiones y deben registrarse o dejar de lado cada noche antes de irse a casa. El correo electrónico vive en la nube, no en la máquina de desarrollo. Etc. Luego, cuando lo desee, puede volver a crear una imagen de sus máquinas de desarrollo (incluso más fácil si son virtuales) y aquellos que no tenían nada extra instalado ni siquiera lo notarán. Es como limpiar el refrigerador de la oficina durante el fin de semana.

Pero ten cuidado: no trabajaría en ese entorno. Instalo utilidades y ayudantes, y juego juegos ocasionalmente, y tampoco agradecería a alguien que intentara evitarlo. Soy productivo como el infierno. Si algunos de sus desarrolladores no son productivos, eliminar sus instalaciones locales no los hará más productivos o dedicados. Aborde ese problema desde la raíz y no le importará que sean administradores.

Supongo que eliminar los derechos de administrador de los desarrolladores debería unirse a la asignación de uno de los administradores del sistema para instalar el software para el equipo. Si ambos no tienen derechos de administrador y no pueden pedirle al administrador que instale cosas por usted, simplemente no tiene mano frente a los desafíos que enfrenta. Es como si encerraras a tu equipo en la cárcel.

Depende de para qué esté escribiendo el software.

Si su software no necesita entrometerse en su sistema, no hay necesidad de poderes de administrador.

Una mejor solución: para fines de instalación / prueba, es posible que desee utilizar máquinas virtuales o computadoras de laboratorio de prueba.

He visto dos enfoques para esto. Una era hacer que todos trabajaran desde computadoras portátiles, que tenían que entregar a los administradores cuando regresaban a casa. Una vez que el administrador lo tuviera, pegarían en un CD que volvería a crear una imagen de la máquina. Una vez que fue reimpreso, se colocó en un estante, donde estaría disponible para la siguiente persona que lo necesitara. Solo asegúrate de que todas las máquinas sean idénticas, de modo que no termines con gente mirándolas en busca de una "buena".

La otra cosa que he visto es hacer que todos arranquen desde un servidor Citrix. Las máquinas no tienen almacenamiento local, solo cargan una imagen estándar de la red y se ejecutan desde allí. Esto funciona mejor si tiene diferentes "tipos" de usuarios que requieren diferentes configuraciones (por ejemplo, los desarrolladores de IU tienen una imagen con Silverlight, los desarrolladores de WCF tienen IIS y SQL Server, etc.)

PERO, con todo lo dicho, creo que Thorbjorn [sic] dio en el clavo: este es un problema de gestión, y probablemente no se abordará adecuadamente con una solución técnica.