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.

logo-design50En 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”).

UAC-1

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.

Exemple UAC Windows

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”.

UAC-4

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

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.

UAC-6

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 :

Étiquette obligatoire\Niveau obligatoire SID de niveau d’intégrité Typiquement
Niveau faible (low) S-1-16-4096 mode protégé d’un navigateur
Niveau moyen (medium) S-1-16-8192 utilisateur standard
Niveau élevé (high) S-1-16-12288 administrateur
Niveau système (system) S-1-16-16384 OS ou machine

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

Paramètre = Contrôle de compte d’utilisateur Valeur par défaut
Mode Approbation administrateur pour le compte Administrateur intégré Désactivé
Passer au Bureau sécurisé lors d’une demande d’élévation Activé
Autoriser les applications UIAccess à demander l’élévation sans utiliser le bureau sécurisé Désactivé
Comportement de l’invite d’élévation pour les  administrateurs en mode d'approbation Administrateur Demande de consentement
Comportement de l’invite d’élévation pour les utilisateurs standard Demande d’informations d’identification
Détecter les installations d'applications et demander l'élévation Activé
Élever uniquement les applications UIAccess installées à des emplacements sécurisés Activé
Élever uniquement les exécutables signés et validés Désactivé
Exécuter les comptes d'administrateurs* en mode d'approbation d'administrateur Activé
Virtualiser les échecs d’écriture des fichiers et de Registre dans des emplacements définis par utilisateur Activé

*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.

Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Partager sur Google+ Envoyer par mail

Christophe Mandin

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

Nombre de posts de cet auteur : 32.Voir tous les posts

2 thoughts on “UAC – Le contrôle de compte d’utilisateur

  • Est-il possible de forcer de façon permanente l’activation de la virtualisation à fin que le logiciel en question n’écrive que dans virtualstore ?

    mais comme vous le dite apparemment des qu’il la fait une fois il reste sur le virtualstore, mais cela même pour d’autre fichier que celui crée ?

    Merci

    Répondre
  • salut j’espère que vous êtes bien , est ce que il y a un méthode pour refuser exécutions des programme portables avec des unité d’organisations ( server 2012 r2 ) et merci

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.