Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Vista Administration contrôle de compte d'utilisateur

contrôle de compte d'utilisateur

18 réponses
Avatar
Pierre-Roger
Bonjours à vous,



J'ai un programme que j'ai installé sur Windows Vista Édition Familiale
Premium



A toute les fois que l'ouvre j'ai une boite de message



Control de compte d'utilisateur.

Un programme non identifié veut accéder à votre ordinateur.



J'avais l'intention de diminué la sécurité

Quand j'ai fait une recherche dans l'aide, il faut que j'utilise secpol.msc

Mais je n'est pas secpol.msc est que ces normale.
Signaler un problème avec ce contenu

8 réponses

Supprimer
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
1 2
Avatar
Jean-Claude BELLAMY
Dans le message :,
Emmanuel Dreux [MS] a pris la peine d'écrire
ce qui suit :
Bonjour,

pour vérifier si un user est admin ( et dans un prompt élevé), il faut
appeler la fonction IsUserAnAdmin qui retourne true si on est admin
dans un prompt élevé.


Sauf que cette fonction (de shell32.dll) est déclarée foireuse sous
(implicitement) VISTA par le MSDN !!!!!!

"This function is available through Microsoft Windows XP Service
Pack 2 (SP2) and Windows Server 2003. It might be altered or
unavailable in subsequent versions of Windows."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/isuseranadmin.asp

"subsequent versions of Windows" = les versions ultérieures de Windows.
Comme il est question dans cet article de XP et W2K3, VISTA est bien une
"version ultérieure", n'est-il pas ?

De plus cette fonction ne me convient pas du tout, car elle ne teste que la
qualité d'admin (ou non) de l'utilisateur COURANT.
Or moi je suis amener à la tester pour un compte donné, indépendant du
compte courant.

De mon point de vu personnel SuperExec est un trou de sécurité
puisque qu'il encrype un mot de passe administrateur qu'un
utilisateur final peut donc décrypter et accéder ( un utilisateur
final peut attacher un debugger, breaker juste après l'appel de la
fonction de décryption du mot de passe admin) et l'obtenir en clair.


Ouais, c'est çà, et la marmotte elle emballe le chocolat dans le papier
d'alu !!!! ;-)

Je lui souhaite bien du plaisir, au debuggeur qui va faire cela !
Mon système de chiffrement est un peu plus complexe qu'un simple appel à une
fonction.
(et attends, je n'ai pas encore publié - rédaction manuel oblige - la
dernière version V4 !)

Je te signale que SuperExec a été conçu pour pallier les DÉFICIENCES de
Microsoft, qui a complèment occulté les situations que rencontrent pleins
d'administrateurs dans leurs entreprises sous W2K, XP, (voire W2K3) et
maintenant VISTA !
A savoir permettre à leurs utilisateurs "lambda" (lesquels, au passage,
n'ont jamais entendu parler du mot "debuggueur"!) d'effectuer des tâches
bien précises avec en tant qu'admin, mais VRAI admin, pas avec le token au
rabais!
Or même sous VISTA, ceci est impossible sans communication du mot de passe,
ou déplacement physique sur le poste de l'administrateur !

Et il y a des cas, avec le nomadisme de plus en plus fréquent dans les
entreprises, où l'utilisateur de base peut se trouver isolé du réseau de sa
boite, mais par contre il doit effectuer certaines tâches requérant un
niveau admin !

Quant à un utilisateur final qui s'amuserait à debugger le code de
SuperExec, ce serait tout sauf un utilisateur final, mais un développeur
et/ou admin!

Emmanuel, je t'invite à descendre de ton petit nuage, et à te confronter
avec la réalité "agricole" ! ;-)

J'avais fais une démo avec TqcRunas et extrait depuis un compte
enduser le mot de passe d'administrateur.
Comparons ce qui est comparable !!!! ;-)



C'est d'ailleurs pour ces mêmes raisons que runas ne permet pas de
scripter la saisie du mot de passe
Cette lacune est une conceté !

