Comment verrouiller les postes de travail tout en prenant en charge les applications héritées qui nécessitent des droits d'administrateur local ?

Je sais que nous luttons tous pour trouver un équilibre entre le verrouillage des postes de travail de nos utilisateurs et leur utilisation. J’ai un vrai problème avec un client dont les utilisateurs installent constamment des barres d’outils, des jeux, des logiciels malveillants, etc. Je souhaite vraiment pouvoir leur retirer leurs droits d’administrateur local (et la direction le souhaite aussi). Le problème est qu’ils dépendent d’une poignée d’applications mal écrites qui nécessitent des droits d’administrateur local pour fonctionner correctement. Avant que quelqu’un ne le suggère, il n’est pas possible de se débarrasser de ces applications.

Je sais que je peux créer des raccourcis personnalisés vers ces applications en utilisant la commande runas et en enregistrant les identifiants d’administrateur local. Le problème avec cette solution est :

  • Je dois fournir manuellement les identifiants d’administrateur local pour chaque utilisateur.

  • Certains programmes dépendent de données dans le profil utilisateur local et ne fonctionnent pas correctement s’ils sont “trompés” en pensant qu’ils s’exécutent sous le profil NomOrdinateur\Administrateur.

Ce que j’aimerais, c’est installer une application ou appliquer une stratégie de groupe qui me permette de spécifier les applications qui devraient être autorisées à élever les permissions du profil local. Existe-t-il une telle solution ?

Comment tout le monde gère-t-il le verrouillage des postes de travail tout en prenant en charge les logiciels hérités/mal écrits ?


Source : [Server Fault](Explorateur de processus - Sysinternals | Microsoft Learn](Moniteur de processus - Sysinternals | Microsoft Learn)

Il est rare qu’un logiciel ait réellement besoin de droits administrateur ; il écrit plutôt dans une zone du registre ou du disque dur à laquelle les administrateurs ont normalement accès et les autres utilisateurs non. Cela peut sembler une nuance, mais c’est fondamental pour résoudre ce problème.

Vous pouvez utiliser les outils Process Monitor modification : merci grawity de Microsoft pour surveiller ce que les applications font, et attribuer des droits sur ces zones aux utilisateurs. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Vous pouvez ensuite utiliser les stratégies de groupe pour appliquer des ACL de sécurité à la fois sur les fichiers et dossiers et sur des parties du registre. Une cause courante de ce problème est le programme qui écrit dans son dossier d’installation dans c:\program files, ou dans ses paramètres globaux sur le registre machine sous HKey Local Machine.