Les droits des «utilisateurs» locaux sont-ils suffisants ou les développeurs ont-ils besoin d'un administrateur local ou d'un utilisateur expérimenté lors du codage?

Nous avons une équipe de développement offshore qui a la mauvaise habitude d'installer des logiciels non-sens sur les bureaux des entreprises (ce qui n'a rien à voir avec leur fonction) et envisage donc de supprimer leurs droits d'administrateur local.

L'administrateur local ou l'utilisateur avec pouvoir local est-il une exigence avec VS2010? Comment courez-vous sans droits élevés? Quels problèmes rencontrerez-vous?

Un programmeur doit travailler en tant qu'utilisateur limité avec un accès administrateur. Autrement dit, le programmeur doit être l'administrateur de la machine, mais pendant qu'il travaille, il doit toujours utiliser un compte utilisateur limité.

Si vous avez besoin de droits élevés pour travailler, pour autre chose que l'installation de logiciels, vous faites quelque chose de très mal. Pire, si vous travaillez en tant qu'utilisateur avancé ou désactivez les invites UAC ou autres, vous ignorez les problèmes qui affecteront les utilisateurs finaux de votre logiciel, les forçant à s'exécuter avec les mêmes privilèges que vous. C'est faux.

C'est vrai, quel que soit le système d'exploitation sur lequel vous vous trouvez. Bien que Windows semble être le seul où il se présente.

Clarifier:

Quand je dis que le développeur doit être un utilisateur limité, je veux dire qu'il doit avoir les droits d'administrateur complets sur la machine, mais quand il teste son code, cela doit être fait dans un environnement à utilisateur limité. Par exemple, le développeur peut utiliser la machine en tant qu'utilisateur administrateur, mais exécute tous les tests sur une machine virtuelle ou dans un compte utilisateur limité. Sous Linux, cela signifie simplement que le développeur a sudoaccès; sous Windows, cela peut signifier un compte de niveau administrateur avec UAC et d'autres fonctionnalités de sécurité entièrement activées.

Il s'agit d'un problème politique ou de gestion, pas technique.

Envisagez de créer et de communiquer une règle «nous ne voulons pas que vous installiez un logiciel qui n'est pas pertinent pour votre fonction», afin que le patron puisse suivre en conséquence.

Pour faciliter cela, l'administrateur système peut demander à chaque machine une liste des programmes installés. Si vous le faites régulièrement, vous pouvez écrire un petit programme pour montrer ce qui a été installé, afin d'avoir un aperçu rapide.

Cela dit, à moins que ces programmes ne soient illégaux ou moralement inacceptables, pourquoi est-ce un problème en premier lieu?

Cela dépend de ce que vous attendez d'eux qu'ils se développent indépendamment.

Certaines choses comme la configuration IIS, le débogage à distance, modifier l'accès au GAC, la capacité d'exécuter votre propre MSI serait certainement affectée. Si ce sont des choses que vous attendez des ressources externalisées de façon indépendante, je ne tenterais pas sans beaucoup de tests.

Si vos sous-traitants travaillent sur une application de bureau, ils peuvent déboguer localement, vous vous en sortirez probablement avec quelques problèmes.

En supposant qu'ils utilisent le contrôle de source, vous pouvez toujours planifier une nouvelle image périodique des machines.

La plupart des endroits où j'ai travaillé s'occupent en grande partie du premier cas et s'attendent à une grande indépendance, donc tous les développeurs sont des administrateurs locaux et la politique de l'entreprise autorise des mesures disciplinaires si vous installez un logiciel non approuvé sur une machine et causez des problèmes.

J'ai besoin des droits d'administrateur pour lancer Apache sur le port 80 de mon MacBook de développement. En dehors de cela, il n'y a aucune raison que je ne puisse pas être sur une machine verrouillée sans droits d'administrateur. Et je pourrais utiliser un port non standard, si j'en avais vraiment besoin. Du point de vue des ressources d'entreprise, il est logique que les développeurs ne soient pas des utilisateurs privilégiés de leurs machines.

Cependant, le verrouillage d'un développeur sur sa machine doit s'accompagner d'une équipe d'administration réactive et volontaire. Si je ne peux pas installer des trucs moi-même, j'ai besoin de quelqu'un qui peut le faire pour moi. Si l'entreprise n'est pas disposée à s'engager dans ce sens, elle doit donner aux développeurs la pleine capacité de leur boîte.

