ENA

*Bonjour Aski*
<ecALT4#7JHA.1716@TK2MSFTNGP03.phx.gbl>

Hello,

Effectivement...
Il a fallu que j'aille dans le registre pour prendre des permissions sur
SAM.
Je ne sais pas encore si c'est un cas particulier de XP sur VPC7.
Je vais compléter la routine d'erreur mais cette clé SAM commence à
m'échauffer les oreilles (ou à me les b...... m.... au choix).

Je viens de vérifier que cela n'était pas particulier à VPC7.
Il faut donc trouver le moyen de donner des permissions sur la clé SAMSAM

Normalement SAMSAM et SECURITY ne sont accessibles que par SYSTEM.
Modifier les permissions de SAM est possible au moins avec l'outil
subinacl. Mais c'est lourd. Il parait plus judicieux de travailler en
tant que SYSTEM avec psexec.

Pour mémoire il existe une astuce éhontée pour ouvrir une console en
tant que SYSTEM via une tâche planifiée :
Supposons qu'il soit 15h59 :
AT 16:00:00 /interactive cmd

C'est un gadget, mais ça peut dépanner.

Psexec est plus pratique.
Pour ouvrir le registre en tant que SYSTEM j'utilise un raccourci avec
cette commande :
psexec.exe -i -d -s regedit.exe -m

Le commutateur -m ouvre une nouvelle session regedit. Je peux ainsi
comparer entre deux fenêtres regedit à quoi j'ai accès ou non.

C'est avec psexec que j'ai utilisé regshot pour voir la clé concernée
lors de l'utilisation de secpol.msc

De la même manière on doit pouvoir faire un psexec reg query ...

XPPRO (machine virtuelle)
Message d'erreur "Get_Admin_Enabled".

Je n'ai aucun message sur mes 2 XPPro en multiboot
N'as-tu pas de détail de l'erreur ?

Get_Admin_Enabled est le titre de la fenêtre d'erreur, mais elle est
vide, avec un bouton OK.

--
Salutations, Jean-François

Hello,

Normalement SAMSAM et SECURITY ne sont accessibles que par SYSTEM.
Modifier les permissions de SAM est possible au moins avec l'outil
subinacl. Mais c'est lourd. Il parait plus judicieux de travailler en tant
que SYSTEM avec psexec.

Pour mémoire il existe une astuce éhontée pour ouvrir une console en tant
que SYSTEM via une tâche planifiée :
Supposons qu'il soit 15h59 :
AT 16:00:00 /interactive cmd

C'est un gadget, mais ça peut dépanner.

J'ai effectivement découvert cette possibilité mais ai préféré psexec.

Psexec est plus pratique.
Pour ouvrir le registre en tant que SYSTEM j'utilise un raccourci avec
cette commande :
psexec.exe -i -d -s regedit.exe -m

Le commutateur -m ouvre une nouvelle session regedit. Je peux ainsi
comparer entre deux fenêtres regedit à quoi j'ai accès ou non.

C'est avec psexec que j'ai utilisé regshot pour voir la clé concernée lors
de l'utilisation de secpol.msc

De la même manière on doit pouvoir faire un psexec reg query ...

J'ai découvert psexec il y a quelque temps pour éliminer une vacherie
laissée par Phantom CD
http://dechily.org/Forum_Aski/topic101.html
J'avais essayé d'introduire un appel à psexec depuis VB mais je n'y suis pas
arrivé.
Je n'ai pas trop envie de le faire par un .cmd et aimerais trouver une autre
solution.

Get_Admin_Enabled est le titre de la fenêtre d'erreur, mais elle est vide,
avec un bouton OK.

Oui Get_Admin_Enabled est le nom de ma procédure. Comme il s'agit d'une API,
il faut déterminer l'erreur (VB ne le fait pas), d'où le message vide.
L'erreur est facile à afficher mais plus difficile à pallier.
--
Cordialement

Aski
MVP Windows Desktop Experience
http://dechily.org/
http://dechily.org/Forum_Aski/

Salut Henri

Je pense à un inconvénient avec psexec, il faut l'enregistrer lors de
la première utilisation. Ce n'est pas dur à contourner
HKEY_CURRENT_USERSoftwareSysinternalsPsExec
EulaAccepted=1
mais ça pose un problème d'éthique.
Il faut donc préparer l'utilisateur à la question posée en anglais.
J'avais eu le problème avec regjump
http://fspsa.free.fr/images/ppr-regjump-licence-agreement.jpg

