Configuration requise pour le développement d’applications Windows Vista pour la compatibilité du contrôle de compte d’utilisateur

 

Jennifer Allen

Mise à jour de juin 2007

Résumé: Ce livre blanc est destiné à aider les développeurs d’applications à concevoir des applications compatibles avec Windows Vista qui sont conformes au contrôle de compte d’utilisateur. Des étapes détaillées sur le processus de conception sont incluses, ainsi que des exemples de code, des exigences et des meilleures pratiques. Ce document détaille également les mises à jour techniques et les modifications apportées à l’expérience utilisateur dans Windows Vista. (71 pages imprimées.)

Contenu

Pourquoi le contrôle de compte d’utilisateur ?
Windows Vista Mises à jour
Nouvelles technologies pour Windows Vista
Architecture UAC
La UAC affectera-t-elle votre application ?
Conception d’applications pour Windows Vista
Déploiement et mise à jour corrective d’applications pour les utilisateurs standard
Dépannage des problèmes courants
Références

Pourquoi le contrôle de compte d’utilisateur ?

Les développeurs d’applications ont créé systématiquement des applications Windows qui nécessitent des droits d’utilisateur et des privilèges Windows excessifs, ce qui exige souvent que l’utilisateur qui exécute soit un administrateur. Par conséquent, peu d’utilisateurs Windows s’exécutent avec le moins de droits d’utilisateur et de privilèges Windows requis. De nombreuses entreprises, cherchant à trouver un équilibre entre facilité de déploiement et facilité d’utilisation et sécurité, ont souvent eu recours au déploiement de leurs bureaux en tant qu’administrateur en raison de problèmes de compatibilité des applications utilisateur standard.

La liste suivante détaille d’autres raisons pour lesquelles il est difficile de s’exécuter en tant qu’utilisateur standard sur des ordinateurs Windows Vista antérieurs à Microsoft :

1. De nombreuses applications Windows nécessitent que l’utilisateur connecté soit un administrateur, mais n’ont pas réellement besoin d’un accès au niveau de l’administrateur. Ces applications effectuent diverses vérifications d’accès administrateur avant d’être autorisées à s’exécuter, notamment :
   • Jeton d’accès administrateur case activée.
   • Demandes d’accès « Tous les accès » dans les emplacements protégés par le système.
   • Écrivez des données dans des emplacements protégés, tels que %ProgramFiles%, %WinDir% et HKLM\Software.
2. De nombreuses applications Windows ne sont pas conçues avec le concept de privilège minimum et ne séparent pas les fonctionnalités utilisateur et administrateur en deux processus distincts.
3. Windows 2000 et Windows XP créent chaque compte d’utilisateur en tant qu’administrateur par défaut ; par conséquent, les composants Windows clés, tels que la date et l’heure et les panneaux de contrôle Gestion de l’alimentation, ne fonctionnent pas correctement pour un utilisateur standard
4. Les administrateurs Windows 2000 et Windows XP doivent créer deux comptes d’utilisateur distincts : un pour les tâches administratives et un compte d’utilisateur standard pour effectuer des tâches quotidiennes. Par conséquent, les utilisateurs doivent se déconnecter de leurs comptes d’utilisateur standard et se reconnecter en tant qu’administrateur ou utiliser l’identification pour effectuer toute tâche d’administration.

Avec le contrôle de compte d’utilisateur (UAC), Microsoft fournit une technologie pour simplifier le déploiement de bureaux utilisateur standard, en entreprise et à la maison.

En s’appuyant sur l’architecture de sécurité Windows telle que conçue à l’origine dans le système d’exploitation Microsoft Windows NT 3.1, l’équipe UAC a cherché à implémenter un modèle utilisateur standard à la fois flexible et plus sécurisé. Dans les versions précédentes de Windows, un jeton d’accès est créé pour un administrateur pendant le processus d’ouverture de session. Le jeton d’accès de l’administrateur inclut la plupart des privilèges Windows et la plupart des identificateurs de sécurité administratifs (SID). Ce jeton d’accès garantit qu’un administrateur peut installer des applications, configurer le système d’exploitation et accéder à n’importe quelle ressource.

L’équipe UAC a eu une approche radicalement différente du processus de création de jetons d’accès dans Windows Vista. Lorsqu’un utilisateur administrateur se connecte à un ordinateur Windows Vista, deux jetons d’accès sont créés : un jeton d’accès utilisateur standard filtré et un jeton d’accès administrateur complet. Au lieu de lancer le bureau (Explorer.exe) avec le jeton d’accès de l’administrateur, le jeton d’accès utilisateur standard est utilisé. Tous les processus enfants héritent de ce lancement initial du bureau (processus explorer.exe), ce qui permet de limiter la surface d’attaque de Windows Vistas. Par défaut, tous les utilisateurs, y compris les administrateurs, se connectent à un ordinateur Windows Vista en tant qu’utilisateurs standard.

Note Il existe une exception à l’instruction précédente : les invités se connectent à l’ordinateur avec moins de droits d’utilisateur et de privilèges que les utilisateurs standard.

Lorsqu’un administrateur tente d’effectuer une tâche d’administration, telle que l’installation d’une application, le contrôle D’utilisateur invite l’utilisateur à approuver l’action. Lorsque l’utilisateur approuve l’action, la tâche est lancée avec le jeton d’accès administrateur complet de l’administrateur. Il s’agit du comportement d’invite d’administrateur par défaut, qui est configurable dans le composant logiciel enfichable Gestionnaire de stratégies de sécurité local (secpol.msc) et avec stratégie de groupe (gpedit.msc).

Note Un compte d’administrateur sur un ordinateur Windows Vista avec UAC activé est également appelé compte d’administrateur en mode d’approbation Administration. Administration mode d’approbation identifie l’expérience utilisateur par défaut pour les administrateurs.

Chaque élévation administrative est également spécifique au processus, ce qui empêche d’autres processus d’utiliser le jeton d’accès sans demander l’approbation de l’utilisateur. Par conséquent, les utilisateurs administrateurs disposent d’un contrôle plus granulaire sur les applications installées, tout en ayant un impact considérable sur les logiciels malveillants qui s’attendent à ce que l’utilisateur connecté s’exécute avec un jeton d’accès administrateur complet.

Les utilisateurs standard ont également la possibilité d’élever leur niveau de flux et d’effectuer des tâches administratives à l’aide de l’infrastructure UAC. Lorsqu’un utilisateur standard tente d’effectuer une tâche d’administration, le contrôle d’utilisateur invite l’utilisateur à entrer des informations d’identification valides pour un compte d’administrateur. Il s’agit du comportement d’invite utilisateur standard par défaut, et il est configurable dans le composant logiciel enfichable Gestionnaire de stratégies de sécurité local (secpol.msc) et avec stratégie de groupe (gpedit.msc).

Windows Vista Mises à jour

Les mises à jour suivantes reflètent les principales modifications cumulatives apportées aux fonctionnalités qui se sont produites dans Windows Vista.

UAC est activé par défaut

Par conséquent, vous pouvez rencontrer des problèmes de compatibilité avec différentes applications qui n’ont pas encore été mises à jour pour le composant UAC Windows Vista. Si une application nécessite un jeton d’accès administrateur (ce qui indique qu’une erreur « accès refusé » est retournée lorsque vous tentez d’exécuter l’application), vous pouvez exécuter le programme en tant qu’administrateur à l’aide de l’option Exécuter en tant qu’administrateur dans le menu contextuel (clic droit). La procédure à suivre est décrite plus loin dans ce document dans la section Exécution de programmes en tant qu’administrateur.

Tous les comptes d’utilisateur suivants sont créés en tant qu’utilisateurs standard

Les comptes d’utilisateur standard et les comptes d’utilisateur administrateur peuvent tirer parti de la sécurité améliorée du contrôle d’utilisateur. Sur les nouvelles installations, par défaut, le premier compte d’utilisateur créé est un compte d’administrateur local en mode d’approbation Administration (UAC activé). Tous les comptes suivants sont ensuite créés en tant qu’utilisateurs standard.

Les invites d’élévation sont affichées sur Le Bureau sécurisé par défaut

Les invites de consentement et d’informations d’identification s’affichent par défaut sur le Bureau sécurisé dans Windows Vista.

Les invites d’élévation pour les applications en arrière-plan sont réduites à la barre des tâches

Les applications en arrière-plan invitent automatiquement l’utilisateur à une élévation dans la barre des tâches, au lieu d’accéder automatiquement au bureau sécurisé pour l’élévation. L’invite d’élévation apparaît réduite dans la barre des tâches et clignote pour informer l’utilisateur qu’une application a demandé une élévation. Un exemple d’élévation d’arrière-plan se produit lorsqu’un utilisateur accède à un site Web et commence à télécharger un fichier d’installation. L’utilisateur accède ensuite à case activée courrier électronique pendant le téléchargement de l’installation en arrière-plan. Une fois le téléchargement terminé en arrière-plan et que l’installation a commencé, l’élévation est détectée en tant que tâche en arrière-plan plutôt qu’en tant que tâche de premier plan. Cette détection empêche l’installation de voler brusquement le focus de l’écran de l’utilisateur pendant que l’utilisateur effectue une autre tâche: la lecture du courrier électronique. Ce comportement crée une meilleure expérience utilisateur pour l’invite d’élévation. Des informations sur la façon dont les développeurs d’applications peuvent s’assurer que leurs applications ne sont pas réduites à la barre des tâches lorsqu’ils demandent une élévation sont disponibles plus loin dans ce document.

Les élévations sont bloquées dans le chemin d’ouverture de session de l’utilisateur

Les applications qui démarrent lorsque l’utilisateur se connecte et nécessitent une élévation sont désormais bloquées dans le chemin d’ouverture de session. Sans empêcher les applications de demander une élévation dans le chemin d’accès de l’utilisateur, les utilisateurs standard et les administrateurs doivent répondre à une boîte de dialogue Contrôle de compte d’utilisateur à chaque ouverture de session. Windows Vista avertit l’utilisateur si une application a été bloquée en plaçant une icône dans la barre d’état système. L’utilisateur peut ensuite cliquer avec le bouton droit sur cette icône pour exécuter les applications qui ont été bloquées pour demander une élévation lorsque l’utilisateur s’est connecté. L’utilisateur peut gérer les applications de démarrage qui sont désactivées ou supprimées de cette liste en double-cliquant sur l’icône de la barre d’état.

Le compte administrateur intégré est désactivé par défaut sur les nouvelles installations

Le compte Administrateur intégré est désactivé par défaut dans Windows Vista. Si Windows Vista détermine, lors d’une mise à niveau à partir de Windows XP, que l’administrateur intégré est le seul compte administrateur local actif, Windows Vista laisse le compte activé et place le compte en mode d’approbation Administration. Par défaut, le compte administrateur intégré ne peut pas se connecter à l’ordinateur en mode sans échec. Pour plus d’informations, consultez les sections suivantes. Le compte administrateur intégré est créé pendant l’installation avec le nom d’utilisateur Administrateur.

Non joint à un domaine

Quand au moins un compte d’administrateur local est activé, le mode sans échec n’autorise pas l’ouverture de session avec le compte d’administrateur intégré désactivé. Au lieu de cela, n’importe quel compte d’administrateur local peut être utilisé pour vous connecter. Si le dernier compte d’administrateur local est rétrogradé, désactivé ou supprimé par inadvertance, le mode sans échec autorise le compte d’administrateur intégré désactivé à se connecter pour la récupération d’urgence.

Joint à un domaine

Dans tous les cas, le compte administrateur intégré désactivé ne peut pas se connecter en mode sans échec. Un compte d’utilisateur membre du groupe Administrateurs du domaine peut se connecter à l’ordinateur pour créer un administrateur local s’il n’en existe aucun.

Note Si le compte d’administration de domaine ne s’était jamais connecté auparavant, l’ordinateur doit être démarré en mode sans échec avec mise en réseau, car les informations d’identification n’auront pas été mises en cache.

Note Une fois l’ordinateur disjoint, il revient au comportement non joint à un domaine décrit précédemment.

Contrôle de compte d’utilisateur et scénarios distants

Lorsqu’un administrateur se connecte à distance à un ordinateur Windows Vista, via le Bureau à distance pour instance, l’utilisateur est connecté à l’ordinateur en tant qu’utilisateur standard par défaut. L’administration à distance a été modifiée pour être restrictive sur le réseau. Cela permet d’empêcher les logiciels malveillants d’effectuer des « bouclages » d’application si un utilisateur s’exécute avec un potentiel administratif.

comptes d’utilisateur local

Lorsqu’un utilisateur disposant d’un compte administrateur dans la base de données locale du Gestionnaire de comptes de sécurité (SAM) d’un ordinateur Windows Vista se connecte à distance à un ordinateur Windows Vista, l’utilisateur n’a aucun potentiel d’élévation sur l’ordinateur distant et ne peut pas effectuer de tâches administratives. Si l’utilisateur souhaite administrer la station de travail avec un compte SAM, il doit se connecter de manière interactive à l’ordinateur à administrer.

Comptes d’utilisateur de domaine

Lorsqu’un utilisateur disposant d’un compte d’utilisateur de domaine se connecte à distance à un ordinateur Windows Vista où il est membre du groupe Administrateurs, l’utilisateur du domaine s’exécute avec un jeton d’accès administrateur complet sur l’ordinateur distant et le contrôle d’utilisateur n’est pas en vigueur.

Nouveaux paramètres de liste de Access Control par défaut (ACL)

Les listes de contrôle d’accès de certains répertoires Windows ont été modifiées pour permettre le partage et la collaboration des données dans les répertoires de données et en dehors des répertoires protégés des utilisateurs. Le répertoire protégé d’un utilisateur est son profil utilisateur (par exemple, C:\Users\Denise\Pictures\), tandis qu’un exemple de répertoire de données est situé en dehors de la partition du système d’exploitation sur un lecteur de données (par exemple, D:\Pictures\). Étant donné que le répertoire racine, C dans cette instance, est protégé par des listes de contrôle d’accès plus restrictives, les utilisateurs n’ont pas pu utiliser les répertoires de données dans les premières versions de Windows Vista.

Ces modifications de la liste de contrôle d’accès garantissent que les utilisateurs peuvent partager et modifier des fichiers sans avoir à fournir d’approbation à une boîte de dialogue Contrôle de compte d’utilisateur. En outre, les utilisateurs peuvent désormais rendre un dossier privé. Cette modification garantit que les utilisateurs peuvent toujours maintenir facilement la confidentialité et l’intégrité des données sur les lecteurs de données. Ces dossiers privés sont toujours lisibles par d’autres administrateurs s’ils sont élevés et doivent être utilisés pour garder les données privées des utilisateurs standard.

Voici les paramètres de liste de contrôle d’accès par défaut sur %systemroot% et le lecteur de données dans Windows XP.

Paramètres de liste de contrôle d’accès windows XP %systemroot% et lecteur de données

Utilisateur ou groupe	entrée Access Control
BUILTIN\Administrators	Contrôle total
NT AUTHORITY\SYSTEM	Contrôle total
CREATOR OWNER	Contrôle total
BUILTIN\Users	Lire Accès spécial : FILE_APPEND_DATA Accès spécial : FILE_WRITE_DATA
Tout le monde	Lire

Le tableau suivant détaille les nouveaux paramètres de liste de contrôle d’accès des lecteurs de données Windows Vista pour les lecteurs de données créés avec format.exe.

Paramètres de liste de contrôle d’accès du lecteur de données Windows Vista

Utilisateur ou groupe	entrée Access Control
BUILTIN\Administrators	Contrôle total
NT AUTHORITY\SYSTEM	Contrôle total
NT AUTHORITY\Authenticated Users	Modifier
BUILTIN\Users	Lecture et exécution Lecture générique, exécution générique

Le tableau suivant détaille les nouveaux paramètres de liste de contrôle d’accès racine du système d’exploitation Windows Vista (%systemroot%).

Paramètres de liste de contrôle d’accès Windows Vista %systemroot%

Utilisateur ou groupe	entrée Access Control
BUILTIN\Administrators	Contrôle total
NT AUTHORITY\SYSTEM	Contrôle total
BUILTIN\Users	Lecture et exécution
NT AUTHORITY\Authenticated Users	Modifier Ajout de données
Étiquette obligatoire\Niveau obligatoire élevé	Aucune écriture

Nouveaux paramètres de sécurité du contrôle d’utilisateur et changements de nom des paramètres de sécurité

Les nouveaux paramètres de sécurité et les mises à jour des noms des paramètres de sécurité sont détaillés dans la section Références de ce document.

Nouvelles technologies pour Windows Vista

Les sections suivantes détaillent les nouvelles technologies pour Windows Vista, notamment la détection du programme d’installation, la mise à jour corrective utilisateur standard avec Windows Installer 4.0, l’isolation des privilèges d’interface utilisateur et la virtualisation.

Service d'installation ActiveX

Le service d’installation ActiveX permet aux entreprises de déléguer l’installation du contrôle ActiveX pour les utilisateurs standard. Ce service garantit que les tâches métier de routine ne sont pas entravées par l’échec des mises à jour et des installations de contrôle ActiveX. Windows Vista inclut également des paramètres stratégie de groupe qui permettent aux professionnels de l’informatique de définir des URL d’hôte à partir desquelles les utilisateurs standard peuvent installer des contrôles ActiveX. Le service d’installation ActiveX se compose d’un service Windows, d’un modèle d’administration stratégie de groupe et de certaines modifications apportées à Internet Explorer. Il s’agit d’un composant facultatif qui ne sera activé que sur les clients sur lesquels il est installé.

Détection du programme d’installation

Les programmes d’installation sont des applications conçues pour déployer des logiciels, et la plupart écrivent dans des répertoires système et des clés de Registre. Ces emplacements système protégés sont généralement accessibles en écriture uniquement par les utilisateurs administrateurs ; cela signifie que les utilisateurs standard ne disposent pas d’un accès suffisant pour installer des programmes. Windows Vista détecte de manière heuristique les programmes d’installation et demande des informations d’identification d’administrateur ou l’approbation de l’utilisateur administrateur afin de s’exécuter avec des privilèges d’accès. Windows Vista détecte également de manière heuristique les programmes de mise à jour et de désinstallation. Notez qu’un objectif de conception de UAC est d’empêcher les installations d’être exécutées à l’insu et au consentement de l’utilisateur, car elles écrivent dans des zones protégées du système de fichiers et du registre.

Important Lorsque vous développez de nouveaux programmes d’installation, tout comme le développement de programmes pour Windows Vista, veillez à incorporer un manifeste d’application avec un élément requestedExecutionLevel approprié (voir la section Étape six : Créer et incorporer un manifeste d’application avec votre application). Lorsque le requestedExecutionLevel est présent dans le manifeste de l’application incorporée, il remplace la détection du programme d’installation.

La détection du programme d’installation s’applique uniquement à :

• Exécutables 32 bits
• Applications sans requestedExecutionLevel
• Processus interactifs s’exécutant en tant qu’utilisateur standard avec LUA activé

Avant la création d’un processus 32 bits, les attributs suivants sont vérifiés pour déterminer s’il s’agit d’un programme d’installation :

• Le nom de fichier inclut des mots clés tels que « install », « setup », « update », etc.
• Mots clés dans les champs de ressource de contrôle de version suivants : Fournisseur, Nom de la société, Nom du produit, Description du fichier, Nom de fichier d’origine, Nom interne et Nom de l’exportation.
• Mots clés dans le manifeste côte à côte incorporé dans l’exécutable.
• Mots clés dans des entrées StringTable spécifiques liées dans l’exécutable.
• Attributs clés dans les données RC liées dans l’exécutable.
• Séquences ciblées d’octets dans l’exécutable.

Note Les mots clés et les séquences d’octets ont été dérivés des caractéristiques courantes observées à partir de différentes technologies d’installation.

Veillez à bien consulter l’intégralité de ce document, y compris la section Étape six : Créer et incorporer un manifeste d’application avec votre application.

Note Le paramètre Contrôle de compte d’utilisateur : Détecter les installations d’application et demander l’élévation doit être activé pour la détection du programme d’installation afin de détecter les programmes d’installation. Ce paramètre est activé par défaut et peut être configuré avec le composant logiciel enfichable Security Policy Manager (secpol.msc) ou avec stratégie de groupe (gpedit.msc).

Vous trouverez des informations générales et une vue d’ensemble de Microsoft Windows Installer dans MSDN Library.

Mise à jour corrective d’applications dans un environnement de contrôle d’utilisateur

Microsoft Windows Installer 4.0 a été conçu avec UAC à l’esprit afin de faciliter l’installation des applications et la mise à jour corrective. Avec l’introduction de Windows Installer 4.0, les correctifs peuvent être appliqués aux applications sans réinstaller une version plus récente de l’application. Cette méthode est idéale lorsqu’une application est déployée dans une installation par ordinateur et que des correctifs doivent être déployés par un utilisateur sans nécessiter de jeton d’accès administratif. Pour plus d’informations sur la création et l’application de correctifs aux applications, consultez Mise à jour corrective Per-User applications managées.

