UAC – Le contrôle de compte d’utilisateur

I. Présentation

Introduit avec Vista, la fonctionnalité de “contrôle de compte d’utilisateur” (alias UAC) a rebuté plus d’un technicien ou administrateur sous Windows, dont la motivation première était de s’en débarrasser :(. Les habitudes (même mauvaises) sont parfois tenaces et l’objectif de cet article est de vous sensibiliser à son usage.

En quelques mots, le concept de l’UAC est approximativement comparable à l’action “sudo” sous Linux qui consiste à élever les privilèges à la demande (et non pour toute la session). Autrement dit, seul le processus “élevé” dispose des privilèges d’administration, sans interférer avec le reste des processus de la session. En revanche, il faut accepter que l’appartenance à un groupe d’administrateurs ne soit plus implicitement suffisante à la réalisation des actions d’installation et de configuration d’un système Windows.

II. Dans le détail

En fait, comme toute règle, il y a des généralités et quelques exceptions, parfois subtiles.

Le comportement de l’UAC peut être déterminé au sein des stratégies de groupe (GPO) sous la rubrique “Paramètres de sécurité … Contrôle de compte d’utilisateur …” mais j’y reviendrais ultérieurement.

En premier lieu, il faut considérer que le compte d’administrateur intégré (builtin) est hors périmètre UAC. C’est à dire qu’il n’est pas concerné par défaut par la restriction et dispose du niveau de privilèges maximum dès l’ouverture de session.

Il n’existe que 2 administrateurs intégrés, celui qui est “local” à tout ordinateur Windows et celui du domaine. Ces comptes ont la particularité d’avoir un identifiant de sécurité (SID) se terminant par 500. La commande suivante permet de vous en assurer :

wmic useraccount where "SID like '%500'" get name, SID

La deuxième subtilité, introduite à partir de Windows 7, porte sur l’élévation automatique des binaires Windows. Remarquez simplement la présence du bouclier sur les consoles alors qu’il n’est pas nécessaire de confirmer l’élévation lors du lancement. (Pour que ce test soit probant il faut bien sûr le réaliser avec un administrateur équivalent, et non l’administrateur intégré).

La troisième particularité de l’UAC est de “virtualiser les échecs d’écriture” (ou plutôt “rediriger”) les tentatives de modification des zones protégées du système. Autrement dit les dossiers Windows, Program Files et le registre machine HKLM. Cela permet à une application “mal conçue”, de fonctionner sans exiger les privilèges d’administration. Ce qui se traduit par la présence d’un dossier “virtualstore” dans le dossier personnel de l’utilisateur et/ou d’une clé “virtualstore” dans sa ruche personnelle HKCU. Ce comportement peut être particulièrement déroutant, du fait qu’il va engendrer des doublons (la version originale inchangée, et une version modifiée dans le contexte de l’utilisateur). Pour éviter cela, il suffit d’octroyer les droits d’écriture sur l’élément réellement concerné, et supprimer l’instance correspondante (clé ou dossier) correspondant.

III. Démonstration

Créons et un prenons un compte local d’administration pour réaliser ce test :

net user adminlocal Pa$$w0rd /add
net localgroup Administrateurs adminlocal /add

Ouvrez une nouvelle session avec ce compte

Ensuite, pour connaitre le niveau de privilège d’un processus, il vous faut lancer le gestionnaire des taches, puis sous l’onglet “Processus” (W7/2008) ou “Détails” (W8/2012*), ajouter la colonne “Virtualisation du contrôle de compte d’utilisateur” (* Pas de menu, nécessite affichage détaillé puis un clic droit sur les entêtes de colonnes, et “sélectionner des colonnes”).

Pour l’exemple, créons un fichier “test.ini” dans le dossier “Windows”. Pour cela, exécutez une invite de commande “en tant qu’administrateur” puis acceptez la confirmation UAC.

Entrez ensuite la commande suivante :

echo “Contenu initial” > C:\windows\test.ini

Conservez cette fenêtre ouverte, puis exécutez une nouvelle invite de commande “normalement”, puis entrez la commande suivante :

echo “Modification” >> C:\windows\test.ini

Un message “accès refusé” devrait s’afficher.

Revenez sur le gestionnaire de tache, puis localisez les lignes correspondantes aux processus “cmd.exe”. Sélectionnez la ligne où la colonne “Virtualisation…” indique “Désactivé” puis effectuez un clic droit sur cette entrée afin de choisir l’option “Virtualisation du contrôle de compte d’utilisateur”.

Puis acceptez l’action en cliquant sur le bouton “Modifier la virtualisation”.

La colonne “virtualisation …” devrait maintenant afficher “Activé”

Revenez dans cette invite de commande puis rappelez la commande précédente.

echo “Modification” >> C:\windows\test.ini

Cette fois, aucune erreur n’est renvoyée et vous pourriez constater que le contenu est modifié via la commande :

type C:\windows\test.ini

Mais il n’en est rien, puisque ce même contrôle dans la première invite de commande en mode administrateur, vous affichera le contenu initial.En revanche, vous pouvez constater qu’un nouveau fichier a été créé sous “%localappdata%\VirtualStore\Windows\test.ini”.

Pour les clés de registre HKLM elles sont redirigées vers : “HKCU\Software\Classes\VirtualStore”

En résumé, la colonne “Virtualisation du contrôle de compte d’utilisateur” affiche 3 statuts.

- Non autorisé : Pour les processus “hors périmètre” UAC. Autrement dit, les processus en mode “Administrateur” avec le niveau de privilège élevé.

- Désactivé : Pour les processus “compatibles”, qui ne sont donc pas censés écrire dans les zones protégées du système

- Activé : Pour les processus concernés par la redirection des échecs d’écriture.

Pour éviter la création de ce “virtualstore”, il suffit d’octroyer les droits d’écriture aux utilisateurs concernés.

Il suffit ensuite de simplement supprimer le fichier ou la clé du virtualstore, et le tour est joué. En cas de doublons, ce sont les fichiers ou clé du Virtualstore qui prévalent (Masque).

IV. Maitrise de l’UAC

A. Contrôle du niveau de privilège

Avant l’exécution d’une commande ou d’un script, il peut ou il peut être intéressant de vérifier le niveau de privilège afin d’éviter un éventuel échec des actions. Pour l’illustration, comme dans l’exemple précédent, ouvrez 2 invites de commande, dont une en tant qu’Administrateur, puis entrez la commande suivante dans chacune d’entre elles :

whoami /groups

Vous constaterez alors 2 différences majeures (puisque les groupes sont nécessairement les mêmes 🙂 ).

- Étiquette obligatoire\Niveau obligatoire moyen : S-1-16-8192
- Étiquette obligatoire\Niveau obligatoire élevé : S-1-16-12288

Note : Vous pouvez également recourir à des outils tels que “Process Explorer” afin de contrôler le niveau de privilège UAC, cf onglet “Security” sur un processus. Vous pourrez constater sur des processus tels que “Internet Explorer” ou “Google Chrome”, le niveau obligatoire “faible”, correspondant au mode protégé du navigateur. (Cet état interdira toute écriture dans le contexte de l’utilisateur qui sera éventuellement redirigée vers locallow).

Les SID correspondant aux différents niveaux d’intégrité sont les suivants :

Voici un petit exemple, permettant de contrôler ce niveau d’exécution en mode batch :

@Echo Off
Echo Le compte actuel "%userdomain%\%USERNAME%"
whoami /groups /fo list | findstr "Admin" > nul
if %errorlevel%==0 (echo est membre d'un groupe Administrateurs) else (echo N'est pas membre d'un groupe Administrateurs)
whoami /groups|findstr S-1-16-12288 > nul
if %errorlevel%==0 (echo Et dispose d'un niveau de privileges maximum) else (echo Et dispose d'un niveau d'utilisateur standard)
Echo Ce compte est aussi membre des groupes suivants
whoami /groups /fo list | findstr "groupe:"
Pause

Sous powershell, il existe plusieurs moyens d’invoquer le niveau des privilèges au moment de l’exécution. Par exemple, vous pouvez utiliser ce genre de commande :

start-process powershell.exe -verb runAs

B. Réglages via les stratégies de groupe (GPO)

Donc, pour revenir aux réglages avancés de l’UAC, vous devrez vérifier / valider vos préférences dans une stratégie de groupe afin de cibler les ordinateurs de votre choix. Pour l’explication des paramètres, lancez l’éditeur de stratégie de groupe local “gpedit.msc” ou plus directement “secpol.msc”

Les réglages sont situés sous “Configuration Ordinateur ... Paramètres Windows ... Paramètres de sécurité ... Options de sécurité ... Contrôle compte d’utilisateur”

*L’avant dernière option concerne tous les comptes d'administrateurs "équivalents" (membres du groupe local "Administrateurs") hormis les comptes Administrateurs intégrés.

Bien que cela soit déconseillé, il est également possible de configurer l’UAC via le registre : “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System”

La clé “EnableLUA” = 0 désactive complètement l’UAC (Je vous laisse seul juge 🙂 ) après un redémarrage du poste.

Christophe Mandin Consultant - Formateur indépendant

Consultant/Formateur indépendant en quête de solutions et de moyens alliant efficacement la théorie et la pratique. Fort d’une expérience de plusieurs dizaines années dans l’informatique, j’ai pu apprécier de nombreuses problématiques, développer des qualités rédactionnelles et un esprit de synthèse, tout en me forgeant de solides fondamentaux théoriques, indispensables à toute analyse et mise en œuvre fonctionnelle. Malgré toutes ces années, je ne me lasse pas du plaisir de transmettre mes connaissances en misant sur 3 critères que sont les fondamentaux, la simplicité et le pragmatisme. Bien à vous. Retrouvez-moi sur LinkedIn : Christophe Mandin

See Full Bio