J'ai découvert psexec il y a quelque temps pour éliminer une vacherie laissée
par Phantom CD
http://dechily.org/Forum_Aski/topic101.html

HS
Tu seras intéressé par RegDelNull qui recherche puis permet
éventuellement de supprimer les clés interdites par la présence
d'embedded-null characters.

Je l'ai trouvé en consultant les derniers kellystwares
409. Remove Locked Regfiles - RegDelNull
http://www.kellys-korner-xp.com/xp_tweaks.htm

J'avais essayé d'introduire un appel à psexec depuis VB mais je n'y suis pas
arrivé.
Je n'ai pas trop envie de le faire par un .cmd et aimerais trouver une autre
solution.

Ce que tu peux faire, considérant le peu d'esthétisme qu'il y a à faire
surgir une fenêtre noire lors de l'exécution d'un programme VB, est de
la masquer
http://www.commentcamarche.net/vbscript/vbs-wshshell.php3

Exemples :

invisible.vbs
Set oShell = CreateObject("WScript.Shell")
oShell.Run """invisible.cmd""",0,true

invisible.cmd
taskmgr
pause

Lancer invisible.vbs avec wscript
Le gestionnaire de tâches est ouvert montrant la présence du processus
cmd.exe. Il suffira de retirer pause pour laisser se fermer le batch.

Une autre façon de procéder ici
http://briskoda.net/tech-shed/running-cmd-line-minimised-hidden/46185/

--
Salutations, Jean-François
http://fspsa.free.fr/Index-de-la-FAQ-WINXP-de-Panthere-Noire.htm
http://fspsa.free.fr/Capture-Ecran-et-Publication-vers-Newsgroups.htm
http://fspsa.free.fr/contamination-lecteurs-amovibles.htm

Bonjour Jean-François,

Je n'ai pas trouvé le moyen de donner les droits nécessaires à la fonction
API pour pouvoir ouvrir SAMSAM. Je vais poser la question à nos amis du NG
vb.
La moins mauvaise solution que j'ai trouvée consiste à envoyer le résultat
de l'interrogation au travers de psexec dans un fichier tampon dans lequel
je reprends la valeur de F qui nous intéresse.
On n'en a besoin qu'en lecture, le problème de l'enregistrement semblant
maîtrisé.
Shell Environ("comspec") & " /c psexec -s reg query
hklmSAMSAMDomainsAccountUsers00001F4 > tmp.txt, 0
Il aurait été préférable de pouvoir rediriger le résultat dans une variable
du programme mais je n'ai rien trouvé.
De même, on est obligé d'enregistrer la totalité de ce qui se trouve sous la
clé 000001F4 mais ce n'est pas très ennuyeux car la position des valeurs qui
nous intéressent (10 ou 11 en hexa) ne varie pas.

Je pense à un inconvénient avec psexec, il faut l'enregistrer lors de la
première utilisation. Ce n'est pas dur à contourner
HKEY_CURRENT_USERSoftwareSysinternalsPsExec
EulaAccepted=1
mais ça pose un problème d'éthique.
Il faut donc préparer l'utilisateur à la question posée en anglais.
J'avais eu le problème avec regjump
http://fspsa.free.fr/images/ppr-regjump-licence-agreement.jpg

Tu as raison. Je préfère cette solution à la modification de la balise Eula.

Je me suis demandé pourquoi Vista 64 fonctionne chez toi car le
fonctionnement de ENA me semble à peu près le même que pour Vista 32.
N'aurais-tu pas modifié les droits sur le registre ?
Ces modifications restent permanentes contrairement à ce que je supposais.

J'avais essayé d'introduire un appel à psexec depuis VB mais je n'y suis
pas arrivé.
Je n'ai pas trop envie de le faire par un .cmd et aimerais trouver une
autre solution.

Ce que tu peux faire, considérant le peu d'esthétisme qu'il y a à faire
surgir une fenêtre noire lors de l'exécution d'un programme VB, est de la
masquer
http://www.commentcamarche.net/vbscript/vbs-wshshell.php3

Exemples :

invisible.vbs
Set oShell = CreateObject("WScript.Shell")
oShell.Run """invisible.cmd""",0,true

La fonction Shell() est évidemment plus simple lorsqu'on est dans
l'environnement VB6.

invisible.cmd
taskmgr
pause

Lancer invisible.vbs avec wscript
Le gestionnaire de tâches est ouvert montrant la présence du processus
cmd.exe. Il suffira de retirer pause pour laisser se fermer le batch.