Intégration de Security Center

Lorsque le contrôle D’utilisateur est désactivé sur un ordinateur Windows Vista, security Center crée une alerte et invite l’utilisateur à réactiver le contrôle d’utilisateur. Security Center affiche cette alerte une fois que l’ordinateur a été redémarré après la modification du paramètre UAC.

Isolation des privilèges de l’interface utilisateur

L’isolation des privilèges d’interface utilisateur (UIPI) est l’un des mécanismes qui permettent d’isoler les applications s’exécutant en tant qu’administrateur complet des processus exécutés en tant que compte inférieur à celui d’un administrateur sur le même bureau interactif. UIPI est spécifique au sous-système de fenêtrage et de graphisme appelé USER qui prend en charge les contrôles de fenêtres et d’interface utilisateur. UIPI empêche une application à privilèges inférieurs d’utiliser des messages Windows pour envoyer des entrées d’un processus à un processus à privilège supérieur. L’envoi d’une entrée d’un processus à un autre permet à un processus d’injecter des entrées dans un autre processus sans que l’utilisateur fournisse d’actions au clavier ou à la souris.

Le concept derrière UIPI est simple. Windows Vista définit un ensemble de niveaux de privilèges d’interface utilisateur de manière hiérarchique. La nature des niveaux est telle que des niveaux de privilèges plus élevés peuvent envoyer des messages de fenêtre aux applications s’exécutant à des niveaux inférieurs. Toutefois, les niveaux inférieurs ne peuvent pas envoyer de messages de fenêtre aux fenêtres d’application aux niveaux supérieurs.

Le niveau de privilèges de l’interface utilisateur est au niveau du processus. Lorsqu’un processus est initialisé, le sous-système utilisateur appelle le sous-système de sécurité pour déterminer le niveau d’intégrité du bureau attribué dans le jeton d’accès de sécurité du processus. Le niveau d’intégrité du bureau est défini par le sous-système de sécurité lorsque le processus est créé et ne change pas. Par conséquent, le niveau de privilège de l’interface utilisateur est également défini par le sous-système Utilisateur lorsque le processus est créé et ne change pas.

Toutes les applications exécutées par un utilisateur standard ont le même niveau de privilège d’interface utilisateur. En tant qu’utilisateur standard, les applications sont exécutées à un niveau de privilège unique. UIPI n’interfère pas ou ne modifie pas le comportement de la messagerie de fenêtre entre les applications au même niveau de privilège. UIPI entre en vigueur pour un utilisateur qui est membre du groupe administrateurs et qui peut exécuter des applications en tant qu’utilisateur standard (parfois appelé processus avec un jeton d’accès filtré) et qui s’exécute également avec un jeton d’accès administrateur complet sur le même bureau. UIPI empêche les processus à privilèges inférieurs d’accéder aux processus à privilèges plus élevés en bloquant le comportement suivant.

Un processus à privilèges inférieurs ne peut pas :

• Effectuez une validation de gestion de fenêtre des privilèges de processus plus élevés.
• SendMessage ou PostMessage vers les fenêtres d’application à privilèges supérieurs. Ces interfaces de programmation d’application (API) retournent la réussite, mais suppriment silencieusement le message de fenêtre.
• Utilisez des hooks de thread pour l’attacher à un processus à privilèges plus élevés.
• Utilisez des hooks de journal pour surveiller un processus à privilèges plus élevés.
• Effectuez l’injection de bibliothèque de liens dynamiques (DLL) dans un processus à privilèges plus élevés.

Avec UIPI activé, les ressources UTILISATEUR partagées suivantes sont toujours partagées entre les processus à différents niveaux de privilèges :

• Fenêtre de bureau, qui possède en fait la surface de l’écran
• Mémoire partagée en lecture seule du tas de bureau
• Table d’atomes globale
• Presse-papiers

La peinture à l’écran est une autre action qui n’est pas bloquée par UIPI. La peinture à l’écran fait référence au processus d’utilisation de la méthode Paint pour afficher du contenu sur une sortie externe( un moniteur, par exemple). Le modèle USER/graphics device interface (GDI) n’autorise pas le contrôle sur les surfaces de peinture ; par conséquent, il est possible pour une application à privilèges inférieurs de peindre sur la zone de surface d’une fenêtre d’application à privilèges plus élevés.

Note Étant donné que l’interpréteur de commandes Windows (Explorer) s’exécute en tant que processus utilisateur standard, tout autre processus exécuté en tant qu’utilisateur standard peut toujours lui envoyer des frappes. C’est la raison principale pour laquelle un compte administrateur en mode approbation Administration est invité à demander un consentement d’élévation lorsqu’il lance une action administrative, par exemple en double-cliquant sur un Setup.exe ou en cliquant sur une icône de bouclier d’élévation.

Virtualisation

Important La virtualisation est implémentée pour améliorer les problèmes de compatibilité des applications pour les applications s’exécutant en tant qu’utilisateur standard sur Windows Vista. Les développeurs ne doivent pas compter sur la virtualisation présente dans les versions ultérieures de Windows.

Avant Windows Vista, de nombreuses applications étaient généralement exécutées par des administrateurs. Par conséquent, les applications peuvent lire et écrire librement des fichiers système et des clés de Registre. Si ces applications étaient exécutées par un utilisateur standard, elles échoueraient en raison d’un accès insuffisant. Windows Vista améliore la compatibilité des applications pour ces utilisateurs en redirigeant les écritures (et les opérations de fichier ou de Registre suivantes) vers un emplacement par utilisateur dans le profil de l’utilisateur. Par exemple, si une application tente d’écrire dans C:\Program Files\Contoso\Settings.ini et que l’utilisateur ne dispose pas des autorisations nécessaires pour écrire dans ce répertoire, l’écriture est redirigée vers C:\Users\<user name>\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. Pour le Registre, si une application tente d’écrire dans HKEY_LOCAL_MACHINE\Software\Contoso\ elle est automatiquement redirigée vers HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso ou HKEY_USERS\< SID >utilisateur _Classes\VirtualStore\Machine\Software\Contoso.

La figure suivante détaille le processus de virtualisation dans Windows Vista. Dans cet exemple, Denise est administrateur en mode approbation Administration et Brian est un utilisateur standard. La virtualisation est composée de deux composants : la virtualisation de fichiers et la virtualisation du Registre.

Figure 1. Processus de virtualisation

Important Lorsque vous développez des programmes Windows Vista, pour réduire la complexité des fichiers virtualisés et des clés de Registre, veillez à incorporer un manifeste d’application avec un élément demandéExecutionLevel approprié afin de désactiver la virtualisation des fichiers et du Registre.

La virtualisation est activée uniquement pour :

• Processus interactifs 32 bits
• Fichiers/dossiers et clés de Registre pouvant être écrits par l’administrateur

La virtualisation est désactivée pour :

• Processus 64 bits
• Processus non interactifs
• Processus qui empruntent l’identité
• Appelants en mode noyau
• Exécutables qui ont un objet requestedExecutionLevel

Virtualisation et itinérance :

• Les fichiers/dossiers de virtualisation et les clés de Registre ne sont pas itinérants (voir profils itinérants)
• Associé à des objets globaux qui ne sont pas itinérants

Virtualisation de fichiers

La virtualisation de fichiers résout le cas où une application s’appuie sur la possibilité de stocker un fichier, tel qu’un fichier de configuration, dans un emplacement système généralement accessible en écriture uniquement par les administrateurs. L’exécution de programmes en tant qu’utilisateur standard dans ce cas peut entraîner des échecs de programme en raison de niveaux d’accès insuffisants.

Lorsqu’une application écrit dans un emplacement système accessible uniquement par les administrateurs, Windows écrit ensuite toutes les opérations de fichier suivantes dans un chemin d’accès spécifique à l’utilisateur sous le répertoire Virtual Store, qui se trouve dans %LOCALAPPDATA%\VirtualStore. Plus tard, lorsque l’application lit ce fichier, le système fournit celui dans le Magasin virtuel. Étant donné que l’infrastructure de sécurité Windows traite la virtualisation sans l’aide de l’application, l’application estime qu’elle a pu lire et écrire directement dans Program Files. La transparence de la virtualisation de fichiers permet aux applications de percevoir qu’elles écrivent et lisent à partir de la ressource protégée, alors qu’en fait, elles accèdent à la version virtualisée.

Note Lorsque vous énumérez des ressources dans des dossiers et dans le Registre, Windows Vista fusionne les clés de fichier/dossier global et de Registre en une seule liste. Dans cette vue fusionnée, la ressource globale (protégée) est répertoriée avec la ressource virtualisée.

Important La copie virtuelle sera toujours présente dans l’application en premier. Par exemple, config.ini est disponible dans \PF\App\config.ini et %LOCALAPPDATA%\VirtualStore\config.ini, et le config.ini dans le magasin virtuel sera toujours celui lu, même si \PF\App\config.ini est mis à jour.

La figure suivante décrit en détail la façon dont les affichages globaux et fusionnés pour les ressources virtualisées sont affichés pour différents utilisateurs.

Figure 2 : Ressources et vues virtualisées

Voici un exemple de processus de virtualisation de fichiers :

Syed Abbas, représentant commercial à la Woodgrove Bank, fonctionne sous un compte d’utilisateur standard sur un ordinateur qu’il partage avec d’autres représentants commerciaux. Syed utilise souvent une application de feuille de calcul pour mettre à jour et enregistrer un fichier dans le répertoire Program Files\SalesV1\ : \Program Files\SalesV1\SalesData.txt. Bien que Program Files\SalesV1\ soit protégé, le fichier sera enregistré correctement à partir du point de vue de l’application de feuille de calcul en raison de la virtualisation de fichiers Windows Vista. Pour ce faire, l’écriture du fichier est redirigée vers Users\username\appdata\Virtual Store\Program Files\SalesV1\SalesData.txt. Lorsque Syed ouvre Windows Explorer et accède au répertoire Program Files, il voit l’affichage global du fichier SalesData.txt.

Note Pour que Syed découvre ses fichiers virtualisés, il doit accéder au magasin virtuel avec le bouton Fichiers de compatibilité dans la barre d’outils Explorer.

Toutefois, une fois que Stuart Munson, un autre représentant commercial, s’est connecté à la station de travail, il ne verra PAS le fichier SalesData.txt dans le répertoire Program Files\SalesV1\. Si un autre utilisateur utilise l’ordinateur et écrit le fichier \Program files\SalesV1\SalesData.txt, cette écriture est également virtualisé dans le magasin virtuel de cet utilisateur. Les fichiers mis à jour et enregistrés par Syed restent indépendants des autres fichiers virtualisés sur le système.

Virtualisation du Registre

La virtualisation du Registre est similaire à la virtualisation de fichiers, mais s’applique aux clés de Registre sous HKEY_LOCAL_MACHINE\SOFTWARE. Cette fonctionnalité permet aux applications qui s’appuient sur la possibilité de stocker des informations de configuration dans HKEY_LOCAL_MACHINE\SOFTWARE de continuer à fonctionner lorsqu’elles sont exécutées sous un compte d’utilisateur standard. Les clés et les données sont redirigées vers HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE. Comme dans le cas de la virtualisation de fichiers, chaque utilisateur dispose d’une copie virtualisée de toutes les valeurs stockées par une application dans HKLM.

Détails de la virtualisation du Registre

• Peut être activé/désactivé sur des clés individuelles dans la ruche logiciel
• Nouvelle option FLAGS dans reg.exe pour le contrôle de virtualisation au niveau clé : Autorise l’activation/désactivation récursive de la virtualisation et le contrôle de la « stratégie de droit d’accès ouvert »
• ZwQueryKey : interrogez par programmation les indicateurs de virtualisation pour une clé.
• La virtualisation se produit par-dessus la redirection WoW64
• Activé à la fois dans les vues de Registre 64 bits et 32 bits : HKU\{SID}_Classes\VirtualStore\Machine\Software et HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264
• La plupart des applications 32 bits héritées utilisent la vue 32 bits

La virtualisation est destinée uniquement à faciliter la compatibilité des applications avec les programmes existants. Les applications conçues pour Windows Vista ne doivent PAS effectuer d’écritures dans des zones système sensibles, et elles ne doivent pas non plus s’appuyer sur la virtualisation pour corriger le comportement incorrect des applications. Lors de la mise à jour du code existant pour l’exécuter sur Windows Vista, les développeurs doivent s’assurer que, pendant l’exécution, les applications stockent uniquement les données dans des emplacements par utilisateur ou dans des emplacements d’ordinateur dans %alluserprofile% (CSIDL_COMMON_APPDATA) qui ont des paramètres de liste de contrôle d’accès (ACL) correctement définis.

Important Microsoft a l’intention de supprimer la virtualisation des futures versions du système d’exploitation Windows à mesure que d’autres applications sont migrées vers Windows Vista. Par exemple, la virtualisation est désactivée sur les applications 64 bits.

Recommandations relatives à la virtualisation

La virtualisation est destinée uniquement à faciliter la compatibilité des applications avec les programmes existants. Les applications conçues pour Windows Vista ne doivent PAS effectuer d’écritures dans des zones système sensibles, ni s’appuyer sur la virtualisation pour fournir une réparation en cas de comportement incorrect des applications. Lors de la mise à jour du code existant pour qu’il s’exécute sur Windows Vista, les développeurs doivent s’assurer que, pendant l’exécution, les applications stockent uniquement les données dans des emplacements par utilisateur ou dans des emplacements d’ordinateur dans %alluserprofile% dont les paramètres de liste de contrôle d’accès (ACL) sont correctement définis.

Important Microsoft a l’intention de supprimer la virtualisation des futures versions du système d’exploitation Windows à mesure que d’autres applications sont migrées vers Windows Vista. Par exemple, la virtualisation est désactivée sur les applications 64 bits.

• Ajoutez un manifeste d’application avec un requestedExecutionLevel approprié pour vos applications interactives. Cela désactive la virtualisation pour l’application manifestée.
• N’utilisez pas le Registre comme mécanisme de communication interprocessus. Les services et les applications utilisateur ont des vues différentes de la clé.
• Tester votre application sur Windows Vista : vérifiez que les processus s’exécutant en tant qu’utilisateur standard n’écrivent pas dans des espaces de noms globaux comme %systemroot%.
• Pour les développeurs de pilotes de filtre : vérifiez votre plage d’altitude. Consultez Filtres du système de fichiers. Celles-ci doivent être supérieures à la virtualisation FSFilter.
• N’oubliez pas que les ressources virtualisées sont des copies par utilisateur de ressources globales.

Modifications du jeton d’accès

Lorsqu’un utilisateur se connecte à un ordinateur Windows Vista, Windows examine les privilèges Windows d’administration et les ID relatifs (RID) que possède le compte d’utilisateur pour déterminer si l’utilisateur doit recevoir deux jetons d’accès (un jeton d’accès filtré et un jeton d’accès complet). Windows crée deux jetons d’accès pour l’utilisateur si l’une des conditions suivantes est remplie :

1. Le compte de l’utilisateur contient l’un des RID suivants.
   • DOMAIN_GROUP_RID_ADMINS
   • DOMAIN_GROUP_RID_CONTROLLERS
   • DOMAIN_GROUP_RID_CERT_ADMINS
   • DOMAIN_GROUP_RID_SCHEMA_ADMINS
   • DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
   • DOMAIN_GROUP_RID_POLICY_ADMINS
   • DOMAIN_ALIAS_RID_ADMINS
   • DOMAIN_ALIAS_RID_POWER_USERS
   • DOMAIN_ALIAS_RID_ACCOUNT_OPS
   • DOMAIN_ALIAS_RID_SYSTEM_OPS
   • DOMAIN_ALIAS_RID_PRINT_OPS
   • DOMAIN_ALIAS_RID_BACKUP_OPS
   • DOMAIN_ALIAS_RID_RAS_SERVERS
   • DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
   • DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
   • DOMAIN_ALIAS_RID_CRYPTO_OPERATORS
2. Le compte d’utilisateur contient tous les privilèges autres que ceux d’un compte d’utilisateur standard. Un compte d’utilisateur standard contient uniquement les privilèges suivants.
   • SeChangeNotifyPrivilege
   • SeShutdownPrivilege
   • SeUndockPrivilege
   • SeIncreaseWorkingSetPrivilege
   • SeTimeZonePrivilege

Les privilèges que le jeton filtré contient sont basés sur le fait que le jeton d’origine contenait l’un des RIDS restreints répertoriés ci-dessus. Si l’un des RID restreints se trouve dans le jeton, tous les privilèges sont supprimés, sauf :

• SeChangeNotifyPrivilege
• SeShutdownPrivilege
• SeUndockPrivilege
• SeReserveProcessorPrivilege
• SeTimeZonePrivilege

Si aucun RID restreint n’était dans le jeton, seuls les privilèges suivants sont supprimés :

• SeCreateTokenPrivilege
• SeTcbPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeDebugPrivilege
• SeImpersonatePrivilege
• SeRelabelPrivilege

Le premier jeton d’accès, appelé jeton d’accès filtré, a les RID précédents (le cas échéant) marqués comme USE_FOR_DENY_ONLY dans le jeton d’accès et les privilèges Windows d’administration, non répertoriés précédemment, sont supprimés. Le jeton d’accès filtré est utilisé par défaut lorsque l’utilisateur lance des applications. Le jeton d’accès complet non modifié, appelé jeton d’accès lié, est attaché au jeton d’accès filtré et est utilisé lorsque des demandes sont effectuées pour lancer des applications avec un jeton d’accès administratif complet.

Pour plus d’informations sur les RID, consultez l’article DE LA bibliothèque MSDN , SID Strings [Security].

Pour plus d’informations sur les privilèges Windows, consultez l’article MSDN Library Authorization Constants [Security].

Architecture UAC

Le diagramme suivant représente le flux de processus pour les lancements d’exécutables dans Windows Vista.

Figure 3. Architecture UAC

Voici une description du flux de processus affiché dans le diagramme d’architecture UAC et de la façon dont le contrôle d’utilisateur est implémenté lorsqu’un exécutable tente de se lancer.

Chemin de lancement de l’utilisateur standard

Le chemin de lancement de l’utilisateur windows Vista standard est similaire au chemin de lancement de Windows XP, mais inclut certaines modifications.

• ShellExecute() appelle CreateProcess().
• CreateProcess() appelle AppCompat, Fusion et Détection du programme d’installation pour déterminer si l’application nécessite une élévation. L’exécutable est ensuite inspecté pour déterminer son objet requestedExecutionLevel, qui est stocké dans le manifeste de l’application de l’exécutable. La base de données AppCompat stocke des informations pour les entrées de correctif de compatibilité d’application d’une application. La détection du programme d’installation détecte les exécutables d’installation.
• CreateProcess() retourne un code d’erreur Win32 indiquant ERROR_ELEVATION_REQUIRED.
• ShellExecute() recherche spécifiquement cette nouvelle erreur et, lors de sa réception, appelle le service d’informations sur l’application (AIS) pour tenter le lancement avec élévation de privilèges.

Chemin de lancement avec élévation de privilèges

Le chemin de lancement de Windows Vista avec élévation de privilèges est un nouveau chemin de lancement Windows.

• AIS reçoit l’appel de ShellExecute() et réévalue le niveau d’exécution et les stratégie de groupe demandés pour déterminer si l’élévation est autorisée et définir l’expérience utilisateur de l’élévation.
• Si le niveau d’exécution demandé nécessite une élévation, le service lance l’invite d’élévation sur le bureau interactif de l’appelant (en fonction de stratégie de groupe), à l’aide du HWND transmis à partir de ShellExecute().
• Une fois que l’utilisateur a donné son consentement ou des informations d’identification valides, AIS récupère le jeton d’accès correspondant associé à l’utilisateur approprié, si nécessaire. Par exemple, une application demandant un requestedExecutionLevel de highestAvailable récupère des jetons d’accès différents pour un utilisateur qui n’est qu’un membre du groupe Opérateurs de sauvegarde que pour un membre du groupe Administrateurs local.
• AIS émet à nouveau un appel CreateProcessAsUser(), en fournissant le jeton d’accès administrateur et en spécifiant le bureau interactif de l’appelant.

La UAC affectera-t-elle votre application ?

Le fait que votre application soit ou non affectée par le contrôle d’utilisateur dépend de l’état actuel de l’application. Dans un certain nombre de cas, aucune modification ne sera nécessaire pour se conformer aux exigences de Microsoft Sécurité Windows. Toutefois, certaines applications, notamment les applications métier, peuvent nécessiter des modifications de leurs processus d’installation, de fonction et de mise à jour pour fonctionner correctement dans un environnement de contrôle d’utilisateur Windows Vista.

Note Si une application fonctionne bien en tant qu’utilisateur standard sur Windows XP, elle fonctionne bien en tant qu’utilisateur standard sur Windows Vista.