C'est un BESOIN unanime ...
Et comme Microsoft ne sait pas comment faire, il se défausse en sortant
l'excuse connue
"It's not a bug, it's by design !"

et que des outils comme superexec
existent et introduisent des risques.


Et être obligé de donner le mot de passe admin en clair à un utilisateur,
c'est mieux ? :-(


Si le système stockait les réponses UAC, un code hostile pourrait
alors s'éxecuter silencieusement...


Argument REJETÉ ! ;-)

Car si code hostile il y a, peux-tu me dire ce qui empêche le code hostile,
prévoyant le coup, à l'aide d'un hook p.ex. ou encore d'un simple VBS de
simuler un clic ou l'action sur la touche Entrée ?

La protection par attente de confirmation, elle est ARCHI-NULLE
!!!!!!!!!!!!!!!!
C'est se MOQUER du monde !


Pour la virtualisation, je ne vois pas, si j'écris un programme qui
écrit toto.ini dans program files, je l'accède alors de manière
transparente depuis c:users.
J'avais fais le test, ça marchait il me semble?


Moi je n'ai pas testé, mais c'est un de tes collègues (Microsoft) auquel
j'avais posé la question qui m'a répondu que çà pouvait foirer à la lecture
!


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

IsUserAnAdmin n'est pas dépréciée dans Vista (malgré la doc MSDN).
IsUserAnAdmin et CheckTokenMemberShip(builtinadministrators) retournent
true dans un prompt élevé, false sinon.

Pour tester si un compte donnée (non logué) est admin, la problématique
n'est pas nouvellen c'est la même que pour 2000/XP/2003:
Il n'y a pas de méthode simple ( récupérer la liste des groupes, gérer les
groupes imbriqués, dans une forêt en mode native, gérer les groupes
universels).

Pour superexec, c'est un peu hors sujet ici ( je savais qu'il ne fallait pas
titiller superexec :-) ), mais ce n'est pas un bug ou un manquement si
runas ne permet pas de passer le mot de passe en ligne de commande: C'est
voulu et archi voulu pour ne tenter les dévelopeurs de script ( par exemple)
à coder en clair des mot de passe admin dans leurs vbs ou cmd.
Il existe du reste divers moyens d'exécuter des taches en tant qu'admin par
le biais de services, de startup scripts, de taches planifiées ou d'outils
tiers ( qui d'ailleurs sont des services) comme netiq, patrol ( qui soit dit
en passant valent ce qu'ils valent) ou bien d'autres encore.
Question sécurité pour superexec, tcqrunas, les obsfucateurs de script etc,
c'est définitivement une ouverture en terme de sécurité puisque le mot de
passe se retrouve au bout de la chaine en clair en mémoire et extractible;
et il suffit qu'une recette de cuisine soit mis en ligne sur Internet pour
que celà devienne accessible à tout le monde.
Ce n'est pas être sur un nuage, la sécurité ne consiste pas à penser que les
utilisateurs n'ont pas le niveau.

Si dans ma boite, un admin ou un développeur met en place ce genre d'outils,
je serais vite admin du domaine ou de la forêt...

Microsoft n'a pas voulu ce scénario avec runas et d'autres outils ont vu le
jour dont superexec ou les obsufcateurs de script. Ses utilisateurs doivent
en connaitre le niveau de risque, c'est tout.
De même runas sous vista ne permet pas d'ouvrir un prompt élevé ( ça c'est
très bête !!! :-) )... et il y a déjà des outils qui ont pris la relève.

