Instances IE ; le retour des problèmes

Le
MCI \(ex do ré Mi chel la si do\) [MVP]
Bonsoir !

Il y a quelques temps, avait été posé le problème d'identifier les
instances d'Internet-explorer (avec les adresses/URL utilisées).

Plusieurs solutions avaient été proposées.

Mais, je tombe sur un problème pas piqué des hannetons

C'est sous Vista ; et c'est un problème lié à l'UAC. Pour tester,
essayez la procédure suivante :
- démarrer une invite de commande en tant qu'Administrateur
(clic-droit + choix dans le menu).
- lancer Internet-Explorer normalement.
- là, on peut voir les instances, avec les différents scripts
proposés. C'est OK.
Ensuite :
- fermez IE
- lancez IE en tant qu'Administrateur (clic-droit + choix dans le
menu).
- maintenant, les scripts ne voient plus l'instance !!!!!!!!! ;-(((



Autre cas (dérivé). Lancez deux invites de commande :
- la première en tant qu'Administrateur (clic-droit + choix dans le
menu).
- la seconde normalement (la barre de titre permet de faire la
différence entre les deux).
- depuis chacune des consoles, lancez IE (normalement, par "Program
FilesInternet Exploreriexplore.exe").
- seule l'instance lancée depuis la console "normale" est visible.
L'autre "n'existe pas".


Toute l'après-midi, j'ai testé des dizaines de cas. Et, j'en arrive
toujours à la même conclusion : "lancement en tant qu'Administrateur" a
moins de pouvoirs que "lancement normal".

Le comportement est similaire, avec IE-7 et IE-8. Et, cela ne sert à
rien de (dé)-cocher des options dans IE (j'ai tout essayé).


Qu'en pensez-vous ?


@+
--
Michel Claveau



PS : avec l'UAC désactivé, il n'y a plus aucun problème.
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Michel__D
Le #17494021
MCI (ex do ré Mi chel la si do) [MVP] a écrit :
Bonsoir !

Il y a quelques temps, avait été posé le problème d'identifier les
instances d'Internet-explorer (avec les adresses/URL utilisées).

Plusieurs solutions avaient été proposées.

Mais, je tombe sur un problème pas piqué des hannetons...

C'est sous Vista ; et c'est un problème lié à l'UAC. Pour tester,
essayez la procédure suivante :
- démarrer une invite de commande en tant qu'Administrateur (clic-droit
+ choix dans le menu).
- lancer Internet-Explorer normalement.
- là, on peut voir les instances, avec les différents scripts proposés.
C'est OK.
Ensuite :
- fermez IE
- lancez IE en tant qu'Administrateur (clic-droit + choix dans le menu).
- maintenant, les scripts ne voient plus l'instance !!!!!!!!! ;-(((



Autre cas (dérivé). Lancez deux invites de commande :
- la première en tant qu'Administrateur (clic-droit + choix dans le menu).
- la seconde normalement (la barre de titre permet de faire la
différence entre les deux).
- depuis chacune des consoles, lancez IE (normalement, par "Program
FilesInternet Exploreriexplore.exe").
- seule l'instance lancée depuis la console "normale" est visible.
L'autre "n'existe pas".


Toute l'après-midi, j'ai testé des dizaines de cas. Et, j'en arrive
toujours à la même conclusion : "lancement en tant qu'Administrateur" a
moins de pouvoirs que "lancement normal".

Le comportement est similaire, avec IE-7 et IE-8. Et, cela ne sert à
rien de (dé)-cocher des options dans IE (j'ai tout essayé).


Qu'en pensez-vous ?



Tes scripts sont lançés dans quel context ?

PS:Si c'est avec un context normal, le résultat semble correct.
Gilles LAURENT [MVP]
Le #17495661
"Michel__D" message de
news:
| MCI (ex do ré Mi chel la si do) [MVP] a écrit :
|| Bonsoir !
||
|| Il y a quelques temps, avait été posé le problème d'identifier les
|| instances d'Internet-explorer (avec les adresses/URL utilisées).
||
|| Plusieurs solutions avaient été proposées.
||
|| Mais, je tombe sur un problème pas piqué des hannetons...
||
|| C'est sous Vista ; et c'est un problème lié à l'UAC. Pour tester,
|| essayez la procédure suivante :
|| - démarrer une invite de commande en tant qu'Administrateur
|| (clic-droit + choix dans le menu).
|| - lancer Internet-Explorer normalement.
|| - là, on peut voir les instances, avec les différents scripts
|| proposés. C'est OK.
|| Ensuite :
|| - fermez IE
|| - lancez IE en tant qu'Administrateur (clic-droit + choix dans le
|| menu).
|| - maintenant, les scripts ne voient plus l'instance !!!!!!!!!
|| ;-(((
||
||
||
|| Autre cas (dérivé). Lancez deux invites de commande :
|| - la première en tant qu'Administrateur (clic-droit + choix dans le
|| menu).
|| - la seconde normalement (la barre de titre permet de faire la
|| différence entre les deux).
|| - depuis chacune des consoles, lancez IE (normalement, par "Program
|| FilesInternet Exploreriexplore.exe").
|| - seule l'instance lancée depuis la console "normale" est visible.
|| L'autre "n'existe pas".
||
||
|| Toute l'après-midi, j'ai testé des dizaines de cas. Et, j'en arrive
|| toujours à la même conclusion : "lancement en tant
|| qu'Administrateur" a moins de pouvoirs que "lancement normal".
||
|| Le comportement est similaire, avec IE-7 et IE-8. Et, cela ne sert à
|| rien de (dé)-cocher des options dans IE (j'ai tout essayé).
||
||
|| Qu'en pensez-vous ?
|
| Tes scripts sont lançés dans quel context ?
|
| PS:Si c'est avec un context normal, le résultat semble correct.

Situation: Trois instances Internet Explorer sont démarrées. Deux sous
l'autorité de l'utilisateur qui a ouvert la session de manière
interactive et une autre sous runas (XP) ou runas/UAC (Vista).

Ce problème n'est à mon sens du fait de l'UAC mais plutôt du composant
COM Shell.Application et plus particulièrement de l'interface
IShellWindows. Le composant COM Shell.Application est lié à la librairie
dynamique shell32.dll qui est chargée et instanciée sous l'autorité de
l'utilisateur qui a ouvert la session de manière interactive. Lorsqu'on
invoque l'interface IShellWindows (shdocvw.dll) via
Shell.Application.Windows avec un autre compte (runas et/ou UAC) alors
cela provoque :

Note: Les commandes ci-dessous s'exécutent sous runas (XP) ou runas/UAC
(Vista).

1- Un conflit d'autorité sous XP (runas) :
WSH D:Test> Set oShApp=CreateObject("Shell.Application")
WSH D:Test> Set colWindows=oshApp.Windows()
:: An error occured (429)
:: Un composant ActiveX ne peut pas créer un objet.

2- Uniquement la lecture des instances du Shell (Internet Explorer et
Explorer) de l'utilisateur qui a ouvert la session de manière
interactive sous Vista (runas et/ou UAC activé) :
WSH D:Test> Set oShApp=CreateObject("Shell.Application")
WSH D:Test> Set colWindows=oshApp.Windows()
WSH D:Test> WScript.Echo colWindows.Count
2 <= pourtant trois instances IE sont démarrées

Sous Vista, la désactivation de l'UAC résoud le problème car il n'y a
plus d'élévation de privilèges "à la demande". L'UAC peut être assimilé
à un runas du point de vue des droits et privilèges. Bien entendu, ce
problème persiste avec le runas sous Vista malgré la désactivation de
l'UAC. Pour résumer, ce fonctionnement peux sembler bizarre de prime
abord (j'avoue avoir été surpris) mais peut s'expliquer ensuite du fait
de l'implémentation de l'interface IShellWindows.

--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
MCI \(ex do ré Mi chel la si do\) [MVP]
Le #17496101
Bonsoir !

En fait, je comprends la logique d'implémentation du "truc". Lorsqu'une
appli est lancée "en tant qu'Administrateur", elle est isolée, dans une
"bulle d'exécution virtuelle" (l'expression est de Microsoft), et n'est
donc pas accessible par "autre chose".

Ce qui me gêne, c'est qu'un autre script, ou un logiciel, lancé lui
aussi "en tant qu'Administrateur" ne puisse pas y accéder non plus.
Cela signifie que l'isolation est plus profonde qu'il ne (me) semblait,
et est liée, non pas au compte/droits, mais à chaque instance
d'exécution par l'UAC.


Je pense aussi que ce n'est pas lié simplement à Shell.Application, mais
à tout l'ensemble des appels COM/Active-X, voire même à plus de choses.

Car, par exemple, si le problème est constaté avec Shell.Application, il
existe aussi avec des .HTA ou d'autres instances d'Internet-explorer,
lorsqu'elles veulent se connecter via Open("","nomfenetre").

Normalement, lorsque l'on ne précise pas le premier paramètre de Open,
cela n'ouvre pas une nouvelle instance (fenêtre) d'IE, mais établit une
connexion à une instance (fenêtre) déjà existante.
Et l'on rencontre strictement le même comportement. Or, cette
possibilité (Open("", ) fonctionne avec des logiciels qui n'utilisent
pas COM, tels que Firefox ou Opera ; ça ne passe donc pas par COM.

D'ailleurs, il serait intéressant de tester avec DynaWrap...


Une autre conséquence, c'est que le travail sous compte du (véritable)
Administrateur n'est pas équivalent à la désactivation de l'UAC. Mais,
bon, c'est moins important.


runas



Une solution, c'est effectivement d'utiliser runlike (mon équivalent de
runas). Comme il change le compte d'exécution, il annule le "en tant
qu'Administrateur".


J'ai encore quelques tests à faire. Mais, je pense que ce comportement
me gênera pour certains scripts.


Et, au passage, je m'aperçois que je ne sais rien du comportement des
objets-COM avec l'UAC...


@-salutations
--
Michel Claveau
Gilles LAURENT [MVP]
Le #17498051
"MCI (ex do ré Mi chel la si do) [MVP]"
news:
| Bonsoir !

Bonsoir,

[...]
| Et, au passage, je m'aperçois que je ne sais rien du comportement des
| objets-COM avec l'UAC...

ROTFL

The COM Elevation Moniker :
http://msdn.microsoft.com/en-us/library/ms679687(VS.85).aspx

--
Gilles LAURENT
MVP Windows Server - Admin Frameworks
http://glsft.free.fr
Publicité
Poster une réponse
Anonyme