Bonjour,
Est-il possible d'avoir un compte utilisateur dans une réseau avec A.D.
qui
puisse être utilisé uniquement pour le lancement d'un programme via "RUN
AS"
mais que ce compte ne puisse pas ouvrir de session directe sur les
mahcines.
De plus, comment puis-je spécifier le mot de passe pour que les
utilisateurs
n'aient pas à le saisir ?
Si je vais un script VBS, puis-je le crypter afin que l'utilisateur
connecté
ne puisse pas connaître le mot de passe du compte utilisé par le runas ?
merci d'avance
Gislain.
Bonjour,
Est-il possible d'avoir un compte utilisateur dans une réseau avec A.D.
qui
puisse être utilisé uniquement pour le lancement d'un programme via "RUN
AS"
mais que ce compte ne puisse pas ouvrir de session directe sur les
mahcines.
De plus, comment puis-je spécifier le mot de passe pour que les
utilisateurs
n'aient pas à le saisir ?
Si je vais un script VBS, puis-je le crypter afin que l'utilisateur
connecté
ne puisse pas connaître le mot de passe du compte utilisé par le runas ?
merci d'avance
Gislain.
Bonjour,
Est-il possible d'avoir un compte utilisateur dans une réseau avec A.D.
qui
puisse être utilisé uniquement pour le lancement d'un programme via "RUN
AS"
mais que ce compte ne puisse pas ouvrir de session directe sur les
mahcines.
De plus, comment puis-je spécifier le mot de passe pour que les
utilisateurs
n'aient pas à le saisir ?
Si je vais un script VBS, puis-je le crypter afin que l'utilisateur
connecté
ne puisse pas connaître le mot de passe du compte utilisé par le runas ?
merci d'avance
Gislain.
Bonjour Gislain :
pour empêcher l'ouverture locale, ajoute ton utilisateur au paramètre
"Interdire l'ouverture d'une session locale" située dans
Configuration ordinateur > Paramètres Windows > Paramètres de sécurité >
Stratégies locales > Attribution des droits utilisateur
-> veille bien à lier la gpo à un niveau suffisamment haut pour toucher
tous
les postes (je n'ai pas dit dans la GPO de domaine par défaut, mais le
cour
y est presque!)
runas ne te permet pas de prédéfinir un mot de passe, pour ceci, je te
suggère plutôt le superexec de notre ami jean Claude
(http://www.bellamyjc.org/fr/superexec.html) ou passer par un psexec (sauf
que tu pointera la machine locale pour l'exécution du script et non un
hôte
distant)
Il existe pas mal de convertisseurs vbs vers exe permettant de ne pas
compromettre le mot de passe .... mais ceux ci sont assez déplorables, je
n'en ai pas trouvé un qui soit vraiment fonctionnel. Une bonne alternative
serait de faire de script en AutoIT (assez similaire au VBS en plus
puissant) qui dispose d'un vrai compilateur. C'est toujours cassable (j'y
ai
assisté en direct!) mais il faudra à ton utilisateur de réelles
connaissances en Hack pour arriver à ce résultat.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Gislain" a écrit dans le message de news:Bonjour,
Est-il possible d'avoir un compte utilisateur dans une réseau avec A.D.
qui
puisse être utilisé uniquement pour le lancement d'un programme via "RUN
AS"
mais que ce compte ne puisse pas ouvrir de session directe sur les
mahcines.
De plus, comment puis-je spécifier le mot de passe pour que les
utilisateurs
n'aient pas à le saisir ?
Si je vais un script VBS, puis-je le crypter afin que l'utilisateur
connecté
ne puisse pas connaître le mot de passe du compte utilisé par le runas ?
merci d'avance
Gislain.
Bonjour Gislain :
pour empêcher l'ouverture locale, ajoute ton utilisateur au paramètre
"Interdire l'ouverture d'une session locale" située dans
Configuration ordinateur > Paramètres Windows > Paramètres de sécurité >
Stratégies locales > Attribution des droits utilisateur
-> veille bien à lier la gpo à un niveau suffisamment haut pour toucher
tous
les postes (je n'ai pas dit dans la GPO de domaine par défaut, mais le
cour
y est presque!)
runas ne te permet pas de prédéfinir un mot de passe, pour ceci, je te
suggère plutôt le superexec de notre ami jean Claude
(http://www.bellamyjc.org/fr/superexec.html) ou passer par un psexec (sauf
que tu pointera la machine locale pour l'exécution du script et non un
hôte
distant)
Il existe pas mal de convertisseurs vbs vers exe permettant de ne pas
compromettre le mot de passe .... mais ceux ci sont assez déplorables, je
n'en ai pas trouvé un qui soit vraiment fonctionnel. Une bonne alternative
serait de faire de script en AutoIT (assez similaire au VBS en plus
puissant) qui dispose d'un vrai compilateur. C'est toujours cassable (j'y
ai
assisté en direct!) mais il faudra à ton utilisateur de réelles
connaissances en Hack pour arriver à ce résultat.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Gislain" <nospam@nospam.com> a écrit dans le message de news:
uWSIObR5FHA.3312@TK2MSFTNGP15.phx.gbl...
Bonjour,
Est-il possible d'avoir un compte utilisateur dans une réseau avec A.D.
qui
puisse être utilisé uniquement pour le lancement d'un programme via "RUN
AS"
mais que ce compte ne puisse pas ouvrir de session directe sur les
mahcines.
De plus, comment puis-je spécifier le mot de passe pour que les
utilisateurs
n'aient pas à le saisir ?
Si je vais un script VBS, puis-je le crypter afin que l'utilisateur
connecté
ne puisse pas connaître le mot de passe du compte utilisé par le runas ?
merci d'avance
Gislain.
Bonjour Gislain :
pour empêcher l'ouverture locale, ajoute ton utilisateur au paramètre
"Interdire l'ouverture d'une session locale" située dans
Configuration ordinateur > Paramètres Windows > Paramètres de sécurité >
Stratégies locales > Attribution des droits utilisateur
-> veille bien à lier la gpo à un niveau suffisamment haut pour toucher
tous
les postes (je n'ai pas dit dans la GPO de domaine par défaut, mais le
cour
y est presque!)
runas ne te permet pas de prédéfinir un mot de passe, pour ceci, je te
suggère plutôt le superexec de notre ami jean Claude
(http://www.bellamyjc.org/fr/superexec.html) ou passer par un psexec (sauf
que tu pointera la machine locale pour l'exécution du script et non un
hôte
distant)
Il existe pas mal de convertisseurs vbs vers exe permettant de ne pas
compromettre le mot de passe .... mais ceux ci sont assez déplorables, je
n'en ai pas trouvé un qui soit vraiment fonctionnel. Une bonne alternative
serait de faire de script en AutoIT (assez similaire au VBS en plus
puissant) qui dispose d'un vrai compilateur. C'est toujours cassable (j'y
ai
assisté en direct!) mais il faudra à ton utilisateur de réelles
connaissances en Hack pour arriver à ce résultat.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Gislain" a écrit dans le message de news:Bonjour,
Est-il possible d'avoir un compte utilisateur dans une réseau avec A.D.
qui
puisse être utilisé uniquement pour le lancement d'un programme via "RUN
AS"
mais que ce compte ne puisse pas ouvrir de session directe sur les
mahcines.
De plus, comment puis-je spécifier le mot de passe pour que les
utilisateurs
n'aient pas à le saisir ?
Si je vais un script VBS, puis-je le crypter afin que l'utilisateur
connecté
ne puisse pas connaître le mot de passe du compte utilisé par le runas ?
merci d'avance
Gislain.
Merci pour l'info de la GPO
Concernant l'outil pour runas, j'ai trouvé AutoIT avec le script qui me
fallait, mais SuperExec est aussi à creuser.
a+
Gislain.
...
Merci pour l'info de la GPO
Concernant l'outil pour runas, j'ai trouvé AutoIT avec le script qui me
fallait, mais SuperExec est aussi à creuser.
a+
Gislain.
...
Merci pour l'info de la GPO
Concernant l'outil pour runas, j'ai trouvé AutoIT avec le script qui me
fallait, mais SuperExec est aussi à creuser.
a+
Gislain.
...
absolument!
note que tu peux pousser jusqu'à combiner AutoIT et superexec ;)
Pour ma part, je fais à peu près tout maintenant en autoIT du fait de la
puissance de l'outil dans ses dernières bêtas, si tu as besoin d'aide,
n'hésite pas.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Gislain" a écrit dans le message de news:Merci pour l'info de la GPO
Concernant l'outil pour runas, j'ai trouvé AutoIT avec le script qui me
fallait, mais SuperExec est aussi à creuser.
a+
Gislain.
...
absolument!
note que tu peux pousser jusqu'à combiner AutoIT et superexec ;)
Pour ma part, je fais à peu près tout maintenant en autoIT du fait de la
puissance de l'outil dans ses dernières bêtas, si tu as besoin d'aide,
n'hésite pas.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Gislain" <nospam@nospam.com> a écrit dans le message de news:
OvuslDQ6FHA.2888@tk2msftngp13.phx.gbl...
Merci pour l'info de la GPO
Concernant l'outil pour runas, j'ai trouvé AutoIT avec le script qui me
fallait, mais SuperExec est aussi à creuser.
a+
Gislain.
...
absolument!
note que tu peux pousser jusqu'à combiner AutoIT et superexec ;)
Pour ma part, je fais à peu près tout maintenant en autoIT du fait de la
puissance de l'outil dans ses dernières bêtas, si tu as besoin d'aide,
n'hésite pas.
Cordialement,
--
Jonathan BISMUTH
MCSE 2000/ADSI-AutoIT Scripter
Transcript (ID: 691839, code: MCSE2000)
www.portail-mcse.net
pour me contacter http://cerbermail.com/?fCeVUi7Icd
"Gislain" a écrit dans le message de news:Merci pour l'info de la GPO
Concernant l'outil pour runas, j'ai trouvé AutoIT avec le script qui me
fallait, mais SuperExec est aussi à creuser.
a+
Gislain.
...
En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
Pour l'instant, mes besoins en script sont limités (cf mes post
précédents), mais je te remerci pour ton offre.
a+
Gislain.
En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
Pour l'instant, mes besoins en script sont limités (cf mes post
précédents), mais je te remerci pour ton offre.
a+
Gislain.
En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
Pour l'instant, mes besoins en script sont limités (cf mes post
précédents), mais je te remerci pour ton offre.
a+
Gislain.
En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
Dans le message :u9Uki$,
Gislain a pris la peine d'écrire ce qui suit :En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
"RunasSet", qui n'est autre que l'intégration de la commande "RunAs" dans
AutoIt, est une partie de mon logicel "SuperExec".
SuperExec est doté d'une interface graphique, qui permet de chosir
"visuellement" :
- l'ordinateur sur lequel sera exécuté la commande
car SuperExec fonctionne à DISTANCE,
- en WORKGROUP
- en DOMAINE
- le ou les utilisateurs ou les groupes d'utilisateurs concernés
- l'application à autoriser (exe, batch, script, MMC...)
- le dossier éventuel d'exécution
- le profil à utiliser (Administrateur, utilisateur, DEFAULT)
- la date limite éventuelle d'exécution
- le nom maximal éventuel d'exécutions
Par ailleurs il donne des infos sur les ordinateurs, les utilisateurs, ...
(OS utilisé, type serveur/station, ..SID, privilèges, ...)
Et toutes les manips sont consignées dans un journal exportable en HTML.
Détail très important : toutes ces données sont stockées sous forme
CHIFFRÉES (en RSA!) dans la BDR (HKLM).
Alors que le couple username/password de l'admin sont codés dans le EXE
créé par le compilateur de AutoIt.
Il y a donc un risque potentiel d'attaque de ce fichier exe.
Donc pour une manip "basique", ne nécessitant pas de protection spéciale,
AutoIt est parfait.
Au dela, si on va dans "l'exotisme", SuperExec est le seul à le permettre.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :u9Uki$n6FHA.3660@TK2MSFTNGP09.phx.gbl,
Gislain <nospam@nospam.com> a pris la peine d'écrire ce qui suit :
En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
"RunasSet", qui n'est autre que l'intégration de la commande "RunAs" dans
AutoIt, est une partie de mon logicel "SuperExec".
SuperExec est doté d'une interface graphique, qui permet de chosir
"visuellement" :
- l'ordinateur sur lequel sera exécuté la commande
car SuperExec fonctionne à DISTANCE,
- en WORKGROUP
- en DOMAINE
- le ou les utilisateurs ou les groupes d'utilisateurs concernés
- l'application à autoriser (exe, batch, script, MMC...)
- le dossier éventuel d'exécution
- le profil à utiliser (Administrateur, utilisateur, DEFAULT)
- la date limite éventuelle d'exécution
- le nom maximal éventuel d'exécutions
Par ailleurs il donne des infos sur les ordinateurs, les utilisateurs, ...
(OS utilisé, type serveur/station, ..SID, privilèges, ...)
Et toutes les manips sont consignées dans un journal exportable en HTML.
Détail très important : toutes ces données sont stockées sous forme
CHIFFRÉES (en RSA!) dans la BDR (HKLM).
Alors que le couple username/password de l'admin sont codés dans le EXE
créé par le compilateur de AutoIt.
Il y a donc un risque potentiel d'attaque de ce fichier exe.
Donc pour une manip "basique", ne nécessitant pas de protection spéciale,
AutoIt est parfait.
Au dela, si on va dans "l'exotisme", SuperExec est le seul à le permettre.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - Jean-Claude.Bellamy@wanadoo.fr
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Dans le message :u9Uki$,
Gislain a pris la peine d'écrire ce qui suit :En quoi l'utilisation conjointe des deux outils est interressante ?
je n'ai pas étudié à fon SuperExec, mais le RunasSet() de AutoIT ne le
remplace t'il pas ?
"RunasSet", qui n'est autre que l'intégration de la commande "RunAs" dans
AutoIt, est une partie de mon logicel "SuperExec".
SuperExec est doté d'une interface graphique, qui permet de chosir
"visuellement" :
- l'ordinateur sur lequel sera exécuté la commande
car SuperExec fonctionne à DISTANCE,
- en WORKGROUP
- en DOMAINE
- le ou les utilisateurs ou les groupes d'utilisateurs concernés
- l'application à autoriser (exe, batch, script, MMC...)
- le dossier éventuel d'exécution
- le profil à utiliser (Administrateur, utilisateur, DEFAULT)
- la date limite éventuelle d'exécution
- le nom maximal éventuel d'exécutions
Par ailleurs il donne des infos sur les ordinateurs, les utilisateurs, ...
(OS utilisé, type serveur/station, ..SID, privilèges, ...)
Et toutes les manips sont consignées dans un journal exportable en HTML.
Détail très important : toutes ces données sont stockées sous forme
CHIFFRÉES (en RSA!) dans la BDR (HKLM).
Alors que le couple username/password de l'admin sont codés dans le EXE
créé par le compilateur de AutoIt.
Il y a donc un risque potentiel d'attaque de ce fichier exe.
Donc pour une manip "basique", ne nécessitant pas de protection spéciale,
AutoIt est parfait.
Au dela, si on va dans "l'exotisme", SuperExec est le seul à le permettre.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] -
http://www.bellamyjc.org ou http://jc.bellamy.free.fr
Bonjour,
j'apporte mon petit grain de sable à cette discussion.
Il est écrit:
"Détail très important : toutes ces données sont stockées sous forme
CHIFFRÉES (en RSA!) dans la BDR (HKLM)."
--> peu importe puisqu'il devient accessible en clair à l'utilisateur
après décryption.
Il suffit de lancer superexec sous un debugger et de breaker sur les
fonctions interessantes ( CryptDecrypt,LogonUser,
CryptUnprotectData...) selon la façon dont le programme est
implémenté afin de récupérer le mot de passe en clair.
Bonjour,
j'apporte mon petit grain de sable à cette discussion.
Il est écrit:
"Détail très important : toutes ces données sont stockées sous forme
CHIFFRÉES (en RSA!) dans la BDR (HKLM)."
--> peu importe puisqu'il devient accessible en clair à l'utilisateur
après décryption.
Il suffit de lancer superexec sous un debugger et de breaker sur les
fonctions interessantes ( CryptDecrypt,LogonUser,
CryptUnprotectData...) selon la façon dont le programme est
implémenté afin de récupérer le mot de passe en clair.
Bonjour,
j'apporte mon petit grain de sable à cette discussion.
Il est écrit:
"Détail très important : toutes ces données sont stockées sous forme
CHIFFRÉES (en RSA!) dans la BDR (HKLM)."
--> peu importe puisqu'il devient accessible en clair à l'utilisateur
après décryption.
Il suffit de lancer superexec sous un debugger et de breaker sur les
fonctions interessantes ( CryptDecrypt,LogonUser,
CryptUnprotectData...) selon la façon dont le programme est
implémenté afin de récupérer le mot de passe en clair.
Je modérerais ton "il suffit de .." ! ;-)
Je modérerais ton "il suffit de .." ! ;-)
Je modérerais ton "il suffit de .." ! ;-)