Je voudrais pouvoir accéder à une clé de la base de registre en vbscript par
.regread et .regwrite.
J'ai réussi à le faire en changeant les permissions sur cette clé (droits
administrateurs) depuis RegEdit.
Je n'ai pas trouvé comment modifier directement ces permissions en vbs avant
de lire ou d'écrire dans cette clé.
Avez-vous des tuyaux sur la question ?
merci d'avance.
--
Cordialement
Aski
MVP Windows Desktop Experience
http://dechily.org/
http://dechily.org/Forum_Aski/
Tu peux utiliser Subinacl.exe, de chez MS.
(voir : http://minilien.fr/a0jn84 )
--
@-salutations
--
Michel Claveau
> Je voudrais pouvoir accéder à une clé de la base de registre en
> vbscript par .regread et .regwrite.
> J'ai réussi à le faire en changeant les permissions sur cette clé
> (droits administrateurs) depuis RegEdit.
> Je n'ai pas trouvé comment modifier directement ces permissions en
> vbs avant de lire ou d'écrire dans cette clé.
avec SetAcl
dont il est question dans le fil lancé par MCI
... peut-être ;o)
HB
Effectivement, cela me semble une voie car je ne vois pas comment les APIs
de gestion de la base de registre pourraient permettre de forcer les
permissions.
Merci pour ton idée.
Autrement il y a regini.exe que tu peut scripter avec Oshell.run etc
...
mais je ne suis pas sûr qu'il tourne correctement sur XP et encore
moins Vista
HB
>>>> Je voudrais pouvoir accéder à une clé de la base de registre en
>>>> vbscript par .regread et .regwrite.
>>>> J'ai réussi à le faire en changeant les permissions sur cette clé
>>>> (droits administrateurs) depuis RegEdit.
>>>> Je n'ai pas trouvé comment modifier directement ces permissions en
>>>> vbs avant de lire ou d'écrire dans cette clé.
>>>
>>> avec SetAcl
>>> dont il est question dans le fil lancé par MCI
>>> ... peut-être ;o)
>>
>> Effectivement, cela me semble une voie car je ne vois pas comment les
>> APIs de gestion de la base de registre pourraient permettre de forcer
>> les permissions.
>> Merci pour ton idée.
> Autrement il y a regini.exe que tu peut scripter avec Oshell.run etc ...
> mais je ne suis pas sûr qu'il tourne correctement sur XP et encore moins
> Vista
Après avoir potassé la documentation, il me semble bien que je vais y
arriver avec SetAcl.
Mon but est de "réveiller" le compte "Administrateur sur XP, Vista, Seven
avec le même script (ou programme).
Cela élimine donc tout exe non compatible avec XP et Vista.
La version exe de SetAcl est bien documentée, ce qui n'est pas le cas de la
version OCX.
La version exe peut également être lancée par oShell.run.
Bonsoir,
[...]
| Mon but est de "réveiller" le compte "Administrateur sur XP, Vista,
| Seven avec le même script (ou programme).
Il est possible d'activer un compte utilisateur via le Provider ADSI
WinNT en effaçant le bit 1 de l'attribut UserFlags :
--- CodeSnippet.vbs ---
Set oUser=GetObject("WinNT://./Administrateur,User")
oUser.UserFlags=oUser.UserFlags And &HFFFFFFFD
oUser.SetInfo
--- CodeSnippet.vbs ---
--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
Aski wrote:
(...)
> Mon but est de "réveiller" le compte "Administrateur sur XP, Vista,
> Seven avec le même script (ou programme).
qu'entends tu par "réveiller" ???
HB
> qu'entends tu par "réveiller" ???
Le compte "Administrateur", quelques fois qualifié de "Super Administrateur"
n'apparaît pas dans les comptes utilisateurs.
Pour XP Home, il faut lancer XP en mode sans échec.
Pour XP Pro, Vista et Seven, il faut faire un certain nombre de manips pour
le rendre visible.
Voici un exemple
http://www.commentcamarche.net/faq/sujet-5963-utiliser-l-administrateur-cache-de-vista
Comme ces manips sont différentes suivant le type d'OS, j'ai réalisé un
script qui détecte cette version et je recherche le moyen de faire
apparaître (et disparaître) ce mode Administrateur automatiquement.
JCB nous a indiqué comment on pouvait le faire en changeant un octet de
HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\000001F4\F
ce qui n'est possible qu'en donnant les permissions nécessaires sur la clé
HKEY_LOCAL_MACHINE\SAM\SAM\.
> Il est possible d'activer un compte utilisateur via le Provider ADSI
> WinNT en effaçant le bit 1 de l'attribut UserFlags :
>
> --- CodeSnippet.vbs ---
> Set oUser=GetObject("WinNT://./Administrateur,User")
> oUser.UserFlags=oUser.UserFlags And &HFFFFFFFD
> oUser.SetInfo
> --- CodeSnippet.vbs ---
Je ne connaissais pas cette possibilité qui semble simple comme bonjour.
Je vais tester sur une virtuelle de Seven.
Beaucoup de documentation, mais il fallait le savoir ...
http://support.microsoft.com/gp/docfratechno/fr
Saurais-tu où de cache ce fameux bit dans le registre ?
Bonjour Aski,
[...]
| Saurais-tu oů de cache ce fameux bit dans le registre ?
A l'endroit que tu cites :
HKLM\SAM\SAM...
Le Provider ADSI WinNT retourne dans l'attribut UserFlags une partie de
la valeur binaire du registre. Cette partie de la valeur binaire du
registre est ainsi automatiquement convertie en une valeur 32 bits
documentée ce qui facilite grandement la manipulation des paramčtres
utilisateurs ;-)
UserFlags :
http://msdn.microsoft.com/en-us/library/aa772300(VS.85).aspx
> Le Provider ADSI WinNT retourne dans l'attribut UserFlags une partie de
> la valeur binaire du registre. Cette partie de la valeur binaire du
> registre est ainsi automatiquement convertie en une valeur 32 bits
> documentée ce qui facilite grandement la manipulation des paramètres
> utilisateurs ;-)
>
> UserFlags :
> http://msdn.microsoft.com/en-us/library/aa772300(VS.85).aspx
Providentiel ce Provider.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADs\Providers\WinNT\
existe bien sur 2k, XP, Vista et Seven
Par contre, on ne trouve les sous-clés Extensions\User que sous Vista et
Seven.
J'ai réussi mes tests sur Seven.
Il faut que je vérifie sur les autres OS.
Sur XP Home, le bit est à 0 mais le "Super Administrateur" n'apparaît qu'en
mode sans échec (by design).
Merci pour ton aide efficace.
> Bonjour,
>
> Je voudrais pouvoir accéder à une clé de la base de registre en vbscript par
> .regread et .regwrite.
> J'ai réussi à le faire en changeant les permissions sur cette clé (droits
> administrateurs) depuis RegEdit.
> Je n'ai pas trouvé comment modifier directement ces permissions en vbs avant
> de lire ou d'écrire dans cette clé.
> Avez-vous des tuyaux sur la question ?
> merci d'avance.
REGINI est présent sur Vista.
On peut l'ajouter à XP
%programfiles%\Windows Resource Kits\Tools\regini.exe
J'ai testé sur Vista et XP la commande
regini permissions.txt
avec permissions.txt ayant pour contenu :
HKEY_LOCAL_MACHINE\Software\bidon [1 5 17]
Les permissions de la clé bidon créée pour l'occasion ont bien été
modifiées comme attendu.
Attention au fait que regini remplace les permissions.
Sources :
Un script VBS pour utiliser regeni
http://blogs.msdn.com/alejacma/archive/2008/03/11/how-to-change-registry-permissions-with-regini-exe-vbscript.aspx
regini /?
...
1 - Administrators Full Access
2 - Administrators Read Access
3 - Administrators Read and Write Access
4 - Administrators Read, Write and Delete Access
5 - Creator Full Access
6 - Creator Read and Write Access
7 - World Full Access
8 - World Read Access
9 - World Read and Write Access
10 - World Read, Write and Delete Access
11 - Power Users Full Access
12 - Power Users Read and Write Access
13 - Power Users Read, Write and Delete Access
14 - System Operators Full Access
15 - System Operators Read and Write Access
16 - System Operators Read, Write and Delete Access
17 - System Full Access
18 - System Read and Write Access
19 - System Read Access
20 - Administrators Read, Write and Execute Access
21 - Interactive User Full Access
22 - Interactive User Read and Write Access
23 - Interactive User Read, Write and Delete Access
http://support.microsoft.com/search/default.aspx?query=regini
--
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
>> Je voudrais pouvoir accéder à une clé de la base de registre en vbscript
>> par .regread et .regwrite.
>> J'ai réussi à le faire en changeant les permissions sur cette clé (droits
>> administrateurs) depuis RegEdit.
> REGINI est présent sur Vista.
> On peut l'ajouter à XP
> %programfiles%\Windows Resource Kits\Tools\regini.exe
> J'ai testé sur Vista et XP la commande
> regini permissions.txt
> avec permissions.txt ayant pour contenu :
> HKEY_LOCAL_MACHINE\Software\bidon [1 5 17]
> Les permissions de la clé bidon créée pour l'occasion ont bien été
> modifiées comme attendu.
> Attention au fait que regini remplace les permissions.
Merci Jean-François.
Si je comprends bien, il est nécessaire de passer par un fichier que RegIni
lit pour déterminer les permissions à accorder ce qui est une bonne solution
pour le déploiement.
Par contre, si j'ai bien compris on message et la doc, RegIni ne permet pas
d'enlever des permissions.
Aski wrote:
(...)
> Si je comprends bien, il est nécessaire de passer par un fichier que
> RegIni lit pour déterminer les permissions à accorder ce qui est une
> bonne solution pour le déploiement.
Tout dépend du contexte ...
Quand on parle de "déploiement" c'est à priori que l'environnement
dispose peut-être déjà d'outils adaptés...
( on est dans un réseau avec un serveur et tout ce qui se visse
dessus )
Dans un domaine, il me semble nettement préférable d'utiliser les GPO
( paramètres de sécurité -> registre )
C'est plus souple et plus précis que Regini qui se limite à faire un
"prix de gros" ...
SetAcl, évoqué dans un autre fil de ce NG, me semble lui aussi
beaucoup plus précis que Regini....
Bref...
Pour moi Regini est dérivé d'anciens outils de NT/2000
et n'a pas trop suivi l'évolution...
C'est un peu comme CACLS comparé aux possibilités réelles...
( avec XCACLS par exemple)
Ceci étant, en dehors d'autres possibilités, ça peut rendre service
;o)
HB
> Tout dépend du contexte ...
> Quand on parle de "déploiement" c'est à priori que l'environnement
> dispose peut-être déjà d'outils adaptés...
> ( on est dans un réseau avec un serveur et tout ce qui se visse dessus )
>
> Dans un domaine, il me semble nettement préférable d'utiliser les GPO
> ( paramètres de sécurité -> registre )
> C'est plus souple et plus précis que Regini qui se limite à faire un "prix
> de gros" ...
>
> SetAcl, évoqué dans un autre fil de ce NG, me semble lui aussi
> beaucoup plus précis que Regini....
>
> Bref...
>
> Pour moi Regini est dérivé d'anciens outils de NT/2000
> et n'a pas trop suivi l'évolution...
> C'est un peu comme CACLS comparé aux possibilités réelles...
> ( avec XCACLS par exemple)
>
> Ceci étant, en dehors d'autres possibilités, ça peut rendre service ;o)
... et que penses-tu du "Provider ADSI" évoqué par Gilles ?
Aski wrote:
>
> ... et que penses-tu du "Provider ADSI" évoqué par Gilles ?
>
> --
1. Ce provider ne sert pas à accéder aux acl du registre
mais à faire le réglage ( L'histoire de administrateur)
"autrement"
La gestion des ACL ( Systeme de fichier ou registre )
directement avec les outils natifs ( VBS + WMI + etc ...)
est possible mais c'est plutôt très compliqué .
J'avais fait un script pour créer automatiquement un partage
et y régler correctement les ACL et je n'avais pas rigolé !
Donc ... un outil tiers ( ou pas) qui simplifie l'accès est toujours
bon à prendre.
Ceci étant, je n'ai pas la prétention de tout savoir ;o)
HB
Oui, j'ai bien l'impression que le Provider est très efficace pour les
spécialistes, mais peut-être aussi dangereux.
SetAcl me semble plus maîtrisable.
--
Cordialement
Aski
> Bonjour Jean-François,
>
>>> Je voudrais pouvoir accéder à une clé de la base de registre en vbscript
>>> par .regread et .regwrite.
>>> J'ai réussi à le faire en changeant les permissions sur cette clé (droits
>>> administrateurs) depuis RegEdit.
>
>> REGINI est présent sur Vista.
>> On peut l'ajouter à XP
>> %programfiles%\Windows Resource Kits\Tools\regini.exe
>> J'ai testé sur Vista et XP la commande
>> regini permissions.txt
>> avec permissions.txt ayant pour contenu :
>> HKEY_LOCAL_MACHINE\Software\bidon [1 5 17]
>> Les permissions de la clé bidon créée pour l'occasion ont bien été
>> modifiées comme attendu.
>> Attention au fait que regini remplace les permissions.
>
> Merci Jean-François.
> Si je comprends bien, il est nécessaire de passer par un fichier que RegIni
> lit pour déterminer les permissions à accorder
Oui.
> ce qui est une bonne solution pour le déploiement.
> Par contre, si j'ai bien compris on message et la doc, RegIni ne permet pas
> d'enlever des permissions.
Par <<Attention au fait que regini remplace les permissions>> je
voulais justement exprimer que regini écrase tout. J'ai vérifié en
mettant à Refuser tous les Utilisateurs et Groupes utilisateurs de ma
clé "bidon". No problemo, un coup de regini, et c'est nettoyé. Si
j'ajoute manuellement un groupe utilisateur dans les permissions il est
supprimé par Regini si on ne l'avait pas prévu dans le fichier de
script. Ce n'est pas aussi fin que subinacl (non utilisable sur Vista).
J'ai pensé qu'il était utile de connaître cette solution regini parce
qu'elle ne fait appel à aucun fichier externe (avec Vista).
SETACL a l'air prometteur, je suppose que tu vas finir par l'adopter.
--
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
> Par <<Attention au fait que regini remplace les permissions>> je voulais
> justement exprimer que regini écrase tout. J'ai vérifié en mettant à
> Refuser tous les Utilisateurs et Groupes utilisateurs de ma clé "bidon".
> No problemo, un coup de regini, et c'est nettoyé. Si j'ajoute manuellement
> un groupe utilisateur dans les permissions il est supprimé par Regini si
> on ne l'avait pas prévu dans le fichier de script. Ce n'est pas aussi fin
> que subinacl (non utilisable sur Vista).
J'ai bien compris que tu savais mais je voulais quand même m'assurer que je
n'avais pas sauté une étape.
> J'ai pensé qu'il était utile de connaître cette solution regini parce
> qu'elle ne fait appel à aucun fichier externe (avec Vista).
>
> SETACL a l'air prometteur, je suppose que tu vas finir par l'adopter.
Probablement.
La méthode donnée par Gilles fonctionne parfaitement dans les 2 sens, mais
je je suis pas sûr de bien comprendre la structure de ce fameux UserFlags.
Elle ne nécessite en principe aucun programme spécifique depuis NT.
J'hésite donc encore .... :o)
--
Amicalement, Henri
Tu es sûr que SubInAcl ne fonctionne pas sous Vista.... pas testé mais
j'ai un doute il me semble avoir vu quelque chose de JCB à ce sujet ..
ou peut-être
http://blogs.msdn.com/astebner/archive/2006/09/04/739820.aspx
--
Amicalement,
jackr13
> Probablement.
> La méthode donnée par Gilles fonctionne parfaitement dans les 2 sens, mais
> je je suis pas sûr de bien comprendre la structure de ce fameux UserFlags.
> Elle ne nécessite en principe aucun programme spécifique depuis NT.
> J'hésite donc encore .... :o)
Voici la solution que j'ai finalement retenue
--------------- Code
Option explicit
dim oUser
Set oUser=GetObject("WinNT://./Administrator,User")
oUser.AccountDisabled=false ' ou true pour désactiver/activer
oUser.SetInfo
Set oUser=nothing
wscript.quit 0
-----------------------------
Merci à Gilles, Jean-François et Lotre pour les axes de recherche qui m'ont
permis d'atteindre le résultat.
La doc se trouve ici.
http://msdn.microsoft.com/en-us/library/aa772235(VS.85).aspx
> Voici la solution que j'ai finalement retenue>
....
> Merci à Gilles, Jean-François et Lotre pour les axes de recherche qui
> m'ont permis d'atteindre le résultat.
> La doc se trouve ici.
> http://msdn.microsoft.com/en-us/library/aa772235(VS.85).aspx
Et sans oublier Jean-Claude qui nous a indiqué où trouver ce fameux bit de
SAM.
Bonsoir,
| Voici la solution que j'ai finalement retenue
|
| --------------- Code
| Option explicit
| dim oUser
|
| Set oUser=GetObject("WinNT://./Administrator,User")
| oUser.AccountDisabled=false ' ou true pour désactiver/activer
| oUser.SetInfo
| Set oUser=nothing
| wscript.quit 0
| -----------------------------
| Merci à Gilles, Jean-François et Lotre pour les axes de recherche qui
| m'ont permis d'atteindre le résultat.
| La doc se trouve ici.
| http://msdn.microsoft.com/en-us/library/aa772235(VS.85).aspx
Choix très judicieux et sage ;-)
La manipulation "live" des données de la base SAM est à procrire.
Pour rappel :
http://fspsa.free.fr/mises-a-jour.htm#reinitialiser-registre
Aaron site Vista dans son texte mais il ne donne pas de témoignage de
réussite avec Vista.
Le téléchargement de subinacl indique
Supported Operating Systems:
Windows 2000; Windows Server 2003; Windows XP
http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b
La page date de 2004.
Le programme est sans doute tout de même utilisable sous Vista mais je
ne peux pas le recommander sans référence plus explicite.
Je vois qu'il est proposé par des intervenants pour Vista :
http://groups.google.com/group/microsoft.public.windows.vista.general/msg/866b58c41778863b
http://groups.google.com/group/microsoft.public.windows.vista.general/search?q=subinacl
TEST
J'ai téléchargé subinacl sur Vista.
Il s'est installé en
%ProgramFiles(x86)%\Windows Resource Kits\Tools\
Il fonctionne pour les fichiers d'après ce que j'ai testé.
Mais pas avec le registre, il ne trouve pas la clé ==>
subinacl /keyreg SOFTWARE\bidon /grant=system=f
HKEY_LOCAL_MACHINE\SOFTWARE\bidon : 2 The system cannot find the file
specified.
Done: 1, Modified 0, Failed 1, Syntax errors 0
Last Done : HKEY_LOCAL_MACHINE\SOFTWARE\bidon
Last Failed: HKEY_LOCAL_MACHINE\SOFTWARE\bidon : 2 The system cannot
find the file specified.
Sur XP ça marche bien, voici ce que ça donne :
subinacl /keyreg SOFTWARE\bidon /grant=system=f
SOFTWARE\bidon : delete Perm. ACE 0 autorite nt\system
SOFTWARE\bidon : new ace for autorite nt\system
HKEY_LOCAL_MACHINE\SOFTWARE\bidon : 2 change(s)
Done: 1, Modified 1, Failed 0, Syntax errors 0
subinacl /subkeyreg SOFTWARE\bidon /grant=system=f
SOFTWARE\bidon : delete Perm. ACE 7 autorite nt\system
SOFTWARE\bidon : delete Perm. ACE 6 autorite nt\system
SOFTWARE\bidon : new ace for autorite nt\system
HKEY_LOCAL_MACHINE\SOFTWARE\bidon : 3 change(s)
SOFTWARE\bidon\sousbidon : delete Perm. ACE 0 autorite nt\system
SOFTWARE\bidon\sousbidon : new ace for autorite nt\system
HKEY_LOCAL_MACHINE\SOFTWARE\bidon\sousbidon : 2 change(s)
Pour info :
Error message when you use Windows Update or
Microsoft Update Web sites to install updates: 0x80070005
http://support.microsoft.com/kb/968003
Cette KB968003 datée de 2009 indique la solution
subinacl pour XP ET Vista, après avoir donné le lien
http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b#AffinityDownloads
qui rappelle ==>
Supported Operating Systems:
Windows 2000; Windows Server 2003; Windows XP
La commande indiquée fonctionne sur Vista !
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
Pas trouvé pourquoi ça ne fonctionne pas sur la clé bidon avec Vista.
--
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
et
un grand merci pour cette synthèse !
HB
> Bonjour,
> un grand merci pour cette synthèse !
Oui, mais il reste le problème que ça n'a pas marché pour ma petite
sous-clé bidon sur Vista. Ça me chiffonne parce que JCB avait déclaré
que cette version de subinacl était ok pour Vista, et comme il n'a pas
l'habitude de raconter des cracs, je dois faire une confuse quelque
part
http://groups.google.fr/group/microsoft.public.fr.windowsxp/msg/d591fe9fd20c6884
--
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/Google-N-Est-Plus-Mon-Ami.htm
Juste pour info. J'utilise Subinacl, sous Vista, pour désactiver, par
batch, les messages du centre de sécurité, lorsque celui ci a été
désactivé (les messages intempestifs restent quand même, et
l'utilisation ne peut pas changer ça, car le centre de sécu ne s'ouvre
plus).
Cette opération nécessite de de venir propriétaire de clefs du registre,
avant de pouvoir y effectuer des modifs.
A priori, Subinacl a toujours bien fonctionné sous Vista (je n'ai pas
essayé qu'avec Vista-32).
--
@-salutations
--
Michel Claveau
Bonjour,
| Oui, mais il reste le problème que ça n'a pas marché pour ma petite
| sous-clé bidon sur Vista. Ça me chiffonne parce que JCB avait déclaré
| que cette version de subinacl était ok pour Vista, et comme il n'a pas
| l'habitude de raconter des cracs, je dois faire une confuse quelque
| part
|
http://groups.google.fr/group/microsoft.public.fr.windowsxp/msg/d591fe9fd20c6884
Je ne suis pas confronté à ce problème :
Product Name: Microsoft Windows Vista Édition Intégrale
Service Pack:
Build number: 6.0.6000
Z:\Download>subinacl /keyreg SOFTWARE\bidon /grant=system=f
SOFTWARE\bidon : delete Perm. ACE 5 autorite nt\system
SOFTWARE\bidon : delete Perm. ACE 4 autorite nt\system
SOFTWARE\bidon : new ace for autorite nt\system
HKEY_LOCAL_MACHINE\SOFTWARE\bidon : 3 change(s)
Elapsed Time: 00 00:00:00
Done: 1, Modified 1, Failed 0, Syntax errors
0
Last Done : HKEY_LOCAL_MACHINE\SOFTWARE\bidon
Je suppose que vous utilisez Vista 64bits. L'outil SubInAcl étant une
application 32bits, avez-vous bien créé la sous-clé "bidon" à l'aide de
l'Editeur du Registre 32bits (C:\Windows\SysWow64\regedit.exe) ?
Comme toujours en plein dans le mille Gilles.
http://support.microsoft.com/kb/305097
http://support.microsoft.com/kb/896459
http://download.microsoft.com/download/3/a/9/3a9ad58f-5634-4cdd-8528-c78754d712e8/28-DW04040_WINHEC2004.ppt
Clée bidon recréée avec SysWow64\regedit.exe
Après avoir supprimé la permission system de bidon ==>
subinacl /subkeyreg SOFTWARE\bidon /grant=system=f
SOFTWARE\bidon : delete Perm. ACE 5 nt authority\system
SOFTWARE\bidon : delete Perm. ACE 4 nt authority\system
SOFTWARE\bidon : new ace for nt authority\system
HKEY_LOCAL_MACHINE\SOFTWARE\bidon : 3 change(s)
Elapsed Time: 00 00:00:00
Done: 1, Modified 1, Failed 0, Syntax errors 0
Last Done : HKEY_LOCAL_MACHINE\SOFTWARE\bidon
M E R C I !
Parce que je me suis déjà fait avoir ;-)
La présentation PowerPoint est très bien faite !
Il fallait la dénicher celle-là !
> Voici la solution que j'ai finalement retenue
>
> --------------- Code
> Set oUser=GetObject("WinNT://./Administrator,User")
> oUser.AccountDisabled=false ' ou true pour désactiver/activer
> oUser.SetInfo
> -----------------------------
> Merci à Gilles, Jean-François et Lotre pour les axes de recherche qui
> m'ont permis d'atteindre le résultat.
> La doc se trouve ici.
> http://msdn.microsoft.com/en-us/library/aa772235(VS.85).aspx
De plus, j'ai légèrement modifié le code fourni par Gilles pour déterminer
l'intitulé exact de l'administrateur, quelle que soit la localisation de
l'OS.
Ce code fonctionne pour XP, Vista et Seven.
Je ne sais pas quelle en serait la traduction en hollandais, japonais ou
arabe.
Elle pourrait être, suivant mon dico :o)
beheerder
管理者
المسؤول
--------------- Code
Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_UserAccount
Where LocalAccount = True And SID LIKE '%-500'")
For Each objItem In colItems
MsgBox "Name: " & objItem.Name
Next
-----------------------------
>>> Mon but est de "réveiller" le compte "Administrateur" sur XP, Vista,
>>> Seven avec le même script (ou programme).
>>> Cela élimine donc tout exe non compatible avec XP et Vista.
>> Voici la solution que j'ai finalement retenue
>>
>> --------------- Code
>> Set oUser=GetObject("WinNT://./Administrator,User")
>> oUser.AccountDisabled=false ' ou true pour désactiver/activer
>> oUser.SetInfo
>> -----------------------------
>> Merci à Gilles, Jean-François et Lotre pour les axes de recherche qui m'ont
>> permis d'atteindre le résultat.
>> La doc se trouve ici.
>> http://msdn.microsoft.com/en-us/library/aa772235(VS.85).aspx
>
> De plus, j'ai légèrement modifié le code fourni par Gilles pour déterminer
> l'intitulé exact de l'administrateur, quelle que soit la localisation de
> l'OS.
> Ce code fonctionne pour XP, Vista et Seven.
> Je ne sais pas quelle en serait la traduction en hollandais, japonais ou
> arabe.
> Elle pourrait être, suivant mon dico :o)
> beheerder
> ����І者
> المسؤول
>
> --------------- Code
> Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
> Set colItems = objWMIService.ExecQuery("Select * from Win32_UserAccount
> Where LocalAccount = True And SID LIKE '%-500'")
> For Each objItem In colItems
> MsgBox "Name: " & objItem.Name
> Next
> -----------------------------
Sympa, ça pourrait servir.
Ça marche comme tu veux sur tous les OS quel que soit le nom donné à
l'Administrateur ?
As-tu prévu un script pour revenir à la situation normale ?
--
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
>> De plus, j'ai légèrement modifié le code fourni par Gilles pour
>> déterminer l'intitulé exact de l'administrateur, quelle que soit la
>> localisation de l'OS.
>> Ce code fonctionne pour XP, Vista et Seven.
>> Je ne sais pas quelle en serait la traduction en hollandais, japonais ou
>> arabe.
>> Elle pourrait être, suivant mon dico :o)
>> beheerder
>> ���І者
>> المسؤول
>>
>> --------------- Code
>> Set objWMIService = GetObject("winmgmts:\\.\root\cimv2")
>> Set colItems = objWMIService.ExecQuery("Select * from Win32_UserAccount
>> Where LocalAccount = True And SID LIKE '%-500'")
>> For Each objItem In colItems
>> MsgBox "Name: " & objItem.Name
>> Next
>> -----------------------------
>
> Sympa, ça pourrait servir.
> Ça marche comme tu veux sur tous les OS quel que soit le nom donné à
> l'Administrateur ?
> As-tu prévu un script pour revenir à la situation normale ?
J'ai testé sur XP Home et Pro, Vista et Seven.
J'aurais pu ne prendre que le premier objet dans la liste qui semble être
systématiquement l'administrateur (le vrai).
C'est le SID qui détermine si l'utilisateur de l'énumération est
l'Administrateur.
http://support.microsoft.com/kb/243330
Donc, on se moque de son "pseudo".
Par contre, on en a besoin pour modifier les valeurs du registre soit sur
Vista/Seven, soit sur XP Pro (méthodes différentes).
Le script est prévu pour afficher l'état et pour rendre actif ou non
l'administrateur.
Par contre, il faut que je vérifie ce qui se passe dans le cas où on est sur
une session Administrateur.
Il faudrait certainement que je ne puisse désactiver l'Administrateur que je
suis dans une autre session.
HS : Ça me rappelle qu'il faut que je demande qu'on corrige le nom
donné au SID S-1-5-13 (même en anglais il y a un S à Server Terminal
User)
> Donc, on se moque de son "pseudo".
Oui, c'est tout l'intérêt de passer par le SID. Donc ça devrait marcher
pour les autres langues et pour les cas où l'utilisateur a changé le
nom de l'Administrateur.
> Par contre, on en a besoin pour modifier les valeurs du registre soit sur
> Vista/Seven, soit sur XP Pro (méthodes différentes).
On a besoin d'être Administrateur pour modifier le registre et tu
proposes donc de permettre un accès plus facile à ce Compte caché.
> Le script est prévu pour afficher l'état et pour rendre actif ou non
> l'administrateur.
On peut restaurer la situation après l'intervention, c'était ma
question. Merci.
> Par contre, il faut que je vérifie ce qui se passe dans le cas où on est sur
> une session Administrateur.
Pas grand chose sans doute, mais tu as raison de vérifier.
> Il faudrait certainement que je ne puisse désactiver l'Administrateur que je
> suis dans une autre session.
Pour sûr !
>> Par contre, on en a besoin pour modifier les valeurs du registre soit sur
>> Vista/Seven, soit sur XP Pro (méthodes différentes).
>
> On a besoin d'être Administrateur pour modifier le registre et tu proposes
> donc de permettre un accès plus facile à ce Compte caché.
Il suffit d'être dans le groupe "Administrateurs".
Mon but est de permettre à tous de le faire sans aller bricoler dans le
registre et sans connaître les diverses manips à effectuer (différentes en
fonction de l'OS) pour y arriver.
De plus, dans le cas de Vista/Seven, il faut modifier les permissions de la
clé SAM\SAM si on veut intervenir directement dans le registre.
>> Il faudrait certainement que je ne puisse désactiver l'Administrateur que
>> je suis dans une autre session.
>
> Pour sûr !
Ouais, mais je l'avais oublié avant de te répondre.
Comme quoi, il est excellent d'être obligé d'écrire ce que l'on fait.