En l'absence d'outillage un peu sérieux, plutôt que de balancer des scripts dont tu pourras difficilement surveiller la bonne exécution tu peux utiliser ces identités dans les droits étendus d'une GPO (ou plus exactement les droits détaillés interdisant la connexion au poste : interdire session interactive, interdire session par le réseau, etc)
https://docs.microsoft.com/fr-fr/tr [...] l-accounts
S-1-5-113 : AUTORITÉ NT\Compte local => tous les comptes locaux sur la machine cible
S-1-5-114 : AUTORITÉ NT\Compte local et membre du groupe Administrateurs => comptes locaux sur la machine également membre du groupe Administrateurs (plus spécifique)
Donc si par exemple tu interdis à "AUTORITÉ NT\Compte local" de se connecter en interactif, via le réseau, en tant que service, en tant que batch et via RDP, et bah tu garantis qu'aucun des comptes locaux "pirate" ne pourra rien faire sur la machine. C'est l'arme nucléaire car tu bloques aussi l'admin local. A voir si c'est acceptable au vu des politiques support de ta boite, notamment vis à vis de la récup des fichiers d'un utilisateurs lors d'un crash / remplacement de poste.
C'est très puissant mais inconvénient c'est pas du tout granulaire (si il y a un process d'exception à gérer, il faut être créatif). En même temps tu n'est pas tellement censé avoir des comptes locaux qui se balladent sur les PC rattachés à un domaine.
---------------
The Lapin, reloaded | "Anything can happen in Formula One, and it usually does." -- Murray Walker