Une autre façon de procéder ici
http://briskoda.net/tech-shed/running-cmd-line-minimised-hidden/46185/

Je n'ai pas eu besoin d'ajouter du code à celui que j'ai indiqué. La fenêtre
cmd n'apparaît pas grâce au switch "/c".
J'ai stocké les 2 liens fort instructifs dans mes favoris.
--
Cordialement

Aski
MVP Windows Desktop Experience
http://dechily.org/
http://dechily.org/Forum_Aski/

*Bonjour Henri*
<eq6BQ#D8JHA.2456@TK2MSFTNGP02.phx.gbl>

Bonjour Jean-François,

Je n'ai pas trouvé le moyen de donner les droits nécessaires à la fonction
API pour pouvoir ouvrir SAMSAM. Je vais poser la question à nos amis du NG
vb.
La moins mauvaise solution que j'ai trouvée consiste à envoyer le résultat de
l'interrogation au travers de psexec dans un fichier tampon dans lequel je
reprends la valeur de F qui nous intéresse.
On n'en a besoin qu'en lecture, le problème de l'enregistrement semblant
maîtrisé.
Shell Environ("comspec") & " /c psexec -s reg query
hklmSAMSAMDomainsAccountUsers00001F4 > tmp.txt, 0
Il aurait été préférable de pouvoir rediriger le résultat dans une variable
du programme mais je n'ai rien trouvé.
De même, on est obligé d'enregistrer la totalité de ce qui se trouve sous la
clé 000001F4 mais ce n'est pas très ennuyeux car la position des valeurs qui
nous intéressent (10 ou 11 en hexa) ne varie pas.

Ok, mais cette commande est incomplète.
Cette commande lit la valeur F :
psexec -s reg query HKLMSAMSAMDomainsAccountUsers00001F4 /v F

Redirection :
psexec -s reg query HKLMSAMSAMDomainsAccountUsers00001F4 /v
F>tmp.txt

Transposition en VBS :

Set Shell = CreateObject("WScript.Shell")
Shell.Run "%comspec% /c psexec -s reg query
HKLMSAMSAMDomainsAccountUsers00001F4 /v F>tmp.txt"
WScript.Sleep 500
Shell.Run "tmp.txt"


En VBS on peut lire une clé avec Shell.RegRead() que j'ai trouvé dans
l'aide script56.chm
http://www.microsoft.com/downloads/details.aspx?FamilyId
592C48-207D-4BE1-8A76-1C4099D7BBB9
Version fr :
http://download.microsoft.com/download/winscript56/install/5.6/w98nt42kme/fr/scd56fr.exe

Voici l'exemple complet :

Set Sh = CreateObject("WScript.Shell")
key = "HKEY_CURRENT_USER"
Sh.RegWrite key & "WSHTest", "testkeydefault"
Sh.RegWrite key & "WSHTeststring1", "testkeystring1"
Sh.RegWrite key & "WSHTeststring2", "testkeystring2", "REG_SZ"
Sh.RegWrite key & "WSHTeststring3", "testkeystring3", "REG_EXPAND_SZ"
Sh.RegWrite key & "WSHTestint", 123, "REG_DWORD"
WScript.Echo Sh.RegRead(key & "WSHTest")
WScript.Echo Sh.RegRead(key & "WSHTeststring1")
WScript.Echo Sh.RegRead(key & "WSHTeststring2")
WScript.Echo Sh.RegRead(key & "WSHTeststring3")
WScript.Echo Sh.RegRead(key & "WSHTestint")
Sh.RegDelete key & "WSHTest"

Il fonctionne.
J'ai testé avec psexec de cette façon :

psexec -s cmd /k cscript regquery.vbs

PsExec v1.82 - Execute processes remotely
Copyright (C) 2001-2007 Mark Russinovich
Sysinternals - www.sysinternals.com


Microsoft (R) Windows Script Host Version 5.7
Copyright (C) Microsoft Corporation. All rights reserved.

testkeydefault
testkeystring1
testkeystring2
testkeystring3
123



J'ai vérifié qu'on lisait de la même façon une valeur DWORD créée pour
l'occasion dans SAMSAM. Mais je n'obtiens pas le contenu de la valeur
BINARY F.

En examinant la RegRead Method dans l'aide, je vois pourquoi je
n'arrive pas à obtenir le contenu de la clé BINARY F avec regread. La
méthode retourne un tableau (VBArray of integers). Je verrai ça plus
tard.