Pourquoi dois-je supprimer les dépendances administratives de mon application ?

Une étape fondamentale vers l’amélioration de la sécurité de l’environnement informatique global consiste à permettre aux utilisateurs de s’exécuter sans utiliser leur jeton d’accès administratif. Si une application fonctionne ou s’installe uniquement quand l’utilisateur est administrateur, les utilisateurs sont obligés d’exécuter des applications avec un accès élevé inutile. Le problème fondamental est que lorsque les utilisateurs sont toujours obligés d’exécuter des applications à l’aide de jetons d’accès élevés, du code trompeur ou malveillant peut facilement modifier le système d’exploitation, ou pire, affecter d’autres utilisateurs.

L’objectif de Microsoft est que les clients comprennent que les applications ne doivent pas s’exécuter inutilement en tant qu’administrateur et qu’ils se posent des questions chaque fois qu’ils sont invités à approuver la demande d’exécution d’une application en tant qu’administrateur. UAC est un composant fondamental pour aider à atteindre cet objectif et contribuera grandement à la restauration d’un environnement informatique plus sécurisé pour tous les utilisateurs.

Réduction du coût total de possession de votre application

Le compte d’utilisateur standard est très attrayant pour les administrateurs informatiques qui souhaitent renforcer la sécurité et le contrôle sur leurs machines managées tout en réduisant le coût total de possession (TCO). Étant donné qu’un compte d’utilisateur standard ne peut pas apporter de modifications système, il existe une relation directe avec la réduction du coût total de possession et un meilleur contrôle de l’installation des applications et des modifications à l’échelle du système. Le compte d’utilisateur standard est également attrayant pour les utilisateurs à domicile où les parents partagent un ordinateur avec des enfants. Microsoft Windows Vista inclut des contrôles parentaux intégrés, qui sont implémentés uniquement en créant des comptes d’utilisateur enfants en tant qu’utilisateurs standard. Les comptes d’utilisateur standard ne peuvent pas non plus modifier ou supprimer des fichiers créés par d’autres utilisateurs. Ils ne peuvent pas lire des fichiers dans les profils d’autres utilisateurs, infecter les fichiers système ou modifier les exécutables partagés par le système, accidentellement ou délibérément. Les comptes d’utilisateur standard entraînent une amélioration globale de la sécurité informatique et des contrôles parentaux.

Sécurisé par défaut

Chez Microsoft, les principes de l’initiative d’informatique digne de confiance de Microsoft ont été ancrés dans le développement de logiciels. Par conséquent, l’amélioration de la sécurité fait partie intégrante du processus de développement de Windows Vista.

Le pilier de sécurité de l’informatique digne de confiance englobe trois principes fondamentaux : sécurisé par conception, sécurisé par défaut et sécurisé dans le déploiement. La façon dont vous et d’autres éditeurs de logiciels indépendants développez vos applications pour contribuer à la sécurité globale du système d’exploitation sera un facteur clé de réussite pour atteindre l’informatique digne de confiance dans Windows Vista.

L’objectif du reste de ce guide est d’aider les développeurs à apprendre à :

• Écrire des applications qui ne nécessitent pas que l’utilisateur soit administrateur pour effectuer des tâches de routine
• Créez des packages d’installation avec les technologies de mise à jour corrective de Windows® Installer 4.0 UAC qui se déploient bien sur le bureau utilisateur standard dans les entreprises et mettent également à jour correctement dans la maison.
• Identifier les fonctionnalités utilisateur et administrative standard et extrapoler les tâches administratives pour la compatibilité UAC
• Écrire des interfaces utilisateur d’application qui utilisent la fonctionnalité UAC

Pour la réussite de l’UAC, il est essentiel que les développeurs d’applications adoptent la philosophie des privilèges minimum et conçoivent que leurs applications fonctionnent correctement lorsqu’ils s’exécutent avec un compte d’utilisateur standard.

L’un des objectifs de la version de Windows Vista est d’évangéliser et d’encourager le principe de la conception pour les utilisateurs et administrateurs standard en mode d’approbation Administration à tous les développeurs. L’atteinte de cet objectif contribuera à la prévention de diverses attaques contre des applications individuelles et atténuera le risque que de telles attaques compromettent la sécurité du système. Bien que ces objectifs puissent être réalisés dans une certaine mesure aujourd’hui en exigeant des administrateurs qu’ils utilisent deux comptes, ils ont tendance à échouer pour les raisons suivantes :

• Il est presque impossible de contrôler un utilisateur disposant d’un jeton d’accès administrateur complet. Les administrateurs peuvent installer des applications et exécuter n’importe quelle application ou script de leur choix. Les responsables informatiques recherchent toujours des moyens de créer des « bureaux standard » où les utilisateurs se connectent en tant qu’utilisateurs standard. Les bureaux standard réduisent considérablement les coûts du support technique et réduisent la surcharge informatique.
• Il y a une surcharge importante lors du basculement d’un compte à l’autre chaque fois que l’utilisateur souhaite effectuer une opération administrative.
• Après avoir effectué une opération d’administration, les utilisateurs peuvent oublier de revenir à leur compte d’utilisateur standard ou décider qu’il est trop important de revenir en arrière.

Par conséquent, les utilisateurs peuvent décider de toujours se connecter à leurs comptes d’administration, ce qui élimine les mesures de sécurité. Pour atténuer ce problème, UAC introduit le concept de mode d’approbation Administration. Un compte d’utilisateur en mode approbation Administration est un compte d’utilisateur membre du groupe Administrateurs locaux sur un système avec UAC activé.

Dans l’entreprise, Administration mode Approbation sera utilisé comme technologie de pont pour la migration vers Windows Vista. Dans l’idéal, les entreprises exécutent tous les utilisateurs en tant qu’utilisateurs standard et désactivent l’invite d’élévation pour les utilisateurs standard. Cette configuration active un bureau standard managé où les installations sont déployées avec une technologie de déploiement de logiciels, telle que Microsoft Systems Management Server (SMS).

Important Microsoft recommande toujours aux membres du groupe Administrateurs du domaine de continuer à gérer deux comptes d’utilisateur distincts dans Windows Vista : un compte d’utilisateur standard et un compte d’utilisateur administrateur de domaine. Toute l’administration du domaine doit être effectuée avec le compte d’administrateur de domaine. Pour améliorer davantage la sécurité, envisagez de déployer une solution de carte intelligente dans des environnements de domaine. Pour plus d’informations, consultez le Guide de planification de l’accès sécurisé à l’aide de cartes à puce .

Voici les objectifs de conception de Windows Vista pour Administration mode d’approbation :

• Éliminer la nécessité d’utiliser deux comptes distincts pour les utilisateurs membres du groupe Administrateurs : cet objectif est atteint en exécutant des programmes uniquement avec un jeton d’accès utilisateur standard, sauf si l’utilisateur autorise l’utilisation du jeton d’accès administratif complet.
• Protégez les processus en cours d’exécution avec un jeton d’accès administratif complet contre l’accès ou la modification par les processus s’exécutant en tant qu’utilisateur standard.
• Assurer une transition transparente entre les espaces de travail administrateur et utilisateur standard.

Actuellement, la plupart des applications Windows doivent être exécutées en tant qu’administrateur, mais n’effectuent pas d’opérations d’administration. Ces applications sont un sous-produit de la philosophie des systèmes d’exploitation Microsoft Windows 9x : « tout le monde est administrateur ».

Voici des exemples d’applications problématiques :

• Applications qui écrivent inutilement dans HKEY_LOCAL_MACHINE (HKLM) ou dans des fichiers système au sein du système de fichiers.
• Une installation ActiveX pour faciliter une application métier avec une interface web.
• Applications qui demandent inutilement l’accès aux ressources qui nécessitent un jeton d’accès administratif complet.

La section suivante présente les nouvelles technologies pour Windows Vista qui ont un impact sur les éditeurs de logiciels indépendants.

Comment déterminer si mon application a des dépendances administratives ?

Pour aider les développeurs, les éditeurs de logiciels indépendants et les organisations à évaluer leurs applications, Microsoft fournit Microsoft Standard User Analyzer. L’analyseur d’utilisateur standard peut être utilisé pour faciliter le comportement d’identité non conforme à l’UAC d’une application. Microsoft recommande aux développeurs d’exécuter cet outil pour identifier les problèmes liés à l’exécution de l’application sous un compte d’utilisateur standard. Ces tests doivent être effectués, même si l’application s’installe déjà et s’exécute correctement sous un compte d’utilisateur standard sur Windows XP. L’application peut effectuer des opérations, telles que la tentative d’écriture dans les emplacements du Registre système, et prendre des décisions en fonction du comportement du système, telles que la recherche d’une réponse d’erreur. Windows Vista peut se comporter différemment des versions antérieures du système d’exploitation Windows en raison de l’ajout d’une nouvelle prise en charge de la compatibilité des applications. Par conséquent, il est recommandé de tester toutes les applications avec la nouvelle version de Standard User Analyzer.

Standard User Analyzer enregistre toutes les opérations administratives rencontrées par une application, y compris l’accès au registre/système de fichiers et les appels d’API avec élévation de privilèges. Ces données sont stockées dans un fichier journal et sont affichées dans l’outil. L’analyseur d’utilisateurs standard identifie les dépendances courantes suivantes, en plus de bien d’autres :

• Dépendance aux objets qui limitent l’accès demandé aux utilisateurs approuvés uniquement.

  Par exemple, HKEY_LOCAL_MACHINE accorde uniquement des KEY_WRITE aux administrateurs et à SYSTEM: une application qui demande KEY_WRITE à HKEY_LOCAL_MACHINE ne fonctionnera pas avec la UAC activée.

• Utilisation de privilèges Windows qui ont des ramifications de sécurité, comme SE_DEBUG_PRIVILEGE, qui permet le débogage des processus d’autres utilisateurs et n’est accordé qu’aux administrateurs.

Quelles sont les conditions requises si j’ai une application administrateur légitime ?

Pour les applications qui, par conception, effectuent des opérations d’administration légitimes, Microsoft a implémenté une extension à la section trustInfo du schéma de manifeste d’application Windows XP actuel. Vous pouvez utiliser ces nouveaux attributs pour indiquer au système que vous disposez d’une application administrative légitime ; le système demande automatiquement l’approbation de l’utilisateur pour lancer l’application avec un jeton d’accès administratif complet. Pour plus d’informations sur l’extension du manifeste d’application, consultez la section Créer et incorporer un manifeste d’application avec votre application dans ce document.

Conception d’applications pour Windows Vista

La liste suivante représente un flux de travail pour la conception de votre application pour Windows Vista :

1. Tester votre application pour la compatibilité des applications Windows Vista
2. Classifier votre application en tant qu’application utilisateur standard, administrateur ou utilisateur mixte
3. Reconcevoir les fonctionnalités de votre application pour la compatibilité UAC
4. Reconcevoir l’interface utilisateur de votre application
5. Reconcevoir le programme d’installation de votre application
6. Créer et incorporer un manifeste d’application avec vos applications administratives
7. Tester votre application
8. Signer votre application
9. Déterminer s’il faut poursuivre le programme de logo Windows Vista

1. Tester la compatibilité de votre application

Le test de compatibilité des applications avec UAC peut être facilement effectué en installant Standard User Analyzer.

Pour utiliser l’affichage du journal graphique de Standard User Analyzer, vous devez installer Microsoft Application Verifier. Le vérificateur d’application est un téléchargement gratuit sur le site Web de Microsoft.

La procédure suivante montre comment identifier les applications d’administration antérieures à Windows Vista qui ne s’exécutent pas correctement sur Windows Vista à l’aide de Standard User Analyzer.

Il existe deux approches que vous pouvez adopter pour utiliser Standard User Analyzer : lancer votre application en tant qu’utilisateur standard ou lancer votre application avec élévation de privilèges en tant qu’administrateur :

Lancez votre application en tant qu’utilisateur standard.

Dans cette instance, l’analyseur d’utilisateur standard s’exécute en mode diagnostic. L’application échoue à la première erreur qu’elle rencontre et l’analyseur d’utilisateur standard indique pourquoi elle a échoué.

Lancez votre application avec élévation de privilèges en tant qu’administrateur.

Dans ce instance, l’analyseur utilisateur standard s’exécute en mode de prédiction. L’application pourra s’exécuter tout au long de son cours et l’analyseur d’utilisateur standard prédira et donnera une vue d’ensemble des erreurs que l’application peut rencontrer si elle est exécutée en tant qu’utilisateur standard.

Une fois les bogues corrigés et résolus, effectuez à nouveau cette procédure en tant qu’utilisateur standard sans l’analyseur d’utilisateur standard pour vous assurer que votre application fonctionne comme prévu sur Windows Vista.

Pour identifier les problèmes de compatibilité des applications pour les applications antérieures à Windows Vista

1. Connectez-vous à un ordinateur Windows Vista en tant qu’administrateur en mode approbation Administration.
2. Cliquez sur Démarrer, sur Tous les programmes, puis sur Analyseur d’utilisateurs standard.
3. Dans Standard User Analyzer, pour Application cible, spécifiez le chemin d’accès au répertoire complet d’une application à tester ou cliquez sur le bouton Parcourir pour localiser le fichier exécutable des programmes avec Windows Explorer.
4. Cliquez sur Lancer , puis sur Continuer dans la boîte de dialogue Contrôle de compte d’utilisateur.
5. Après le lancement de l’application de test, effectuez des tâches d’administration standard dans l’application et fermez l’application lorsque vous avez terminé.
6. Dans Standard User Analyzer, examinez la sortie de chaque onglet. Utilisez ces données pour identifier les problèmes de compatibilité que le programme peut avoir.

2. Classifier votre application en tant qu’application utilisateur standard, administrateur ou utilisateur mixte

Les applications administratives dans Windows Vista ont souvent un mélange de fonctionnalités d’administration et de fonctionnalités utilisateur standard. Par conséquent, un certain nombre d’options doivent être prises en compte pour décider du fonctionnement de votre application dans Windows Vista. La fonctionnalité d’administration peut être supprimée ou séparée de la fonctionnalité de compte d’utilisateur standard en invitant l’utilisateur à approuver.

Questions pour vous aider à classifier votre application

Répondez aux questions suivantes pour déterminer si votre application nécessitera une refonte pour la compatibilité de Windows Vista :

• Votre application s’exécute-t-elle en tant qu’utilisateur standard ?
• La fonctionnalité d’administration peut-elle être corrigée pour ne plus nécessiter de jeton d’accès administrateur ?
• Les sections administratives peuvent-elles être supprimées des fonctionnalités du programme ?

Votre application s’exécute-t-elle en tant qu’utilisateur standard ?

Pour répondre à cette question, assurez-vous que l’application ou la fonctionnalité est entièrement utilisée par les utilisateurs standard. Si une partie de votre fonctionnalité nécessite que l’utilisateur soit administrateur, la réponse à cette question est « Non ».

Comment vérifier que l’application ou le panneau de configuration peut être utilisé par les utilisateurs standard :

• Testez minutieusement l’application ou le panneau de configuration en tant qu’utilisateur standard et en tant qu’administrateur. Vérifiez que les interactions utilisateur sont toutes exactement les mêmes pour les utilisateurs standard et les administrateurs.
• Vérifiez où les paramètres sont stockés dans le Registre. Si des paramètres sont stockés dans HKLM, l’application ou le panneau de configuration nécessite probablement un jeton d’accès administrateur.
• Si l’un des paramètres est par ordinateur, l’application ou le panneau de configuration nécessite un jeton d’accès administrateur.
• Si l’un des paramètres effectue quelque chose dans les profils d’autres utilisateurs, l’application ou le panneau de configuration nécessite un jeton d’accès administrateur.

La fonctionnalité d’administration peut-elle être corrigée de ne plus exiger de jeton d’accès administrateur ?

Si votre application ou panneau de configuration a des paramètres ou des interactions qui nécessitent un jeton d’accès administrateur complet, peut-il être modifié pour fonctionner correctement en tant qu’utilisateur standard ? Plus précisément, le programme peut-il stocker des informations dans les paramètres par utilisateur à la place ? Si ce n’est pas le cas, la réponse à cette question est « Non ».

Un bon exemple du type de fonctionnalité/paramètre qui peut être corrigé est Calc.exe (calculatrice Windows). Dans Windows XP, le paramètre « Scientifique » et « Standard » était un paramètre par ordinateur, ce qui signifiait qu’un jeton d’accès administratif complet était nécessaire pour modifier le paramètre. Dans Windows Vista, ce paramètre est stocké dans le profil de l’utilisateur.

Comment vérifier que les sections administratives peuvent être supprimées de la fonctionnalité du programme :

• Testez minutieusement l’application ou le panneau de configuration en tant qu’utilisateur standard et en tant qu’administrateur. L’expérience peut-elle être la même pour les deux types d’utilisateurs ?

• Est-il possible de réduire les listes de contrôle d’accès (ACL) requises pour écrire dans la clé HKLM ?

  Note Ce cours ne doit pas être pris à la légère. Soyez prudent pour ne pas compromettre la sécurité globale du système en réduisant le contrôle accordé par l’ACL.

• Est-il possible de modifier l’interface utilisateur pour définir l’état par utilisateur plutôt que l’état global (et ne pas exposer la modification de l’état global via l’interface utilisateur) ?

Les sections administratives peuvent-elles être supprimées de la fonctionnalité du programme ?

Votre fonctionnalité doit-elle absolument avoir cette fonctionnalité ? Si vous ne pouvez pas couper les fonctionnalités d’administration, la réponse à cette question est « Non ».

Pour déterminer si les sections administratives peuvent être supprimées des fonctionnalités du programme, procédez comme suit :

• Testez le panneau de configuration en tant qu’utilisateur standard et administrateur. Quel est le scénario utilisateur pour conserver cette fonctionnalité ?
• Ce paramètre/fonctionnalité est-il exposé ailleurs ? La fonctionnalité du panneau de configuration est peut-être redondante.

Analyse des réponses pour classifier votre application

Si vous avez répondu « Oui » à l’une des questions précédentes

Apportez les modifications nécessaires dans l’application ou le panneau de configuration (le cas échéant) pour éliminer les éléments qui nécessitent que l’utilisateur dispose d’un jeton d’accès administratif complet.

La liste suivante détaille les avantages d’une véritable application utilisateur standard :

• Votre fonctionnalité est également utilisable pour tous les utilisateurs. Il s’agit de l’état idéal, car la plupart des fonctionnalités ne doivent pas nécessiter un jeton d’accès administrateur complet.
• Vos utilisateurs ne verront jamais d’invite d’élévation avec vos fonctionnalités.
• Vos fonctionnalités sont beaucoup plus sécurisées en ne nécessitant jamais le jeton d’accès administrateur.

Si vous avez répondu « Non » à toutes les questions précédentes

L’application ou le panneau de configuration doivent être modifiés pour que la fonctionnalité fonctionne avec le contrôle D’utilisateur.

Vérifiez que l’application ou le Panneau de configuration fonctionne avec le contrôle d’utilisateur :

Enfin, testez l’application ou le panneau de configuration en tant qu’utilisateur standard et administrateur. Vérifiez que les autres options (questions précédentes) ne peuvent pas être utilisées pour cette application ou panneau de configuration particulier.

3. Reconcevoir les fonctionnalités de votre application pour la compatibilité du contrôle d’utilisateur

Utilisez les informations de cette section une fois que vous avez classé votre application et déterminé si elle doit être repensée pour la UAC.

Un composant important de la refonte de votre application pour Windows Vista consiste à examiner le modèle d’accès utilisateur de votre application au cœur de celui-ci.

Configuration requise pour toutes les applications Windows Vista

Spécifier un objet requestedExecutionLevel

Pour que la UAC fonctionne correctement, le système d’exploitation doit être en mesure d’identifier le code qui a besoin de privilèges élevés et le code qui ne le fait pas.

Dans Windows Vista, ces modifications nécessitent que les applications soient marquées avec des informations qui permettent au système d’exploitation de déterminer dans quel contexte l’application doit être lancée. Par exemple, les applications utilisateur standard doivent être marquées pour s’exécuter en tant qu’appelants, et les applications compatibles avec l’accessibilité doivent être identifiées par le système.

Ne pas inscrire de composants avec Rundll32

Certaines applications utilisent les exécutables Windows Rundll32 pour exécuter des composants. Toutefois, cette méthode n’est pas conforme aux exigences de développement Windows Vista. L’appel direct dans Rundll32 entraîne des problèmes de compatibilité UAC. Lorsqu’une application s’appuie sur les exécutables Rundll32 pour effectuer son exécution, Rundll32 appelle le service d’informations sur l’application (AIS) au nom de l’application pour lancer l’invite d’élévation du contrôle d’utilisateur. Par conséquent, l’invite d’élévation du contrôle d’utilisateur n’a aucune connaissance de l’application d’origine et affiche l’application demandant l’élévation en tant que « processus hôte Windows (Rundll32) ». Sans une description claire et une icône pour l’application demandant une élévation, les utilisateurs n’ont aucun moyen d’identifier l’application et de déterminer s’il est sûr de l’élever.

