The WinOps Blog

Lors de mes différentes péripécies il a toujours été prévu à travers les outils d’executer mes scripts en tant qu’administrateur local…. Mais…

Aujourd’hui je travaille sur un outil arcaïque nommé LANDesk, qui je ne sais pas comment exactement (et puis ça m’interesse pas !!), empêche l’execution des scripts vbs (wscript.exe ne marche pas) sous le compte local system… Et puis, j’ai pas envie de trouver pourquoi, puisque mon but est de trouver une solution clé en main.

Alors, j’ai cherché, j’ai cherché et j’ai cherché… un moyen de faire runas en ligne de commande silencieuse…

Et j’ai fini par trouver:

runasspc.exe

Cet outil permet de faire un runas en ligne de commande silencieuse, c’est à dire sans cette Saloperie de “veuillez fournir le mot de passe…Etc” qu’affiche “runas.exe” natif windows.

Voici la syntaxe:

unasspc.exe /program:"%1 %2" /domain:%3 /user:%4 /password:%5 /quiet

où:

“%1 %2” = le programme à lancer.

Par exemple pour lancer hello.vbs:

                                                   %1= “C:\windows\system32\wscript.exe”

                                                   %2= “C:\…\hello.vbs”

mais si c’est pour lancer notepad alors: on remplace “%1 %2” par notepad.exe…

%2 = le domaine

%4 = username

%5 = le mot de passe.

Par exemple, pour lancer le script Hello.vbs en tant qu’administrateur local (mot de passe = P@ssw0rd). Il faut faire:

runas.cmd /program:"c:\windows\system32\wscript.exe C:\Users\toto\Desktop\hello.vbs" /domain:"localhost" /user:administrateur /password:P@ssw0rd /quiet

Mais on peut aussi le mettre dans un batch si on veut récupérer les informations via des variables d’environnement (si vous voyez ce que je veux dire landesk envt variables par exemple…):

dans le batch, on mettra:

runasspc.exe /program:"%1 %2" /domain:%3 /user:%4 /password:%5 /quiet

et on executera comme ça:

runas.cmd "c:\windows\system32\wscript.exe" "C:\Users\toto\Desktop\hello.vbs" "localhost" administrateur P@ssw0rd

Et si on veut parser des variables ça donnera dans landesk:

runas.cmd "c:\windows\system32\wscript.exe" "C:\Users\toto\Desktop\hello.vbs" %LDDomain% %LDUser% %LDPass%

Lsrunas

LSrunas can be used to run a command using another user account and passing the password as a parameter.
This is a big improvement over the standard runas tool which is not able to accept a password.
LSrunas can be used in scripts.
Parameters:
-----------
/user: specifies the username
/password: specifies the password
/domain: specifies the domain
/command: specifies the command to execute and the parameters
/runpath: specifies the path where the command should start
Examples:
---------
lsrunas /user:administrator /password:s3cr3tp@ssw0rd /domain:Mydomain /command:notepad.exe /runpath:c:\
lsrunas /user:administrator /password:s3cr3tp@ssw0rd/domain:Mydomain /command:"C:\Program Files\Internet Explorer\iexplore.exe" /runpath:c:\

lsrunas /user:administrator /password:s3cr3tp@ssw0rd /domain:Mydomain /command:"C:\Program Files\Internet Explorer\iexplore.exe http://www.google.be" /runpath:c:\

in batch:

lsrunas.exe /program:"%1 %2" /domain:%3 /user:%4 /password:%5 /quiet

lsrunas /user:%4 /password:%5 /domain:%3 /command:”%1 %2”

in landesk:

runas.cmd "c:\windows\system32\wscript.exe" "C:\Users\toto\Desktop\hello.vbs" %LDDomain% %LDUser% %LDPass%

Résultat on pourra lancer un script vbs pendant un provisionning pour effectuer une configuration spécifique comme par exemple détecter si l’architecture est x64 ou x86 et renvoyer ça dans un variable du template. Puis, utiliser des conditions…etc

A quoi ça sert?

A avoir un seul template, quelle que soit la langue, quelle que soit l’architecture, quel que soit le modèle, quel que soit le groupe ciblé…etc

Et c’est mieux 1 seul template qui prend tout en charge que 50 templates.

Après tout on est ingénieur, non? on a fait de études scientifiques, non?

Donc on adore la mise en équation. On est pas de bidouilleurs et on fait du boulot propre!!

BATCH c’est rouillé!!

//////////////////////////////////////////

PS: petite mise à jour:

1) lancer un programme en tant que compte système:

puis on lance le programme ;)

2) lancer un script powershell as local admin:

3) lancer une commande via powershell as local admin:

@+