Faire exécuter un script à distance par un utilisateur lambda
5 réponses
alain_nicolas
Bonjour,
Tout est dans le titre : comment faire exécuter un script vbs situé sur un
serveur ISA par un utilisateur ne faisant pas partie des administrateurs.
Merci pour vos réponses,
Alain
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gilles LAURENT [MVP]
"alain_nicolas" a écrit dans le message de news: | Bonjour,
Bonjour,
| Tout est dans le titre : comment faire exécuter un script vbs situé | sur un serveur ISA par un utilisateur ne faisant pas partie des | administrateurs. Merci pour vos réponses, | Alain
Pour cela, j'utiliserai les outils CPAU et PSExec. L'outil CPAU permettra de créer un job chiffré contenant les credentials d'un compte habilité à se connecter sur le serveur et l'outil PSExec permettra d'exécuter le script VBScript sur la machine distante.
- La première étape consiste à créer le job chiffré. Cette étape sera réalisée par l'administrateur du serveur : > cpau -u serveradministrateur -p password -ex "psexec server wscript c:testtest.vbs" -enc -file vbscript.job
Note: Dans cet exemple, le script VBScript test.vbs est présent dans le dossier c:test du serveur server
- La seconde étape consiste à copier le job chiffré vbscript.job ainsi que les outils CPAU et PSExec sur le poste de travail de l'utilisateur lambda dans un dossier dédié
Ensuite, pour exécuter le script distant : > cpau -dec -file vbscript.job
Note: Un raccourci peut être créé sur le bureau de l'utilisateur
En espérant avoir été suffisamment clair ;-)
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"alain_nicolas" <alainnicolas@discussions.microsoft.com> a écrit dans le
message de
news:A5A5493C-240C-4951-94AD-81DD1DB33440@microsoft.com
| Bonjour,
Bonjour,
| Tout est dans le titre : comment faire exécuter un script vbs situé
| sur un serveur ISA par un utilisateur ne faisant pas partie des
| administrateurs. Merci pour vos réponses,
| Alain
Pour cela, j'utiliserai les outils CPAU et PSExec. L'outil CPAU
permettra de créer un job chiffré contenant les credentials d'un compte
habilité à se connecter sur le serveur et l'outil PSExec permettra
d'exécuter le script VBScript sur la machine distante.
- La première étape consiste à créer le job chiffré. Cette étape sera
réalisée par l'administrateur du serveur :
> cpau -u serveradministrateur -p password -ex "psexec \server
wscript c:testtest.vbs" -enc -file vbscript.job
Note: Dans cet exemple, le script VBScript test.vbs est présent dans le
dossier c:test du serveur \server
- La seconde étape consiste à copier le job chiffré vbscript.job ainsi
que les outils CPAU et PSExec sur le poste de travail de l'utilisateur
lambda dans un dossier dédié
Ensuite, pour exécuter le script distant :
> cpau -dec -file vbscript.job
Note: Un raccourci peut être créé sur le bureau de l'utilisateur
En espérant avoir été suffisamment clair ;-)
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"alain_nicolas" a écrit dans le message de news: | Bonjour,
Bonjour,
| Tout est dans le titre : comment faire exécuter un script vbs situé | sur un serveur ISA par un utilisateur ne faisant pas partie des | administrateurs. Merci pour vos réponses, | Alain
Pour cela, j'utiliserai les outils CPAU et PSExec. L'outil CPAU permettra de créer un job chiffré contenant les credentials d'un compte habilité à se connecter sur le serveur et l'outil PSExec permettra d'exécuter le script VBScript sur la machine distante.
- La première étape consiste à créer le job chiffré. Cette étape sera réalisée par l'administrateur du serveur : > cpau -u serveradministrateur -p password -ex "psexec server wscript c:testtest.vbs" -enc -file vbscript.job
Note: Dans cet exemple, le script VBScript test.vbs est présent dans le dossier c:test du serveur server
- La seconde étape consiste à copier le job chiffré vbscript.job ainsi que les outils CPAU et PSExec sur le poste de travail de l'utilisateur lambda dans un dossier dédié
Ensuite, pour exécuter le script distant : > cpau -dec -file vbscript.job
Note: Un raccourci peut être créé sur le bureau de l'utilisateur
En espérant avoir été suffisamment clair ;-)
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
moi
Gilles LAURENT [MVP] wrote:
"alain_nicolas" a écrit dans le message de news:
Bonjour,
Bonjour,
petites remarques :
Les options -c et -f de PsExec permettent de ne pas à avoir préalablement copié soit-même ce que l'on veut exécuter sur la machine distante...
PsExec permet déjà de choisir l'autorité sous laquelle s'exécutera la tâche; je ne vois donc pas l'intêret à double l'info dans la tâche elle-même. ( options -u et -p ou bien -s )
AutoIt3 me semble préférable à CPAU qui nécessitera le fichier job + ce qu'il faut pour l'exécuter.. Un prgm fait avec AutoIt3 est autonome donc plus facile à faire exécuter par psexec ...
... mais tout ça est aussi affaire de goût et d'habitude ;o)
HB
Gilles LAURENT [MVP] wrote:
"alain_nicolas" <alainnicolas@discussions.microsoft.com> a écrit
dans
le message de
news:A5A5493C-240C-4951-94AD-81DD1DB33440@microsoft.com
Bonjour,
Bonjour,
petites remarques :
Les options -c et -f de PsExec permettent de ne pas à avoir
préalablement copié soit-même ce que l'on veut exécuter sur la machine
distante...
PsExec permet déjà de choisir l'autorité sous laquelle s'exécutera la
tâche; je ne vois donc pas l'intêret à double l'info dans la tâche
elle-même. ( options -u et -p ou bien -s )
AutoIt3 me semble préférable à CPAU qui nécessitera le fichier job +
ce qu'il faut pour l'exécuter..
Un prgm fait avec AutoIt3 est autonome donc plus facile à faire
exécuter par psexec ...
... mais tout ça est aussi affaire de goût et d'habitude ;o)
Les options -c et -f de PsExec permettent de ne pas à avoir préalablement copié soit-même ce que l'on veut exécuter sur la machine distante...
PsExec permet déjà de choisir l'autorité sous laquelle s'exécutera la tâche; je ne vois donc pas l'intêret à double l'info dans la tâche elle-même. ( options -u et -p ou bien -s )
AutoIt3 me semble préférable à CPAU qui nécessitera le fichier job + ce qu'il faut pour l'exécuter.. Un prgm fait avec AutoIt3 est autonome donc plus facile à faire exécuter par psexec ...
... mais tout ça est aussi affaire de goût et d'habitude ;o)
HB
Gilles LAURENT [MVP]
"moi" a écrit dans le message de news:
Bonjour,
| petites remarques :
Je vous en prie ;-)
| Les options -c et -f de PsExec permettent de ne pas à avoir | préalablement copié soit-même ce que l'on veut exécuter sur la machine | distante...
Tout à fait ! Cependant Alain semble indiquer que le script est déjà présent sur le serveur. Votre remarque est toutefois très pertinente.
| PsExec permet déjà de choisir l'autorité sous laquelle s'exécutera la | tâche; je ne vois donc pas l'intêret à double l'info dans la tâche | elle-même. ( options -u et -p ou bien -s )
C'est l'administrateur du serveur qui crée et indique les credentials à utiliser pour le job. Ensuite, l'utilisateur lambda exécute simplement le job sans connaissance des credentials pour d'une part se connecter au serveur et d'autre part exécuter le script distant via PSExec.
| AutoIt3 me semble préférable à CPAU qui nécessitera le fichier job + | ce qu'il faut pour l'exécuter.. | Un prgm fait avec AutoIt3 est autonome donc plus facile à faire | exécuter par psexec ...
Les exécutables générés par AutoIt *semblent* être reversibles :-( <nolink>
| ... mais tout ça est aussi affaire de goût et d'habitude ;o)
Tout à fait !
Merci pour l'enrichissement de cette réponse !
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"moi" <moi@pas.la.ici> a écrit dans le message de
news:eAyQzFBEJHA.4744@TK2MSFTNGP02.phx.gbl
Bonjour,
| petites remarques :
Je vous en prie ;-)
| Les options -c et -f de PsExec permettent de ne pas à avoir
| préalablement copié soit-même ce que l'on veut exécuter sur la machine
| distante...
Tout à fait ! Cependant Alain semble indiquer que le script est déjà
présent sur le serveur. Votre remarque est toutefois très pertinente.
| PsExec permet déjà de choisir l'autorité sous laquelle s'exécutera la
| tâche; je ne vois donc pas l'intêret à double l'info dans la tâche
| elle-même. ( options -u et -p ou bien -s )
C'est l'administrateur du serveur qui crée et indique les credentials à
utiliser pour le job. Ensuite, l'utilisateur lambda exécute simplement
le job sans connaissance des credentials pour d'une part se connecter au
serveur et d'autre part exécuter le script distant via PSExec.
| AutoIt3 me semble préférable à CPAU qui nécessitera le fichier job +
| ce qu'il faut pour l'exécuter..
| Un prgm fait avec AutoIt3 est autonome donc plus facile à faire
| exécuter par psexec ...
Les exécutables générés par AutoIt *semblent* être reversibles :-(
<nolink>
| ... mais tout ça est aussi affaire de goût et d'habitude ;o)
Tout à fait !
Merci pour l'enrichissement de cette réponse !
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
| Les options -c et -f de PsExec permettent de ne pas à avoir | préalablement copié soit-même ce que l'on veut exécuter sur la machine | distante...
Tout à fait ! Cependant Alain semble indiquer que le script est déjà présent sur le serveur. Votre remarque est toutefois très pertinente.
| PsExec permet déjà de choisir l'autorité sous laquelle s'exécutera la | tâche; je ne vois donc pas l'intêret à double l'info dans la tâche | elle-même. ( options -u et -p ou bien -s )
C'est l'administrateur du serveur qui crée et indique les credentials à utiliser pour le job. Ensuite, l'utilisateur lambda exécute simplement le job sans connaissance des credentials pour d'une part se connecter au serveur et d'autre part exécuter le script distant via PSExec.
| AutoIt3 me semble préférable à CPAU qui nécessitera le fichier job + | ce qu'il faut pour l'exécuter.. | Un prgm fait avec AutoIt3 est autonome donc plus facile à faire | exécuter par psexec ...
Les exécutables générés par AutoIt *semblent* être reversibles :-( <nolink>
| ... mais tout ça est aussi affaire de goût et d'habitude ;o)
Tout à fait !
Merci pour l'enrichissement de cette réponse !
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
Méta-MCI \(MVP\)
Bonsoir !
Les exécutables générés par AutoIt *semblent* être reversibles
Il y a une option, dans le compilateur, pour empêcher, ou non, la décompilation.
Et aussi, Autoit contient les instructions nécessaires pour exécuter "quelque chose" sous un autre compte utilisateur.
Enfin, aucune des solutions discutées ne permettent d'outre-passer l'UAC. Pour cela, il faudrait "préparer" le poste cible. Mais, si cela est possible, la question n'aurait plus le même sens.
@+
Michel Claveau
Bonsoir !
Les exécutables générés par AutoIt *semblent* être reversibles
Il y a une option, dans le compilateur, pour empêcher, ou non, la
décompilation.
Et aussi, Autoit contient les instructions nécessaires pour exécuter
"quelque chose" sous un autre compte utilisateur.
Enfin, aucune des solutions discutées ne permettent d'outre-passer
l'UAC. Pour cela, il faudrait "préparer" le poste cible. Mais, si cela
est possible, la question n'aurait plus le même sens.
Les exécutables générés par AutoIt *semblent* être reversibles
Il y a une option, dans le compilateur, pour empêcher, ou non, la décompilation.
Et aussi, Autoit contient les instructions nécessaires pour exécuter "quelque chose" sous un autre compte utilisateur.
Enfin, aucune des solutions discutées ne permettent d'outre-passer l'UAC. Pour cela, il faudrait "préparer" le poste cible. Mais, si cela est possible, la question n'aurait plus le même sens.
@+
Michel Claveau
Gilles LAURENT [MVP]
"Méta-MCI (MVP)" a écrit dans le message de news:48c2b667$0$873$ | Bonsoir !
Bonjour,
|| Les exécutables générés par AutoIt *semblent* être reversibles | | Il y a une option, dans le compilateur, pour empêcher, ou non, la | décompilation.
Cette option n'est plus présente dans les dernières versions du compilateur, à ce que j'ai compris celle-ci est maintenant fixée par défaut. Je viens de refaire un test de compilation avec la dernière version 3.2.12.1. Je suis en mesure de décompiler l'executable sans problème et donc de récupérer le script .au3 en clair. Si celui-ci contient des credentials alors il y aura un petit problème de sécurité :-(
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr
"Méta-MCI (MVP)" <enleverlesX.XmcX@XmclaveauX.com> a écrit dans le
message de
news:48c2b667$0$873$ba4acef3@news.orange.fr
| Bonsoir !
Bonjour,
|| Les exécutables générés par AutoIt *semblent* être reversibles
|
| Il y a une option, dans le compilateur, pour empêcher, ou non, la
| décompilation.
Cette option n'est plus présente dans les dernières versions du
compilateur, à ce que j'ai compris celle-ci est maintenant fixée par
défaut. Je viens de refaire un test de compilation avec la dernière
version 3.2.12.1. Je suis en mesure de décompiler l'executable sans
problème et donc de récupérer le script .au3 en clair. Si celui-ci
contient des credentials alors il y aura un petit problème de sécurité
:-(
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
"Méta-MCI (MVP)" a écrit dans le message de news:48c2b667$0$873$ | Bonsoir !
Bonjour,
|| Les exécutables générés par AutoIt *semblent* être reversibles | | Il y a une option, dans le compilateur, pour empêcher, ou non, la | décompilation.
Cette option n'est plus présente dans les dernières versions du compilateur, à ce que j'ai compris celle-ci est maintenant fixée par défaut. Je viens de refaire un test de compilation avec la dernière version 3.2.12.1. Je suis en mesure de décompiler l'executable sans problème et donc de récupérer le script .au3 en clair. Si celui-ci contient des credentials alors il y aura un petit problème de sécurité :-(
-- Gilles LAURENT MVP Windows Server - Admin Frameworks http://glsft.free.fr