Hello,
Je dispose d'un réseau "point à point" de 5 PC, XP Pro et XP Home mélangés,
toutes les connexions fichiers, dossiers et internet sont au point.
Tous les utilisateurs sont de type "Administrateur", WMI est installé sur
toutes les machines, d'une "console WMI", j'accède au service WMI de
n'importe quel PC, MAIS pour le code VBS suivant :
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
Jean-Claude BELLAMY
Dans le message news: , Xavier HALOUCHERY s'est ainsi exprimé:
Hello, Je dispose d'un réseau "point à point" de 5 PC, XP Pro et XP Home mélangés, toutes les connexions fichiers, dossiers et internet sont au point. Tous les utilisateurs sont de type "Administrateur", WMI est installé sur toutes les machines, d'une "console WMI", j'accède au service WMI de n'importe quel PC, MAIS pour le code VBS suivant :
Si je l'exécute en "Local", c'est OK, mais si je mets le nom d'une autre des mes machines, j'obtiens toujours l'erreur suivante :
......... Erreur d'exécution Microsoft VBScript: Permission refusée: 'GetObject'
De quelle permission s'agit-il ? Tout simplement de la permission d'accéder à la base WMI de ta machine
distante ! Il faut que le compte utilisé sur la machine locale se retrouve à l'identique sur la machine distante (username/password), et diqpsoe des permissions suffisantes (admin en principe)
L'accès à WMI depuis un VBS peut faire appel à 2 syntaxes différentes :
1) Set objWMIService = GetObject("winmgmts:" & strComputer _ & "rootcimv2") Simple, mais ne permet pas d'indiquer un autre compte utilisateur/password
2) Set objLocator = CreateObject("WbemScripting.SWbemLocator") Set ObjService = objLocator.ConnectServer(strComputer, _ "rootCIMV2", UserName, Password) Un peu plus complexe, mais permet d'effectuer des requêtes WMI sous un autre compte utilisateur/password NB: si c'est l'ordinateur local qui est visé, username/password doivent être vides, et donc implicitement c'est le compte en cours qui est retenu.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
Dans le message news:OE160WXaEHA.4048@TK2MSFTNGP10.phx.gbl ,
Xavier HALOUCHERY <decfixh@wanadoo.fr> s'est ainsi exprimé:
Hello,
Je dispose d'un réseau "point à point" de 5 PC, XP Pro et XP Home
mélangés, toutes les connexions fichiers, dossiers et internet sont
au point.
Tous les utilisateurs sont de type "Administrateur", WMI est installé
sur toutes les machines, d'une "console WMI", j'accède au service WMI
de n'importe quel PC, MAIS pour le code VBS suivant :
Si je l'exécute en "Local", c'est OK, mais si je mets le nom d'une
autre des mes machines, j'obtiens toujours l'erreur suivante :
......... Erreur d'exécution Microsoft VBScript: Permission refusée:
'GetObject'
De quelle permission s'agit-il ?
Tout simplement de la permission d'accéder à la base WMI de ta machine
distante !
Il faut que le compte utilisé sur la machine locale se retrouve à
l'identique sur la machine distante (username/password), et diqpsoe des
permissions suffisantes (admin en principe)
L'accès à WMI depuis un VBS peut faire appel à 2 syntaxes différentes :
1) Set objWMIService = GetObject("winmgmts:\" & strComputer _
& "rootcimv2")
Simple, mais ne permet pas d'indiquer un autre compte utilisateur/password
2) Set objLocator = CreateObject("WbemScripting.SWbemLocator")
Set ObjService = objLocator.ConnectServer(strComputer, _
"rootCIMV2", UserName, Password)
Un peu plus complexe, mais permet d'effectuer des requêtes WMI sous un autre
compte utilisateur/password
NB: si c'est l'ordinateur local qui est visé, username/password doivent être
vides, et donc implicitement c'est le compte en cours qui est retenu.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org Jean-Claude.Bellamy@wanadoo.fr *
JC.Bellamy@free.fr
Dans le message news: , Xavier HALOUCHERY s'est ainsi exprimé:
Hello, Je dispose d'un réseau "point à point" de 5 PC, XP Pro et XP Home mélangés, toutes les connexions fichiers, dossiers et internet sont au point. Tous les utilisateurs sont de type "Administrateur", WMI est installé sur toutes les machines, d'une "console WMI", j'accède au service WMI de n'importe quel PC, MAIS pour le code VBS suivant :
Si je l'exécute en "Local", c'est OK, mais si je mets le nom d'une autre des mes machines, j'obtiens toujours l'erreur suivante :
......... Erreur d'exécution Microsoft VBScript: Permission refusée: 'GetObject'
De quelle permission s'agit-il ? Tout simplement de la permission d'accéder à la base WMI de ta machine
distante ! Il faut que le compte utilisé sur la machine locale se retrouve à l'identique sur la machine distante (username/password), et diqpsoe des permissions suffisantes (admin en principe)
L'accès à WMI depuis un VBS peut faire appel à 2 syntaxes différentes :
1) Set objWMIService = GetObject("winmgmts:" & strComputer _ & "rootcimv2") Simple, mais ne permet pas d'indiquer un autre compte utilisateur/password
2) Set objLocator = CreateObject("WbemScripting.SWbemLocator") Set ObjService = objLocator.ConnectServer(strComputer, _ "rootCIMV2", UserName, Password) Un peu plus complexe, mais permet d'effectuer des requêtes WMI sous un autre compte utilisateur/password NB: si c'est l'ordinateur local qui est visé, username/password doivent être vides, et donc implicitement c'est le compte en cours qui est retenu.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
Xavier HALOUCHERY
Merci à JCB de m'avoir répondu en ce jour de fête Nationale.
J'ai donc créé un Comte identique (type admin) sur une machine XP Pro et une XP Home. Sur les 2 machines avec la console WMI, j'ai affecté "TOUS les droits" de ce compte à l'espace de Nom "rootcimv2". Actuellement, ces 2 machines ne sont pas "loggées" avec ce Nouveau Compte. J'ai exécuté la 2ème version de ton exemple (en partant des 2 machines) en mettant bien sur, les références du nouveau compte, He bin, ça marche pas ! Toujours le même message : Permission refusée ! Les machines doivent-elles être déjà loggées sur le nouveau compte ? Qu'est-ce que j'ai oublié ? A+
Hello, Je dispose d'un réseau "point à point" de 5 PC, XP Pro et XP Home mélangés, toutes les connexions fichiers, dossiers et internet sont au point. Tous les utilisateurs sont de type "Administrateur", WMI est installé sur toutes les machines, d'une "console WMI", j'accède au service WMI de n'importe quel PC, MAIS pour le code VBS suivant :
Si je l'exécute en "Local", c'est OK, mais si je mets le nom d'une autre des mes machines, j'obtiens toujours l'erreur suivante :
......... Erreur d'exécution Microsoft VBScript: Permission refusée: 'GetObject'
De quelle permission s'agit-il ? Tout simplement de la permission d'accéder à la base WMI de ta machine
distante ! Il faut que le compte utilisé sur la machine locale se retrouve à l'identique sur la machine distante (username/password), et diqpsoe des permissions suffisantes (admin en principe)
L'accès à WMI depuis un VBS peut faire appel à 2 syntaxes différentes :
1) Set objWMIService = GetObject("winmgmts:" & strComputer _ & "rootcimv2") Simple, mais ne permet pas d'indiquer un autre compte utilisateur/password
2) Set objLocator = CreateObject("WbemScripting.SWbemLocator") Set ObjService = objLocator.ConnectServer(strComputer, _ "rootCIMV2", UserName, Password) Un peu plus complexe, mais permet d'effectuer des requêtes WMI sous un autre
compte utilisateur/password NB: si c'est l'ordinateur local qui est visé, username/password doivent être
vides, et donc implicitement c'est le compte en cours qui est retenu.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
Merci à JCB de m'avoir répondu en ce jour de fête Nationale.
J'ai donc créé un Comte identique (type admin) sur une machine XP Pro et une
XP Home.
Sur les 2 machines avec la console WMI, j'ai affecté "TOUS les droits" de ce
compte à l'espace de Nom "rootcimv2".
Actuellement, ces 2 machines ne sont pas "loggées" avec ce Nouveau Compte.
J'ai exécuté la 2ème version de ton exemple (en partant des 2 machines) en
mettant bien sur, les références du nouveau compte, He bin, ça marche pas !
Toujours le même message : Permission refusée !
Les machines doivent-elles être déjà loggées sur le nouveau compte ?
Qu'est-ce que j'ai oublié ?
A+
Hello,
Je dispose d'un réseau "point à point" de 5 PC, XP Pro et XP Home
mélangés, toutes les connexions fichiers, dossiers et internet sont
au point.
Tous les utilisateurs sont de type "Administrateur", WMI est installé
sur toutes les machines, d'une "console WMI", j'accède au service WMI
de n'importe quel PC, MAIS pour le code VBS suivant :
Si je l'exécute en "Local", c'est OK, mais si je mets le nom d'une
autre des mes machines, j'obtiens toujours l'erreur suivante :
......... Erreur d'exécution Microsoft VBScript: Permission refusée:
'GetObject'
De quelle permission s'agit-il ?
Tout simplement de la permission d'accéder à la base WMI de ta machine
distante !
Il faut que le compte utilisé sur la machine locale se retrouve à
l'identique sur la machine distante (username/password), et diqpsoe des
permissions suffisantes (admin en principe)
L'accès à WMI depuis un VBS peut faire appel à 2 syntaxes différentes :
1) Set objWMIService = GetObject("winmgmts:\" & strComputer _
& "rootcimv2")
Simple, mais ne permet pas d'indiquer un autre compte utilisateur/password
2) Set objLocator = CreateObject("WbemScripting.SWbemLocator")
Set ObjService = objLocator.ConnectServer(strComputer, _
"rootCIMV2", UserName, Password)
Un peu plus complexe, mais permet d'effectuer des requêtes WMI sous un
autre
compte utilisateur/password
NB: si c'est l'ordinateur local qui est visé, username/password doivent
être
vides, et donc implicitement c'est le compte en cours qui est retenu.
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org Jean-Claude.Bellamy@wanadoo.fr *
JC.Bellamy@free.fr
Merci à JCB de m'avoir répondu en ce jour de fête Nationale.
J'ai donc créé un Comte identique (type admin) sur une machine XP Pro et une XP Home. Sur les 2 machines avec la console WMI, j'ai affecté "TOUS les droits" de ce compte à l'espace de Nom "rootcimv2". Actuellement, ces 2 machines ne sont pas "loggées" avec ce Nouveau Compte. J'ai exécuté la 2ème version de ton exemple (en partant des 2 machines) en mettant bien sur, les références du nouveau compte, He bin, ça marche pas ! Toujours le même message : Permission refusée ! Les machines doivent-elles être déjà loggées sur le nouveau compte ? Qu'est-ce que j'ai oublié ? A+
Hello, Je dispose d'un réseau "point à point" de 5 PC, XP Pro et XP Home mélangés, toutes les connexions fichiers, dossiers et internet sont au point. Tous les utilisateurs sont de type "Administrateur", WMI est installé sur toutes les machines, d'une "console WMI", j'accède au service WMI de n'importe quel PC, MAIS pour le code VBS suivant :
Si je l'exécute en "Local", c'est OK, mais si je mets le nom d'une autre des mes machines, j'obtiens toujours l'erreur suivante :
......... Erreur d'exécution Microsoft VBScript: Permission refusée: 'GetObject'
De quelle permission s'agit-il ? Tout simplement de la permission d'accéder à la base WMI de ta machine
distante ! Il faut que le compte utilisé sur la machine locale se retrouve à l'identique sur la machine distante (username/password), et diqpsoe des permissions suffisantes (admin en principe)
L'accès à WMI depuis un VBS peut faire appel à 2 syntaxes différentes :
1) Set objWMIService = GetObject("winmgmts:" & strComputer _ & "rootcimv2") Simple, mais ne permet pas d'indiquer un autre compte utilisateur/password
2) Set objLocator = CreateObject("WbemScripting.SWbemLocator") Set ObjService = objLocator.ConnectServer(strComputer, _ "rootCIMV2", UserName, Password) Un peu plus complexe, mais permet d'effectuer des requêtes WMI sous un autre
compte utilisateur/password NB: si c'est l'ordinateur local qui est visé, username/password doivent être
vides, et donc implicitement c'est le compte en cours qui est retenu.
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
Jean-Claude BELLAMY
Dans le message news: , Xavier HALOUCHERY s'est ainsi exprimé:
Merci à JCB de m'avoir répondu en ce jour de fête Nationale.
J'ai donc créé un Comte identique "A moi Comte (identique), deux mots ! " (désolé, je n'ai pas pu résister;-))
(type admin) sur une machine XP Pro et une XP Home. Arrrrrggggggghhhhhhhhhhhhhhh !!!!
Mais il fallait dire tout de suite que tu travaillais avec XP HOME ! Ah cette fichue rétention d'information ! Ce n'est pas étonnant que çà ne marche pas!
XP HOME est un OS complètement DÉBILE (au niveau réseau), lequel, sous prétexte de sécuriser les connexions (parce que MS a du penser que les utilisateurs de XP HOME sont des "newbies" intégraux), transforme TOUT utilisateur distant (même ayant un nom et password d'administrateur) comme ... INVITÉ !!!!
Exemple : Sur le PC "A" appelant (XP PRO ou HOME), tu es sous le compte "admin" / pwd "toto" Sur le PC "B" appelé (XP HOME), il existe bien là aussi un compte "admin" / pwd "toto" Et bien, "admin"/"toto" de A est vu par B comme "invité"/"" !!!!
Si bien qu'il est impossible, avec cet OS à la c... , : - d'accéder aux partages administratifs (C$, D$,..) - d'accéder au registre à distance (même si on a démarré manuellement le service RemoteRegistry, j'ai testé!) - d'accéder à distance à WMI
Exemples vécus à l'instant : Dans mon LAN, j'ai une machine "DAKAR" sous XP HOME (justement pour "débusquer" ce genre de gag pas marrant)
Depuis une machine sous XP PRO j'exécute les commandes suivantes :
C:>setsvc -mDAKAR -uBELLAMY -pxxxxxxxxx Erreur 0x80070005 survenue dans la connexion à DAKAR : Accès refusé. (c'est un script VBS que j'ai écrit qui permet de gérer les services à distance)
C:dir dakarc$ Accès refusé.
Par contre, vers une autre machine "YAOUNDE" (sous XP PRO), çà marche sans pb :
C:>setsvc -mYAOUNDE -uBELLAMY -pxxxxxxxxxx Liste des services de la machine YAOUNDE 45 services démarrés : ----------------------- 1 Audio Windows (Auto) 2 Explorateur d'ordinateur (Auto) 3 Services de cryptographie (Auto) 4 Client DHCP (Auto) ....
C:>dir yaoundec$ Le volume dans le lecteur yaoundec$ s'appelle XPPRO Le numéro de série du volume est 8CA3-F692 Répertoire de yaoundec$ 15/06/2004 17:56 <REP> Documents and Settings 07/07/2004 15:59 <REP> Program Files ...
Les machines doivent-elles être déjà loggées sur le nouveau compte ? Non, il n'est même pas besoin qu'une session soit ouverte
Qu'est-ce que j'ai oublié ? Que XP HOME est un système d'exploitation au rabais ! ;-)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
Dans le message news:ug4NR0aaEHA.2488@tk2msftngp13.phx.gbl ,
Xavier HALOUCHERY <decfixh@wanadoo.fr> s'est ainsi exprimé:
Merci à JCB de m'avoir répondu en ce jour de fête Nationale.
J'ai donc créé un Comte identique
"A moi Comte (identique), deux mots ! " (désolé, je n'ai pas pu résister;-))
(type admin) sur une machine XP Pro et une XP Home.
Arrrrrggggggghhhhhhhhhhhhhhh !!!!
Mais il fallait dire tout de suite que tu travaillais avec XP HOME !
Ah cette fichue rétention d'information !
Ce n'est pas étonnant que çà ne marche pas!
XP HOME est un OS complètement DÉBILE (au niveau réseau), lequel, sous
prétexte de sécuriser les connexions (parce que MS a du penser que les
utilisateurs de XP HOME sont des "newbies" intégraux), transforme TOUT
utilisateur distant (même ayant un nom et password d'administrateur) comme
... INVITÉ !!!!
Exemple :
Sur le PC "A" appelant (XP PRO ou HOME), tu es sous le compte "admin" / pwd
"toto"
Sur le PC "B" appelé (XP HOME), il existe bien là aussi un compte "admin" /
pwd "toto"
Et bien, "admin"/"toto" de A est vu par B comme "invité"/""
!!!!
Si bien qu'il est impossible, avec cet OS à la c... , :
- d'accéder aux partages administratifs (C$, D$,..)
- d'accéder au registre à distance (même si on
a démarré manuellement le service RemoteRegistry,
j'ai testé!)
- d'accéder à distance à WMI
Exemples vécus à l'instant :
Dans mon LAN, j'ai une machine "DAKAR" sous XP HOME (justement pour
"débusquer" ce genre de gag pas marrant)
Depuis une machine sous XP PRO j'exécute les commandes suivantes :
C:>setsvc -mDAKAR -uBELLAMY -pxxxxxxxxx
Erreur 0x80070005 survenue dans la connexion à DAKAR : Accès refusé.
(c'est un script VBS que j'ai écrit qui permet de gérer les services à
distance)
C:dir \dakarc$
Accès refusé.
Par contre, vers une autre machine "YAOUNDE" (sous XP PRO), çà marche sans
pb :
C:>setsvc -mYAOUNDE -uBELLAMY -pxxxxxxxxxx
Liste des services de la machine YAOUNDE
45 services démarrés :
-----------------------
1 Audio Windows (Auto)
2 Explorateur d'ordinateur (Auto)
3 Services de cryptographie (Auto)
4 Client DHCP (Auto)
....
C:>dir \yaoundec$
Le volume dans le lecteur \yaoundec$ s'appelle XPPRO
Le numéro de série du volume est 8CA3-F692
Répertoire de \yaoundec$
15/06/2004 17:56 <REP> Documents and Settings
07/07/2004 15:59 <REP> Program Files
...
Les machines doivent-elles être déjà loggées sur le nouveau compte ?
Non, il n'est même pas besoin qu'une session soit ouverte
Qu'est-ce que j'ai oublié ?
Que XP HOME est un système d'exploitation au rabais ! ;-)
--
May the Force be with You!
La Connaissance s'accroît quand on la partage
----------------------------------------------------------
Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org
http://www.bellamyjc.org Jean-Claude.Bellamy@wanadoo.fr *
JC.Bellamy@free.fr
Dans le message news: , Xavier HALOUCHERY s'est ainsi exprimé:
Merci à JCB de m'avoir répondu en ce jour de fête Nationale.
J'ai donc créé un Comte identique "A moi Comte (identique), deux mots ! " (désolé, je n'ai pas pu résister;-))
(type admin) sur une machine XP Pro et une XP Home. Arrrrrggggggghhhhhhhhhhhhhhh !!!!
Mais il fallait dire tout de suite que tu travaillais avec XP HOME ! Ah cette fichue rétention d'information ! Ce n'est pas étonnant que çà ne marche pas!
XP HOME est un OS complètement DÉBILE (au niveau réseau), lequel, sous prétexte de sécuriser les connexions (parce que MS a du penser que les utilisateurs de XP HOME sont des "newbies" intégraux), transforme TOUT utilisateur distant (même ayant un nom et password d'administrateur) comme ... INVITÉ !!!!
Exemple : Sur le PC "A" appelant (XP PRO ou HOME), tu es sous le compte "admin" / pwd "toto" Sur le PC "B" appelé (XP HOME), il existe bien là aussi un compte "admin" / pwd "toto" Et bien, "admin"/"toto" de A est vu par B comme "invité"/"" !!!!
Si bien qu'il est impossible, avec cet OS à la c... , : - d'accéder aux partages administratifs (C$, D$,..) - d'accéder au registre à distance (même si on a démarré manuellement le service RemoteRegistry, j'ai testé!) - d'accéder à distance à WMI
Exemples vécus à l'instant : Dans mon LAN, j'ai une machine "DAKAR" sous XP HOME (justement pour "débusquer" ce genre de gag pas marrant)
Depuis une machine sous XP PRO j'exécute les commandes suivantes :
C:>setsvc -mDAKAR -uBELLAMY -pxxxxxxxxx Erreur 0x80070005 survenue dans la connexion à DAKAR : Accès refusé. (c'est un script VBS que j'ai écrit qui permet de gérer les services à distance)
C:dir dakarc$ Accès refusé.
Par contre, vers une autre machine "YAOUNDE" (sous XP PRO), çà marche sans pb :
C:>setsvc -mYAOUNDE -uBELLAMY -pxxxxxxxxxx Liste des services de la machine YAOUNDE 45 services démarrés : ----------------------- 1 Audio Windows (Auto) 2 Explorateur d'ordinateur (Auto) 3 Services de cryptographie (Auto) 4 Client DHCP (Auto) ....
C:>dir yaoundec$ Le volume dans le lecteur yaoundec$ s'appelle XPPRO Le numéro de série du volume est 8CA3-F692 Répertoire de yaoundec$ 15/06/2004 17:56 <REP> Documents and Settings 07/07/2004 15:59 <REP> Program Files ...
Les machines doivent-elles être déjà loggées sur le nouveau compte ? Non, il n'est même pas besoin qu'une session soit ouverte
Qu'est-ce que j'ai oublié ? Que XP HOME est un système d'exploitation au rabais ! ;-)
-- May the Force be with You! La Connaissance s'accroît quand on la partage ---------------------------------------------------------- Jean-Claude BELLAMY [MVP] - http://www.bellamyjc.org http://www.bellamyjc.org *