Pour finir, un malware ne pourra pas émuler le click.
En effet la fenêtre de validation UAC est affichée dans un secure desktop
inaccessible par script ou programmation. ( pas possible d'y faire un
sendkeys ou sendmesage).
Donc, si la réponse à UAC était cachée, un programme malhonnête pourrait en
profiter pou exécuter silencieusement une action d'administration ( et
passerait à travers UAC).
De même le prompt élevé est protégé ( pas de copy/paste depuis un prompt non
élevé pour empêcher un malware non élevé d'utiliser cette fenêtre élevée).
Et pour finir, de même, il n'est plus possible de faire un openprocess etc,
manipuler les acls sur le process élevé pour y injecter et exécuter des
threads depuis un process non élevé. ( principe d'isolation).

--
Cordialement,

Emmanuel Dreux.

"Jean-Claude BELLAMY" wrote in message
news:
Dans le message :,
Emmanuel Dreux [MS] a pris la peine
d'écrire ce qui suit :
Bonjour,

pour vérifier si un user est admin ( et dans un prompt élevé), il faut
appeler la fonction IsUserAnAdmin qui retourne true si on est admin
dans un prompt élevé.


Sauf que cette fonction (de shell32.dll) est déclarée foireuse sous
(implicitement) VISTA par le MSDN !!!!!!

"This function is available through Microsoft Windows XP Service
Pack 2 (SP2) and Windows Server 2003. It might be altered or
unavailable in subsequent versions of Windows."
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/isuseranadmin.asp

"subsequent versions of Windows" = les versions ultérieures de Windows.
Comme il est question dans cet article de XP et W2K3, VISTA est bien une
"version ultérieure", n'est-il pas ?

De plus cette fonction ne me convient pas du tout, car elle ne teste que
la qualité d'admin (ou non) de l'utilisateur COURANT.
Or moi je suis amener à la tester pour un compte donné, indépendant du
compte courant.

De mon point de vu personnel SuperExec est un trou de sécurité
puisque qu'il encrype un mot de passe administrateur qu'un
utilisateur final peut donc décrypter et accéder ( un utilisateur
final peut attacher un debugger, breaker juste après l'appel de la
fonction de décryption du mot de passe admin) et l'obtenir en clair.


Ouais, c'est çà, et la marmotte elle emballe le chocolat dans le papier
d'alu !!!! ;-)

Je lui souhaite bien du plaisir, au debuggeur qui va faire cela !
Mon système de chiffrement est un peu plus complexe qu'un simple appel à
une fonction.
(et attends, je n'ai pas encore publié - rédaction manuel oblige - la
dernière version V4 !)

Je te signale que SuperExec a été conçu pour pallier les DÉFICIENCES de
Microsoft, qui a complèment occulté les situations que rencontrent pleins
d'administrateurs dans leurs entreprises sous W2K, XP, (voire W2K3) et
maintenant VISTA !
A savoir permettre à leurs utilisateurs "lambda" (lesquels, au passage,
n'ont jamais entendu parler du mot "debuggueur"!) d'effectuer des tâches
bien précises avec en tant qu'admin, mais VRAI admin, pas avec le token au
rabais!
Or même sous VISTA, ceci est impossible sans communication du mot de
passe, ou déplacement physique sur le poste de l'administrateur !

Et il y a des cas, avec le nomadisme de plus en plus fréquent dans les
entreprises, où l'utilisateur de base peut se trouver isolé du réseau de
sa boite, mais par contre il doit effectuer certaines tâches requérant un
niveau admin !

Quant à un utilisateur final qui s'amuserait à debugger le code de
SuperExec, ce serait tout sauf un utilisateur final, mais un développeur
et/ou admin!

Emmanuel, je t'invite à descendre de ton petit nuage, et à te confronter
avec la réalité "agricole" ! ;-)

J'avais fais une démo avec TqcRunas et extrait depuis un compte
enduser le mot de passe d'administrateur.
Comparons ce qui est comparable !!!! ;-)



C'est d'ailleurs pour ces mêmes raisons que runas ne permet pas de
scripter la saisie du mot de passe
Cette lacune est une conceté !

C'est un BESOIN unanime ...
Et comme Microsoft ne sait pas comment faire, il se défausse en sortant
l'excuse connue
"It's not a bug, it's by design !"

et que des outils comme superexec
existent et introduisent des risques.


Et être obligé de donner le mot de passe admin en clair à un utilisateur,
c'est mieux ? :-(


Si le système stockait les réponses UAC, un code hostile pourrait
alors s'éxecuter silencieusement...


Argument REJETÉ ! ;-)

