Os direitos locais de "Usuário" são suficientes ou os desenvolvedores precisam de Administrador Local ou Usuário Avançado durante a codificação?

Temos uma equipe de desenvolvimento offshore que tem o péssimo hábito de instalar software sem sentido em desktops corporativos (que não tem nada a ver com o cargo) e, portanto, está pensando em remover seus direitos de administrador local.

O administrador local ou o usuário avançado local é um requisito do VS2010? Como você corre sem direitos elevados? Quais problemas você enfrentará?

Um programador deve trabalhar como um usuário limitado com acesso de administrador. Ou seja, o programador deve ser o administrador da máquina, mas enquanto trabalha, ele sempre deve usar uma conta de usuário limitada.

Se você precisar de direitos elevados para trabalhar, por qualquer coisa, exceto pela instalação de software, estará fazendo algo muito errado. Pior, se você trabalha como usuário avançado ou desativa os prompts do UAC ou algo semelhante, está ignorando os problemas que afetarão os usuários finais do seu software, forçando-os a executar com os mesmos privilégios que você. Isto está errado.

Isso é verdade, independentemente do sistema operacional em que você está. Embora o Windows pareça ser o único onde ele aparece.

Esclarecer:

Quando digo que o desenvolvedor deve ser um usuário limitado, quero dizer que eles devem ter direitos administrativos totais à máquina, mas quando testam seu código, isso deve ser feito em um ambiente de usuário limitado. Por exemplo, o desenvolvedor pode estar operando a máquina como um usuário compatível com Admin, mas executa todos os testes em uma máquina virtual ou em uma conta de usuário limitada. No Linux, isso significa simplesmente que o desenvolvedor tem sudoacesso; no Windows, isso pode significar uma conta no nível de administrador com o UAC e outros recursos de segurança totalmente ativados.

Esta é uma questão política ou administrativa, não técnica.

Considere a possibilidade de criar e comunicar uma regra "não queremos que você instale software que não seja relevante para a sua função", para que o chefe possa acompanhar de acordo.

Para ajudar nisso, o administrador do sistema pode solicitar a cada máquina uma lista de programas instalados. Se você fizer isso regularmente, poderá escrever um pequeno programa para mostrar o que foi instalado, para obter uma visão geral rápida.

Dito isto, a menos que os programas sejam ilegais ou moralmente inaceitáveis, por que isso é um problema em primeiro lugar?

Depende do que você espera que eles se desenvolvam independentemente.

Algumas coisas, como configuração do IIS, depuração remota, modificam o acesso ao GAC, a capacidade de executar seu próprio MSI seria definitivamente afetada. Se essas são as coisas que você espera que os recursos terceirizados façam independentemente, eu não tentaria isso sem muitos testes.

Se seu pessoal terceirizado estiver trabalhando em um aplicativo de desktop, eles poderão depurar localmente, você provavelmente se safará com poucos problemas.

Supondo que eles estejam usando o controle de origem, você sempre pode agendar uma imagem periódica das máquinas.

Na maioria dos lugares em que trabalhei, faço parte do primeiro caso e espero alta independência, portanto todos os desenvolvedores são administradores locais e a política corporativa permite medidas disciplinares se você instalar software não aprovado em qualquer máquina e causar problemas.

Preciso de direitos de administrador para ativar o Apache na porta 80 no meu MacBook de desenvolvimento. Além disso, não há motivo para não estar em uma máquina bloqueada sem direitos de administrador. E eu poderia usar uma porta fora do padrão, se realmente precisasse. Do ponto de vista dos recursos da empresa, faz sentido que os desenvolvedores não sejam usuários privilegiados de suas máquinas.

No entanto, bloquear um desenvolvedor em sua máquina precisa vir junto com uma equipe de administradores responsiva e disposta. Se eu não consigo instalar as coisas sozinho, preciso de alguém que possa fazer isso por mim, chop chop, e sem me submeter a três rodadas de documentos de aprovação sobre isso. Se a empresa não estiver disposta a se comprometer com isso, eles devem dar aos desenvolvedores uma execução completa de suas caixas.