Je préfère ce dernier, évidemment, mais je peux voir la sagesse du premier.

J'exécute VS 2010 pas en tant qu'administrateur la grande majorité du temps. Mais si vous souhaitez ajouter ou supprimer un service, configurer IIS ou bricoler dans le registre, vous aurez besoin des droits d'administrateur. Certains outils de profilage vous invitent également à relancer VS en tant qu'administrateur. Je pense donc que donner à vos personnes offshore des comptes qui ne disposent pas de pouvoirs d'administrateur les empêchera de faire certaines (peut-être petites) parties de leur travail.

De plus, avec l'essor de l'UAC, de plus en plus d'applications peuvent désormais s'installer sans pouvoirs d'administrateur. Ils ne mettent rien dans HKLM, ils ne touchent à rien sous System32, ils placent l'exe quelque part dans le dossier users \ whoever, ce qui les rend beaucoup plus faciles à supprimer mais peut ne pas répondre à votre point d'origine qu'ils installent " logiciel absurde "par lequel je suppose que vous entendez des jeux, des lecteurs de musique, etc.

Si vous voulez vraiment empêcher les installations locales, le meilleur pari est peut-être la vieille vision du "réseau est l'ordinateur" des premiers jours de Java. Tout le monde travaille à partir d'un système de contrôle de version et doit s'enregistrer ou se ranger chaque nuit avant de rentrer chez lui. Le courrier électronique vit dans le cloud et non sur la machine de développement. Etc. Ensuite, quand vous le souhaitez, vous pouvez recréer l'image de leurs machines de développement (encore plus facile si elles sont virtuelles) et ceux qui n'avaient rien de plus installé ne le remarqueront même pas. Un peu comme nettoyer le frigo du bureau pendant le week-end.

Mais attention, je ne travaillerais pas dans cet environnement. J'installe des utilitaires et des aides, et je joue à des jeux de temps en temps, et je ne prendrais pas gentiment quelqu'un qui a essayé d'empêcher non plus. Je suis productif comme l'enfer. Si certains de vos développeurs ne sont pas productifs, supprimer leurs installations locales ne les rendra pas plus productifs ou dédiés. Résolvez ce problème à la racine et cela ne vous dérangera pas qu'ils soient des administrateurs.

Je suppose que la suppression des droits d'administrateur des développeurs devrait aller de pair avec l'attribution d'un des administrateurs système pour installer le logiciel pour l'équipe. Si vous n'avez pas tous les deux des droits d'administrateur et que vous ne pouvez pas demander à l'administrateur d'installer des trucs pour vous, vous êtes juste sans main devant les défis auxquels vous êtes confronté. C'est comme si vous enfermiez votre équipe offsore en prison.

Cela dépend de la raison pour laquelle vous écrivez un logiciel.

Si votre logiciel n'a pas besoin de s'immiscer dans votre système, il n'y a pas besoin de pouvoirs d'administrateur.

Une meilleure solution: à des fins d'installation / de test, on peut vouloir utiliser des machines virtuelles ou des ordinateurs de laboratoire de test.

J'ai vu deux approches à cela. L'une consistait à faire travailler tout le monde à partir d'ordinateurs portables, qu'ils devaient remettre aux administrateurs lorsqu'ils rentraient chez eux. Une fois que l'administrateur l'aura, il collera un CD qui réimaginera la machine. Une fois qu'il a été réimagé, il est allé sur une étagère, où il serait disponible pour la prochaine personne qui en aurait besoin. Assurez-vous simplement que toutes les machines sont identiques, afin de ne pas vous retrouver avec des gens qui les parcourent tous à la recherche d'une "bonne" machine.

L'autre chose que j'ai vue, c'est que tout le monde démarre à partir d'un serveur Citrix. Les machines n'ont aucun stockage local, elles chargent simplement une image standard à partir du réseau et s'exécutent à partir de cela. Cela fonctionne mieux si vous avez différents "types" d'utilisateurs qui nécessitent des configurations différentes (par exemple, les développeurs d'interface utilisateur ont une image avec Silverlight, les développeurs WCF ont IIS et SQL Server, etc.)

MAIS, avec tout cela dit, je pense que Thorbjorn [sic] a mis le doigt sur la tête: c'est un problème de gestion, et ne sera probablement pas traité de manière adéquate avec une solution technique.