Car si code hostile il y a, peux-tu me dire ce qui empêche le code
hostile, prévoyant le coup, à l'aide d'un hook p.ex. ou encore d'un simple
VBS de simuler un clic ou l'action sur la touche Entrée ?

La protection par attente de confirmation, elle est ARCHI-NULLE
!!!!!!!!!!!!!!!!
C'est se MOQUER du monde !


Pour la virtualisation, je ne vois pas, si j'écris un programme qui
écrit toto.ini dans program files, je l'accède alors de manière
transparente depuis c:users.
J'avais fais le test, ça marchait il me semble?


Moi je n'ai pas testé, mais c'est un de tes collègues (Microsoft) auquel
j'avais posé la question qui m'a répondu que çà pouvait foirer à la
lecture !


--
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 :,
Emmanuel Dreux [MS] a pris la peine d'écrire
ce qui suit :
[...]
De même runas sous vista ne permet pas d'ouvrir un prompt élevé ( ça
c'est très bête !!! :-) )... et il y a déjà des outils qui ont pris
la relève.


Si !
Il suffit de choisir le compte "Administrateur"
Et là on est en prompt élevé, sans problème ...
(je l'ai fait)
Evidemment, j'avais activé le compte admin (désactivé par défaut)

A ce sujet, un truc que je n'ai pas pigé : pourquoi (sur une Ultimate) il
n'est pas demandé de password pour le compte admin lors de l'installation ?
C'est quand même un peu gros !
On se croirait revenu à XP HOME.

Pour finir, un malware ne pourra pas émuler le click.
En effet la fenêtre de validation UAC est affichée dans un secure
desktop inaccessible par script ou programmation. ( pas possible d'y
faire un sendkeys ou sendmesage).
Bien vu !!!!

Merci pour l'info ...


Donc, si la réponse à UAC était cachée, un programme malhonnête
pourrait en profiter pou exécuter silencieusement une action
d'administration ( et passerait à travers UAC).
De même le prompt élevé est protégé ( pas de copy/paste depuis un
prompt non élevé pour empêcher un malware non élevé d'utiliser cette
fenêtre élevée). Et pour finir, de même, il n'est plus possible de
faire un openprocess etc, manipuler les acls sur le process élevé
pour y injecter et exécuter des threads depuis un process non élevé.
( principe d'isolation).


Je ne suis pas sûr d'avoir tout compris.
Car si j'ouvre (avec runas ou superexec) une fenêtre de commande (avec un
CreateProcessWithLogon) en utilisant le compte "administrateur", je peux
faire ensuite tout ce que je veux avec tous les droits admin.

(Et dès que la V4 de SuperExec est terminée, je te l'envoie, pour la
soumettre à ta vindicte ... !)

PS : pour te prouver mon objectivité, j'ai changé il y a 2 jours la langue
de mon Ultimate (EN->FR) depuis Windows Update, et bien ce fut nasodigital !
Simple, ergonomique, assez rapide, fiable, ...
Un grand bravo au(x) concepteur(s) de cette fonctionnalité.

Par contre je n'ai pas trouvé sur le site MS la liste des versions qui
supportent cette remarquable fonctionnalité.
- Ultimate (Intergrale) -> OK
- Entreprise -> je crois ?
Mais y en a-t-il d'autres ? (pour ma culture perso)

Merci d'avance pour l'info si tu l'as ...

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

Voici le lien décrivant sur quel versions sont disponibles MUI (ulitmate et
enterprise) et LIP (toutes).
http://windowshelp.microsoft.com/Windows/en-US/Help/35a1b021-d96c-49a5-8d8f-5e9d64ab5ecc1033.mspx

"Je ne suis pas sûr 'avoir tout compris":
--> Tu lances ton prompt admin (de la manière que tu veux), les prompts ( ou
programmes) non élevés ne peuvent pas interagir avec:
Tu ne pourras par faire un drag & drop dans cette fenêtre elevée depuis un
prompt non élevé ( ça, ça m'ennuie, je tape maintenant des km de lignes de
commandes pour accéder mes pgm en invite de commande).
De même tu ne pourras pas faire un sendmessage depuis une fenêtre non élevée
vers un prompt ou programme élevé ( shatter attack).

Effectivement; il n'est pas demandé de mot de passe au compte admin à
l'installation.
Ce compte est désactivé par défaut, mais utilisable en mode sans echec (
combien de personnes ont perdu ce mot de passe dans le passé ??? :-) ).
Par contre, ce mot de passe est positionnable dans une installation unattend
( heureusement!!!).