Je me suis demandé pourquoi Vista 64 fonctionne chez toi car le
fonctionnement de ENA me semble à peu près le même que pour Vista 32.
N'aurais-tu pas modifié les droits sur le registre ?

Non, j'essaie de rester aussi standard que possible pour ne pas tomber
dans le piège "ça marche sur mon PC et pas chez les autres".

Ces modifications restent permanentes contrairement à ce que je supposais.

Si on parle bien des droits sur le registre, il faudrait effectivement
tout remettre dans l'état où on l'a trouvé en sortant du programme.
Quelle commande utilises-tu pour modifier les droits ?

Pour rappel :
Au cas où on aurait un malheur en accédant à ces clés sensibles, on se
récupère facilement si on utilise Erunt
http://fspsa.free.fr/erunt.htm

Si on n'avait pas prévu Erunt, on revient à un point de restauration
avec WINRE, ou on récupère la ruche concernée avec un BARTPE ou la CDR
http://fspsa.free.fr/problemes-irrecuperables.htm
http://fspsa.free.fr/problemes-irrecuperables.htm#la-strategie-locale-de-ce-systeme-ne-vous-permet-pas-d-ouvrir-une-session-de-maniere-interactive

http://www.commentcamarche.net/vbscript/vbs-wshshell.php3
http://briskoda.net/tech-shed/running-cmd-line-minimised-hidden/46185/

J'ai stocké les 2 liens fort instructifs dans mes favoris.

Ça me rappelle que j'ai fait une page de liens sur le VBS
http://fspsa.free.fr/vbscripting.htm
Si ça peut servir...

--
Salutations, Jean-François
http://fspsa.free.fr/Index-de-la-FAQ-WINXP-de-Panthere-Noire.htm
http://fspsa.free.fr/Capture-Ecran-et-Publication-vers-Newsgroups.htm
http://fspsa.free.fr/contamination-lecteurs-amovibles.htm

Bonjour Jean-François,

On avance...

Cette commande lit la valeur F :
psexec -s reg query HKLMSAMSAMDomainsAccountUsers00001F4 /v F

Génial. Je n'ai pas trouvé même après coup (le switch /v ou -v est utilisé
pour autre chose dans le help de psexec)

Redirection :
psexec -s reg query HKLMSAMSAMDomainsAccountUsers00001F4 /v
F>tmp.txt

Il ne faut surtout pas d'espace avant ">".

Transposition en VBS :

Pas de problème en VB6

Dim S As String
S = Environ("comspec") & " /c psexec -s reg query
hklmSAMSAMDomainsAccountUsers00001F4 /v F>tmp.txt"
Shell S, 0
'Lire le fichier
Open "tmp.txt" For Input As #1
'Effectue 3 inputs successifs afin de récupérer la valeur dans la
chaîne S
Input #1, S, S, S
Close 1
'éliminer ce qui précède la valeur
S = Trim$(Mid$(S, InStr(S, "REG_BINARY") + 10))
' développé provisoirement
S = Mid$(S, 8 * 7 * 2 + 1, 2)
Adm_Enabled = (Asc(S) = 10)

http://www.microsoft.com/downloads/details.aspx?FamilyId
592C48-207D-4BE1-8A76-1C4099D7BBB9>

En VBS on peut lire une clé avec Shell.RegRead() que j'ai trouvé dans

Oui, cela revient au même que l'utilisation des API dans VB.

En examinant la RegRead Method dans l'aide, je vois pourquoi je n'arrive
pas à obtenir le contenu de la clé BINARY F avec regread. La méthode
retourne un tableau (VBArray of integers). Je verrai ça plus tard.

En utilisant la méthode API équivalente et en traçant la variable, on
constate qu'il est détectée comme un String.
C'est pourquoi j'ai utilisé ce type de variable.

Je me suis demandé pourquoi Vista 64 fonctionne chez toi car le
fonctionnement de ENA me semble à peu près le même que pour Vista 32.
N'aurais-tu pas modifié les droits sur le registre ?

Non, j'essaie de rester aussi standard que possible pour ne pas tomber
dans le piège "ça marche sur mon PC et pas chez les autres".

Alors je ne comprend pas cette différence de comportement 32/64 bits.

Si on parle bien des droits sur le registre, il faudrait effectivement
tout remettre dans l'état où on l'a trouvé en sortant du programme.
Quelle commande utilises-tu pour modifier les droits ?

Manuellement...
J'ajoute mon nom d'utilisateur (groupe Administrateurs) en cliquant à droite
sur la clé correspondante. Je prends uniquement des droits de lecture.

