Fonctionnement du contrôle de compte d’utilisateur
S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016
Le Contrôle de compte d’utilisateur (UAC) contribue à éviter que des programmes malveillants n’endommagent un ordinateur tout en permettant aux organisations de déployer un bureau mieux administré. Avec UAC, les applications et les tâches sont toujours exécutées dans le contexte de sécurité d’un compte non administrateur, sauf si un administrateur autorise spécifiquement l’accès administrateur au système. Le contrôle de compte d’utilisateur peut bloquer l’installation automatique d’applications non autorisées et empêcher les modifications accidentelles de paramètres système.
Processus et interactions UAC
Chaque application qui nécessite le jeton d’accès administrateur doit demander à l’administrateur de donner son consentement. La seule exception à cette règle est la relation qui existe entre les processus parent et enfant. Les processus enfants héritent du jeton d’accès utilisateur du processus parent. Les deux processus parent et enfant doivent cependant avoir le même niveau d’intégrité. Windows Server 2012 protège les processus en marquant leurs niveaux d’intégrité. Les niveaux d’intégrité sont des mesures de la confiance. Une application d’intégrité « élevée » est une application qui effectue des tâches qui modifient les données système, comme une application de partitionnement de disque, tandis qu’une application à « faible » intégrité est une application qui effectue des tâches susceptibles de compromettre le système d’exploitation, comme un navigateur web. Les applications avec des niveaux d’intégrité inférieurs ne peuvent pas modifier les données dans les applications avec des niveaux d’intégrité plus élevés. Lorsqu’un utilisateur standard tente d’exécuter une application qui nécessite un jeton d’accès administrateur, UAC exige que l’utilisateur fournisse des informations d’identification d’administrateur valides.
Pour mieux comprendre comment ce processus se produit, il est important de passer en revue les détails du processus d’ouverture de session Windows Server 2012.
Processus d’ouverture de session Windows Server 2012
L’illustration suivante montre comment le processus d’ouverture de session d’un administrateur diffère du processus d’ouverture de session d’un utilisateur standard.
Par défaut, les utilisateurs standard et les administrateurs accèdent aux ressources et exécutent des applications dans le contexte de sécurité des utilisateurs standard. Lorsqu’un utilisateur ouvre une session sur un ordinateur, le système crée un jeton d’accès spécialement pour lui. Ce jeton d’accès contient des informations sur le niveau d’accès accordé à l’utilisateur, notamment des identificateurs de sécurité et des privilèges Windows spécifiques.
Lorsqu’un administrateur ouvre une session, deux jetons d’accès sont créés pour l’utilisateur : un jeton d’accès utilisateur standard et un jeton d’accès administrateur. Le jeton d’accès utilisateur standard contient les mêmes informations spécifiques à l’utilisateur que le jeton d’accès administrateur, mais les privilèges et SID administratifs Windows sont supprimés. Le jeton d’accès utilisateur standard est utilisé pour démarrer des applications qui n’effectuent pas de tâches administratives (applications utilisateur standard). Le jeton d’accès utilisateur standard est ensuite utilisé pour afficher le bureau (Explorer.exe). Explorer.exe est le processus parent duquel tous les autres processus lancés par l’utilisateur héritent leur jeton d’accès. Par conséquent, toutes les applications s’exécutent avec des privilèges d’utilisateur standard, sauf si un utilisateur fournit son consentement ou des informations d’identification pour utiliser un jeton d’accès administrateur total dans une application.
Un utilisateur membre du groupe Administrateurs peut ouvrir une session, naviguer sur le Web et lire ses courriers électroniques avec un jeton d’accès utilisateur standard. Lorsque l’administrateur doit effectuer une tâche qui requiert le jeton d’accès administrateur, Windows Server 2012 demande automatiquement l’approbation de l’utilisateur. Cette demande s’appelle une invite d’élévation. Vous pouvez configurer son comportement à l’aide du composant logiciel enfichable Stratégie de sécurité locale (Secpol.msc) ou de la stratégie de groupe.
Notes
Le terme "élévation" désigne le processus de Windows Server 2012 qui invite l’utilisateur à fournir son consentement ou ses informations d’identification pour utiliser un jeton d’accès administrateur total.
Expérience utilisateur du contrôle de compte d’utilisateur
Lorsque l’UAC est activé, l’expérience utilisateur des utilisateurs standard est différente de celle des administrateurs en mode d’approbation Administration. La méthode recommandée et la plus sécurisée d’exécution de Windows Server 2012 consiste à faire de votre compte d’utilisateur principal un compte d’utilisateur standard. L’exécution en tant qu’utilisateur standard contribue à optimiser la sécurité d’un environnement géré. Avec le composant d’élévation UAC intégré, les utilisateurs standard peuvent facilement effectuer une tâche d’administration en entrant des informations d’identification valides pour un compte d’administrateur local. Le composant d’élévation UAC intégré par défaut pour les utilisateurs standard est l’invite d’informations d’identification.
L’alternative à l’exécution en tant qu’utilisateur standard consiste à exécuter en tant qu’administrateur en mode d’approbation administrateur. Grâce au composant d’élévation du contrôle de compte d’utilisateur intégré, les membres du groupe Administrateurs local peuvent facilement effectuer une tâche d’administration en fournissant l’approbation. Le composant d’élévation UAC intégré par défaut pour un compte d’administrateur en mode d’approbation administrateur est appelé invite de consentement. Le comportement des invites d’élévation UAC peut être configuré à l’aide du composant logiciel enfichable Stratégie de sécurité locale (Secpol.msc) ou de la stratégie de groupe.
Les invites de consentement et d’informations d’identification
Le contrôle de compte d’utilisateur étant activé, Windows Server 2012 demande le consentement ou les informations d’identification d’un compte d’administrateur local valide avant de démarrer un programme ou une tâche nécessitant un jeton d’accès administrateur total. Cette invite garantit qu’aucun logiciel malveillant ne peut être installé en mode silencieux.
Demande de consentement
La demande de consentement est présentée lorsqu’un utilisateur tente d’effectuer une tâche qui nécessite un jeton d’accès administrateur. Voici une capture d’écran de l’invite de consentement UAC.
Demande d’informations d’identification
La demande d’informations d’identification est présentée lorsqu’un utilisateur standard tente d’effectuer une tâche nécessitant un jeton d’accès administrateur. Le comportement des invites par défaut d’utilisateur standard peut être configuré à l’aide du composant logiciel enfichable Stratégie de sécurité locale (Secpol.msc) ou de la stratégie de groupe. Les administrateurs peuvent également être amenés à présenter leurs informations d’identification si le paramètre de stratégie Contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour les administrateurs en mode d’approbation Administrateur est défini avec la valeur Demande d’informations d’identification.
La capture d’écran suivante est un exemple d’invite d’informations d’identification UAC.
Invites d’élévation UAC
Les invites d’élévation du contrôle de compte d’utilisateur sont codées avec des couleurs différentes selon l’application, ce qui permet d’identifier immédiatement le risque de sécurité potentiel de l’application. Lorsqu’une application tente de s’exécuter avec un jeton d’accès administrateur total, Windows Server 2012 commence par analyser le fichier exécutable afin d’en déterminer l’éditeur. Les applications sont tout d’abord classées en trois catégories, selon l’éditeur du fichier exécutable : Windows Server 2012, vérifiées par l’éditeur (signées), et non vérifiées par l’éditeur (non signées). Le diagramme suivant illustre la façon dont Windows Server 2012 détermine l’invite d’élévation en couleur à présenter à l’utilisateur.
Le codage de couleur de l’invite d’élévation est le suivant :
Arrière-plan rouge avec une icône de bouclier rouge : l’application est bloquée par la stratégie de groupe ou émane d’un éditeur bloqué.
Arrière-plan bleu avec une icône de bouclier bleue et dorée : l’application est une application d’administration Windows Server 2012, telle qu’un élément du Panneau de configuration.
Arrière-plan bleu avec une icône de bouclier bleue : l’application est signée à l’aide de la technologie Authenticode et elle est approuvée par l’ordinateur local.
Arrière-plan jaune avec une icône de bouclier jaune : l’application est signée ou non signée mais elle n’est pas encore approuvée par l’ordinateur local.
Icône de bouclier
Certains éléments du Panneau de configuration, tels que Propriétés de dates et d’heures, contiennent une combinaison d’opérations d’utilisateur standard et d’administrateur. Les utilisateurs standard peuvent afficher l’horloge et changer le fuseau horaire, mais un jeton d’accès administrateur complet est requis pour modifier l’heure système locale. L’image suivante est une capture d’écran de l’élément du Panneau de configuration Propriétés de dates et d’heures.
L’icône de bouclier sur le bouton Changer la date et l’heure indique que le processus requiert un jeton d’accès administrateur complet et qu’il va afficher une invite d’élévation du contrôle de compte d’utilisateur.
Sécurisation de l’invite d’élévation
La sécurisation du processus d’élévation est renforcée car l’invite est envoyée sur le bureau sécurisé. Les demandes de consentement et d’informations d’identification sont affichées sur le bureau sécurisé par défaut de Windows Server 2012. Seuls les processus Windows peuvent accéder au bureau sécurisé. Pour obtenir des niveaux de sécurité plus élevés, il est recommandé de laisser le paramètre de stratégie Contrôle de compte d’utilisateur : passer au Bureau sécurisé lors d’une demande d’élévation activé.
Lorsqu’un fichier exécutable demande l’élévation, le bureau interactif, également appelé bureau de l’utilisateur, passe au bureau sécurisé. Le bureau sécurisé atténue le bureau de l’utilisateur et affiche une invite d’élévation à laquelle vous devez répondre avant de continuer. Lorsque l’utilisateur clique sur Oui ou sur Non, le bureau repasse au bureau de l’utilisateur.
Les logiciels malveillants peuvent présenter une imitation du bureau sécurisé, mais lorsque le paramètre de stratégie Contrôle de compte d’utilisateur : comportement de l’invite d’élévation pour les administrateurs en mode d’approbation Administrateur est défini sur Demande de consentement, ils n’obtiennent pas d’élévation si l’utilisateur clique sur Oui sur l’imitation. En revanche, si le paramètre de stratégie est défini sur Demande d’informations d’identification, il est possible que les logiciels malveillants imitant la demande d’informations d’identification parviennent à réunir les informations d’identification de l’utilisateur. Toutefois, le programme malveillant ne bénéficie pas de privilèges élevés, et le système dispose d’autres protections qui empêchent les programmes malveillants de prendre le contrôle de l’interface utilisateur, même avec un mot de passe collecté.
Si les logiciels malveillants peuvent présenter une imitation du bureau sécurisé, ce problème ne peut pas se produire sauf si un utilisateur a précédemment installé les logiciels malveillants sur l’ordinateur. Comme les processus nécessitant un jeton d’accès administrateur ne peuvent pas s’installer en mode silencieux lorsque le contrôle de compte d’utilisateur est activé, l’utilisateur doit explicitement fournir un consentement en cliquant sur Oui ou en fournissant des informations d’identification d’administrateur. Le comportement spécifique de l’invite d’élévation UAC dépend de la stratégie de groupe.
Architecture UAC
Le diagramme suivant montre l’architecture du contrôle de compte d’utilisateur en détail.
Pour mieux comprendre chaque composant, consultez le tableau ci-dessous :
| Composant | Description |
|---|---|
| Utilisateur | |
| L’utilisateur effectue une opération nécessitant des privilèges | Si l’opération modifie le système de fichiers ou le Registre, la virtualisation est appelée. Toutes les autres opérations appellent ShellExecute. |
| ShellExecute | ShellExecute appelle CreateProcess. ShellExecute recherche l’erreur ERROR_ELEVATION_REQUIRED dans CreateProcess. S’il reçoit l’erreur, ShellExecute appelle le service Informations sur l’application pour tenter d’effectuer la tâche demandée à l’aide de l’invite avec élévation de privilèges. |
| CreateProcess | Si l’application nécessite une élévation, CreateProcess rejette l’appel avec ERROR_ELEVATION_REQUIRED. |
| Système | |
| Service Informations sur l’application | Service système qui démarre des applications nécessitant un ou plusieurs privilèges ou droits d’utilisateur élevés pour s’exécuter (des tâches d’administration locales, par exemple), et des applications nécessitant des niveaux d’intégrité plus élevés. Le service Informations sur l’application aide à démarrer ces applications en créant un nouveau processus pour l’application avec le jeton d’accès complet d’un utilisateur administratif lorsque l’élévation est requise et (en fonction de la stratégie de groupe) le consentement est donné par l’utilisateur pour le faire. |
| Élévation d’une installation ActiveX | Si ActiveX n’est pas installé, le système vérifie le niveau du curseur UAC. Si ActiveX est installé, le paramètre de stratégie de groupe Contrôle de compte d’utilisateur : passer au Bureau sécurisé lors d’une demande d’élévation est activé. |
| Vérifier le niveau du curseur du contrôle de compte d’utilisateur | UAC dispose désormais de quatre niveaux de notification et d’un curseur à utiliser pour sélectionner le niveau de notification :
|
| Bureau sécurisé activé | Le paramètre de stratégie Contrôle de compte d’utilisateur : passer au Bureau sécurisé lors d’une demande d’élévation est activé : - Si le bureau sécurisé est activé, toutes les demandes d’élévation passent au bureau sécurisé quels que soient les paramètres de stratégie de comportement d’invite pour les administrateurs et les utilisateurs standard. |
| CreateProcess | CreateProcess appelle AppCompat, Fusion et Détection des programmes d’installation pour déterminer si l’application nécessite une élévation. Le fichier exécutable est alors examiné pour déterminer son niveau d’exécution demandé, qui est stocké dans le manifeste d’application du fichier exécutable. CreateProcess échoue si le niveau d’exécution demandé spécifié dans le manifeste ne correspond pas au jeton d’accès et s’il renvoie une erreur (ERROR_ELEVATION_REQUIRED) à ShellExecute. |
| AppCompat | La base de données AppCompat stocke des informations dans les entrées de correctif de compatibilité d’application pour une application. |
| Fusion | La base de données Fusion stocke les informations des manifestes d’application qui décrivent les applications. Le schéma de manifeste est mis à jour pour ajouter un nouveau champ de niveau d’exécution demandé. |
| Détection des programmes d’installation | La détection du programme d’installation détecte les fichiers exécutables d’installation, ce qui empêche l’exécution des installations à l’insu et au consentement de l’utilisateur. |
| Noyau | |
| Virtualisation | La technologie de virtualisation garantit que les applications non conformes n’échouent pas en mode silencieux ou d’une manière dont la cause ne peut pas être déterminée. UAC fournit également la virtualisation et la journalisation des fichiers et du registre pour les applications qui écrivent dans des zones protégées. |
| Système de fichiers et Registre | La virtualisation de fichiers par utilisateur et du registre redirige les demandes d’écriture de fichiers et de registre par ordinateur vers des emplacements équivalents par utilisateur. Les demandes de lecture sont d’abord redirigées vers l’emplacement par utilisateur virtualisé, puis vers l’emplacement par ordinateur. |
UAC sur Windows Server 2012 présente des différences par rapport aux versions précédentes de Windows. Le nouveau curseur ne désactivera jamais complètement UAC. Le nouveau paramètre :
Maintient le service UAC en cours d’exécution.
Provoque l’approbation automatique de toutes les demandes d’élévation initiées par les administrateurs sans afficher d’invite UAC.
Refuse automatiquement toutes les demandes d’élévation pour les utilisateurs standard.
Important
Pour désactiver complètement UAC, vous devez désactiver la stratégie Contrôle de compte d’utilisateur : exécuter les comptes d’administrateurs en mode d’approbation d’administrateur.
Avertissement
Les applications personnalisées ne fonctionnent pas sur Windows Server 2012 lorsque l’UAC est désactivé.
Virtualisation
Étant donné que les administrateurs système dans les entreprises tentent de sécuriser les systèmes, de nombreuses applications métier sont conçues pour n’utiliser qu’un jeton d’accès utilisateur standard. Les administrateurs n’ont donc pas besoin de remplacer la majorité des applications lorsqu’ils exécutent Windows Server 2012 avec le contrôle de compte d’utilisateur activé.
Windows Server 2012 intègre la technologie de la virtualisation des fichiers et du Registre pour les applications non compatibles avec le contrôle de compte d’utilisateur qui requièrent un jeton d’accès administrateur pour s’exécuter correctement. Grâce à la virtualisation, même les applications non compatibles avec le contrôle de compte d’utilisateur sont compatibles avec Windows Server 2012. Lorsqu’une application administrative non compatible UAC tente d’écrire dans un répertoire protégé, comme Program Files, le contrôle de compte d’utilisateur donne à l’application sa propre vue virtualisée de la ressource qu’il tente de modifier. La copie virtualisée est gérée dans le profil utilisateur. Cette stratégie crée une copie distincte du fichier virtualisé pour chaque utilisateur qui exécute l’application non conforme.
La plupart des tâches d’application fonctionnent correctement à l’aide des fonctionnalités de virtualisation. Bien que la virtualisation autorise l’exécution d’une majorité d’applications, il s’agit d’un correctif à court terme et non d’une solution à long terme. Les développeurs d’applications doivent modifier leurs applications au plus vite afin de les rendre compatibles avec le programme Logo Program Windows Server 2012, plutôt que de s’appuyer sur la virtualisation des fichiers, des dossiers et du Registre.
La virtualisation n’est pas une possibilité dans les scénarios suivants :
La virtualisation ne s’applique pas aux applications qui sont élevées et s’exécutent avec un jeton d’accès d’administration total.
La virtualisation ne prend en charge que les applications 32 bits. Les applications 64 bits non élevées reçoivent simplement un message d’accès refusé lorsqu’elles tentent d’acquérir un descripteur (identificateur unique) sur un objet Windows. Les applications 64 bits Windows natives doivent être compatibles avec le contrôle de compte d’utilisateur et pouvoir écrire des données dans les emplacements corrects.
La virtualisation est désactivée pour une application si l’application inclut un manifeste d’application avec un attribut de niveau d’exécution demandé.
Niveaux d’exécution des requêtes
Un manifeste d'application est un fichier XML qui décrit et identifie les assemblys côte à côte partagés et privés auxquels une application doit se lier au moment de l'exécution. Dans Windows Server 2012, le manifeste d’application contient des entrées pour assurer la compatibilité des applications avec le contrôle de compte d’utilisateur. Les applications administratives qui incluent une entrée dans le manifeste de l’application demandent à l’utilisateur l’autorisation d’accéder au jeton d’accès de l’utilisateur. Même s’il manque une entrée dans le manifeste d’application, la plupart des applications d’administration peuvent s’exécuter sans modification grâce aux correctifs de compatibilité des applications. Les correctifs de compatibilité des applications sont des entrées de base de données qui permettent à des applications non compatibles avec le contrôle de compte d’utilisateur de fonctionner correctement avec Windows Server 2012.
Toutes les applications compatibles UAC doivent avoir un niveau d’exécution demandé ajouté au manifeste de l’application. Si l’application nécessite un accès administratif au système, le marquage de l’application avec un niveau d’exécution demandé « Administrateur requis » garantit que le système identifie ce programme comme une application administrative et effectue les étapes d’élévation nécessaires. Les niveaux d’exécution demandés indiquent les privilèges requis pour une application.
Technologie de détection des programmes d’installation
Les programmes d’installation sont des applications conçues pour déployer des logiciels. La plupart des programmes d’installation écrivent dans les répertoires système et les clés du Registre. Ces emplacements système protégés sont généralement accessibles en écriture uniquement par un administrateur dans la technologie de détection du programme d’installation, ce qui signifie que les utilisateurs standard n’ont pas suffisamment d’accès pour installer des programmes. Windows Server 2012 détecte les programmes d’installation de manière heuristique et demande les informations d’identification ou l’approbation de l’administrateur afin de les exécuter avec des privilèges d’accès. Windows Server 2012 détecte également de manière heuristique les mises à jour et programmes qui désinstallent les applications. L’un des objectifs conceptuels du contrôle de compte d’utilisateur est d’empêcher l’exécution des installations à l’insu ou sans le consentement de l’utilisateur, car les programmes d’installation écrivent dans des zones protégées du système de fichiers et du Registre.
La détection du programme d’installation s’applique uniquement aux :
Fichiers exécutables 32 bits.
Applications sans attribut de niveau d’exécution demandé.
Processus interactifs s’exécutant en tant qu’utilisateur standard avec UAC 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 comme « install », « setup » ou « update ».
Les champs de gestion des versions des ressources contiennent les mots clés suivants : Fournisseur, Nom de la société, Nom du produit, Description du fichier, Nom de fichier initial, Nom interne et Nom d’exportation.
Les mots clés contenus dans le manifeste côte à côte sont incorporés dans le fichier exécutable.
Les mots clés dans les entrées StringTable spécifiques sont liés dans le fichier exécutable.
Les attributs clés dans les données de script de ressource sont liés dans le fichier exécutable.
Il existe des séquences d’octets ciblées au sein du fichier exécutable.
Notes
Les mots clés et les séquences d’octets sont dérivés des caractéristiques communes observées dans de nombreuses technologies de programmes d’installation.
Notes
Le paramètre de stratégie Contrôle de compte d’utilisateur : détecter les installations d’applications et demander l’élévation doit être activé pour que la technologie puisse détecter les programmes d’installation. Ce paramètre est activé par défaut et peut être configuré localement à l’aide du composant logiciel enfichable Stratégie de sécurité locale (Secpol.msc), ou bien configuré pour le domaine OU ou des groupes spécifiques à l’aide de la stratégie de groupe (Gpedit.msc).