Si votre application appelle Rundll32 pour exécuter des composants, utilisez le workflow suivant pour reconcevoir l’appel d’exécution.

1. Créez un fichier exécutable distinct pour votre application.
2. Dans le nouveau fichier exécutable, appelez la fonction exportée dans votre DLL que vous auriez spécifiée avec Rundll32. Vous devrez peut-être charger la DLL si elle n’a pas de fichier .lib.
3. Dans un fichier de ressources, créez et ajoutez une icône pour l’exécutable. Cette icône s’affiche dans l’invite d’élévation contrôle de compte d’utilisateur lorsque l’application demande une élévation.
4. Fournissez un nom court et explicite pour l’exécutable. Ce nom s’affiche dans l’invite d’élévation du contrôle de compte d’utilisateur lorsque l’application demande une élévation.
5. Créez et incorporez un fichier manifeste d’application pour l’exécutable et marquez-le avec le niveau d’exécution demandé de requireAdministrator. Ce processus est détaillé dans la section Créer et incorporer un manifeste d’application avec votre application.
6. Authenticode signe le nouveau fichier exécutable. Ce processus est détaillé dans la section Authenticode Sign Your Application.

Après la désinstallation d’une application, l’utilisateur doit pouvoir la réinstaller sans erreur.

Configuration requise pour les applications utilisateur standard

Voici un résumé des éléments à retenir lors de la conception d’applications qui fonctionnent correctement sous un compte d’utilisateur standard. Les développeurs doivent garder ces exigences à l’esprit pendant la phase de conception de leurs applications.

Paramétrage

• N’effectuez jamais d’actions administratives (par exemple, terminer le processus d’installation) lors de la première exécution ; elle doit être effectuée dans le cadre du processus d’installation initial.
• N’écrivez jamais directement dans le répertoire ou les sous-répertoires Windows. Utilisez les méthodes appropriées pour installer des fichiers tels que des polices.
• Si vous devez mettre à jour automatiquement votre application, utilisez un mécanisme adapté à une utilisation par les utilisateurs standard, tel que la mise à jour corrective du contrôle de compte d’utilisateur Windows Installer 4.0 pour effectuer la mise à jour.

Enregistrement de l’état

• N’écrivez pas d’informations par utilisateur ou d’informations accessibles en écriture par l’utilisateur dans des fichiers programme ou des répertoires de programmes.
• N’utilisez pas de chemins codés en dur dans le système de fichiers. Tirez parti de l’API KnownFolders et de ShGetFolder pour trouver où écrire des données.

Exécuter et tester sous un compte d’utilisateur standard

Si vous écrivez une application non administrative, telle qu’une application métier ou une application utilisateur telle qu’un jeu, vous devez toujours écrire des données d’application dans un emplacement auquel l’utilisateur standard a accès. Voici quelques-unes des exigences recommandées.

• Écrire des données par utilisateur dans le profil utilisateur : CSIDL_APPDATA.
• Écrire des données par ordinateur dans Users\All Users\All Users\Application Data: CSIDL_COMMON_APPDATA.
• L’application ne peut dépendre d’aucune API d’administration. Par exemple, un programme qui s’attend à appeler correctement la fonction Windows SetTokenInformation() échoue sous un compte d’utilisateur standard.

Prendre en charge le basculement rapide d’utilisateur (FUS)

Les applications sont généralement installées par un utilisateur autre que l’utilisateur qui exécutera l’application. Par exemple, dans la maison, cela signifie qu’un parent installe l’application pour l’enfant. Dans l’entreprise, un système de déploiement, tel que SMS ou stratégie de groupe publication, installe l’application à l’aide d’un compte d’administrateur.

Si les paramètres par utilisateur n’existent pas lors de la première exécution, régénérez-les. Ne partez pas du principe que le processus d’installation s’est occupé des paramètres.

Configuration requise pour les applications administrateur

Utiliser la propriété HWND pour être reconnu comme une application de premier plan

Les applications en arrière-plan invitent automatiquement l’utilisateur pour une élévation dans la barre des tâches, plutôt que d’accéder automatiquement au bureau sécurisé pour l’élévation. L’invite d’élévation apparaît réduite dans la barre des tâches et clignote pour informer l’utilisateur qu’une application a demandé une élévation. Un exemple d’élévation d’arrière-plan se produit lorsqu’un utilisateur accède à un site Web et commence à télécharger un fichier d’installation. L’utilisateur accède ensuite à case activée courrier électronique pendant que l’installation est téléchargée en arrière-plan. Une fois le téléchargement terminé en arrière-plan et que l’installation a commencé, l’élévation est détectée comme une tâche en arrière-plan plutôt qu’une tâche de premier plan. Cette détection empêche l’installation de voler brusquement le focus de l’écran de l’utilisateur pendant que l’utilisateur effectue une autre tâche : lecture du courrier électronique. Ce comportement crée une meilleure expérience utilisateur pour l’invite d’élévation.

Toutefois, certaines applications de premier plan s’affichent actuellement en tant qu’applications en arrière-plan sur Windows Vista. Ce comportement est le résultat d’un HWND parent absent. Pour vous assurer que Windows Vista reconnaît votre application en tant qu’application de premier plan, vous devez passer un HWND parent avec un appel ShellExecute, CreateElevatedComObject (COM) ou du code managé.

Le mécanisme d’élévation UAC utilise le HWND pour déterminer si l’élévation est une élévation d’arrière-plan ou de premier plan. Si l’application est considérée comme une application en arrière-plan, l’élévation est placée sur la barre des tâches en tant que bouton clignotant. L’utilisateur doit cliquer sur le bouton, comme pour toute application demandant l’accès au premier plan, avant que l’élévation continue. Si vous ne passez pas le HWND, cela se produit même si l’application peut avoir un premier plan.

L’exemple de code suivant montre comment passer HWND avec ShellExecute :

BOOL RunAsAdmin( HWND hWnd, LPTSTR lpFile, LPTSTR lpParameters )
{
    SHELLEXECUTEINFO   sei;
    ZeroMemory ( &sei, sizeof(sei) );

    sei.cbSize          = sizeof(SHELLEXECUTEINFOW);
    sei.hwnd            = hWnd;
    sei.fMask           = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
    sei.lpVerb          = _TEXT("runas");
    sei.lpFile          = lpFile;
    sei.lpParameters    = lpParameters;
    sei.nShow           = SW_SHOWNORMAL;

    if ( ! ShellExecuteEx ( &sei ) )
    {
        printf( "Error: ShellExecuteEx failed 0x%x\n", GetLastError() );
        return FALSE;
    }
    return TRUE;
}

L’exemple de code suivant montre comment passer HWND avec CreateElevatedComObject à l’aide du moniker d’élévation. Il suppose que vous avez déjà initialisé COM sur le thread actuel. Pour plus d’informations sur le moniker d’élévation, consultez l’étape 4 de ce document.

HRESULT CreateElevatedComObject(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv)
{
    BIND_OPTS3 bo;
    WCHAR  wszCLSID[50];
    WCHAR  wszMonikerName[300];

    StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0])); 
    HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);
    if (FAILED(hr))
        return hr;
    memset(&bo, 0, sizeof(bo));
    bo.cbStruct = sizeof(bo);
    bo.hwnd = hwnd;
    bo.dwClassContext  = CLSCTX_LOCAL_SERVER;
    return CoGetObject(wszMonikerName, &bo, riid, ppv);

BIND_OPTS3 est nouveau dans Windows Vista. Il est dérivé de BIND_OPTS2. La définition est la suivante :

typedef struct tagBIND_OPTS3 : tagBIND_OPTS2
{
    HWND hwnd;
} BIND_OPTS3, * LPBIND_OPTS3;

Le seul ajout est un champ HWND, hwnd. Ce handle représente une fenêtre qui devient le propriétaire de l’interface utilisateur d’élévation lorsque l’invite de bureau sécurisée est activée.

L’exemple de code suivant montre comment passer HWND dans du code managé pour s’assurer que les boîtes de dialogue parentes connaissent le HWND et son utilisation.

System.Diagnostics.Process newProcess = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("D:\SomeProgram.exe");
info.UseShellExecute = true;
info.ErrorDialog = true;
info.ErrorDialogParentHandle = this.Handle;
newProcess.StartInfo = info;
newProcess.Start();

Ne pas demander d’élévation dans le chemin d’ouverture de session de l’utilisateur

Les applications qui démarrent lorsque l’utilisateur se connecte et nécessitent une élévation sont désormais bloquées dans le chemin d’ouverture de session. Sans empêcher les applications de demander une élévation dans le chemin d’accès de l’utilisateur, les utilisateurs standard et les administrateurs doivent répondre à une boîte de dialogue Contrôle de compte d’utilisateur à chaque ouverture de session. Windows Vista avertit l’utilisateur si une application a été bloquée en plaçant une icône dans la barre d’état système. L’utilisateur peut ensuite cliquer avec le bouton droit sur cette icône pour exécuter des applications qui n’ont pas pu demander une élévation lorsque l’utilisateur s’est connecté. L’utilisateur peut gérer les applications de démarrage désactivées ou supprimées de cette liste en double-cliquant sur l’icône de la barre d’état.

Un exemple de code C++ illustrant comment utiliser le Planificateur de tâches pour effectuer l’élévation pour l’utilisateur est disponible dans la section Références de ce document.

Ne pas utiliser les runas pour lancer un processus avec élévation de privilèges

L’option Exécuter en tant que... de Windows XP et Windows Server 2003 a été remplacée par Exécuter en tant qu’administrateur dans le menu contextuel (disponible lorsque vous cliquez avec le bouton droit sur un exécutable) dans Windows Vista. Lorsqu’un utilisateur standard sélectionne l’option Exécuter en tant qu’administrateur , une liste d’administrateurs actifs s’affiche sur l’ordinateur local. Les utilisateurs standard disposant de privilèges plus élevés, tels que les membres du groupe Opérateurs de sauvegarde, s’affichent également. Lorsqu’un administrateur sélectionne l’option Exécuter en tant qu’administrateur , une boîte de dialogue Contrôle de compte d’utilisateur invite immédiatement l’utilisateur à continuer avant d’exécuter l’application.

Les utilisateurs doivent utiliser la commande runas à l’invite de commandes afin d’exécuter une application en tant qu’autre utilisateur.

Important N’oubliez pas que les runas ne permettent pas de lancer une application avec un jeton d’accès élevé, qu’il s’agisse d’un utilisateur standard disposant de privilèges tels qu’un opérateur de sauvegarde ou un administrateur. La commande runas accorde à l’utilisateur la possibilité de lancer une application avec des informations d’identification différentes. La meilleure méthode à utiliser pour lancer une application avec un autre compte consiste à effectuer l’action par programmation à l’aide d’un service et à ne pas compter sur l’utilisateur pour exécuter le composant en tant qu’utilisateur différent. Si votre programme utilise par programmation la commande runas, vérifiez qu’il n’est pas destiné à lancer un processus avec élévation de privilèges.

Si votre application demande à l’utilisateur d’exécuter des parties de l’application avec un autre compte d’utilisateur, vérifiez que la commande runas avec l’option d’invite de commandes est exposée. Le tableau suivant détaille les paramètres disponibles pour la commande runas .

Paramètres runas

Paramètre	Description
/noprofile	Spécifie que le profil de l’utilisateur ne doit pas être chargé. Cela permet à l’application de se charger plus rapidement, mais peut entraîner un dysfonctionnement de certaines applications.
/Profil	Spécifie que le profil de l’utilisateur doit être chargé. Il s'agit du paramètre par défaut.
/Env	Utilisez l’environnement actuel au lieu de celui de l’utilisateur.
/netonly	Utilisez ce paramètre si les informations d’identification spécifiées concernent uniquement l’accès à distance.
/savecred	Utilisez les informations d’identification précédemment enregistrées par l’utilisateur. Cette option n’est pas disponible sur Windows XP édition familiale et sera ignorée.
/smartcard	Utilisez ce paramètre si les informations d’identification à fournir proviennent d’un carte intelligent.
/user	Nom de l'utilisateur. Le nom d’utilisateur doit être fourni sous la forme USER\DOMAIN ou USER@DOMAIN.
/showtrustlevels	Affiche les niveaux de confiance qui peuvent être utilisés comme arguments pour le paramètre /trustlevel.
/trustlevel	Un des niveaux énumérés dans /showtrustlevels.
Programme	Ligne de commande d’un exécutable.

Exemple :

runas /noprofile /user:mymachine\Denise cmd

Remarques :

• Entrez le mot de passe de l’utilisateur uniquement lorsque vous y êtes invité.
• Le paramètre /profile n’est pas compatible avec le paramètre /netonly.
• Le paramètre /savecred n’est pas compatible avec le paramètre /smartcard.

Configuration requise pour les applications console

Une application console présente sa sortie dans la fenêtre de console et non avec une interface utilisateur distincte. Si une application a besoin d’un jeton d’accès administrateur complet pour s’exécuter, cette application doit être lancée à partir d’une fenêtre de console avec élévation de privilèges.

Vous devez effectuer les opérations suivantes pour les applications console :

Marquez que votre application « asInvoker »

Pour ce faire, créez le manifeste de votre application dans lequel vous définissez RequestedExecutionLevel == asInvoker. Cette configuration permet aux appelants de contextes non élevés de créer votre processus, ce qui leur permet de passer à l’étape 2.

Indiquez un message d’erreur si l’application est exécutée sans jeton d’accès administrateur complet

Si l’application est lancée dans une console sans élévation de privilèges, votre application doit envoyer un message bref et quitter. Le message recommandé est le suivant :

« Accès refusé. Les autorisations d’administrateur sont nécessaires pour utiliser les options sélectionnées. Utilisez une invite de commandes administrateur pour effectuer ces tâches. »

L’application doit également retourner le code d’erreur ERROR_ELEVATION_REQUIRED en cas d’échec du lancement pour faciliter la création de scripts.

Configuration requise pour les scripts

Les scripts peuvent être considérés comme un groupe d’applications exécutés dans un ordre prédéfini et les résultats de l’une d’elles étant canalisées dans l’autre.

Pour que vos scripts soient conformes à la UAC, examinez la logique de vos scripts et ajoutez des « tests » pour vous assurer qu’avant d’effectuer une action dans le script, vous (ou la personne exécutant le script) disposez des privilèges suffisants pour effectuer cette tâche.

Configuration requise pour les opérations en bloc

Si une tâche effectuée par votre application se compose d’actions sur plusieurs objets et que certains d’entre eux peuvent nécessiter le jeton d’accès administratif de l’utilisateur, affichez l’invite d’élévation la première fois qu’elle est nécessaire. Si l’utilisateur approuve l’élévation, effectuez le reste des tâches. Sinon, arrêtez l’opération de traitement par lots. Ce comportement est cohérent avec l’opération de sélection/copie/suppression multiple en cours.

API qui aident à identifier un administrateur

• IsUserAnAdmin()
• GetTokenInformation()

Autorisations d’accès de registre/de gestion qui sont intrinsèquement différentes entre les administrateurs et les utilisateurs standard

• MAXIMUM_ALLOWED
• KEY_WRITE
• DELETE (lorsqu’il est appliqué aux clés de Registre)
• Autres mots clés de type HKLM (ouverts avec MAXIMUM_ALLOWED sur XP) :
• SHELLKEY_HKLM_EXPLORER
• SHELLKEY_HKLM_SHELL

Les autres API qui sont redirigées vers les valeurs du Registre HKLM et la virtualisation s’appliquent

