Le service informatique aurait-il besoin d'un mot de passe de domaine d'utilisateur?

Y a-t-il quelque chose qu'un administrateur de domaine Windows pourrait devoir faire lors de la configuration d'un poste de travail pour un nouvel utilisateur qui ne peut absolument pas être fait sans le mot de passe du compte de domaine de l'utilisateur? Pour éviter de demander aux utilisateurs leurs mots de passe, l'administrateur pourrait, en théorie, changer le mot de passe, se connecter en tant qu'utilisateur et faire tout ce qu'il voulait, mais cela leur donnerait-il réellement des autorisations supplémentaires qu'ils n'ont pas déjà en vertu d'être un administrateur de domaine?

METTRE À JOUR:

Jusqu'à présent, les réponses se référaient à «l'optimisation» ou à la modification du profil de l'utilisateur. Cependant, il y a cet article de Microsoft sur la modification du profil par défaut qui est appliqué aux utilisateurs lors de leur première connexion et ces instructions pour modifier les paramètres de registre Windows d'un autre utilisateur à tout moment. Qu'est-ce qu'un administrateur changerait lors de sa connexion en tant qu'utilisateur que l'administrateur ne pourrait pas modifier à l'aide de ces techniques ou d'autres techniques disponibles n'impliquant pas la connexion en tant qu'utilisateur? Le simple fait de se connecter en tant qu'utilisateur n'est pas une raison pour demander ou modifier le mot de passe de l'utilisateur. Je cherche une raison pratique de le faire.

Il n'est ni acceptable ni nécessaire qu'un administrateur demande le mot de passe d'un utilisateur.

Dans les circonstances où il peut être nécessaire qu'un administrateur se connecte en tant qu'utilisateur (et je ne pense pas que de telles circonstances existent), l'utilisateur doit se connecter et superviser les activités de l'administrateur.

La raison en est la responsabilité. Il est de la responsabilité de chaque utilisateur de s'assurer que son mot de passe est sécurisé. Si une activité malveillante remontait aux informations d'identification d'un utilisateur, cet utilisateur pourrait être tenu responsable. Par conséquent, ils doivent s'assurer que leurs informations d'identification restent sécurisées.

Il est également de la responsabilité de l'organisation de veiller à ce que cela soit non seulement adopté, mais appliqué. Il y a eu un cas juridique où quelqu'un dans une organisation a envoyé un e-mail malveillant en utilisant la boîte aux lettres de quelqu'un d'autre. Le propriétaire de la boîte aux lettres a finalement été licencié. Bien qu'ils aient fait valoir qu'ils avaient donné leur mot de passe à quelqu'un d'autre, l'entreprise a insisté sur le fait qu'il était de leur responsabilité de maintenir l'intégrité de leurs informations d'identification, et qu'ils étaient donc responsables, comme le dictait la politique informatique de leur entreprise. Cela a ensuite été annulé par un tribunal lorsque cet utilisateur a prouvé qu'il existait une culture de partage de mots de passe endémique au sein de l'organisation. Le tribunal a statué que si l'entreprise ne pouvait pas être considérée comme appliquant activement sa politique informatique, elle ne pouvait pas compter sur elle pour rendre des comptes dans ces circonstances.

Cela dit, il y a clairement un fossé entre la théorie et la pratique. J'ai passé un contrat pour une grande entreprise multinationale qui fournit, entre autres, des services de conseil informatique, et dans le cadre de la procédure documentée pour une mise à niveau SOE, on nous a demandé de demander le mot de passe de l'utilisateur final.

Personnellement, j'adopte une approche dure à ce sujet. Je ne pense pas qu'il soit nécessaire de demander des mots de passe (ou de les redéfinir pour accéder au compte d'un utilisateur). S'il y a une charge de travail considérablement accrue pour contourner cela, alors tant pis. Ce n'est pas une excuse pour compromettre la sécurité. Je suppose que je suis juste chanceux de ne pas être un manager, et donc je n'ai pas à assumer la responsabilité de ces décisions lorsque quelqu'un me le demande.

Soyons clairs: si vous êtes administrateur de domaine, vous pouvez installer un logiciel - un pilote de périphérique me vient à l'esprit - qui peut littéralement faire n'importe quoi. Cependant, il s'agit de divers degrés d'impraticabilité, allant de "Quelle est la clé de registre pour l'arrière-plan du bureau, encore?" jusqu'à "Et puis nous accrochons à l'appel de lecture de fichier à l'intérieur de la couche de profil crypté afin de faire croire à Firefox qu'ils ont désactivé les cookies de doubleclick.net".

Vous demandez un absolu, et je pense que ce n'est pas la bonne façon de voir les choses, parce que la réponse va être "Vous n'avez jamais vraiment besoin du mot de passe de l'utilisateur ", ce qui est très trompeur. La réalité est que tant que Microsoft ne fournira pas (ou que vous n'installez pas de logiciel tiers pour permettre) une capacité comme * NIX's su/ sudo, vous ne pourrez jamais imiter parfaitement le compte d'un utilisateur à toutes fins tout en conservant un semblant de raison, sans nécessiter occasionnellement utilisation – note je n'ai pas dit "divulgation!" - de leur mot de passe.