--
Cordialement,

Emmanuel Dreux.

"Jean-Claude BELLAMY" wrote in message
news:e9%
Dans le message :,
Emmanuel Dreux [MS] a pris la peine
d'écrire ce qui suit :
[...]
De même runas sous vista ne permet pas d'ouvrir un prompt élevé ( ça
c'est très bête !!! :-) )... et il y a déjà des outils qui ont pris
la relève.


Si !
Il suffit de choisir le compte "Administrateur"
Et là on est en prompt élevé, sans problème ...
(je l'ai fait)
Evidemment, j'avais activé le compte admin (désactivé par défaut)

A ce sujet, un truc que je n'ai pas pigé : pourquoi (sur une Ultimate) il
n'est pas demandé de password pour le compte admin lors de l'installation
?
C'est quand même un peu gros !
On se croirait revenu à XP HOME.

Pour finir, un malware ne pourra pas émuler le click.
En effet la fenêtre de validation UAC est affichée dans un secure
desktop inaccessible par script ou programmation. ( pas possible d'y
faire un sendkeys ou sendmesage).
Bien vu !!!!

Merci pour l'info ...


Donc, si la réponse à UAC était cachée, un programme malhonnête
pourrait en profiter pou exécuter silencieusement une action
d'administration ( et passerait à travers UAC).
De même le prompt élevé est protégé ( pas de copy/paste depuis un
prompt non élevé pour empêcher un malware non élevé d'utiliser cette
fenêtre élevée). Et pour finir, de même, il n'est plus possible de
faire un openprocess etc, manipuler les acls sur le process élevé
pour y injecter et exécuter des threads depuis un process non élevé.
( principe d'isolation).


Je ne suis pas sûr d'avoir tout compris.
Car si j'ouvre (avec runas ou superexec) une fenêtre de commande (avec un
CreateProcessWithLogon) en utilisant le compte "administrateur", je peux
faire ensuite tout ce que je veux avec tous les droits admin.

(Et dès que la V4 de SuperExec est terminée, je te l'envoie, pour la
soumettre à ta vindicte ... !)

PS : pour te prouver mon objectivité, j'ai changé il y a 2 jours la langue
de mon Ultimate (EN->FR) depuis Windows Update, et bien ce fut nasodigital
!
Simple, ergonomique, assez rapide, fiable, ...
Un grand bravo au(x) concepteur(s) de cette fonctionnalité.

Par contre je n'ai pas trouvé sur le site MS la liste des versions qui
supportent cette remarquable fonctionnalité.
- Ultimate (Intergrale) -> OK
- Entreprise -> je crois ?
Mais y en a-t-il d'autres ? (pour ma culture perso)

Merci d'avance pour l'info si tu l'as ...

--
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
Sylvain Caicoya
Bonjour,

En fait, la question est « L’usage d’UAC est fastidieux, cependant est-il
judicieux de le désactiver »
Après avoir regardé l’ensemble des Post liés à cette question, je ne pense
pas qu’il soit si terrible de valider son élévation de privilège, le jour ou
je le penserai, il sera peut-être temps pour moi de m’adonner à une activité
plus calme.
L’idée d’UAC est quand même de maintenir le poste utilisateur dans un état
connu pour cela Windows Vista utilise 3 niveaux d’exécution :
* asInvoker
* highestAvailable
* requireAdministrator
Ces niveaux sont identifiables par l’utilitaire strings.exe. Cet utilitaire
est dispo à l’adresse suivante :
http://www.microsoft.com/technet/sysinternals/default.mspx
J’utilise en tant que MVP Windows Vista depuis la version 5229 et il est
vrai qu’à cette époque cela été vraiment pénible, aujourd’hui le dosage est
assez juste à mon sens. J’ai pour plusieurs raisons désactivé UAC pour un
utilisateur, pour les admins, pour la machine mais uniquement pour des
raisons de tests.
Utiliser UAC, n’est pas plus fastidieux que de faire CTRL+ALT+SUPPR 50 fois
par jour ?
Désactivons aujourd’hui UAC, puis après soyons tous admin … bref ! Mais
après il ne faudra plus se plaindre des problèmes de sécurité.
En conclusion, essayez de prendre l’habitude, il est vrai que les premiers
temps cela déroute un peu après, cela passe sans problème.

--
Sylvain CAICOYA
MVP Windows Sécurité



Bonjour,

Voici le lien décrivant sur quel versions sont disponibles MUI (ulitmate et
enterprise) et LIP (toutes).
http://windowshelp.microsoft.com/Windows/en-US/Help/35a1b021-d96c-49a5-8d8f-5e9d64ab5ecc1033.mspx

"Je ne suis pas sûr 'avoir tout compris":
--> Tu lances ton prompt admin (de la manière que tu veux), les prompts ( ou
programmes) non élevés ne peuvent pas interagir avec:
Tu ne pourras par faire un drag & drop dans cette fenêtre elevée depuis un
prompt non élevé ( ça, ça m'ennuie, je tape maintenant des km de lignes de
commandes pour accéder mes pgm en invite de commande).
De même tu ne pourras pas faire un sendmessage depuis une fenêtre non élevée
vers un prompt ou programme élevé ( shatter attack).

Effectivement; il n'est pas demandé de mot de passe au compte admin à
l'installation.
Ce compte est désactivé par défaut, mais utilisable en mode sans echec (
combien de personnes ont perdu ce mot de passe dans le passé ??? :-) ).
Par contre, ce mot de passe est positionnable dans une installation unattend
( heureusement!!!).