• WritePrivateProfileString(,,,"system.ini »);
• CheckSectionAccess(« system.ini »,...);

4. Reconcevoir l’interface utilisateur de votre application pour la compatibilité UAC

Suivez les instructions de cette section pour développer l’interface utilisateur de votre application pour la compatibilité UAC. Le respect étroit de ces instructions dans le développement de votre application garantit que votre application aura une expérience utilisateur cohérente et prévisible dans Windows Vista.

• Impact du contrôle de compte d’utilisateur sur l’expérience utilisateur Windows
• Objectifs de l’expérience utilisateur UAC
• Invite d’élévation
• Flux de processus d’expérience utilisateur
• Points d’entrée d’élévation
• Implémentation de l’interface utilisateur
• Quand ajouter une icône de bouclier à l’interface utilisateur de votre application
• Décisions clés pour les applications administrateur uniquement

Important Le simple fait de réfracter l’interface utilisateur de votre application ne répond pas aux exigences de compatibilité UAC. Les fonctionnalités de base de votre application doivent être conformes aux exigences du modèle utilisateur standard Windows Vista. Ces exigences ont été détaillées à l’étape précédente, Étape 3 : Concevoir les fonctionnalités de votre application pour la compatibilité UAC.

Impact du contrôle de compte d’utilisateur sur l’expérience utilisateur Windows

L’impact le plus important et le plus immédiat sur l’expérience utilisateur sera ressenti par les administrateurs. Les utilisateurs administrateurs doivent maintenant fournir l’autorisation d’accomplir des tâches administratives. En plus de cela, les utilisateurs standard pourront désormais demander aux administrateurs d’autoriser certaines tâches d’administration dans la session actuellement connectée.

Objectifs de l’expérience utilisateur UAC

L’objectif général de l’expérience utilisateur UAC est de fournir une prévisibilité dans l’expérience utilisateur :

• Pour un administrateur, cela signifie que l’utilisateur sait toujours quand il doit accorder l’autorisation d’exécuter une tâche avec élévation de privilèges.

Il s’agit du fait de demander le propre jeton d’accès administrateur de l’utilisateur afin qu’il puisse apporter les modifications requises par l’administrateur.

• Pour les utilisateurs standard, cela signifie qu’ils sauront quand ils :
  • Doit fournir l’approbation de l’administrateur (environnements d’accueil et non managés) pour les tâches d’administration
  • OU Lorsque le ne peut pas terminer une tâche (environnements managés où l’élévation est explicitement interdite) et doit contacter le support technique

Objectifs de conception

La liste suivante comprend les objectifs de conception du contrôle d’utilisateur.

Éliminer l’élévation inutile

Les utilisateurs doivent être élevés uniquement pour effectuer des tâches qui nécessitent un jeton d’accès administrateur. Toutes les autres tâches doivent être conçues pour éliminer le besoin d’élévation. Les logiciels pré-Windows Vista nécessitent souvent inutilement un jeton d’accès administrateur en écrivant dans les sections du Registre HKLM ou HKCR ou dans les dossiers program files ou système Windows.

Soyez prévisible

Les administrateurs doivent savoir quelles tâches nécessitent une élévation. S’ils ne peuvent pas prédire avec précision le besoin d’élévation, ils sont plus susceptibles de donner leur consentement pour les tâches administratives alors qu’ils ne le devraient pas. Les utilisateurs standard doivent savoir quelles tâches nécessitent qu’un administrateur effectue ou ne peuvent pas être effectuées du tout dans des environnements managés.

Exiger un effort minimal

Les tâches qui nécessitent un jeton d’accès privilégié plus élevé doivent être conçues pour exiger une seule élévation. Les tâches qui nécessitent plusieurs élévations deviennent rapidement fastidieuses.

Revenir à l’utilisateur standard

Une fois qu’une tâche nécessitant un niveau plus élevé de jeton d’accès est terminée, le programme doit revenir à l’état utilisateur standard.

Invite d’élévation

L’invite d’élévation est basée sur une interface utilisateur Windows existante. L’invite d’élévation affiche des informations contextuelles sur l’exécutable qui demande une élévation, et le contexte est différent selon que l’application est signée ou non Authenticode. L’invite d’élévation se présente sous deux variantes : l’invite de consentement et l’invite d’informations d’identification.

Invite de consentement

L’invite de consentement s’affiche aux administrateurs en mode d’approbation Administration lorsqu’ils tentent d’effectuer une tâche d’administration. Il s’agit de l’expérience utilisateur par défaut pour les administrateurs en mode d’approbation Administration et peut être configurée dans le composant logiciel enfichable Gestionnaire de stratégies de sécurité (secpol.msc) local et avec stratégie de groupe.

La figure suivante est un exemple d’invite de consentement de contrôle de compte d’utilisateur.

Figure 4. Invite de consentement du Contrôle de compte d'utilisateur

Invite d’informations d’identification

L’invite d’informations d’identification s’affiche pour les utilisateurs standard lorsqu’ils tentent d’effectuer une tâche d’administration. Il s’agit de l’expérience utilisateur par défaut pour les utilisateurs standard et peut être configurée dans le composant logiciel enfichable Security Policy Manager local (secpol.msc) et avec stratégie de groupe.

La figure suivante est un exemple d’invite d’informations d’identification de contrôle de compte d’utilisateur.

Figure 5. Invite de demande d'informations d'identification du Contrôle de compte d'utilisateur

Stratégie de consentement d’invite d’élévation par défaut pour Windows Vista

Le tableau suivant décrit le style d’invite par défaut pour chaque type de compte d’utilisateur dans Windows Vista.

Comportement d’invite d’élévation par défaut

Type de compte d’utilisateur	Paramètre d’invite d’élévation
Utilisateur standard	Demander les informations d’identification
Compte administrateur en mode d’approbation Administration	Demande de consentement

Flux de processus d’expérience utilisateur

Le flux de processus de l’expérience utilisateur UAC se compose de trois composants distincts :

1. Point d’entrée d’élévation (par exemple, un contrôle ou un lien qui affiche l’icône de bouclier UAC).
2. Invite d’élévation (demande de consentement ou d’informations d’identification d’administrateur).
3. Processus avec élévation de privilèges.

L’exemple de workflow suivant résume la façon dont les composants précédents sont liés :

1. Un administrateur en mode d’approbation Administration se connecte à un ordinateur Windows Vista.
2. L’utilisateur décide ensuite d’ajouter un autre utilisateur administrateur pour l’ordinateur.
3. L’utilisateur clique sur Démarrer, sur Panneau de configuration, puis sur le lien dans la section Sécurité intitulé Autoriser un programme via le Pare-feu Windows, qui s’affiche en ligne avec une icône de bouclier.
4. Une invite de consentement s’affiche pour demander l’approbation de l’utilisateur.
5. L’utilisateur clique sur Continuer et le processus avec élévation de privilèges est créé.
6. Dans Paramètres du Pare-feu Windows, l’utilisateur modifie les paramètres du Pare-feu Windows, puis clique sur OK, ce qui met fin au processus avec élévation de privilèges.
7. L’utilisateur continue à travailler sur l’ordinateur en tant qu’utilisateur standard.

Note Les points d’entrée d’élévation ne se souviennent pas de l’état (par exemple, lorsque vous revenez à partir d’un emplacement ou d’une tâche protégé), ainsi que le point d’entrée ne se souviendra pas que l’élévation s’est produite. Par conséquent, l’utilisateur doit réélever pour entrer à nouveau la tâche/le lien/le bouton.

Points d’entrée d’élévation

Pour les points d’entrée, l’icône de bouclier est attachée à certains contrôles (par exemple, boutons, liens de commande, liens hypertexte) pour indiquer que l’étape immédiate suivante nécessite une élévation.

Icône Bouclier

L’icône de bouclier est la décoration de l’interface utilisateur principale pour un point d’élévation UAC. Cette icône indique les activités liées à la sécurité dans Windows Vista et les versions précédentes de Windows, et cette relation se poursuit dans Windows Vista.

La figure suivante est un exemple d’icône de bouclier.

Figure 6. Icône de bouclier

L’icône de bouclier jouera un rôle essentiel dans les trois composants de l’expérience utilisateur UAC.

Lors de l’affichage du système avec Windows Explorer, toute application marquée pour demander un jeton d’accès administrateur lors de son lancement sera automatiquement décorée d’un glyphe de protection sur son icône. Cela permet aux utilisateurs de savoir quelles applications, une fois lancées, demandent une élévation.

Propriétés de l’icône de bouclier :

• Apparence cohérente dans l’ensemble de l’expérience utilisateur UAC.
• Ne reflète aucun état visuel (par exemple, actif, pointeur, désactivé, etc.).
• Ne se souvient pas de l’état.

Il existe trois styles de contrôle cohérents qu’un point d’entrée marqué avec une icône de bouclier peut prendre dans l’expérience utilisateur :

• Bouton UAC
• Lien hypertexte UAC
• Lien de commande UAC

Ces styles s’appliquent à tous les scénarios où ces éléments d’interface utilisateur peuvent apparaître, tels que les Assistants, les Pages de propriétés, Panneau de configuration Framework, les Explorateurs, etc. Chacun des styles implique qu’une invite d’élévation s’affiche immédiatement une fois que l’utilisateur clique sur un contrôle d’interface utilisateur UAC.

Un quatrième point d’entrée de l’interface utilisateur UAC, la superposition d’icône UAC, est également abordé dans cette section. Si un exécutable reçoit ou non une superposition d’icônes n’est pas contrôlé par le développeur d’application. Windows Vista superpose une icône de bouclier sur les icônes des applications pour les exécutables qui ont demandéExecutionLevel défini sur requireAdministrator.

Bouton UAC Shield

Le bouton de protection UAC doit être utilisé dans n’importe quel bouton d’interface utilisateur qui, lorsqu’il est appuyé, nécessite l’invite d’élévation pour inviter l’utilisateur à approuver ou à fournir des informations d’identification.

Les boutons de protection UAC peuvent être utilisés en tant que boutons de validation (par exemple , Suivant dans un Assistant) ou en tant que bouton pour afficher une interface utilisateur de paramètres supplémentaires (par exemple, Modifier les paramètres dans une boîte de dialogue de propriété).

Le bouton de protection UAC se compose de deux composants d’interface utilisateur :

• Icône de bouclier
• Étiquette de texte

Le bouton de protection UAC est empaqueté de manière à ce que les développeurs puissent l’utiliser à la place d’un bouton normal. Le bouton UAC prend également en charge le rendu de l’icône de bouclier sur le côté gauche ou droit de l’étiquette de texte. En outre, les développeurs auront la possibilité de masquer/afficher l’icône de bouclier lorsque le bouton UAC est affiché.

La capture d’écran suivante est un exemple de bouton de protection UAC.

Figure 7. Bouton de protection UAC

Lien hypertexte UAC

Le lien hypertexte UAC doit être utilisé dans tout lien hypertexte d’interface utilisateur qui, lorsqu’il est cliqué, nécessite l’invite d’élévation pour inviter l’utilisateur à approuver ou à fournir des informations d’identification.

Un lien hypertexte UAC se compose des composants suivants :

• Icône de bouclier
• Contrôle Lien hypertexte

Le lien hypertexte UAC n’est pas empaqueté avec l’icône de bouclier que le développeur peut utiliser. Les développeurs devront obtenir la ressource d’icône de bouclier et la restituer à côté du lien hypertexte.

La capture d’écran suivante est un exemple de lien hypertexte UAC.

Figure 8. Lien hypertexte UAC

Lien de commande UAC

Le lien de commande UAC doit être utilisé dans n’importe quel bouton d’interface utilisateur qui, lorsqu’il est cliqué, nécessite l’invite d’élévation pour inviter l’utilisateur à approuver ou à fournir des informations d’identification.

Les liens de commande UAC ne doivent être utilisés que comme boutons de validation (par exemple, « Effectuer cette option » dans une boîte de dialogue).

Le lien de commande UAC se compose des composants suivants :

• Icône de bouclier
• Composants de lien de commande standard
• Texte du lien
• Texte de note

Le lien de commande UAC est empaqueté de manière à ce qu’un développeur puisse utiliser un lien de commande UAC à la place d’un lien de commande normal. Le lien de commande UAC prend en charge le rendu de l’icône de bouclier sur le côté gauche ou droit du lien de commande.

Voici un exemple de lien de commande UAC.

Figure 9. Lien de commande UAC

Superpositions d’icônes

Dans Windows Vista, si un fichier exécutable nécessite une élévation pour être lancé, l’icône de l’exécutable doit être « marquée » avec une icône de bouclier pour indiquer ce fait. Le manifeste d’application de l’exécutable doit marquer « requireAdministrator » pour désigner l’exécutable comme nécessitant un jeton d’accès administratif complet. La superposition d’icône de bouclier sera également automatiquement placée sur les exécutables qui sont considérés comme nécessitant une élévation conformément à l’heuristique de détection du programme d’installation. Par exemple, un fichier nommé setup.exe reçoit automatiquement une superposition d’icône de bouclier, même si l’exécutable n’a pas de manifeste d’application incorporé.

La figure suivante est un exemple de superposition d’icône UAC.

Figure 10. Superposition d’icône UAC

Note Des conseils sur la création et l’incorporation d’un manifeste d’application avec un exécutable sont fournis dans la section Créer et incorporer un manifeste d’application avec votre application de ce document.

Implémentation de l’interface utilisateur

Implémentation et API de l’icône Bouclier

Cette section fournit des informations préliminaires sur les icônes et les API disponibles pour les développeurs lors de la migration ou de l’implémentation de nouvelles fonctionnalités d’application administrative.

Implémentation d’icône de bouclier et API

Icônes	API
Shield	Ressource utilisateur : IDI_SHIELD
Bouton	Button_SetElevationRequired(hwndButton)
Syslink/Lien hypertexte	Disposition IDI_SHIELD en regard de syslink
Lien de commande	Charger IDI_SHIELD et définir comme icône de lien de commande
Menu contextuel	Prise en charge des icônes dans DefCM pour les commandes statiques

Ajouter une icône Bouclier à l’interface utilisateur

Ajoutez une petite icône :

#include <shellapi.h>
SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_SMALLICON, &sii);
hiconShield  = sii.hIcon;

Ajouter une grande icône :

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_LARGEICON, &sii);
hiconShield  = sii.hIcon;

Ajoutez une icône de taille personnalisée :

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICONLOCATION, &sii);
hiconShield  = ExtractIconEx(sii. ...);

Note En règle générale, vous ne devez pas ajouter l’icône de bouclier directement à votre interface utilisateur. Il est recommandé d’utiliser l’une des méthodes suivantes pour imbeddding de l’icône de bouclier dans un contrôle. En outre, l’ajout simple d’une icône de bouclier dans votre interface utilisateur ne garantit pas la compatibilité UAC. Vous devez également réfuter l’ensemble de l’expérience utilisateur de votre application (ajouter un élément requestedExecutionLevel, corriger les bogues standard de l’utilisateur et vérifier que l’interface utilisateur est conviviale et compatible avec l’UAC).

Ajouter une icône de bouclier à un bouton

Le contrôle de bouton standard (PUSHBUTTON, DEFPUSHBUTTON) a été amélioré pour vous permettre d’ajouter une icône avec le texte affiché, sans avoir à définir les styles BS_ICON ou BS_BITMAP.

Pour afficher l’icône de bouclier, appelez la macro suivante (définie dans commctrl.h) :

Button_SetElevationRequiredState(hwndButton, fRequired);

Notez que hwndButton est le HWND du bouton ; fRequired détermine s’il faut afficher (TRUE) ou masquer (FALSE) l’icône de protection UAC.

Ajouter une icône de bouclier à un bouton Windows Installer

Les boîtes de dialogue Windows Installer créées à l’aide de la prise en charge des tables internes peuvent ajouter un bouclier au dernier bouton de la séquence de dialogue d’interface utilisateur en définissant l’attribut ElevationShield sur le contrôle.

Ajouter une icône de bouclier à un bouton « Suivant » d’un Assistant

Important L’affichage de l’icône de protection UAC, le bouton « Suivant » est uniquement pris en charge dans AeroWizards (PSH_AEROWIZARD).

Pour afficher l’icône de bouclier sur le bouton « Suivant » d’une page spécifique dans un AeroWizard, utilisez le code suivant :

case WM_NOTIFY:
    if (reinterpret_cast<NMHDR*>(lParam)->code == PSN_SETACTIVE)
    {
        // Show next button
        //
        // Note new wParam flag -- when PSWIZBF_ELEVATIONREQUIRED flag
        // is specified, it indicates that the next page will require
        // elevation, so if the next button is being shown, show it as
        // a shield button.

        SendMessage(GetParent(hwndDlg), 
                    PSM_SETWIZBUTTONS, 
                    PSWIZBF_ELEVATIONREQUIRED, 
                    PSWIZBF_NEXT);

        // return 0 to accept the activation
        SetWindowLong(hwndDlg, DWLP_MSGRESULT, 0); 
    }
    break;

Ajouter une icône de bouclier à un bouton de boîte de dialogue Tâche

Attention Un bouton de boîte de dialogue de tâche ne doit jamais nécessiter une icône de bouclier UAC. L’action « appuyer » sur un bouton de boîte de dialogue de tâche est censée valider/annuler et ignorer la boîte de dialogue de tâche. Il serait étrange qu’un tel bouton affiche ensuite l’invite d’élévation à l’utilisateur.

Élever une boîte de dialogue modale

Utilisez le moniker d’élévation pour élever l’objet COM représentant la boîte de dialogue modale.

Tâches :

• Déplacez la boîte de dialogue dans un objet COM.
• Exposez une méthode ShowDialog().
• Utilisez l’API CreateElevatedComObject() pour créer l’objet COM et appeler ShowDialog().

Cette API exécute une instance de l’objet COM en tant qu’administrateur après avoir suivi le processus d’élévation.

Note Une version de cette API plus complexe à appeler est disponible. Une version simplifiée sera disponible dans une version ultérieure de Windows Vista.

Instructions relatives à l’éducation et à l’assistance des utilisateurs

Lorsqu’une interface utilisateur a été refactorisé et placé derrière un bouton, les éditeurs de logiciels indépendants doivent évaluer si une modification du nom du bouton est justifiée. Microsoft recommande vivement d’utiliser Avancé comme étiquette de bouton pour les tâches d’élévation. Au lieu de cela, utilisez des étiquettes plus descriptives et compréhensibles, comme Modifier les paramètres ou un terme qui suggère ce qui se trouve derrière le bouton.

Instructions pour l’interface utilisateur administrateur uniquement

Si une application est toujours lancée par un administrateur, vous n’avez pas besoin d’ajouter des boucliers supplémentaires dans l’interface utilisateur de l’application. Cela est dû au fait que l’application sera élevée et tout ce qu’elle fait l’est et n’a donc pas besoin d’une élévation supplémentaire.

Note Si vous avez des liens vers une autre interface utilisateur administrateur dans votre expérience utilisateur administrateur uniquement, l’interface utilisateur lance sa cible avec élévation de privilèges. Par conséquent, vous n’avez pas besoin de placer des boucliers dans une application uniquement administrative.

Quand ajouter l’icône Bouclier à l’interface utilisateur de votre application

Une application de choix administratif

Un processus avec élévation de privilèges ou un objet COM

L’application initiale démarre sans nécessiter d’élévation. Les éléments de l’interface utilisateur qui nécessitent un jeton d’accès administratif sont décorés d’une icône de bouclier en tant qu’identification. Cette décoration indique à l’utilisateur que l’utilisation de cette fonctionnalité nécessite l’approbation de l’administrateur. Lorsque l’application détecte que l’un de ces boutons a été sélectionné, elle dispose des deux options suivantes.

• L’application lance un deuxième programme à l’aide de ShellExeucute() pour effectuer la tâche d’administration. Ce deuxième programme serait marqué avec un requestedExecutionLevel de requireAdministrator, entraînant ainsi l’invite d’approbation de l’utilisateur. Ce deuxième programme s’exécuterait avec un jeton d’accès administratif complet et serait en mesure d’effectuer la tâche souhaitée.
• L’application lance un objet COM à l’aide de CreateElevatedComObject(). Cette API lancerait l’objet COM avec un jeton d’accès administratif complet après approbation et cet objet COM serait en mesure d’effectuer la tâche souhaitée.

Cette méthode offre l’expérience utilisateur la plus riche et est la méthode préférée pour gérer les fonctionnalités d’administration.

La liste suivante détaille les exigences d’un processus avec élévation de privilèges ou d’un objet COM :

• Le panneau de configuration doit implémenter la décoration du bouclier et son architecture requise.
• Le développeur doit déterminer où le bouclier doit aller sur l’interface utilisateur.
• Le développeur doit effectuer le travail architectural pour séparer la logique métier en objet COM de l’objet d’interface utilisateur.
• Le développeur doit appeler le processus d’élévation du contrôle d’utilisateur lorsque l’événement OnClick pour l’icône de bouclier est détecté.

La liste suivante détaille les avantages de la conception correcte d’un processus avec élévation de privilèges ou d’un objet COM :

• Il s’agit de la meilleure expérience utilisateur globale pour les deux types d’utilisateurs. L’interface utilisateur sera lancée, visible par tout le monde, et toutes les fonctionnalités de contrôle d’utilisateur sur cette interface utilisateur seront accessibles à tout le monde. Ce n’est que lorsqu’une tâche d’administrateur est requise que l’utilisateur tente d’élever pour terminer la tâche.
• En effectuant ce travail maintenant, vous serez entièrement conforme au contrôle d’utilisateur à l’avenir.
• La séparation de l’interface utilisateur/COM est une bonne pratique architecturale.

Si vous cliquez sur une icône de bouclier, l’application lance un programme avec élévation de privilèges ou un objet COM avec élévation de privilèges pour effectuer la tâche.

Application administrateur uniquement

Dans cette instance, le lancement initial de l’application nécessite l’approbation de l’administrateur. Cette méthode est appelée « invite avant le lancement ». Une fois lancée, l’application s’exécute avec un jeton d’accès administratif complet et peut donc effectuer les tâches d’administration souhaitées. Cette méthode est le moins efficace pour le développeur. Le manifeste de l’application est marqué avec un requestedExecutionLevel de requireAdministrator.

Important Bien que cela nécessite le moins de travail pour le développeur, notez que, tout comme d’autres applications d’administration dans Windows Vista, les administrateurs devront élever leur niveau pour utiliser cette application et que les utilisateurs standard ne pourront pas utiliser l’application.

La liste suivante décrit les conditions requises pour les applications administrateur uniquement :

• Le manifeste de l’application doit contenir un jeu de marquage requestedExecutionLevel sur requireAdministrator.
• L’utilisateur est invité à obtenir l’approbation de l’administrateur avant que Windows ne lance l’application avec un jeton d’accès administratif complet.

La liste suivante détaille les avantages de la conception correcte d’une application administrateur uniquement :

• Le système d’exploitation n’a pas à « deviner » si votre application d’installation est une application administrative.
• Les utilisateurs standard recevront automatiquement un indicateur indiquant que l’opération est une opération administrative. Par exemple, lorsque vous voyez l’icône d’une application marquée requireAdministrator, un bouclier est incorporé dans l’icône.
• Sur Windows Vista, si vous marquez votre application comme requireAdministrator, vous savez qu’une fois lancée, elle s’exécutera avec un jeton d’accès administrateur complet. Les utilisateurs doivent élever leur niveau pour exécuter l’application (en tant qu’administrateur en mode d’approbation Administration ou en utilisant Exécuter en tant qu’administrateur).

Note Le marquage d’une application requireAdministrator n’élève PAS l’application en mode silencieux. L’utilisateur devra toujours donner son consentement d’élévation pour démarrer l’application. Il n’existe aucun moyen de marquer une application dans Windows Vista pour élever silencieusement.

La liste suivante détaille les points à prendre en considération pour la conception d’une application administrateur uniquement :

• Cette expérience utilisateur signifie que tous les utilisateurs verront une invite d’élévation (l’invite d’informations d’identification ou l’invite de consentement) avant même que l’interface utilisateur ne soit visible. Cela signifie également que personne n’est en mesure d’afficher simplement les paramètres actuels avant l’authentification avec les informations d’identification d’administrateur
• Si vous marquez requireAdministrator sur une application d’installation, vous devez savoir que l’utilisateur qui exécute l’installation est différent de l’utilisateur qui peut utiliser l’application. Par conséquent, vous ne devez pas modifier HKEY_CURRENT_USER (HKCU) et d’autres paramètres par utilisateur, tels que l’écriture dans le profil utilisateur, pendant votre configuration administrative.

Important Vous devez supposer que l’utilisateur exécutant l’application d’administration est différent de l’utilisateur normal sur l’ordinateur.

Les exécutables qui nécessitent un jeton d’accès administrateur sont marqués par une superposition d’icône de bouclier.

Application mixte

Une application mixte est une application qui peut être exécutée par tous les utilisateurs du système (utilisateurs standard, administrateurs en mode d’approbation Administration et ceux entre les deux, comme les opérateurs de sauvegarde). Il s’agit également d’une application « invite avant le lancement ». L’application s’exécute avec le jeton d’accès de l’appelant et se lance normalement pour les utilisateurs standard (aucune invite d’élévation). Le programme doit ensuite modifier son comportement au moment de l’exécution pour désactiver les fonctionnalités qui ne seraient pas disponibles pour l’utilisateur en fonction du jeton d’accès administratif obtenu.

Une application mixte n’a pas la possibilité d’obtenir des privilèges administratifs supplémentaires une fois lancée . par conséquent, il ne fournit pas la flexibilité du processus élevé ou de la méthode d’objet COM décrite précédemment. Cela est particulièrement utile pour les applications qui nécessitent un jeton d’accès supérieur à celui d’un utilisateur standard, mais inférieur à un administrateur complet.

Par exemple, la console MMC (Microsoft Management Console) est marquée comme la plus élevéeAvailable. Si un véritable utilisateur standard exécute la console MMC, MMC se lance en tant qu’application utilisateur standard sans aucune tentative d’élévation ni invite. Si l’utilisateur est un utilisateur de « jeton fractionné », tel qu’un administrateur en mode d’approbation Administration ou un opérateur de sauvegarde, le système d’exploitation invite l’utilisateur à obtenir son consentement pour lancer la console MMC avec le privilège « le plus élevé » disponible de l’utilisateur. Dans le cas d’un utilisateur standard qui dispose de privilèges d’opérateur de sauvegarde, après élévation, la console MMC est lancée avec utilisateur standard + opérateur de sauvegarde, mais rien de plus. Si un administrateur lance la console MMC, après l’élévation, MMC s’exécute en tant qu’application administrateur complète.

