Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Avoir un compte utilisateur avec ouverture de session interdite

9 réponses
Avatar
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.

9 réponses

Avatar
Jonathan Bismuth
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.




Avatar
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.


"Jonathan Bismuth" a écrit
dans le message de news:%
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.








Avatar
Jonathan Bismuth
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.
...


Avatar
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.

"Jonathan Bismuth" wrote in
message news:
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.
...





Avatar
Jonathan Bismuth
re Gis,

l'avantage de superexec est simple, c'est un vrai outil avec console d'admin
d'un côté et exécutable utilisateur de l'autre (je te passe les paramètres
de planification d'exécution et autres....). La fonction de runas de AutoIT
est plus limitée et pour obtenir le même niveau de fonctionnalité, tu as pas
mal de code à pondre donc bon...
Il est toutefois vrai qu'elle permet de s'en sortir dans la plupart des cas
simples :)

@+
--
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:
u9Uki$
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.


Avatar
Jean-Claude BELLAMY
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

Avatar
Emmanuel Dreux [MS]
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.

J'avais par exemple extrait le mot de passe en clair d'un produit similaire
appelé TqcRunas.
SuperExec ne devrait pas résister plus longtemps ( sauf que je n'arrive pas
à le faire fonctionner, il crashe systématiquement).

I tested this "product", switched to a enduser account with no priviledges,
created a task requiring admin privildeges ( ex defrag), entered the admin
credentials and stored the task in test.tqc.

As enduser, I then debugged TqcRunas.exe test.tqc ... and got the admin
password in clear in a few minutes.

bp ADVAPI32!CryptDecrypt
then print the IN/OUT buffer after the decryption:

0:000> db 0x008f8d18
008f8d18 49 4e 00 00 00 00 00 00-00 00 00 00 00 00 00 00 IN..............
008f8d28 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
008f8d38 00 00 00 00 01 00 00 00-00 00 00 00 00 00 00 00 ................
008f8d48 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
008f8d58 00 00 00 00 01 00 00 00-00 00 00 00 ff fe ff 00 ................
008f8d68 ff fe ff 1c 43 00 3a 00-5c 00 57 00 49 00 4e 00 ....C.:..W.I.N.
008f8d78 44 00 4f 00 57 00 53 00-5c 00 73 00 79 00 73 00 D.O.W.S..s.y.s.
008f8d88 74 00 65 00 6d 00 33 00-32 00 5c 00 64 00 66 00 t.e.m.3.2..d.f.
...
0:000> db 0x008f8d18 +0x80
008f8d98 72 00 67 00 2e 00 6d 00-73 00 63 00 ff fe ff 07 r.g...m.s.c.....
008f8da8 4d 00 41 00 4e 00 55 00-58 00 50 00 32 00 14 00 M.A.N.U.X.P.2...
008f8db8 00 00 ff fe ff 09 26 00-50 00 61 00 73 00 73 00 ......&.P.a.s.s.
008f8dc8 77 00 6f 00 72 00 64 00-da 39 a3 ee 5e 6b 4b 0d w.o.r.d..9..^kK.
008f8dd8 32 55 bf ef 95 60 18 90-af d8 07 09 ff fe ff 00 2U...`..........
008f8de8 ff fe ff 0e 61 00 64 00-6d 00 69 00 6e 00 69 00 ....a.d.m.i.n.i.
008f8df8 73 00 74 00 72 00 61 00-74 00 65 00 75 00 72 00 s.t.r.a.t.e.u.r.
008f8e08 ff fe ff 00 00 00 00 00-00 00 ab ab ab ab ab ab ................

--
Cordialement,

Emmanuel Dreux


"Jean-Claude BELLAMY" a écrit dans le
message de news: %
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





Avatar
Jean-Claude BELLAMY
Dans le message :ei%,
Emmanuel Dreux [MS] a pris la peine d'écrire
ce qui suit :
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 .." ! ;-)
Car je teste la façon dont le runtime (se.exe) est lancé !
De plus les clefs de chiffrement sont variables...
(donc je souhaite bien du plaisir à celui qui voudrait déplomber les infos
chiffrées dans la BDR)

Je n'affirmerais certainement pas qu'un hacker suffisamment costaud
n'arrivera pas à craquer le pwd admin, mais n'oublions pas le rôle et les
conditions d'utilisation de SuperExec!
A savoir, dasn un usage familial ou professionnel, sur un PC dans un
workgroup ou un domaine, autoriser ponctuellement un utilisateur "lambda" à
effectuer UNE tâche bien précise avec des privilèges d'admin, sans pour
autant lui communiquer le pwd de l'admin.

<Message perso>
Quand tu écris :
"sauf que je n'arrive pas à le faire fonctionner,
il crashe systématiquement."
pourrais-tu m'en dire plus ?
Quel OS utilisé ?
Machine locale ou distante ?
Domaine, Workgroup ou PC totalement isolé ?
Quelle tâche (exe, batch, ...)
Quelle(s) est(sont) les injurebox ?
Où a lieu le crash? A la préparation (superexec.exe) ou à l'exécution
(se.exe) ?
</Message perso>

--
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

Avatar
GG [MVP]
Bonjour JCB et Emmanuel,

Je modérerais ton "il suffit de .." ! ;-)


Emmanuel occupe toi d'utiliser Kapimon (c'est un mec
du support MS France qu'il l'a developpé, tu peux le trouver)
et ensuite tu pourras même dire a JC, un jeu d'enfant.
Si tu as besoin d'aide pour avoir de l'aide de l'auteur
mail me.

JCB utilise kapimon et tu verras c'est simple même
éceourant de voir comme certaines choses sont trop
evidentes surtout quand tu charges simplement les
symboliques du kernel de Windows. L'auteur de
cet utilitaire m'a même appris comment récupérer
un mot de passe de ton accès bancaire, non pardon
je n'ai pas encore réussi a l'installer chez toi cette
utilitaire. Mais chut !!! kapimon est difficile a trouvé
il se cache derrière google. -)
Il n'y a surtout pas d'adware dans kapimon mais
simplement un driver qui vous surveille.
--
Cordialement.
GG.
http://sbsfr.mvps.org/
http://gilsga.mvps.org/