--
Cordialement,

Emmanuel Dreux.

"Jean-Claude BELLAMY" wrote in message
news:e9%
Dans le message :,
Emmanuel Dreux [MS] a pris la peine
d'écrire ce qui suit :
[...]
De même runas sous vista ne permet pas d'ouvrir un prompt élevé ( ça
c'est très bête !!! :-) )... et il y a déjà des outils qui ont pris
la relève.


Si !
Il suffit de choisir le compte "Administrateur"
Et là on est en prompt élevé, sans problème ...
(je l'ai fait)
Evidemment, j'avais activé le compte admin (désactivé par défaut)

A ce sujet, un truc que je n'ai pas pigé : pourquoi (sur une Ultimate) il
n'est pas demandé de password pour le compte admin lors de l'installation
?
C'est quand même un peu gros !
On se croirait revenu à XP HOME.

Pour finir, un malware ne pourra pas émuler le click.
En effet la fenêtre de validation UAC est affichée dans un secure
desktop inaccessible par script ou programmation. ( pas possible d'y
faire un sendkeys ou sendmesage).
Bien vu !!!!

Merci pour l'info ...


Donc, si la réponse à UAC était cachée, un programme malhonnête
pourrait en profiter pou exécuter silencieusement une action
d'administration ( et passerait à travers UAC).
De même le prompt élevé est protégé ( pas de copy/paste depuis un
prompt non élevé pour empêcher un malware non élevé d'utiliser cette
fenêtre élevée). Et pour finir, de même, il n'est plus possible de
faire un openprocess etc, manipuler les acls sur le process élevé
pour y injecter et exécuter des threads depuis un process non élevé.
( principe d'isolation).


Je ne suis pas sûr d'avoir tout compris.
Car si j'ouvre (avec runas ou superexec) une fenêtre de commande (avec un
CreateProcessWithLogon) en utilisant le compte "administrateur", je peux
faire ensuite tout ce que je veux avec tous les droits admin.

(Et dès que la V4 de SuperExec est terminée, je te l'envoie, pour la
soumettre à ta vindicte ... !)

PS : pour te prouver mon objectivité, j'ai changé il y a 2 jours la langue
de mon Ultimate (EN->FR) depuis Windows Update, et bien ce fut nasodigital
!
Simple, ergonomique, assez rapide, fiable, ...
Un grand bravo au(x) concepteur(s) de cette fonctionnalité.

Par contre je n'ai pas trouvé sur le site MS la liste des versions qui
supportent cette remarquable fonctionnalité.
- Ultimate (Intergrale) -> OK
- Entreprise -> je crois ?
Mais y en a-t-il d'autres ? (pour ma culture perso)

Merci d'avance pour l'info si tu l'as ...

--
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 :,
Sylvain Caicoya a pris la peine d'écrire ce qui
suit :

En fait, la question est « L'usage d'UAC est fastidieux, cependant
est-il judicieux de le désactiver »
Après avoir regardé l'ensemble des Post liés à cette question, je ne
pense pas qu'il soit si terrible de valider son élévation de
privilège, le jour ou je le penserai, il sera peut-être temps pour
moi de m'adonner à une activité plus calme.


Tout dépend du public concerné !
Si c'est un administrateur ou un développeur, OUI, il est judicieux, pour ne
pas dire VITAL, de le désactiver !

Utiliser UAC, n'est pas plus fastidieux que de faire CTRL+ALT+SUPPR
50 fois par jour ?
??????????

J'appuie sur CRTL ALT SUPPR éventuellement (quand la barre de taches est
masquée) pour faire apparaitre le gestionnaire de tâches, c'est tout.
Et si c'est pour redémarrer le système, je viens de regarder depuis combien
de temps je tourne : plus de 300 h, soit presque 13 jours.