L’avantage de concevoir correctement une application mixte est que l’application est disponible pour tous les utilisateurs du système, même si certaines fonctionnalités peuvent être désactivées.

La liste suivante détaille les points à prendre en compte pour la conception d’applications mixtes :

• Le développeur doit modifier dynamiquement le comportement de l’application en fonction des privilèges Windows d’administration et des droits utilisateur disponibles auprès de l’utilisateur.
• L’utilisateur standard ne peut jamais agir sur les fonctions au niveau de l’administration de l’interface utilisateur. Il n’existe aucun risque d’élévation d’invite une fois le programme en cours d’exécution (les administrateurs doivent élever avant d’ouvrir l’interface utilisateur).

Note Il existe une solution de contournement pour la puce précédente. Un administrateur peut lancer une invite de commandes avec élévation de privilèges sur l’ordinateur de l’utilisateur standard et exécuter l’application à partir de l’invite de commandes. Par exemple, cliquez avec le bouton droit sur l’invite de commandes, sélectionnez Exécuter en tant qu’administrateur, puis tapez « applicationname.exe » dans l’invite de commandes.

L’expérience utilisateur est ramifiée entre l’utilisateur standard et l’administrateur dans Administration mode d’approbation.

Exemple d’application mixte : application de sauvegarde

L’application peut être lancée par un membre du groupe Opérateurs de sauvegarde. Le programme vérifie ensuite que le niveau le plus élevé de privilèges d’administration Windows et de droits utilisateur disponibles auprès de l’utilisateur est suffisant pour le fonctionnement du programme. Pour plus d’informations sur le comportement du lancement du programme, consultez la section Marquage du manifeste d’application et Comportement de lancement d’application de ce document.

Décisions clés pour la conception d’applications Administrator-Only

Objets métier back-end

Cette section fournit une vue d’ensemble des trois modèles qu’un développeur peut choisir lors du développement d’une application d’administration qui offre la meilleure expérience utilisateur.

• Modèle broker Administration
• Modèle de service Back-End
• Modèle objet COM Administration

modèle broker Administration

Dans le modèle broker Administration, l’application est divisée en deux exécutables indépendants : un exécutable utilisateur standard et un exécutable administratif. Le développeur, à l’aide d’un manifeste d’application, marque le programme utilisateur standard avec un requestedExecutionLevel asInvoker et marque le programme d’administration avec un requestedExecutionLevel de requireAdministrator. Un utilisateur lance d’abord le programme utilisateur standard. Lorsque l’utilisateur tente d’effectuer une opération que le programme utilisateur standard connaît nécessite un jeton d’accès administrateur complet, il exécute un ShellExecute() et lance le programme d’administration. L’API Windows ShellExecute() examine le manifeste et demande l’approbation de l’utilisateur avant d’exécuter l’application avec le jeton d’accès administratif complet de l’utilisateur. Le programme d’administration peut ensuite effectuer les tâches administratives.

Note Le programme exécutable d’administration peut activer la communication interprocessus avec un exécutable utilisateur standard à l’aide de la mémoire partagée, du RPC local ou des canaux nommés. Si le programme d’administration active la communication avec l’exécutable utilisateur standard, le développeur doit utiliser les bonnes pratiques de sécurité pour valider toutes les entrées du programme à privilèges inférieurs.

Note Il n’existe aucun canal de communication entre les deux programmes une fois le deuxième programme lancé

Les détails de liste suivants utilisent pour le modèle de répartiteur d’administration :

• Assistants : lorsque l’Assistant Matériel réalise que le pilote requis n’est pas installé sur l’ordinateur ou situé à l’emplacement approuvé de l’entreprise, il a besoin d’une application avec élévation de privilèges avec la possibilité de déplacer un pilote dans le magasin d’ordinateurs.
• Autorun.exe appel de Setup.exe : la première fois que vous placez un CD de jeu, l’opération requise à partir de autorun.exe consiste à configurer l’application. La deuxième fois que vous insérez le CD, l’opération par défaut consiste à jouer au jeu.

L’un des avantages de l’utilisation du modèle de répartiteur d’administration est qu’il s’agit probablement du mécanisme le plus facile à implémenter pour le développeur.

La liste suivante détaille certains inconvénients de l’utilisation du modèle broker Administration :

• Les transitions d’application à application peuvent prêter à confusion pour l’utilisateur. Il peut être difficile de tenir l’utilisateur informé de la raison pour laquelle une nouvelle application apparaît sur le moniteur.
• En outre, l’état est plus difficile à passer entre ces deux applications. Par exemple, vous ne l’utiliseriez pas pour passer l’état entre un panneau de configuration utilisateur standard (CPL) et son équivalent administrateur simplement pour permettre à la même CPL d’avoir des fonctionnalités administratives et non administratives. La CPL utilisateur standard doit stocker son état quelque part.
• Souvent, il y a beaucoup de code répliqué lors du fractionnement des fonctionnalités entre deux programmes.

Pour implémenter le modèle de répartiteur d’administration, créez deux programmes (un utilisateur standard et un administrateur), marquez-les avec le manifeste approprié requestedExecutionLevel et lancez le programme d’administration à partir du programme utilisateur standard à l’aide de ShellExecute().

Modèle de service Back-End

Dans le modèle de service principal, l’application est de nouveau divisée en deux exécutables indépendants : un exécutable utilisateur standard qui fournit l’interface utilisateur à l’utilisateur et un service principal s’exécutant sur le système. L’appel de procédure distante Microsoft (RPC) est utilisé pour communiquer entre les deux. L’application frontale est marquée avec un requestedExecutionLevel asInvoker et le service back-end s’exécute en tant que SYSTEM. La communication entre l’application et le service back-end s’effectue avec RPC.

L’une des utilisations du modèle de service back-end consiste à contrôler les programmes susceptibles d’avoir un impact sur le système, tels que les programmes antivirus ou les logiciels anti-espions). L’application frontale fournit les moyens par lesquels l’utilisateur connecté et les aspects de contrôle du service.

L’un des principaux avantages de l’utilisation du modèle de service principal est qu’aucune invite d’élévation n’est requise.

La liste suivante détaille certains inconvénients de l’utilisation du modèle de service back-end :

• Le service doit limiter les types d’activités que l’application front-end peut lui demander d’effectuer. Par exemple, un service antivirus peut permettre à un utilisateur standard de lancer une analyse du système, mais pas de désactiver la vérification antivirus en temps réel.
• L’ajout d’un service inutile au système peut avoir un impact sur l’ensemble du système. Assurez-vous que votre service est vraiment nécessaire pour votre implémentation Windows Vista et que le service est correctement conçu.

Pour implémenter le modèle de service principal, créez une application frontale utilisateur standard et un service principal. Installez le service dans le système pendant l’installation du produit.

Modèle objet COM Administration

Ce modèle est inclus ici, mais a été abordé en détail précédemment dans ce document. Le modèle objet COM d’administration permet à l’élévation administrative dynamique d’effectuer des opérations spécifiques à partir d’une application ou d’un panneau de configuration.

L’un des principaux avantages de l’utilisation du modèle objet COM d’administration est qu’il présente la meilleure expérience utilisateur pour l’utilisateur.

La liste suivante détaille certains inconvénients de l’utilisation du modèle objet COM d’administration :

• Nécessite le plus de travail pour le développeur, car chaque fonctionnalité d’application doit être évaluée et testée pour les fonctionnalités d’administrateur et cette fonction doit être fournie par un objet COM back-end.
• L’utilisateur doit fournir une approbation d’élévation.
• L'« unité » résultante de l’application utilisateur standard et Administration objet COM back-end est désormais « drivable » et n’est pas protégée par l’UIPI et d’autres mécanismes d’isolation.

Pour implémenter le modèle objet COM administrateur, créez une application frontale utilisateur standard et lancez des objets COM back-end avec élévation de privilèges pour effectuer des tâches d’administration.

5. Reconcevoir le programme d’installation de votre application

Les meilleures pratiques suivantes concernent les installations d’applications bien conduites dans un environnement Windows Vista ou UAC. Cette liste n'est pas exhaustive. Pour obtenir une explication plus détaillée de la configuration requise pour le logo pour Windows Vista, y compris la configuration requise pour le contrôle d’utilisateur, consultez la documentation sur le logo Windows Vista et la version détaillée du dernier brouillon du document instructions sur les logo Windows Vista.

Utilisez ces exigences lors de la refonte de votre application.

Utilisez Windows Installer 4.0 pour votre package d’installation.

La plupart des exigences suivantes sont déjà intégrées au moteur Windows Installer. L’utilisation de Windows Installer pour votre package d’installation vous aidera à répondre aux exigences d’installation de Windows Vista suivantes.

Utilisez des fichiers avec version et ne pas passer à une version antérieure pendant l’installation.

Le contrôle de version des fichiers garantit que l’état d’installation final est correct une fois l’installation terminée. Sans les versions de fichier, un certain transfert spécial sera nécessaire pour garantir que votre installation fonctionne correctement pour de nombreux scénarios d’installation différents. En outre, lors de l’installation de fichiers avec version, ne pas passer à une version antérieure, en particulier les fichiers partagés. Les versions de rétrogradation peuvent être bonnes pour votre application, mais cela provoque souvent des problèmes avec d’autres applications. En déclarant les versions correctes de vos fichiers dans votre package Windows Installer, Windows Installer prend en charge cette fonctionnalité en mode natif.

Installez des applications et stockez les données par utilisateur dans différents emplacements.

Les applications doivent être installées dans un dossier sous le répertoire Programs Files. Pour configurer cela, vous pouvez utiliser la propriété ProgramFilesFolder dans la table Direcotry de votre package Windows Installer. Les données de configuration par utilisateur doivent être stockées dans des fichiers sous le répertoire \Users\username\AppData ou dans des clés de Registre sous la racine HKCU. Les données utilisateur, les modèles et les fichiers créés par l’application ont tous des emplacements appropriés dans le sous-répertoire \Users\username. Bien que cela n’ait pas été appliqué dans le passé, étant donné que de nombreux utilisateurs exécutaient des programmes avec un jeton d’accès administrateur complet, les applications qui ne placent pas les informations à l’emplacement approprié sont susceptibles d’échouer. Cela est particulièrement vrai lorsque la virtualisation est désactivée.

Utilisez un emplacement de dossier cohérent lors de l’installation des composants partagés.

Les composants partagés doivent être installés dans le répertoire Common Files à l’aide de la propriété CommonFilesFolder dans la table Répertoire de votre package Windows Installer. La gestion des composants partagés peut être problématique et doit être évitée, si possible. Un développeur qui n’installe pas de composants partagés de manière cohérente peut se retrouver avec des informations d’inscription COM (Component Object Model) pointant vers des composants plus anciens. Les modules de fusion Windows Installer (MSM) sont spécifiquement conçus pour permettre aux composants partagés de s’installer de manière cohérente dans le contexte de tous les packages qui installent le composant partagé. D’autres problèmes surviennent lorsque les modifications des composants partagés entraînent l’échec des applications existantes. Une façon de résoudre ce problème consiste à créer des applications à l’aide d’assemblys microsoft .NET ou Win32 avec version.

Effectuez une restauration du programme d’installation en cas d’échec de l’installation.

Les logiciels partiellement installés peuvent échouer de manière étrange et inattendue, offrant une expérience utilisateur médiocre. Windows Installer prend en charge cette fonctionnalité de restauration.

N’installez pas de raccourcis d’application sur le profil de l’utilisateur.

Bien qu’il soit tentant d’ajouter votre icône d’application à chaque point d’exposition connu dans Windows, les utilisateurs ont souvent l’impression d’avoir perdu le contrôle de leur ordinateur. Les utilisateurs sont ensuite obligés de supprimer manuellement ces raccourcis pour rétablir l’apparence souhaitée de l’ordinateur. Si le développeur souhaite ajouter des icônes au bureau, demandez l’autorisation à l’utilisateur lors de l’installation. Windows Vista traite de la détectabilité des applications après l’installation et de la liste des applications les plus récemment utilisées pour éviter la traversée du menu Démarrer volumineux.

Évitez de lancer automatiquement des applications en arrière-plan lors de l’ouverture de session de l’utilisateur.

Bien qu’il soit possible d’ajouter des programmes au groupe de démarrage ou à la clé d’exécution pendant l’installation, cela ajoute une surcharge au système. Au fil du temps, les performances du système de l’utilisateur peuvent se dégrader considérablement. Si votre application peut tirer parti d’une tâche en arrière-plan, autorisez-la à être configurable par l’utilisateur. En outre, l’ajout d’une tâche de démarrage via la clé d’exécution HLKM peut empêcher un compte d’utilisateur standard de modifier le comportement à l’avenir. Si l’utilisateur souhaite qu’une application soit lancée au moment de la connexion, stockez les informations dans la clé d’exécution de HKCU.

Suivez propre logique de suppression.

Un utilisateur peut supprimer une application non seulement pour libérer de l’espace disque, mais aussi pour rétablir l’état de l’ordinateur avant l’installation de l’application. Le processus de désinstallation de l’application doit supprimer correctement et complètement l’application. Windows Installer utilise par défaut les règles suivantes :

• Tous les fichiers et dossiers d’application non partagés.
• Fichiers d’application partagés dont le nombre de références (refcount) atteint zéro.
• Entrées de Registre, à l’exception des clés qui peuvent être partagées par d’autres programmes.
• Tous les raccourcis du menu Démarrer créés par l’application au moment de l’installation.
• Les préférences de l’utilisateur peuvent être considérées comme des données utilisateur et laissées pour compte, mais une option permettant d’effectuer une suppression complètement propre doit être incluse.
• Le programme de désinstallation lui-même (s’il n’utilise pas Windows Installer).

6. Créer et incorporer un manifeste d’application avec votre application

Dans Windows Vista, la bonne façon de marquer vos applications consiste à incorporer un manifeste d’application dans votre programme qui indique au système d’exploitation ce dont l’application a besoin. Dans la version Windows Vista, il existe des dispositions permettant au code non manifeste ou non signé de s’exécuter avec un jeton d’accès administratif complet.

Note Dans les versions ultérieures, la seule façon d’exécuter une application avec élévation de privilèges sera d’avoir un manifeste signé qui identifie le niveau de privilège dont l’application a besoin.

Schéma du manifeste d’application

Les manifestes d’application ne sont pas nouveaux dans la version Windows Vista. Les manifestes ont été utilisés dans Windows XP pour aider les développeurs d’applications à identifier les versions des DLL avec lesquelles l’application a été testée. Fournir le niveau d’exécution est une extension de ce schéma de manifeste existant.

Le manifeste de l’application Windows Vista a été amélioré avec des attributs qui permettent aux développeurs de marquer leurs applications avec un niveau d’exécution demandé. Le format suivant est celui-ci.

<requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>

Valeurs possibles du niveau d’exécution demandé

Valeurs	Description	Commentaire
asInvoker	L’application s’exécute avec le même jeton d’accès que le processus parent.	Recommandé pour les applications utilisateur standard. Effectuez une réfractation avec des points d’élévation internes conformément aux instructions fournies dans ce document.
highestAvailable	L’application s’exécute avec les privilèges les plus élevés que l’utilisateur actuel peut obtenir.	Recommandé pour les applications en mode mixte. Prévoyez de réfracter l’application dans une version ultérieure.
requireAdministrator	L’application s’exécute uniquement pour les administrateurs et nécessite que l’application soit lancée avec le jeton d’accès complet d’un administrateur.	Recommandé pour les applications administrateur uniquement. Les points d’élévation internes ne sont pas nécessaires. L’application s’exécute déjà avec élévation de privilèges.

Note Les applications d’hébergement peuvent devenir des applications utilisateur ou administrateur standard uniquement si elles prennent en charge ce type d’application hébergée. Par exemple, MMC.exe héberge désormais uniquement les composants logiciels enfichables d’administration, et Explorer.exe héberge uniquement le code utilisateur standard.

Comportement du système

Application Markin	Virtualiser?
Banalisée	Oui
asInvoker	Non
requireAdministrator	Non
highestAvailable	Non

Marquage du manifeste d’application et comportement de lancement d’application

Cette section détaille le comportement de l’invite d’élévation en fonction du jeton d’accès du processus parent, le paramètre pour le contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour les administrateurs dans Administration stratégie mode d’approbation et le contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour la stratégie des utilisateurs standard et le marquage du niveau d’exécution demandé pour l’application.

Si une application peut s’exécuter et quels droits d’utilisateur et privilèges d’administration Windows elle peut obtenir dépendent de la combinaison du niveau d’exécution demandé de l’application dans la base de données de compatibilité de l’application et des privilèges administratifs disponibles pour le compte d’utilisateur qui a lancé l’application. Les tableaux suivants identifient le comportement d’exécution possible en fonction de ces combinaisons possibles.

Comportement de lancement d’application pour un membre du groupe Administrateurs local

Jeton d’accès au processus parent	Stratégie de consentement pour les membres du groupe Administrateurs locaux	None ou asInvoker	highestAvailable	requireAdministrator
Utilisateur standard	Aucune invite	Lancement de l’application en tant qu’utilisateur standard	L’application démarre avec un jeton d’accès administratif complet ; aucune invite	L’application démarre avec un jeton d’accès administratif complet ; aucune invite
Utilisateur standard	Demande de consentement	Lancement de l’application en tant qu’utilisateur standard	L’application démarre avec un jeton d’accès administratif complet ; invite de consentement	L’application démarre avec un jeton d’accès administratif complet ; invite de consentement
Utilisateur standard	Demander les informations d’identification	Lancement de l’application en tant qu’utilisateur standard	L’application démarre avec un jeton d’accès administratif complet ; demander des informations d’identification	L’application démarre avec un jeton d’accès administratif complet ; demander des informations d’identification
Administrateur (contrôle de compte utilisateur désactivé)	N/A	L’application démarre avec un jeton d’accès administratif complet ; aucune invite	L’application démarre avec un jeton d’accès administratif complet ; aucune invite	L’application démarre avec un jeton d’accès administratif complet ; aucune invite

Comportement de lancement d’application pour un compte d’utilisateur standard