http://fspsa.free.fr/vbscripting.htm
Si ça peut servir...

Plus complet que mes liens épars. :o)
--
Cordialement

Aski
MVP Windows Desktop Experience

*hey*
<#zfbSON8JHA.1492@TK2MSFTNGP03.phx.gbl>

psexec -s reg query HKLMSAMSAMDomainsAccountUsers00001F4 /v
F>tmp.txt

Il ne faut surtout pas d'espace avant ">".

Tiens ? Ça n'a pas d'importance ! Je n'en ai pas mis pour raccourcir la
ligne mais pourquoi des espaces gêneraient ? C'est le *résultat* de la
commande qui est redirigé. J'ai testé avec plein d'espaces et le
résultat est bien le même dans tmp.txt
On peut même mettre la redirection en début de ligne
http://fspsa.free.fr/lettre-lecteur-amovible.htm#mountvol-assignnewletter.cmd

Dim S As String
S = Environ("comspec") & " /c psexec -s reg query
hklmSAMSAMDomainsAccountUsers00001F4 /v F>tmp.txt"
Shell S, 0
'Lire le fichier
Open "tmp.txt" For Input As #1
'Effectue 3 inputs successifs afin de récupérer la valeur dans la
chaîne S
Input #1, S, S, S
Close 1
'éliminer ce qui précède la valeur
S = Trim$(Mid$(S, InStr(S, "REG_BINARY") + 10))
' développé provisoirement
S = Mid$(S, 8 * 7 * 2 + 1, 2)
Adm_Enabled = (Asc(S) = 10)

En VBS on peut lire une clé avec Shell.RegRead() que j'ai trouvé dans

Oui, cela revient au même que l'utilisation des API dans VB.

En examinant la RegRead Method dans l'aide, je vois pourquoi je n'arrive
pas à obtenir le contenu de la clé BINARY F avec regread. La méthode
retourne un tableau (VBArray of integers). Je verrai ça plus tard.

En utilisant la méthode API équivalente et en traçant la variable, on
constate qu'il est détectée comme un String.
C'est pourquoi j'ai utilisé ce type de variable.

Oui parce que tu manipules des chaines, non ?
C'est la commande reg query qui lit la valeur F.
Or cette commande ne connait pas les tableaux ==> résultat = chaine.
Alors que la méthode VBS regread renvoie un tableau pour une BINARY.
C'est là la différence entre les deux façons de procéder.

Je me suis demandé pourquoi Vista 64 fonctionne chez toi car le
fonctionnement de ENA me semble à peu près le même que pour Vista 32.
N'aurais-tu pas modifié les droits sur le registre ?

Non, j'essaie de rester aussi standard que possible pour ne pas tomber dans
le piège "ça marche sur mon PC et pas chez les autres".

Alors je ne comprend pas cette différence de comportement 32/64 bits.

ENA-1-0-10

VISTA 32 :
Je note que ENA semble ne pas vérifier pas le résultat.
Il indique "Le compte administrateur est activé".
Mais au lancement suivant de ENA, on a à nouveau
"Le compte administrateur est désactivé"
J'ai désactivé l'UAC, redémarré, sans amélioration.
Qu'est-ce qu'on modifie dans Vista pour activer le BIA ?

VISTA 64 :
Toujours ok.

Si on parle bien des droits sur le registre, il faudrait effectivement tout
remettre dans l'état où on l'a trouvé en sortant du programme.
Quelle commande utilises-tu pour modifier les droits ?

Manuellement...

Mais comment comptes-tu automatiser l'opération ?

J'ajoute mon nom d'utilisateur (groupe Administrateurs) en cliquant à droite
sur la clé correspondante. Je prends uniquement des droits de lecture.

OK. Je croyais que tu avais trouvé la façon d'ouvrir l'accès à SAMSAM
de façon plus scriptée :)

--
Salutations, Jean-François
http://fspsa.free.fr/lenteur.htm

> Alors je ne comprend pas cette différence de comportement 32/64 bits.

La commande net user administrateur /active:yes
donne toujours de bons résultats.
Mais pas ENA sur le Vista32....
ENA arrive à désactiver le BIA.
Mais pas à le réactiver.

--
Salutations, Jean-François
http://fspsa.free.fr/Index-de-la-FAQ-WINXP-de-Panthere-Noire.htm
http://fspsa.free.fr/Capture-Ecran-et-Publication-vers-Newsgroups.htm
http://fspsa.free.fr/Virus-Malwares-Comment-on-se-fait-infecter.htm