Beaucoup d'entre nous ont travaillé dans des environnements où la divulgation des mots de passe était requise pour diverses raisons. J'irai même jusqu'à dire que nous considérons tous que c'est une mauvaise idée. Si cela doit être fait, l'utilisateur final doit y consentir, ne pas être contraint.

À l'époque, comme en 1998, mon service informatique demandait le mot de passe d'un utilisateur lorsque nous faisions un remplacement de PC afin que nous puissions le configurer exactement comme il avait l'ancien. Jusqu'aux emplacements des icônes. Comme nous étions dans un environnement Novell NetWare sans domaine WinNT correspondant, la modification de leur mot de passe réseau n'a pas changé leur mot de passe local, nous avions donc besoin de ce mot de passe si nous voulions fournir ce niveau de service transparent.

C'était il y a 13 ans. Vous avez spécifiquement posé des questions sur les domaines Windows. Au poste que je venais de quitter, une grande université, c'était à l'utilisateur final de divulguer ou non un mot de passe ou d'être là pour tout travail en cours. En d'autres termes, l'utilisateur final y a opté plutôt que d'être forcé par l'informatique. Certains types de cadres très occupés en haut de l'organigramme avaient généralement leur assistant d'administration connecté pour eux, il était donc facile pour les informaticiens de se connecter (le consentement avait déjà été délégué).

Sous Windows, la seule façon de régler manuellement le profil d'un utilisateur est de se connecter en tant qu'utilisateur. Si ce profil a besoin d'être ajusté manuellement pour une raison quelconque (il reste une mauvaise désinstallation qui gêne une réinstallation ou d'autres choses étranges), l'informaticien devra se connecter en tant qu'utilisateur. Cela peut être fait en forçant un changement de mot de passe administratif, en demandant à l'utilisateur de divulguer son mot de passe, ou en demandant à l'utilisateur de connecter le technicien informatique en tant que lui-même et de laisser le technicien informatique travailler.

Certaines applications pendant l'installation nécessitent la possibilité d'apporter des modifications ou de référencer le profil de l'utilisateur (c'est-à-dire les applications CRM qui s'intègrent avec Outlook) en utilisant des variables d'environnement comme% userprofile%, en modifiant HK_CURRENT_USER, etc.

Bien que vous puissiez certainement "désosser" une installation avec des outils comme procmon, puis modifier manuellement le profil de l'utilisateur, le registre, etc. après coup, cela est très inefficace, peu pratique et sujet aux erreurs.

Absolument pas à 100%. Tout ce qui doit être fait avec un autre compte d'utilisateurs doit être fait en réinitialisant le mot de passe des utilisateurs, en se connectant, puis en demandant à l'utilisateur d'appeler le service d'assistance ou en restituant le mot de passe à quelque chose aux utilisateurs et en définissant le compte pour forcer le mot de passe à changer lors de la prochaine connexion. Tout en admettant que j'ai travaillé dans des environnements assez grands et / ou sécurisés, la divulgation de votre mot de passe à quiconque était généralement un motif de résiliation (et cela devrait être le cas dans la plupart des situations)

La plupart de ces messages semblent assez anciens, mais j'espère que certaines personnes bien informées sont toujours actives sur le fil, car cela semble continuer à être un sujet d'actualité.

On peut certainement affirmer que vous ne devriez jamais avoir à demander un mot de passe. Je préférerais de loin dire à mes utilisateurs "ne jamais partager" ... et oui, la configuration peut dans la plupart des cas être gérée par un administrateur pour un utilisateur. Mais le dépannage est une autre affaire.

Nous soutenons un programme individuel avec 2600 étudiants et 500 employés. Nous traitons quotidiennement des problèmes logiciels "bizarres". Il est assez fréquent que nous devions rencontrer le problème en tant qu'utilisateur afin de résoudre le problème (ou déterminer avec une certaine confiance qu'un rechargement va être nécessaire). Absolument, nous essayons de le faire avec l'utilisateur présent - mais ce n'est pas toujours pratique; ils ont un calendrier à respecter.

Et les cartes à puce? Existe-t-il une possibilité dans un environnement AD 2010/2012 qu'une carte à puce puisse être associée (temporairement) à un compte de domaine? Cela permettrait d'accéder au compte de l'utilisateur en réalité, sans exposer spécifiquement son mot de passe. La carte pourrait alors être désactivée une fois le dépannage terminé. Les techniciens pouvaient utiliser le compte, mais les cartes pouvaient être bien surveillées.

Nous utilisons des lecteurs d'empreintes digitales depuis des années, mais le processus pour configurer cela pour une technologie spécifique, puis effacer cette impression n'est tout simplement pas possible. Je ne sais pas à quel point le processus serait complexe pour "autoriser" puis "désactiver" une carte à puce pour un utilisateur particulier, mais il semble que cela pourrait être un compromis décent.

Oui: tout ce qui doit être fait pour leur profil. Lorsque cela se produit, vous devez soit connaître leur mot de passe, soit le définir, comme vous l'avez dit. Ensuite, ils peuvent le changer lorsque vous avez terminé.

Si vous vous connectez en tant qu'utilisateur, vous ne leur accordez pas d'autorisations supplémentaires. Vous vous connectez avec eux avec leurs autorisations.