Discussion :

[pitchalov]

Bonjour à tous.

Je pose ce message pour une question d'ordre "fiabilité de code" en vbs.

Alors voilà, j'ai besoin de lancer des commandes RunAs en vbs afin de lancer des installations qui nécessitent les droits d'admin, et cela par des utilisateurs n'en ayant pas...

Le problème, c'est qu'après avoir regardé un peu sur le web les manières de lancer ce runas, il s'avère qu'il n'y a pas moyen de passer le mot de passe du superutilisateur en paramètre de la commande. Il est donc nécessaire d'envoyer un SendKeys du password après le lancement commande.

Le code ressemble donc à cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
objWshShell = WScript.CreateObject("WScript.Shell")
objWshShell.Run objWshShell.ExpandEnvironmentStrings("%systemroot%") & "\system32\runas.exe" & " Mesparamètres " & " monExe"
WScript.Sleep 150
objWshShell.SendKeys "MonPassword" & "~"

Voilà ma question : Est-ce que cette méthode est fiable ou pas? (Elle est utilisée par JC Bellamy dans son script xrunas.vbs).

Sinon y a-t-il une autre méthode pour réaliser cette action, d'une meilleure manière?

Merci de vos réponses.

[ced600]

En VBS avec le WMI, tu peux te connecter sur un poste distant (ou local, avec l'adresse IP du poste local, vu alors comme le poste distant) en précisant le compte utilisateur et le mot de passe (tout sera dans le code et en clair, et même si tu passes par un fichier cryptée, le code de décryptage sera dans le script).
Ensuite à partir de là, tu peux agir comme si tu été en local, et par exemple créer un process et l'exécuter pour lancer un installeur.

[pitchalov]

Merci de ta réponse ced600.

J'avais pensé à cette solution, mais je n'ai pas d'autre choix que de lancer le script en local sur le poste avec le compte utilisateur car il doit y avoir une interaction entre l'user et le script, par l'intermédiaire de popup.

J'avais aussi pensé à le lancer par GPO ordinateur ou tâche planifiée, mais le problème est toujours le même.

Le problème sécurité n'est pas le plus important au niveau de ce script, le truc c'est qu'il va être massivement déployé et il ne peut pas y avoir de code hasardeux.

D'où ma question "Est-ce que l'utilisation de la commande RunAs de l'objet Shell et d'un sendkey est fiable?"...

Auriez-vous d'autres suggestions? ou une idée sur la fiabilité de cette solution?

[omen999]

bonjour,

Est-ce que l'utilisation de la commande RunAs de l'objet Shell et d'un sendkey est fiable?

non
mais sauf si tu comptes piloter un missile nucléaire en vbscript, tu peux sans doute accepter une fiablité de 99%...
ton code est d'ailleurs incomplet puisque l'ami bellamy comme d'autres d'ailleurs sur le net: http://www.tek-tips.com/faqs.cfm?fid=2760
ont pris soin d'intercaler avant ou après le sleep (plutôt avant) un petit AppActivate pour activer la fenêtre cible

[pitchalov]

Oui c'est vrai.
Cela dit il y a déjà tellement de bordel lors du déploiement sur tous les postes que je préfère que les erreurs viennent pas du programme.

Sinon, j'ai trouvé l'outil psexec qui permet de faire une install à distance ou en local, mais en passant en paramètre le login ET le mot de passe.

Donc je pense que je partirai sur cette solution.

Merci de vos réponses

[spantemonium]

j'ai déjà besoin de faire ce genre de manip, et j'avais passé les user et password dans mon script vbs.

pour ne pas qu'ils soient lus, je les avait compilés grace a l'outil vbs2exe.

coté script ca change rien (ca décale juste l'index des arguments de 1 mais tu n'en utilise pas dans ton exemple) et c'est pratique.

enjoy^^

[ced600]

en ce qui concerne psexec, il marche très bien, mais fait attention au WorkingDirectory, en VBS il y a longtemps, j'ai eu des problème avec psexec parce que je n'avais pas configuré correctement le WorkingDirectory.

[pitchalov]

Merci du conseil, j'ai pu le vérifier quand j'ai commencé à lancer des scripts avec psexec.

Je rajoute que pour accepter automatiquement la licence eula, il suffit de mettre le paramètre /accepteula à psexec. Cette info peut être utile pour quelqu'un au cas où.

Sujet résolu