Bonsoir Jean-François,

Il ne faut surtout pas d'espace avant ">".

Tiens ? Ça n'a pas d'importance !

Oui, tu as raison, j'ai trouvé pourquoi j'avais cette erreur de lecture de
fichier que j'avais injustement attribuée à ces malheureux espaces.
Dans mes tests je n'effaçais pas systématiquement tmp.txt :
- lorsqu'ils étaient effacés, il y avait erreur de lecture (que j'attribuais
à l'espace ajouté)
- lorsqu'ils ne l'étaient pas, tmp.txt n'était pas encore créé lorsqu'on
arrivait à l'ouverture du fichier.
Le responsable est donc Shell dont la fin d'exécution doit être contrôlée
(il existe des méthodes).

Dim S As String
S = Environ("comspec") & " /c psexec -s reg query
hklmSAMSAMDomainsAccountUsers00001F4 /v F>tmp.txt"
Shell S, 0
'Lire le fichier
Open "tmp.txt" For Input As #1
'Effectue 3 inputs successifs afin de récupérer la valeur dans la
chaîne S
Input #1, S, S, S
Close 1
'éliminer ce qui précède la valeur
S = Trim$(Mid$(S, InStr(S, "REG_BINARY") + 10))
' développé provisoirement
S = Mid$(S, 8 * 7 * 2 + 1, 2)
Adm_Enabled = (Asc(S) = 10)

En utilisant la méthode API équivalente et en traçant la variable, on
constate qu'il est détectée comme un String.
C'est pourquoi j'ai utilisé ce type de variable.

Oui parce que tu manipules des chaines, non ?

Oui.

C'est la commande reg query qui lit la valeur F.

C'est en utilisant l'API (avec les droits adéquats) que j'ai pu constater
que le système considérait la valeur comme une chaîne.

Or cette commande ne connait pas les tableaux ==> résultat = chaine.
Alors que la méthode VBS regread renvoie un tableau pour une BINARY.
C'est là la différence entre les deux façons de procéder.

Au départ, je pensais avoir à traiter un tableau de binaires comme indiqué
par le types.

ENA-1-0-10

VISTA 32 :
Je note que ENA semble ne pas vérifier pas le résultat.
Il indique "Le compte administrateur est activé".
Mais au lancement suivant de ENA, on a à nouveau
"Le compte administrateur est désactivé"
J'ai désactivé l'UAC, redémarré, sans amélioration.
Qu'est-ce qu'on modifie dans Vista pour activer le BIA ?

VISTA 64 :
Toujours ok.

Je n'ai pas mis en ligne la nouvelle version que tu as déjà testée
(heureusement :o) ).
Il faut que je fasse demain en y intégrant PSEXEC.

La version 10 vérifie pour XP les 2 conditions après exécution de la
commande. Mais je n'avais pas encore étendu la vérification à Vista/Seven.
C'est fait maintenant.
Pour XP, les 2 éléments sont la fameuse valeur F de SAM et la valeur
Administrateur de UserList.
Pour Vista, les 2 éléments sont la fameuse valeur F de SAM et la propriété
"AccountDisabled" de l'objet "WinNT://./Administrateur,User

J'ajoute mon nom d'utilisateur (groupe Administrateurs) en cliquant à
droite sur la clé correspondante. Je prends uniquement des droits de
lecture.

C'est ce que je faisais avant d'utiliser PSEXEC. Je répondais à ta question
("Quelle commande utilises-tu pour modifier les droits ?").

OK. Je croyais que tu avais trouvé la façon d'ouvrir l'accès à SAMSAM de
façon plus scriptée :)

Je t'ai donné le code ! (ne te moquerais-tu un tantinet ?). ;o)
--
Cordialement

Aski
MVP Windows Desktop Experience
http://dechily.org/
http://dechily.org/Forum_Aski/

"JF" <jf@news.invalid> a écrit dans le message de groupe de discussion :
OW4lpaQ8JHA.5400@TK2MSFTNGP03.phx.gbl...

Alors je ne comprend pas cette différence de comportement 32/64 bits.

La commande net user administrateur /active:yes
donne toujours de bons résultats.
Mais pas ENA sur le Vista32....

Elle n'y était pas encore sur la version 10 (32 et 64).

ENA arrive à désactiver le BIA.
Mais pas à le réactiver.

Cela me paraît logique compte tenu de l'absence de modification de F.
Cela devrait être la même chose sur 32 et 64, non ?

Attendons la version 11 (avec PSEXEC) promise demain.
--
Aski