Comment exécuter CMD.exe sous le compte système local ?

Question

Je suis actuellement sous Vista et je voudrais effectuer manuellement les mêmes opérations que mon service Windows. Comme le service Windows est exécuté sous le compte système local, j'aimerais émuler ce même comportement. En gros, je voudrais exécuter CMD.EXE sous le compte système local.

J'ai trouvé des informations en ligne qui suggèrent de lancer le CMD.exe à l'aide de la commande AT du planificateur de tâches DOS, mais j'ai reçu un avertissement de Vista indiquant que "en raison d'améliorations de la sécurité, cette tâche s'exécutera à l'heure prévue mais pas de manière interactive". Voici un exemple de commande :

AT 12:00 /interactive cmd.exe

Une autre solution proposait de créer un service Windows secondaire via le Service Control (sc.exe) qui ne fait que lancer CMD.exe.

C:\sc create RunCMDAsLSA binpath= "cmd" type=own type=interact
C:\sc start RunCMDAsLSA

Dans ce cas, le service ne parvient pas à démarrer et le message d'erreur suivant s'affiche :

FAILED 1053: The service did not respond to the start or control request in a timely fashion.

La troisième suggestion était de lancer CMD.exe via une tâche planifiée. Bien que vous puissiez exécuter des tâches planifiées sous différents comptes, je ne pense pas que le compte système local en fasse partie.

J'ai également essayé d'utiliser les Runas, mais je pense que je me heurte à la même restriction que celle rencontrée lors de l'exécution d'une tâche planifiée.

Jusqu'à présent, chacune de mes tentatives s'est soldée par un échec. Des suggestions ?

Answer 1

Bien que je n'aie pas testé personnellement, j'ai de bonnes raisons de croire que la solution AT COMMAND mentionnée ci-dessus fonctionnera pour XP, 2000 et Server 2003. D'après mes tests et ceux de Bryant, nous avons identifié que la même approche ne fonctionne pas avec Vista ou Windows Server 2008 -- très probablement en raison de la sécurité accrue et du fait que le commutateur /interactive est déprécié.

Cependant, je suis tombé sur ceci article qui démontre l'utilisation de PSTools de SysInternals (qui a été racheté par Microsoft en juillet 2006). J'ai lancé la ligne de commande via ce qui suit et, comme par magie, je me suis retrouvé sous le compte administrateur local :

psexec -i -s cmd.exe

PSTools fonctionne bien. Il s'agit d'un ensemble d'outils légers et bien documentés qui apporte une solution appropriée à mon problème.

Un grand merci à ceux qui ont proposé leur aide.

Answer 2

1. Télécharger psexec.exe de Sysinternals .
2. Placez-le dans votre lecteur C:\.
3. Connectez-vous en tant qu'utilisateur standard ou administrateur et utilisez la commande suivante : cd \ . Cela vous place dans le répertoire racine de votre lecteur, où se trouve psexec.
4. Utilisez la commande suivante : psexec -i -s cmd.exe où -i est pour interactif et -s est pour compte système.
5. Lorsque la commande est terminée, un shell cmd est lancé. Tapez whoami il dira "système".
6. Ouvrez le gestionnaire des tâches. Détruisez explorer.exe.
7. Depuis un shell de commande élevé, tapez start explorer.exe .
8. Lorsque l'explorateur est lancé, remarquez le nom "système" dans la barre de menu de démarrage. Maintenant vous pouvez supprimer certains fichiers dans le répertoire system32 qu'en tant qu'administrateur vous ne pouvez pas supprimer ou en tant qu'administrateur vous devriez essayer de changer les permissions pour supprimer ces fichiers.

Les utilisateurs qui essaient de renommer ou de supprimer des fichiers système dans n'importe quel répertoire protégé de Windows doivent savoir que tous les fichiers Windows sont protégés par DACLS. Pour renommer un fichier, vous devez changer le propriétaire et remplacer TrustedInstaller qui possède le fichier et faire en sorte qu'un utilisateur comme un utilisateur appartenant au groupe administrateur soit le propriétaire du fichier.

Answer 3

Trouvé une réponse ici qui semble résoudre le problème en ajoutant /k start au paramètre binPath. Cela vous donnerait donc :

sc create testsvc binpath= "cmd /K start" type= own type= interact

Cependant, Ben a dit que cela n'a pas fonctionné pour lui et quand je l'ai essayé sur Windows Server 2008, il a bien créé le processus cmd.exe sous le système local, mais il n'était pas interactif (je ne pouvais pas voir la fenêtre).

Je ne pense pas qu'il existe un moyen facile de faire ce que vous demandez, mais je me demande pourquoi vous le faites ? Essayez-vous simplement de voir ce qui se passe lorsque vous exécutez votre service ? Il semble que vous pourriez simplement utiliser la journalisation pour déterminer ce qui se passe au lieu de devoir exécuter l'exe en tant que système local...

Answer 4

Je vous recommande de déterminer le jeu d'autorisations minimum dont votre service a réellement besoin et de l'utiliser, plutôt que le contexte beaucoup trop privilégié du système local. Par exemple, Service local .

Les services interactifs ne fonctionnent plus - ou du moins, n'affichent plus l'interface utilisateur - sur Windows Vista et Windows Server 2008 en raison des éléments suivants session 0 isolation .

Answer 5

Une alternative à cela est Process hacker si vous allez dans run as... (Interactive doesn't work for people with the security enhancments but that wont matter) et quand la boîte s'ouvre, mettez Service dans le type de boîte et mettez SYSTEM dans la boîte utilisateur et mettez le nom de l'utilisateur. dans la case type et mettez SYSTEM dans la case utilisateur et mettez C:\Users\Windows\system32\cmd.exe Laissez le reste, cliquez sur ok et vous obtenez une fenêtre avec cmd et exécutez en tant que système. Maintenant, faites les autres étapes pour vous-même parce que je suggère que vous les connaissez.