Par contre, si j'avais laissé UAC actif, j'aurais du cliquer dans la boite
de dialogue de confirmation au moins 150 fois dans la même période!


Désactivons aujourd'hui UAC, puis après soyons tous admin . bref !
Mais après il ne faudra plus se plaindre des problèmes de sécurité.
Je n'en ai JAMAIS eu !

Il suffit de savoir ce que l'on fait ...
Évidemment, quand je parle "d'administrateur" ou de "développeur", il est
implicite pour moi que ce sont de VRAIS "pros", des "baroudeurs de Windows",
et non pas des bidouilleurs du dimanche qui veulent se donner le grand
frisson ! ;-)

En conclusion, essayez de prendre l'habitude, il est vrai que les
premiers temps cela déroute un peu après, cela passe sans problème.
NON, cela ne me déroute pas, par contre cela me facilite énormément le

transit intestinal ! ;-)

P.ex. si je ne désactive pas UAC, aucun de mes scripts VBS autoinstallables
(console.vbs, newfolder.vbs, ...) ne peuvent s'exécuter !
(car ils modifient des entrées dans HKCR, ce qui déplait à cette chochotte
d'UAC).
Et là il n'y a même pas de boite de dialogue me demandant si "gna gna gna
..." !

Donc le verdict irrévocable, dans ce cas, est :
mv UAC /dev/nul
;-)



PS : il n'était pas nécessaire de recopier L'INTÉGRALITÉ du fil de
discussion ! ;-)

--
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
David Sebban [MSFT]
P.ex. si je ne désactive pas UAC, aucun de mes scripts VBS
autoinstallables
(console.vbs, newfolder.vbs, ...) ne peuvent s'exécuter !
(car ils modifient des entrées dans HKCR, ce qui déplait à cette chochotte
d'UAC).
Et là il n'y a même pas de boite de dialogue me demandant si "gna gna gna
..." !

Donc le verdict irrévocable, dans ce cas, est :
mv UAC /dev/nul
;-)