Jeton d’accès au processus parent	Stratégie de consentement pour les utilisateurs standard	asInvoker	highestAvailable	requireAdministrator
Utilisateur standard	Aucune invite	Lancement de l’application en tant qu’utilisateur standard	Lancement de l’application en tant qu’utilisateur standard	Échec du lancement de l’application
Utilisateur standard	Demander les informations d’identification	Lancement de l’application en tant qu’utilisateur standard	Lancement de l’application en tant qu’utilisateur standard	Demander les informations d’identification de l’administrateur avant d’exécuter l’application
Utilisateur standard (contrôle de compte d'utilisateur désactivé)	N/A	Lancement de l’application en tant qu’utilisateur standard	Lancement de l’application en tant qu’utilisateur standard	L’application peut se lancer, mais échouera ultérieurement

Comportement de lancement d’application pour un utilisateur standard avec des privilèges supplémentaires (par exemple, opérateur de sauvegarde)

Jeton d’accès au processus parent	Stratégie de consentement pour les utilisateurs standard	asInvoker	highestAvailable	requireAdministrator
Utilisateur standard	Aucune invite	Lancement de l’application en tant qu’utilisateur standard	L’application est lancée en tant qu’utilisateur standard avec des privilèges supplémentaires	Échec du lancement de l’application
Utilisateur standard	Demander les informations d’identification	Lancement de l’application en tant qu’utilisateur standard	Demander des informations d’identification avant d’exécuter l’application	Demander les informations d’identification de l’administrateur avant d’exécuter l’application
Utilisateur standard (contrôle de compte d'utilisateur désactivé)	N/A	Lancement de l’application en tant qu’utilisateur standard	L’application est lancée en tant qu’utilisateur standard avec des privilèges supplémentaires	L’application peut se lancer, mais échouera ultérieurement

Valeurs uiAccess

Valeurs uiAccess possibles

Valeur	Description
False	L’application n’a pas besoin de diriger l’entrée vers l’interface utilisateur d’une autre fenêtre sur le bureau. Les applications qui ne fournissent pas d’accessibilité doivent définir cet indicateur sur false. Les applications qui sont requises pour diriger l’entrée vers d’autres fenêtres du bureau (clavier visuel, par exemple) doivent définir cette valeur sur true.
True	L’application est autorisée à contourner les niveaux de contrôle de l’interface utilisateur pour diriger l’entrée vers des fenêtres à privilèges plus élevés sur le bureau. Ce paramètre ne doit être utilisé que pour les applications de technologie d’assistance d’interface utilisateur.

Important Les applications dont l’indicateur uiAccess est défini sur true doivent être signées Authenticode pour démarrer correctement. En outre, l’application doit résider dans un emplacement protégé dans le système de fichiers. \Program Files\ et \windows\system32\ sont actuellement les deux emplacements protégés autorisés.

Guide pratique pour créer un manifeste incorporé avec Microsoft Visual Studio

Visual Studio offre la possibilité d’incorporer automatiquement un fichier manifeste XML dans la section de ressources de l’image exécutable portable (PE). Cette section explique comment utiliser Visual Studio pour créer une image PE signée contenant un manifeste. Ce manifeste peut donc inclure les attributs requestedExecutionLevel nécessaires permettant à l’application de s’exécuter avec le niveau de privilège souhaité sur Windows Vista. Lorsque le programme est lancé, les informations de manifeste sont extraites de la section des ressources du pe et utilisées par le système d’exploitation. Il n’est pas nécessaire d’utiliser l’interface utilisateur graphique (GUI) de Visual Studio pour inclure un manifeste. Une fois que les modifications nécessaires se trouvent dans le code source, la compilation et la liaison à l’aide d’outils en ligne de commande incluent également le manifeste dans l’image PE résultante.

Fichier manifeste

Pour marquer votre application, commencez par créer un fichier manifeste à utiliser avec l’application cible. Cela peut être effectué à l’aide de n’importe quel éditeur de texte. Le fichier manifeste doit avoir le même nom que le target.exe avec une extension .manifest , comme illustré dans l’exemple ci-dessous.

Executable: IsUserAdmin.exe 
Manifest:IsUserAdmin.exe.manifest
Sample application manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="IsUserAdmin"
     type="win32"/> 
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Les parties du manifeste qui doivent être ajustées pour votre application sont marquées en gras. Il s'agit des dossiers suivants :

• Identité de l’assembly
• Le nom
• Type
• Description
• Attributs dans le requestedExecutionLevel

Génération de manifestes d’application dans du code C/C++ avec Visual Studio 2005 pour les applications Windows Vista uniquement

Important Si votre application est destinée à s’exécuter à la fois sur Windows Vista et Windows XP, vous devez suivre les procédures décrites dans la section suivante : Génération et incorporation d’un manifeste avec Microsoft Visual Studio 2005 pour Les applications Windows XP et Windows Vista.

Ensuite, vous devez joindre le manifeste à l’exécutable en ajoutant une ligne dans le fichier de ressources de l’application (fichier .rc) pour que Microsoft Visual Studio incorpore votre manifeste dans la section de ressources du fichier PE. Pour ce faire, placez le manifeste dans le même répertoire que le code source du projet que vous générez, puis modifiez le fichier .rc pour inclure les lignes suivantes.

#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST "IsUserAdmin.exe.manifest"

Après la reconstruction de l’application, le manifeste doit être incorporé dans la section de ressources de l’exécutable.

Génération et incorporation d’un manifeste avec Microsoft Visual Studio 2005 pour les applications Windows XP et Windows Vista

Dans Visual Studio 2005, l’interface d’environnement de développement intégré (IDE) C/C++ qui permet l’inclusion de fichiers manifestes supplémentaires dans un fichier exécutable cible effectue un traitement sur le xml, ce qui insère une balise xmlns en double. Pour cette raison, la méthode précédemment documentée sur la façon d’inclure un manifeste dans un projet Visual Studio 2005 C++ ne peut pas être utilisée si l’application doit s’exécuter à la fois sur Windows Vista et Windows XP. Les procédures suivantes sont modifiées pour inclure des balises de version explicites dans la section trustInfo.

Un correctif est prévu pour l’outil mt.exe afin de résoudre le problème où il génère la déclaration d’espace de noms en double dans le code XML. Tant qu’une nouvelle version de mt.exe n’est pas disponible, vous pouvez éviter le problème de fusion des manifestes en ajoutant explicitement des balises de version dans la section trustinfo du manifeste. Un exemple de manifeste est illustré ci-dessous :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
      <ms_asmv2:security>
         <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
      </ms_asmv2:security>
   </ms_asmv2:trustInfo>
</assembly>

Projet C ou C++

La procédure suivante explique comment créer un manifeste pour un type de projet C ou C++ dans Visual Studio 2005.

Pour créer un manifeste pour un projet C ou C++ dans Microsoft Visual Studio 2005

1. Ouvrir votre projet dans Microsoft Visual Studio 2005
2. Sous Projet, sélectionnez Propriétés.
3. Dans Propriétés, sélectionnez Outil manifeste, puis Entrée et Sortie.
4. Ajoutez le nom de votre fichier manifeste d’application sous Fichiers manifeste supplémentaires.
5. Régénérez votre application.

Note Les manifestes mis à jour qui incluent des balises de version explicites permettent à l’application de s’exécuter correctement sur Windows Vista et Windows XP.

Code managé (C#, J# et Visual Basic)

Visual Studio n’incorpore actuellement pas de manifeste par défaut dans du code managé. Pour le code managé, le développeur insère simplement un manifeste par défaut dans l’exécutable cible à l’aide de mt.exe. Les étapes sont les suivantes :

Pour insérer un fichier manifeste par défaut dans l’exécutable cible avec mt.exe

1. Utilisez un éditeur de texte, tel que le Bloc-notes Windows, pour créer un fichier manifeste par défaut, temp.manifest.
2. Utilisez mt.exe pour insérer le manifeste. La commande serait : mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

Ajout du manifeste d’application en tant qu’étape dans Visual Studio post-build

L’ajout du manifeste d’application peut également être automatisé en tant qu’étape post-génération. Cette option est disponible pour C/C++ et les deux langages de code managé C# et J#.

Note L’IDE n’inclut actuellement pas d’option post-build pour une application Visual Basic.

Placez la ligne suivante en tant que tâche de post-génération dans Propriétés du projet :

mt.exe -manifest "$(ProjectDir)$(TargetName).exe.manifest" 
-updateresource:"$(TargetDir)$(TargetName).exe;#1"

7. Tester votre application

Testez votre application repensée ou nouvelle pour la compatibilité de l’application avec Standard User Analyzer. Une procédure détaillant ce processus a été décrite plus haut dans ce document dans la section Tester votre application pour la compatibilité des UAC.

Utilisez le workflow suivant pour tester votre application.

Pour tester votre application pour la compatibilité finale de l’UAC

1. Testez l’application avec l’outil Standard User Analyzer.
2. Connectez-vous à un ordinateur Windows Vista en tant qu’administrateur en mode d’approbation Administration et exécutez votre programme. Vérifiez que vous testez toutes les fonctionnalités et notez l’expérience utilisateur. Classez les bogues d’élévation ou d’interface utilisateur en conséquence.
3. Connectez-vous à un ordinateur Windows Vista en tant qu’utilisateur standard et exécutez votre programme. Vérifiez que vous testez toutes les fonctionnalités et notez les différences ou les échecs dans l’expérience utilisateur standard par rapport à l’administrateur dans Administration’expérience utilisateur du mode d’approbation. Classer les bogues d’élévation et d’expérience utilisateur en conséquence.

8. Authenticode Sign Your Application

L’application contient désormais un manifeste, qui sera détecté et les informations analysées au lancement de l’application. L’exécutable peut toutefois être falsifié. Pour éviter cela, vous devez signer l’application avec une signature Authenticode. Notez que Windows Vista a la possibilité d’empêcher le lancement d’une application non signée avec un jeton d’accès administrateur complet. Si vous souhaitez que votre application fonctionne correctement dans des environnements verrouillés, tout en affichant une interface utilisateur plus conviviale, elle doit être signée avec une signature Authenticode.

Pour signer l’application, vous pouvez générer un certificat à partir de makecert.exe ou obtenir une clé de signature de code auprès de l’une des autorités de certification commerciales, telles que VeriSign, Thawte ou une autorité de certification Microsoft.

Note Vous aurez besoin d’un certificat commercial si vous utilisez votre application pour être approuvé sur l’ordinateur cible d’un client qui installe votre application.

Si vous utilisez le fichier makecert.exe pour générer votre paire de clés de signature, sachez qu’il génère uniquement une clé 1024 bits. Les signatures Authenticode doivent être au moins une clé 2 048 bits. Le fichier makecert.exe ne doit être utilisé qu’à des fins de test.

La procédure suivante décrit en détail les exigences générales relatives à l’utilisation de makecert.exe pour générer votre paire de clés de signature. Un exemple et makecert.exe paramètres suivent cette procédure.

Pour utiliser makecert.exe pour générer votre paire de clés de signature

1. Générez le certificat.
2. Signez le code.
3. Installez le certificat de test.

Exemple de procédure de signature

Les procédures suivantes sont fournies à titre d’exemples et ne sont pas destinées à être strictement suivies. Par exemple, remplacez le nom du certificat de test par le nom de votre certificat et assurez-vous d’adapter les procédures à votre autorité de certification et à votre environnement de développement spécifiques.

Étape 1 : Générer le certificat

makecert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" 
ContosoTest.cer

makecert.exe paramètres

Paramètre	Description
/r	Créer le certificat auto-signé
/Pe	Rend la clé privée du certificat exportable vers la machine de signature.
/ss StoreName	Nom du magasin de certificats qui stockera le certificat de test. Exemple : PrivateCertStore
/n X500Name	Nom X500 de l’objet du certificat. Exemple : Contoso.com(Test)
CertificateName.cer	Nom du certificat. Exemple : ContosoTest.cer

Étape 2 : Signer le code

Signtool sign /v /s PrivateCertStore /n Contoso.com(Test) /t 
http://timestamp.verisign.com/scripts/timestamp.dll file.exe

Étape 3 : Installer le certificat de test

Pour installer le certificat de test

1. Lancez une fenêtre de commande avec élévation de privilèges en cliquant avec le bouton droit sur Invite de commandes et en sélectionnant Exécuter en tant qu’administrateur.
2. Dans l’invite de commandes, tapez mmc.exe , puis appuyez sur Entrée.
3. Dans mmc, sélectionnez Fichier , puis Ajouter/Supprimer un composant logiciel enfichable...
4. Dans Ajouter ou supprimer des composants logiciels enfichables, sélectionnez Certificats, cliquez sur Ajouter, puis sur OK.
5. Dans la boîte de dialogue du composant logiciel enfichable Certificats, sélectionnez Compte d’ordinateur , puis cliquez sur Suivant.
6. Dans Sélectionner un ordinateur, sélectionnez Ordinateur local, puis cliquez sur OK.
7. Dans Ajouter ou supprimer des composants logiciels enfichables, cliquez sur OK.
8. Dans le composant logiciel enfichable Certificats, accédez à Autorités de certification racines approuvées, cliquez avec le bouton droit sur Certificats, sélectionnez Toutes les tâches, puis sélectionnez Importer...
9. Dans l’Assistant Importation de certificat, importez le certificat de test ContosoTest.cer.

9. Participer au programme de logo Windows Vista

Microsoft propose le programme de logo Windows Vista pour aider les clients à identifier les systèmes et les périphériques qui répondent à une définition de base complète des fonctionnalités de la plateforme et des objectifs de qualité afin de garantir une expérience informatique exceptionnelle pour les utilisateurs finaux.

Déploiement et mise à jour corrective d’applications pour les utilisateurs standard

En règle générale, les entreprises devront réfléchir à la façon dont elles installeront des applications sur les stations de travail de leurs utilisateurs de manière automatisée, ce qui réduit les coûts administratifs. Ce problème comporte fondamentalement deux parties : premièrement, comment ces applications doivent être empaquetées pour le déploiement et deuxièmement, quelle technologie doit être utilisée pour les déployer. Dans le cas des environnements d’entreprise plus petits, un mécanisme de déploiement robuste et automatisé peut ne pas être nécessaire.

En supposant que l’entreprise a déjà effectué un inventaire des logiciels exécutés dans son environnement, l’étape suivante consiste à reconditionner ces applications pour le déploiement. Microsoft recommande le format Windows Installer, car il a la possibilité unique de séparer la gestion des paramètres par utilisateur des paramètres par ordinateur. Ce type de gestion n’est généralement pas possible avec d’autres formats d’empaquetage, en particulier les exécutables de déploiement qui sont simplement exécutés par un compte disposant de privilèges supplémentaires, comme SYSTEM. La bibliothèque MSDN contient de nombreux articles sur Windows Installer ; l’une des suggestions est la feuille de route vers la documentation de Windows Installer.

Le format Windows Installer inclut la possibilité pour l’utilisateur de contrôler l’installation de ces applications via stratégie de groupe (Microsoft IntelliMirror) et également par SMS. Pour activer l’installation à la demande avec une extension de fichier ou des raccourcis, les tableaux suivants du package Windows Installer doivent être remplis avec des données publicitaires : raccourci, extension, icône et Verbe. Il est également recommandé de remplir la classe, MIME, ProgID et TypeLib. Pour plus d’informations sur IntelliMirror et Installer à la demande , consultez Correctifs Per-User applications managées .

Il existe d’autres technologies de programme d’installation qui permettent aux applications d’installer par utilisateur et de prendre en charge la mise à jour automatique, comme ClickOnce. Cela signifie que le programme d’installation n’aura pas besoin de privilèges d’administrateur ou supérieurs pour l’installation et que l’utilisateur exécutera toujours la dernière version tant que l’ordinateur est connecté au réseau. Il impose également certaines limites à la capacité d’un professionnel de l’informatique à contrôler l’installation de ces applications.

Le déploiement ClickOnce est une technologie d’installation de Microsoft .NET qui installe et configure automatiquement une application côté client lorsqu’un utilisateur clique sur un lien de manifeste, tel qu’un manifeste dans un site web, sur un CD ou sur un chemin d’accès UNC (Universal Naming Convention). Par défaut, l’application se copie dans le dossier Fichiers Internet temporaires et s’exécute dans un environnement restreint.

Note Même si votre application a été signée avec le nom fort informatique qui lui donne une confiance totale, vous ne pouvez toujours pas faire quoi que ce soit qui nécessite des autorisations d’administrateur, comme l’accès à certaines parties du système de fichiers et du Registre. Toutefois, les applications ClickOnce sont ciblées en tant qu’applications par utilisateur. Cela ne doit donc pas être un problème.

Important ClickOnce ne doit pas être utilisé pour le déploiement d’applications qui effectuent des opérations d’administration.

Déploiement sur un seul ordinateur

Pour déployer une application pour un seul ordinateur, l’administrateur doit « publier » l’application sur cet ordinateur.

Déploiement sur tous les utilisateurs d’un domaine

Pour publier des annonces pour tous les utilisateurs d’un domaine, l’administrateur doit « publier » l’application via stratégie de groupe déploiement. Actuellement, seul le composant de déploiement de logiciels basé sur stratégie de groupe des systèmes d’exploitation Windows Server® 2003 et du système d’exploitation Windows 2000 Server tire parti de cette fonctionnalité.

Mise à jour corrective d’applications en tant qu’utilisateur standard avec Windows Installer 4.0

La mise à jour corrective des comptes d’utilisateur standard permet aux auteurs de package Windows Installer d’identifier les correctifs signés qui peuvent être appliqués par un futur utilisateur standard. Les conditions suivantes doivent être remplies pour activer la mise à jour corrective utilisateur standard avec Windows Installer 4.0 :

• L’application a été installée à l’aide de Windows Installer 4.0.
• L’application a initialement été installée par machine.
• La table MsiPatchCertificate est présente et renseignée dans le package Windows Installer d’origine (.msi fichier).
• Les correctifs sont signés numériquement par un certificat listé dans la table MsiPatchCertificate.
• Les correctifs peuvent être validés par rapport à la signature numérique.
• La mise à jour corrective des comptes d’utilisateur standard n’a pas été désactivée en définissant la propriété MSIDISABLELUAPATCHING ou la stratégie DisableLUAPatching.

Comportement de désinstallation utilisateur standard de Windows Installer 4.0

Le comportement attendu d’un correctif Windows Installer 4.0 appliqué par un utilisateur standard est qu’il peut également être supprimé par l’utilisateur standard.

Dépannage des problèmes courants

Les sections suivantes détaillent les problèmes courants rencontrés avec les applications dans Windows Vista.

Voici quelques problèmes courants :

• Problèmes d’installation d’ActiveX
• Les documents ActiveX n’installent pas
• Application, infrastructure ou complément requis
• Une autorisation d’administration est requise pour l’installation/la mise à jour corrective
• Emplacements des paramètres d’application par utilisateur
• L’application enregistre par défaut dans un répertoire protégé

Problèmes d’installation d’ActiveX

Les contrôles ActiveX doivent être installés par un administrateur. Les contrôles ActiveX sont généralement utilisés dans les applications métier pour étendre les fonctionnalités du navigateur Web afin de créer des interfaces utilisateur plus flexibles ou d’élever l’accès aux ressources informatiques normalement refusés aux applications exécutées dans le navigateur Web. Les contrôles ActiveX sont généralement installés en incorporant une référence au contrôle ActiveX dans une page web. Microsoft Internet Explorer télécharge et installe le contrôle s’il n’existe pas sur l’ordinateur local. En règle générale, les contrôles ActiveX téléchargés de cette façon résident dans le répertoire %HOMEPATH%\Local Settings\Temporary Internet Files, qui est accessible en écriture par les utilisateurs standard. Toutefois, pour fonctionner dans Internet Explorer, les contrôles doivent avoir plusieurs entrées de registre, qui ne sont pas possibles pour les non-administrateurs.

Résolution

La suppression du contrôle ActiveX de l’application entraîne presque toujours une perte de fonctionnalités. Par conséquent, cela n’est pas recommandé pour la correction, sauf si le contrôle ActiveX fournit une amélioration visuelle ou fonctionnelle qui ne fait pas partie des fonctionnalités principales du site. Par exemple, un ticker boursier sur un portail non lié aux actions.

Dans la plupart des cas, l’empaquetage du contrôle ActiveX pour l’installation par SMS ou stratégie de groupe est la solution appropriée. Toutefois, la plupart des contrôles ne sont pas inclus dans l’image de base. Les sites Web doivent donc modifier leurs pages pour qu’elles échouent correctement. Cela doit comprendre la détection du contrôle ActiveX manquant et la redirection vers la page de demande de logiciel Managed Desktop.

Les documents ActiveX ne sont pas installés

Les documents ActiveX sont une technologie déconseillée de Microsoft Visual Basic 4 et Microsoft Visual Basic 5. Ils peuvent être téléchargés de la même manière que les contrôles ActiveX.

Résolution

Étant donné que Visual Basic 4 et Visual Basic 5 sont déconseillés, Microsoft vous recommande de remplacer l’application. Il doit être possible d’installer le document ActiveX dans le cadre d’une installation d’un client ; Toutefois, les mises à jour du document seront limitées sans redéploiement via SMS ou stratégie de groupe.

Application, infrastructure ou complément requis

De nombreuses applications ont des dépendances sur d’autres logiciels, qui peuvent ne pas être installés par défaut, soit parce qu’ils sont déjà disponibles sur l’ordinateur, soit parce que l’autre application ne fournit pas de fichiers binaires distribuables pour une utilisation par des tiers. Dans des circonstances normales, l’utilisateur serait invité à acquérir et à installer le logiciel supplémentaire. Sous un bureau managé, l’installation n’est pas possible. Adobe Acrobat, Microsoft Office, les composants Web Office, WinZip et la stratégie de sécurité microsoft .NET informatique en sont des exemples.

Résolution

Une fois les dépendances identifiées, elles peuvent être empaquetées avec l’image de base ou mises à disposition via une installation SMS à la demande. L’application peut être amené à modifier la façon dont elle avertit l’utilisateur final du logiciel manquant, en le dirigeant vers le site d’installation du SMS plutôt que vers le fabricant.

L’autorisation d’administration est requise pour l’installation/la mise à jour corrective

Étant donné que l’installation d’un programme nécessite l’ajout de fichiers à Program Files, il nécessite toujours des autorisations d’administration et, par conséquent, doit être exécuté en tant qu’utilisateur disposant d’autorisations élevées.

Note Vous pouvez également envoyer (push) le correctif avec SMS ou stratégie de groupe conjointement avec le panneau de configuration Ajout/Suppression de programmes (ARP). l’utilisateur sélectionne le logiciel à installer et le programme d’installation du système effectue le reste, l’utilisateur n’a pas besoin d’être administrateur. Pour les installations initiales, cela peut être résolu en empaquetant le logiciel pour qu’un agent d’installation sorte. Toutefois, certaines applications s’appuient sur des mises à jour automatiques fréquentes qui peuvent ne pas s’aligner correctement sur un modèle d’application géré de manière centralisée.

Les applications qui détectent les mises à jour et tentent de corriger elles-mêmes ne pourront pas le faire, car elles n’auront pas l’autorisation de modifier les fichiers dans les répertoires système.

Résolution

• Empaquetez votre application/correctif pour le déploiement par SMS. Les applications peuvent toujours détecter qu’une mise à niveau est disponible (tant qu’elles le font sans nécessiter d’autorisations administratives) et peuvent rediriger vers le site d’approvisionnement.
• Déterminez si votre application a besoin d’autorisations d’ordinateur élevées, telles que le système de fichiers, l’accès au Registre ou l’interopérabilité COM. Si ce n’est pas le cas, il peut être possible de réécrire l’application en tant que package de déploiement ClickOnce, qui s’exécutera dans le bac à sable Microsoft .NET.
• Convertir en application web sans dépendances côté client.

Per-User Emplacements des paramètres d’application

Pour Windows Vista, les paramètres d’application qui doivent être modifiés au moment de l’exécution doivent être stockés dans l’un des emplacements suivants :

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Les documents enregistrés par l’utilisateur doivent être stockés dans CSIDL_MYDOCUMENTS.

Note Le dossier Documents d’un utilisateur n’est plus stocké sous Documents et paramètres. Dans Windows Vista, un nouveau répertoire racine sur le système de fichiers appelé Utilisateurs contient désormais les profils des utilisateurs de l’ordinateur.

Étant donné que ces répertoires ont changé, les développeurs sont encouragés à utiliser des CSIDL pour localiser le chemin d’accès à des répertoires connus spécifiques de manière indépendante du système. Pour plus d’informations, consultez CSIDL.

Une application a besoin d’un accès en écriture au système de fichiers. Lors de l’exécution sous un bureau managé, une application dispose uniquement des autorisations d’écriture sur les dossiers suivants et leurs enfants.

• CSIDL_PROFILE
• CSIDL_COMMON_APPDATA

Note Les utilisateurs standard ne peuvent pas écrire dans Users\Common.

• C:\Users\Common>cd « Application Data »
  • C:\Users\Common\Application Data>Echo File > File.txt
  • C:\Users\Common\Application Data>

Les applications ne doivent pas tenter d’écrire dans d’autres emplacements, tels que les suivants :

• C:\windows.
• C:\Windows\System32.
• Program Files\{application}.
• C:\{application}.

Note Cela fonctionne si l’utilisateur a créé le dossier, ce que les membres du groupe Utilisateurs peuvent faire par défaut.

Une application tente de créer spécifiquement C:\Users\Profiles\{user} n’est pas autorisée, car l’utilisateur peut uniquement créer des dossiers sous C:\Users\{user}. L’emplacement choisi semble être confondu en fonction de l’emplacement où Microsoft a stocké le dossier Documents sur les versions précédentes du système d’exploitation.

Les paramètres d’application qui doivent être modifiés au moment de l’exécution doivent être stockés dans l’un des emplacements suivants :

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Les documents enregistrés par l’utilisateur doivent être stockés dans le dossier CSIDL_MYDOCUMENTS.

Tous les chemins ne doivent pas être codés en dur, mais doivent utiliser la fonction Environment.GetFolderPath().

La valeur par défaut de l’application est l’enregistrement dans un répertoire protégé

Certaines applications permettent aux utilisateurs d’enregistrer ou d’exporter des données vers leur ordinateur local. Souvent, la boîte de dialogue utilise par défaut des emplacements comme C:\, pour lesquels les utilisateurs standard ne disposent pas d’autorisations d’écriture. En outre, certaines applications ne répondent pas correctement lorsque le code permettant d’écrire le fichier échoue en raison d’un accès refusé à partir du système d’exploitation.

Résolution

Supposons que les utilisateurs peuvent uniquement écrire dans leurs propres profils. Pour les documents enregistrés intentionnellement par les utilisateurs, initialisez les boîtes de dialogue pour démarrer dans Documents (Environment.GetFolderPath(Environment.SpecialFolder.Personal). N’oubliez pas que la boîte de dialogue Enregistrer permet à un utilisateur d’accéder à d’autres emplacements que le profil de l’utilisateur. L’application doit donc inclure une logique pour s’assurer qu’elle échoue correctement si un utilisateur choisit un autre répertoire que celui de son profil.

Références

Cette section inclut une référence de virtualisation et une référence des paramètres de sécurité.

Informations de référence sur la virtualisation

Virtualisation de fichiers

• Virtualize (%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(Subdirectories)
• Rediriger vers : %LOCALAPPDATA%\VirtualStore
• Exécutables binaires exclus : .exe, .dll .sys

Virtualisation du registre :

• Virtualize (HKLM\SOFTWARE)
• Redirigez vers : HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys>
• Clés exclues de la virtualisation
• HKLM\Software\Classes
• HKLM\Software\Microsoft\Windows
• HKLM\Software\Microsoft\Windows NT

Applicabilité

• Les magasins virtuels ne sont pas itinérants
• Les objets globaux correspondants ne sont pas itinérants
• Activé uniquement pour les utilisateurs standard interactifs
• Désactivé pour les processus non interactifs
• Désactivé pour les exécutables 64 bits
• Désactivé pour les exécutables qui demandent un niveau d’exécution (requestedExecutionLevel) dans leur manifeste d’application, le modèle de séparation
• Désactivé pour le mode noyau et les appelants emprunts d’identité
• Seuls les fichiers et clés de Registre accessibles en écriture par l’administrateur sont virtualisés

Informations de référence sur les paramètres de sécurité du contrôle d’utilisateur

Cette référence détaille les paramètres de sécurité disponibles pour administrer le contrôle d’utilisateur avec stratégie de groupe ou la stratégie de sécurité locale de l’ordinateur.

Note Les procédures présentées dans cette section sont destinées à administrer des ordinateurs non gérés. Pour utiliser stratégie de groupe pour administrer les paramètres de manière centralisée dans un environnement managé, utilisez Utilisateurs et ordinateurs Active Directory (dsa.msc) au lieu du composant logiciel enfichable Gestionnaire de stratégies de sécurité local (secpol.msc).

Configuration des paramètres de sécurité du contrôle d’utilisateur

La procédure suivante explique en détail comment configurer les paramètres de sécurité du contrôle d’utilisateur avec le Gestionnaire de stratégies de sécurité. La procédure détaille l’expérience utilisateur par défaut pour un administrateur en mode d’approbation Administration.

Pour afficher/définir les paramètres de sécurité du contrôle d’utilisateur avec le Gestionnaire de stratégies de sécurité

1. Cliquez sur le bouton Démarrer , tapez secpol.msc dans la zone de recherche, puis appuyez sur Entrée.
2. À l’invite de consentement contrôle de compte d’utilisateur, cliquez sur Continuer.
3. Dans Paramètres de sécurité locaux, développez Stratégies locales, puis cliquez sur Options de sécurité.
4. Cliquez avec le bouton droit sur le paramètre de sécurité que vous souhaitez modifier, puis sélectionnez Propriétés.

La procédure suivante explique en détail comment configurer les paramètres de sécurité UAC avec le stratégie de groupe. La procédure détaille l’expérience utilisateur par défaut pour un administrateur en mode d’approbation Administration.

Pour afficher/définir les paramètres de sécurité UAC avec l’éditeur d’objets stratégie de groupe

1. Cliquez sur le bouton Démarrer , tapez gpedit.msc dans la zone de recherche, puis appuyez sur Entrée.
2. À l’invite de consentement contrôle de compte d’utilisateur, cliquez sur Continuer.
3. Dans stratégie de groupe, développez Configuration utilisateur, puis Options de sécurité.
4. Cliquez avec le bouton droit sur le paramètre de sécurité que vous souhaitez modifier, puis sélectionnez Propriétés.

Paramètres de sécurité UAC

Le tableau suivant répertorie les paramètres de sécurité UAC configurables. Ces paramètres peuvent être configurés avec security Policy Manager (secpol.msc) ou gérés de manière centralisée avec stratégie de groupe (gpedit.msc).

Paramètres de sécurité UAC

Paramètre	Description	Valeur par défaut
Contrôle de compte d’utilisateur : Administration mode d’approbation pour le compte administrateur intégré.	Il existe deux paramètres possibles : Activé : l’administrateur intégré est exécuté en tant qu’administrateur en mode d’approbation Administration. Désactivé : l’administrateur s’exécute avec un jeton d’accès administrateur complet.	Désactivé pour les nouvelles installations et pour les mises à niveau où l’administrateur intégré n’est pas le seul administrateur local actif sur l’ordinateur. Le compte Administrateur intégré est désactivé par défaut pour les installations et les mises à niveau sur les ordinateurs joints à un domaine. Activé pour les mises à niveau lorsque Windows Vista détermine que le compte Administrateur intégré est le seul administrateur local actif sur l’ordinateur. Si Windows Vista le détermine, le compte Administrateur intégré est également activé après la mise à niveau. Le compte Administrateur intégré est désactivé par défaut pour les installations et les mises à niveau sur les ordinateurs joints à un domaine.
Contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour les administrateurs en mode d’approbation Administrateur	Il existe trois valeurs possibles pour ce paramètre : Élever sans invite : élever en mode silencieux. Demander des informations d’identification : demandez aux utilisateurs d’entrer leur mot de passe de connexion avant de continuer. Invite de consentement : demandez l’approbation de l’utilisateur avant de l’élever. Il s'agit du paramètre par défaut.  Ce paramètre détermine comment l’utilisateur est invité avant d’exécuter un programme avec des autorisations plus élevées. Cette stratégie n’est en vigueur que lorsque l’UAC est activée.	Demande de consentement
Contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour les utilisateurs standard	Détermine la façon dont l’utilisateur est invité avant d’exécuter un programme avec des autorisations plus élevées. Cette stratégie n’est en vigueur que lorsque l’UAC est activée. Voici les options de configuration disponibles pour ce paramètre : Refuser automatiquement les demandes d’élévation : les utilisateurs ne sont pas invités lorsqu’une application souhaite effectuer une tâche d’administration. Le lancement de l’application échoue et présente une erreur d’accès refusé ou équivalente à l’utilisateur. Demander des informations d’identification : demandez aux utilisateurs d’entrer leur mot de passe de connexion avant de continuer.	Demander les informations d’identification
Contrôle de compte d’utilisateur : détecter les installations d’applications et demander l’élévation	Il existe deux valeurs possibles : Activé : l’utilisateur est invité à fournir son consentement ou ses informations d’identification lorsque Windows Vista détecte un programme d’installation. Désactivé : les installations d’application échouent en mode silencieux ou échouent de manière non déterministe.	activé
Contrôle de compte d’utilisateur : élever uniquement les exécutables signés et validés	Il existe deux valeurs possibles : Activé : seuls les fichiers exécutables signés s’exécutent. Ce paramètre empêche l’exécution des applications non signées. Désactivé : le code signé et le code non signé seront exécutés.	Désactivé
Contrôle de compte d’utilisateur : élever uniquement les applications UIAccess installées à des emplacements sécurisés	Il existe deux valeurs possibles : Activé : le système accorde uniquement des privilèges uiAccess et des droits d’utilisateur aux exécutables qui sont lancés à partir de %ProgramFiles% ou %windir%. Les listes de contrôle d’accès de ces répertoires garantissent que l’exécutable n’est pas modifiable par l’utilisateur (ce qui permettrait sinon l’élévation de privilèges). Les exécutables UIAccess lancés à partir d’autres emplacements sont lancés sans privilèges supplémentaires (c’est-à-dire qu’ils exécutent « asInvoker »). Désactivé : les vérifications d’emplacement n’étant pas effectuées, toutes les applications UIAccess seront lancées avec le jeton d’accès complet de l’utilisateur lors de l’approbation de l’utilisateur.	activé
Contrôle de compte d’utilisateur : exécuter les comptes d’administrateurs en mode d’approbation d’administrateur	Il existe deux valeurs possibles : Activé : les administrateurs et les utilisateurs standard sont invités lors de la tentative d’exécution d’opérations d’administration. Le style d’invite dépend de la stratégie. Désactivé : L’UAC est essentiellement « désactivé » et le service AIS est désactivé du démarrage automatique.	activé
Contrôle de compte d’utilisateur : passer au Bureau sécurisé lors d’une demande d’élévation	Il existe deux valeurs possibles : Activé : affiche l’invite d’élévation UAC sur le bureau sécurisé. Le bureau sécurisé ne peut recevoir que des messages provenant de processus Windows, ce qui élimine les messages des logiciels malveillants. Par conséquent, les invites de consentement et d’informations d’identification ne peuvent pas être usurpées sur le bureau sécurisé. Désactivé : l’invite d’élévation UAC s’affiche sur le bureau de l’utilisateur.	activé
Contrôle de compte d’utilisateur : virtualiser les échecs d’écritures de fichiers et de Registre dans des emplacements définis par utilisateur	Il existe deux valeurs possibles : Activé : les applications qui ne disposent pas d’une entrée de base de données de compatibilité d’application ou d’un marquage de niveau d’exécution demandé dans le manifeste d’application ne sont pas conformes À la UAC. Les environnements qui utilisent des logiciels non conformes doivent conserver ce paramètre activé. Désactivé : les applications compatibles UAC ne doivent pas écrire dans des zones protégées et provoquer des échecs d’écriture. Par conséquent, les environnements qui utilisent uniquement des applications compatibles UAC doivent désactiver ce paramètre. Les applications non conformes qui tentent d’écrire dans Program Files et %systemroot% échouent en mode silencieux si ce paramètre est désactivé.	activé

Note Dans la plupart des cas, l’option Élever sans invite n’est pas recommandée. L’élévation sans invite permettrait aux applications qui s’exécutent en tant qu’utilisateur standard de lancer des applications administratives sans le consentement de l’utilisateur et de contourner efficacement l’UAC.

Exemple de code du planificateur de tâches

L’exemple de code C++ suivant montre comment utiliser le Planificateur de tâches pour effectuer l’élévation pour l’utilisateur. Par conséquent, l’application peut automatiquement s’élever pendant l’ouverture de session à l’aide des informations d’identification d’un administrateur et Windows Vista ne bloque pas l’application. Vous devez créer un utilisateur administrateur pour votre application pendant l’installation afin que cette solution fonctionne correctement.

//---------------------------------------------------------------------
//  This file is part of the Microsoft .NET Framework SDK Code Samples.
// 
//  Copyright (C) Microsoft Corporation.  All rights reserved.
// 
//This source code is intended only as a supplement to Microsoft
//Development Tools and/or on-line documentation.  See these other
//materials for detailed information regarding Microsoft code samples.
// 
//THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY
//KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
//IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
//PARTICULAR PURPOSE.
//---------------------------------------------------------------------

/****************************************************************************
* Main.cpp - Sample application for Task Scheduler V2 COMAPI                * Component: Task Scheduler                          
* Copyright (c) 2002 - 2003, Microsoft Corporation 
* This sample creates a task to at the time registered to start the desired task.                                                             *
****************************************************************************/
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <comdef.h>
#include <comutil.h>
//Include Task header files - Included in Windows Vista Beta-2 SDK from MSDN
#include <taskschd.h>
#include <conio.h>
#include <iostream>
#include <time.h>

using namespace std;

#define CLEANUP \
pRootFolder->Release();\
        pTask->Release();\
        CoUninitialize();

HRESULT CreateMyTask(LPCWSTR, wstring);

void __cdecl wmain(int argc, wchar_t** argv)
{
wstring wstrExecutablePath;
WCHAR taskName[20];
HRESULT result;

if( argc < 2 )
{
printf("\nUsage: LaunchApp yourapp.exe" );
return;
}

// Pick random number for task name
srand((unsigned int) time(NULL));
wsprintf((LPWSTR)taskName, L"Launch %d", rand());

wstrExecutablePath = argv[1];

result = CreateMyTask(taskName, wstrExecutablePath);
printf("\nReturn status:%d\n", result);

}
HRESULT CreateMyTask(LPCWSTR wszTaskName, wstring wstrExecutablePath)
{
    //  ------------------------------------------------------
    //  Initialize COM.
TASK_STATE taskState;
int i;
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if( FAILED(hr) )
    {
        printf("\nCoInitializeEx failed: %x", hr );
        return 1;
    }

    //  Set general COM security levels.
    hr = CoInitializeSecurity(
        NULL,
        -1,
        NULL,
        NULL,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
        RPC_C_IMP_LEVEL_IMPERSONATE,
        NULL,
        0,
        NULL);

    if( FAILED(hr) )
    {
        printf("\nCoInitializeSecurity failed: %x", hr );
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Create an instance of the Task Service. 
    ITaskService *pService = NULL;
    hr = CreateElevatedComObject( CLSID_TaskScheduler,
                           NULL,
                           CLSCTX_INPROC_SERVER,
                           IID_ITaskService,
                           (void**)&pService );  
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        CoUninitialize();
        return 1;
    }
        
    //  Connect to the task service.
    hr = pService->Connect(_variant_t(), _variant_t(), _variant_t(), _variant_t());
    if( FAILED(hr) )
    {
        printf("ITaskService::Connect failed: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Get the pointer to the root task folder.  This folder will hold the
    //  new task that is registered.
    ITaskFolder *pRootFolder = NULL;
    hr = pService->GetFolder( _bstr_t( L"\\") , &pRootFolder );
    if( FAILED(hr) )
    {
        printf("Cannot get Root Folder pointer: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }
    
    //  Check if the same task already exists. If the same task exists, remove it.
    hr = pRootFolder->DeleteTask( _bstr_t( wszTaskName), 0  );
    
    //  Create the task builder object to create the task.
    ITaskDefinition *pTask = NULL;
    hr = pService->NewTask( 0, &pTask );

    pService->Release();  // COM clean up.  Pointer is no longer used.
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        pRootFolder->Release();
        CoUninitialize();
        return 1;
    }
        

    //  ------------------------------------------------------
    //  Get the trigger collection to insert the registration trigger.
    ITriggerCollection *pTriggerCollection = NULL;
    hr = pTask->get_Triggers( &pTriggerCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get trigger collection: %x", hr );
CLEANUP
        return 1;
    }
  
    //  Add the registration trigger to the task.
    ITrigger *pTrigger = NULL;
    
    hr = pTriggerCollection->Create( TASK_TRIGGER_REGISTRATION, &pTrigger );     
    pTriggerCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\nCannot add registration trigger to the Task %x", hr );
        CLEANUP
        return 1;
    }
    pTrigger->Release();

    //  ------------------------------------------------------
    //  Add an Action to the task.     
    IExecAction *pExecAction = NULL;
    IActionCollection *pActionCollection = NULL;

    //  Get the task action collection pointer.
    hr = pTask->get_Actions( &pActionCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get Task collection pointer: %x", hr );
        CLEANUP
        return 1;
    }
    
    //  Create the action, specifying that it is an executable action.
    IAction *pAction = NULL;
    hr = pActionCollection->Create( TASK_ACTION_EXEC, &pAction );
    pActionCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\npActionCollection->Create failed: %x", hr );
        CLEANUP
        return 1;
    }

    hr = pAction->QueryInterface( IID_IExecAction, (void**) &pExecAction );
    pAction->Release();
    if( FAILED(hr) )
    {
        printf("\npAction->QueryInterface failed: %x", hr );
        CLEANUP
        return 1;
    }

    //  Set the path of the executable to the user supplied executable.
hr = pExecAction->put_Path( _bstr_t( wstrExecutablePath.c_str() ) );  

//hr = pExecAction->put_Path( (BSTR)wstrExecutablePath );  
    if( FAILED(hr) )
    {
        printf("\nCannot set path of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    hr = pExecAction->put_Arguments( _bstr_t( L"" ) );  
//    hr = pExecAction->put_Arguments( _bstr_t( L"ArgumentsToYourExecutable--HelpFileToOpen" ) );  
   if( FAILED(hr) )
    {
        printf("\nCannot set arguments of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    
    //  ------------------------------------------------------
    //  Save the task in the root folder.
    IRegisteredTask *pRegisteredTask = NULL;
    hr = pRootFolder->RegisterTaskDefinition(
            _bstr_t( wszTaskName ),
            pTask,
        TASK_CREATE, 
_variant_t(_bstr_t( L"S-1-5-32-545")),//Well Known SID for \\Builtin\Users group
_variant_t(), 
TASK_LOGON_GROUP,
            _variant_t(L""),
            &pRegisteredTask);
    if( FAILED(hr) )
    {
        printf("\nError saving the Task : %x", hr );
        CLEANUP
        return 1;
    }
    printf("\n Success! Task successfully registered. " );
for (i=0; i<100; i++)//give 10 seconds for the task to start
{
pRegisteredTask->get_State(&taskState);
if (taskState == TASK_STATE_RUNNING)
{
printf("\nTask is running\n");
break;
}
Sleep(100);
}
if (i>= 100) printf("Task didn't start\n");

//Delete the task when done
    hr = pRootFolder->DeleteTask(
            _bstr_t( wszTaskName ),
            NULL);
    if( FAILED(hr) )
    {
        printf("\nError deleting the Task : %x", hr );
        CLEANUP
        return 1;
    }

    printf("\n Success! Task successfully deleted. " );

//  Clean up.
    CLEANUP
    CoUninitialize();
    return 0;
}