Prefiro o último, obviamente, mas posso ver a sabedoria do primeiro.

Eu corro o VS 2010 não como administrador na grande maioria das vezes. Mas se você deseja adicionar ou remover um serviço, configurar o IIS ou mexer no registro, precisará de direitos de administrador. Além disso, algumas das ferramentas de criação de perfil exigem que você reinicie o VS como administrador. Então, eu acho que dar contas a seus funcionários no exterior que não têm poderes administrativos os impedirá de fazer algumas (talvez pequenas) partes de seus trabalhos.

Além disso, com o surgimento do UAC, mais e mais aplicativos agora podem ser instalados sem poderes de administrador. Eles não colocam coisas no HKLM, não tocam em nada no System32, colocam o exe em algum lugar na pasta users \ whoever, e isso os torna muito mais fáceis de remover, mas pode não abordar o ponto original que eles estão instalando " software sem sentido ", com o qual suponho que você quer dizer jogos, tocadores de música etc.

Se você realmente deseja impedir instalações locais, talvez a melhor aposta seja a visão antiga de "a rede é o computador" desde os primeiros dias de Java. Todo mundo trabalha em um sistema de controle de versão e deve fazer o check-in ou arquivar todas as noites antes de voltar para casa. O email vive na nuvem, não na máquina de desenvolvimento. Etc. Então, quando você quiser, poderá recriar novamente suas máquinas de desenvolvimento (ainda mais fácil se forem virtuais) e aqueles que não tinham nada instalado extra nem perceberão. É como limpar a geladeira do escritório no fim de semana.

Mas esteja avisado - eu não trabalharia nesse ambiente. Eu instalo utilitários e ajudantes, e jogo ocasionalmente, e não seria gentil com alguém que tentasse impedir isso. Eu sou produtivo como o inferno. Se alguns de seus desenvolvedores não forem produtivos, remover as instalações locais não os tornará mais produtivos ou dedicados. Resolva esse problema na raiz e você não se importará que eles sejam administradores.

Suponho que a remoção dos direitos de administrador dos desenvolvedores seja associada à atribuição de um dos administradores de sistema para instalar o software para a equipe. Se vocês dois não têm direitos de administrador e não podem pedir ao administrador que instale coisas para você, você está sem mãos diante dos desafios que está enfrentando. É como se você prendesse seu time na prisão.

Depende do que você está escrevendo o software.

Se o seu software não precisar se intrometer no sistema, não haverá necessidade de poderes de administrador.

Uma solução melhor: para fins de instalação / teste, pode-se usar VMs ou computadores de laboratório de teste.

Eu já vi duas abordagens para isso. Uma era fazer com que todos trabalhassem nos laptops, que eles precisavam entregar aos administradores quando voltavam para casa. Uma vez que o administrador o tinha, eles colavam um CD que reinventava a imagem da máquina. Uma vez que foi recriada, foi colocada em uma prateleira, onde estaria disponível para a próxima pessoa que precisasse. Apenas certifique-se de que todas as máquinas sejam idênticas, para não acabar com as pessoas procurando por todas elas procurando uma "boa".

A outra coisa que vi é fazer com que todos inicializem a partir de um servidor Citrix. As máquinas não têm armazenamento local, apenas carregam uma imagem padrão da rede e executam a partir dela. Isso funciona melhor se você tiver "tipos" diferentes de usuários que exigem configurações diferentes (por exemplo, os desenvolvedores da interface do usuário têm uma imagem com o Silverlight, os desenvolvedores do WCF têm o IIS e o SQL Server, etc.)

MAS, com tudo o que foi dito, acho que Thorbjorn [sic] acertou na cabeça: esse é um problema de gerenciamento e provavelmente não será tratado adequadamente com uma solução técnica.