/mode provoc ON
Jean Claude, as tu pensé à ... réécrire tes scripts ??
/mode provoc OFF

et sinon mv UAC /dev/nul ... c'est bien entendu des alias que tu as crée
dans POWERSHELL pour desactiver UAC :) (au cas ou certains lecteurs
penseraient que "mv toto /dev/nul" fonctionne sous vista ;)

--
David Sebban | Microsoft Consulting Services France
This Posting is with NO WARRANTIES and confers NO RIGHTS
Ce message est SANS GARANTIES et ne confère AUCUNS DROITS

Avatar
Emmanuel Dreux [MS]
David, David, qu'as-tu fais malheureux!

Va pas réveiller la bête, laisse-la se repêtre tranquillement :-)

En fait c'est pour ça que Jean-Claude haït UAC, ses années de développement
passées, sa capitalisation passée réduite en poussière sous Vista, plus rien
ne marche ... maudite UAC...

Jean-Claude, fais-nous un petit effort, rend-nous tes scripts compatibles
Vista :-)

Pour tes scripts, un petit tuyau: Shellexecute avec le verb Runas force
systématiquement l'élévation UAC, même si l'application n'a pas de fichier
Manifest permettant de demander l'élévation, ( aujourd'hui ces applications
plantent silencieusement).

Tu as donc 2 solutions pour que tes scripts demandent l'élévation avec UAC:

1. Tu compiles un programme super compliqué d'une ligne qui fait un
ShellExecute(runas) de l'éxecutable passé en ligne de commande que tu
appelles UACElevate et tu lances tes programmes par UACElevate. Tu seras
ainsi certain qu'il y aura une demande d'élévation, et le programme ne
plantera pas silencieusement faute de privilèges et droits. ( voir bout de
code en 3).

2. Pour le faire en script, idem, rien de plus simple:

-------------
-------------------------------------------------------
if (WScript.Arguments.Length >= 1) {
Application = WScript.Arguments(0);
Arguments = "";
for (Index = 1; Index < WScript.Arguments.Length; Index += 1) {
if (Index > 1) {
Arguments += " ";
}

Arguments += WScript.Arguments(Index);
}

new ActiveXObject("Shell.Application").ShellExecute(Application,
Arguments, "", "runas");

} else {
WScript.Echo("elevate Application Arguments");
}
------------------------------------------------------------------------------------------------

3. Voici une fonction prête à compiler en code managé, 2 lignes de modif
pour passer l'exe en ligne de commande, et voilà ...
private void LaunchElevatedProcess()
{
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = @"path_to_your.exe";
startInfo.Verb = "runas";

try
{
Process p = Process.Start(startInfo);
}
catch(Exception ex)
{
// TODO user cancelled
MessageBox.Show(ex.Message, "caught it!"); //for demo purposes
return;
}
}

--
Cordialement,

Emmanuel Dreux.

"David Sebban [MSFT]" wrote in message
news:

P.ex. si je ne désactive pas UAC, aucun de mes scripts VBS
autoinstallables
(console.vbs, newfolder.vbs, ...) ne peuvent s'exécuter !
(car ils modifient des entrées dans HKCR, ce qui déplait à cette
chochotte d'UAC).
Et là il n'y a même pas de boite de dialogue me demandant si "gna gna gna
..." !

Donc le verdict irrévocable, dans ce cas, est :
mv UAC /dev/nul
;-)


/mode provoc ON
Jean Claude, as tu pensé à ... réécrire tes scripts ??
/mode provoc OFF

et sinon mv UAC /dev/nul ... c'est bien entendu des alias que tu as crée
dans POWERSHELL pour desactiver UAC :) (au cas ou certains lecteurs
penseraient que "mv toto /dev/nul" fonctionne sous vista ;)

--
David Sebban | Microsoft Consulting Services France
This Posting is with NO WARRANTIES and confers NO RIGHTS
Ce message est SANS GARANTIES et ne confère AUCUNS DROITS



1 2