UAC expliqué : le seul niveau à ne pas utiliser

février 26, 2026 • février 26, 2026 • Lecture : 29 min • Views: 1

Cet article vous a aidé ?

Si vous avez déjà vu un serveur Windows passer de « tout va bien » à « mystérieusement hanté », il y a de bonnes chances que le Contrôle de compte d’utilisateur (UAC) y soit pour quelque chose.
Pas parce que l’UAC est mauvais. Parce que quelqu’un a « résolu » un problème d’invite en le désactivant, puis a oublié—jusqu’à ce qu’une tâche planifiée s’exécute en tant qu’administrateur et fasse quelque chose de créatif.

L’UAC est un de ces contrôles sur lesquels tout le monde a un avis, généralement formé lors d’un fiasco d’installation à 2 h du matin.
Voici le point de vue franc et orienté production : on peut débattre de la fréquence des invites toute la journée, mais il y a exactement un niveau d’UAC à ne pas utiliser : « Ne jamais notifier. »
Il supprime la rambarde tout en conservant la voiture.

L’UAC en une phrase (et pourquoi vous en avez encore besoin)

L’UAC est la façon dont Windows vous permet d’être administrateur sans exécuter tout en tant qu’administrateur en permanence.
Il le fait en vous donnant deux « identités » (jetons) : une normale pour le travail quotidien, et une élevée pour les tâches administratives—puis en forçant une transition délibérée.

Ce n’est pas théorique. La différence entre « mon utilisateur fait partie des Administrateurs » et « mon processus est élevé » détermine si un logiciel malveillant peut écrire dans des emplacements protégés, s’injecter dans des processus privilégiés ou modifier silencieusement le comportement du système.
L’UAC n’est pas parfait. C’est quand même l’un des contrôles les plus efficaces sur une flotte Windows parce qu’il change le contexte d’exécution par défaut.

Le seul niveau d’UAC à ne pas utiliser : « Ne jamais notifier »

« Ne jamais notifier » est le paramètre UAC qui fait se sentir productifs les administrateurs et fait sentir aux équipes sécurité qu’elles tiennent un sac en papier mouillé.
Ce n’est pas seulement « moins de popups ». Cela change la façon dont l’élévation fonctionne pour les administrateurs sur la machine.

Voici l’effet pratique : les administrateurs peuvent finir par exécuter plus de choses en mode élevé sans s’en rendre compte. Certaines protections UAC (notamment les invites et des parties du comportement de consentement) sont effectivement contournées.
Vous perdez un signal clé—votre propre conscience—au moment même où un processus franchit une frontière de privilège.

Si vous voulez moins d’invites, vous avez de meilleures options : utilisez le paramètre par défaut, ou—sur des flottes gérées—utilisez la stratégie pour ajuster le comportement de consentement tout en conservant la frontière de sécurité intacte.
Mais n’utilisez pas « Ne jamais notifier » comme un « correctif ». Ce n’est pas un correctif. C’est une décision d’arrêter de détecter une classe d’erreurs.

Blague n°1 : Désactiver l’UAC pour arrêter les invites, c’est comme retirer la pile du détecteur de fumée parce qu’il est « trop bruyant ». Très paisible. Bref.

Alors que devriez-vous utiliser à la place ?

Postes de travail : gardez l’UAC activé, le niveau par défaut convient généralement ; conservez Secure Desktop activé sauf si vous avez une raison solide et testée.
Serveurs : gardez l’UAC activé. Si vous avez besoin d’automatisation, utilisez des tâches planifiées/services avec des comptes explicites et le moindre privilège. Ne « résolvez » pas l’automatisation en désactivant globalement les invites.
Bastions / VDI d’administration : gardez l’UAC activé et envisagez des invites plus strictes pour les administrateurs ; traitez ces postes comme des frontières de sécurité.

Comment l’UAC fonctionne réellement (division des jetons, niveaux d’intégrité, Secure Desktop)

Jetons divisés : l’astuce centrale

Lorsqu’un utilisateur est membre du groupe local Administrators, Windows ne lui donne pas simplement une session constamment élevée.
Avec l’UAC activé, la session interactive obtient typiquement un jeton administrateur filtré pour les processus normaux et un jeton administrateur complet utilisé seulement après élévation.

En pratique cela signifie :

Explorer (et tout ce lancé normalement depuis lui) s’exécute sans privilèges administratifs.
Lorsque vous « Exécuter en tant qu’administrateur » (ou qu’un processus demande une élévation), Windows demande le consentement/les identifiants, puis lance le processus en utilisant le jeton complet.
La frontière n’est pas magique, mais elle bloque une longue liste d’opérations « oups » de se produire silencieusement.

Niveaux d’intégrité : le système de classes sociales des processus

Windows utilise le Contrôle d’intégrité obligatoire (Mandatory Integrity Control, MIC). Les processus et objets reçoivent des étiquettes d’intégrité : Low, Medium, High, System.
La plupart des processus utilisateur sont Medium. Les processus administrateurs élevés sont High. Certains processus isolés (comme d’anciens sandboxs de navigateurs) peuvent être Low.

Le point opérationnel important : même si vous avez des permissions via des ACL, le MIC peut toujours bloquer des opérations d’écriture d’objets de moindre intégrité vers des objets de plus haute intégrité.
C’est pourquoi certaines écritures de registre « ça a marché sur ma machine » échouent en contexte utilisateur standard.

Secure Desktop : pourquoi l’écran s’assombrit

Quand les invites UAC apparaissent sur le Secure Desktop, l’interface passe à un bureau séparé où d’autres processus ne peuvent pas facilement envoyer des frappes/cliques à l’invite.
Ce n’est pas du théâtre. C’est une mesure anti-shatter/anti-usurpation.

Quand des gens désactivent Secure Desktop parce que « ça scintille » en sessions à distance, ils échangent souvent une petite gêne contre une augmentation réelle du risque d’usurpation d’invite et d’automatisation de l’UI.
Si vous devez le modifier, faites-le délibérément et documentez le compromis de menace.

Virtualisation : le hack de compatibilité qui cause des bizarreries

La virtualisation UAC existe pour maintenir en vie les applications legacy (qui insistent pour écrire sous Program Files ou HKLM) sans planter sous des droits utilisateur standard.
Windows redirige silencieusement certaines écritures vers des emplacements par utilisateur comme %LOCALAPPDATA%\VirtualStore.

C’est utile, et aussi un piège de débogage. Vous pensez qu’une app écrit dans la configuration globale ; elle écrit en réalité dans une copie d’ombre par utilisateur.
Sur des serveurs, cela peut conduire à des « ça marche pour Bob, ça échoue pour Alice » qui font détester les ordinateurs à tout le monde.

Les niveaux UAC expliqués comme pour un SRE (pas comme un magicien)

Le curseur UAC dans l’UI classique de Windows correspond à plusieurs paramètres de stratégie sous-jacents. Mais en pratique, vous choisissez une posture sur deux choses :
(1) quand les administrateurs sont invités, et (2) si les invites se font sur le Secure Desktop.

Toujours notifier

Windows invite quand des applications essaient d’installer un logiciel ou de modifier le système, et aussi quand vous changez des paramètres Windows.
C’est le mode strict. Idéal pour les environnements à haut risque et les bastions d’administration.

Compromis : plus d’invites, plus de friction. Les gens tenteront de « contourner » si vous ne fournissez pas des workflows administratifs sensés.

Par défaut : Me prévenir uniquement quand des applications tentent de faire des modifications (avec Secure Desktop)

C’est le réglage « Windows suppose que des adultes existent ». Invites pour les changements système initiés par des applications ; ne harcèle pas quand vous modifiez certains paramètres vous-même.
Prompts sur Secure Desktop.

Pour la plupart des organisations, cela devrait être la base. Si vous ne savez pas quoi choisir, choisissez ceci.

Me prévenir uniquement quand des applications tentent de faire des modifications (sans Secure Desktop)

Même logique d’invite, mais sans l’isolation Secure Desktop.
Cela réduit le basculement/assombrissement du bureau, ce que certaines équipes préfèrent pour les outils à distance ou l’enregistrement d’écran.

Compromis : vous affaiblissez l’isolation de l’UI. Si vous faites cela, soyez honnête sur la raison et compensez ailleurs (contrôles endpoint plus stricts, contrôle d’applications fort, workflows admin monitorés).

Ne jamais notifier (à ne pas faire)

Sur de nombreux systèmes, cela transforme effectivement l’UAC en un artefact de compatibilité plutôt qu’en une frontière de contrôle pour les administrateurs.
Les processus administrateurs peuvent s’élever sans barrière de consentement. Vous perdez une fonction de contrainte cruciale : le moment « attendez, pourquoi ça demande l’admin ? ».

C’est le paramètre qui devrait déclencher un ticket, pas un haussement d’épaules.

Faits et historique intéressants à utiliser en revue de conception

L’UAC est arrivé avec Windows Vista comme rupture délibérée avec la culture « tout le monde est admin » qui dominait les postes Windows XP.
Les premières versions de Vista étaient volontairement bruyantes pour rééduquer éditeurs de logiciels et utilisateurs ; les versions suivantes ont ajusté les invites et la compatibilité applicative.
Les niveaux d’intégrité (MIC) ont été une addition architecturale majeure qui a permis une séparation réelle au-delà des seules ACL.
Secure Desktop existe parce que les bureaux normaux sont vulnérables aux attaques de shatter et à l’injection de messages UI ; isoler les invites réduit l’usurpation.
La virtualisation UAC a été conçue pour maintenir les apps legacy pendant la transition vers l’utilisation en utilisateur standard—utile, mais cela peut masquer une mauvaise conception d’app.
« Exécuter en tant qu’administrateur » n’est pas une permission ; c’est un événement de sélection de jeton. Même utilisateur, jeton différent, droits effectifs différents.
Être dans Administrators ne signifie pas que votre processus est élevé quand l’UAC est activé—cette incompréhension cause encore des pannes en entreprise.
Certaines composantes Windows s’élèvent automatiquement sous certaines conditions ; les environnements qui comptent sur « personne ne peut s’élever » sans invite comprennent mal ces mécanismes.
Les restrictions de l’UAC à distance peuvent changer le comportement des comptes locaux sur le réseau (filtrage de jeton), ce qui affecte les partages admin et les outils de gestion à distance.

Feuille de diagnostic rapide

Quand quelque chose « a besoin d’admin » ou « l’UAC est cassé », ne paniquez pas. Diagnostiquez dans cet ordre :

1) Confirmer la posture UAC actuelle (stratégie + réalité du curseur)

Vérifiez les valeurs de stratégie de registre clés (EnableLUA, ConsentPromptBehaviorAdmin, PromptOnSecureDesktop).
Vérifiez si la machine est jointe au domaine et reçoit des GPO qui remplacent les paramètres locaux.

2) Confirmer si le processus en échec est réellement élevé

Regardez le type d’élévation du jeton et le niveau d’intégrité pour le processus.
Si il tourne en Medium alors qu’il devrait être High, trouvez pourquoi l’élévation n’a pas eu lieu (pas de manifest, invite bloquée, shim de compatibilité applicative, hypothèses d’auto-élévation COM, etc.).

3) Déterminer quelle ressource est bloquée

Chemin de fichier : est-ce sous Program Files, Windows, ou un autre répertoire protégé ?
Ruche de registre : HKLM vs HKCU. La virtualisation est-elle en jeu ?
Contrôle de service, tâches planifiées, install de driver : cela sent toujours l’élévation.

4) Décider de la bonne voie de correction

Si c’est une action admin ponctuelle : élevez correctement, faites le changement, journalisez-le.
Si c’est de l’automatisation : migrez vers un service/tâche avec des privilèges explicites ; ne désactivez pas l’UAC pour « faire fonctionner » l’automatisation.
Si c’est un problème d’app : corrigez le packaging, les manifests et les emplacements d’écriture ; n’enseignez pas de mauvaises habitudes à votre flotte.

Tâches pratiques : 12+ vérifications avec commandes, sorties et décisions

Voici les commandes que j’utilise réellement quand quelqu’un dit « L’UAC pose problème » ou « on l’a désactivé parce que ça cassait les installations ».
Pour chaque tâche : commande, ce que la sortie signifie, et la décision à prendre.

Task 1: Check whether UAC is enabled (EnableLUA)

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name EnableLUA | Format-List"

EnableLUA : 1

Signification : 1 signifie que l’UAC est activé sur le système. 0 signifie qu’il est désactivé (et nécessite typiquement un redémarrage pour prendre effet).

Décision : Si c’est 0, enregistrez cela comme un défaut de sécurité et planifiez un changement contrôlé pour le réactiver. Attendez des changements de comportement des apps/services ; testez.

Task 2: Check admin consent prompt behavior

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name ConsentPromptBehaviorAdmin | Format-List"

ConsentPromptBehaviorAdmin : 5

Signification : Les valeurs varient selon la stratégie. Courant : 5 est « Prompt for consent for non-Windows binaries » dans de nombreuses configurations ; d’autres valeurs peuvent signifier « élever sans inviter » (mauvais), ou « demander les identifiants ».

Décision : Si les administrateurs sont configurés pour s’élever sans invite, vous avez recréé le monde pré-Vista avec des étapes en plus. Corrigez via GPO.

Task 3: Verify Secure Desktop prompting

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name PromptOnSecureDesktop | Format-List"

PromptOnSecureDesktop : 1

Signification : 1 signifie que les invites sont sur le Secure Desktop ; 0 signifie qu’elles apparaissent sur le bureau utilisateur.

Décision : Conservez à 1 sauf si vous avez une contrainte UX distante concrète et des contrôles compensatoires.

Task 4: Detect “Never notify” user experience state via slider-adjacent values

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name EnableLUA,ConsentPromptBehaviorAdmin,PromptOnSecureDesktop | Format-Table -AutoSize"

EnableLUA ConsentPromptBehaviorAdmin PromptOnSecureDesktop
--------- ------------------------- --------------------
        1                         0                    0

Signification : Cette combinaison suggère fortement un comportement « pas d’invite » pour les administrateurs (dangereux), plus pas de Secure Desktop.

Décision : Traitez comme une configuration non sûre. Planifiez une remédiation et communiquez l’impact : certaines applications legacy qui dépendaient d’élévation silencieuse vont casser—et c’est voulu.

Task 5: Determine if the machine is receiving UAC policy via domain GPO

cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Applied Group Policy Objects|The user is a part of|The computer is a part of' -Context 0,2"

Applied Group Policy Objects
-----------------------------
  Default Domain Policy
  Workstation Baseline

The computer is a part of the following security groups
-------------------------------------------------------
  DOMAIN\Domain Computers

Signification : Vous avez confirmé que des GPO de base s’appliquent. Si les paramètres locaux « ne tiennent pas », c’est généralement parce que la stratégie les rétablit.

Décision : Modifiez l’UAC via la GPO de base, pas manuellement sur une seule machine. La dérive n’est pas une stratégie.

Task 6: Check if the current shell is elevated

cr0x@server:~$ powershell -NoProfile -Command "[Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent() | ForEach-Object { $_.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) }"
True

Signification : Cela vous dit que l’utilisateur fait partie des Administrateurs, pas si le processus est élevé. Les gens confondent cela constamment.

Décision : Si des actions échouent encore, vérifiez l’élévation du jeton ensuite, pas l’appartenance au groupe.

Task 7: Check token elevation and integrity level (process context)

cr0x@server:~$ powershell -NoProfile -Command "whoami /groups | Select-String -Pattern 'Mandatory Label' -Context 0,3"

Mandatory Label\High Mandatory Level          Label            S-1-16-12288

Signification : « High Mandatory Level » indique un processus élevé. « Medium » indique non élevé. « System » indique le contexte système.

Décision : Si vous devez écrire des emplacements système et que vous êtes en Medium, élevez intentionnellement. Ne changez pas l’UAC pour correspondre à un workflow cassé.

Task 8: Confirm whether UAC virtualization is in play for legacy writes

cr0x@server:~$ powershell -NoProfile -Command "Test-Path $env:LOCALAPPDATA\VirtualStore; Get-ChildItem $env:LOCALAPPDATA\VirtualStore -ErrorAction SilentlyContinue | Select-Object -First 5 | Format-Table Name,LastWriteTime -AutoSize"

True

Name        LastWriteTime
----        -------------
Program Files  1/18/2026 2:11:49 PM
Windows        1/02/2026 9:40:10 AM

Signification : Si VirtualStore contient du contenu, quelque chose a essayé d’écrire dans des chemins protégés sans élévation et a été redirigé.

Décision : Corrigez l’app pour utiliser %ProgramData% ou une config par utilisateur sous %AppData%. Ne « résolvez » pas cela en désactivant l’UAC.

Task 9: Find recent UAC-related events

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 20 | Where-Object { $_.Message -match 'New Process Name' -and $_.Message -match 'Consent.exe|Ui0Detect|svchost.exe' } | Select-Object -First 5 | Format-Table TimeCreated,Id,ProviderName -AutoSize"

TimeCreated             Id ProviderName
-----------             -- ------------
02/05/2026 09:12:44   4688 Microsoft-Windows-Security-Auditing

Signification : L’audit de création de processus peut montrer indirectement l’activité de l’UI de consentement. Beaucoup d’environnements ne journalisent pas cela par défaut ; si vous le faites, c’est de l’or.

Décision : Si vous ne pouvez pas observer les événements d’élévation, vous naviguez à l’aveugle. Envisagez d’activer un audit approprié dans les zones admin.

Task 10: Verify remote UAC token filtering behavior for local accounts

cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name LocalAccountTokenFilterPolicy -ErrorAction SilentlyContinue | Format-List"

LocalAccountTokenFilterPolicy : 0

Signification : 0 signifie que les connexions distantes utilisant des comptes locaux obtiennent un jeton filtré (plainte courante « pourquoi je n’accède pas à admin$ à distance ?»). 1 désactive le filtrage (plus risqué).

Décision : Privilégiez les comptes de domaine avec délégation appropriée pour l’administration distante. N’arrêtez pas le filtrage largement à moins de comprendre totalement la surface d’attaque.

Task 11: Test a protected write to confirm elevation behavior

cr0x@server:~$ powershell -NoProfile -Command "New-Item -Path 'C:\Program Files\UACProbe.txt' -ItemType File -ErrorAction Stop"

New-Item : Access to the path 'C:\Program Files\UACProbe.txt' is denied.

Signification : Vous n’êtes pas élevé (ou la stratégie/ACL vous bloque). Sur un système standard, cela devrait échouer en intégrité Medium.

Décision : Si cela réussit dans une session non élevée, quelque chose ne va vraiment pas : soit vous êtes élevé sans le remarquer, soit les ACL ont été assouplies.

Task 12: Check whether a scheduled task is running with highest privileges

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask -TaskName 'NightlyMaintenance' -ErrorAction SilentlyContinue | Get-ScheduledTaskInfo | Format-List"

LastRunTime      : 02/05/2026 02:00:01
LastTaskResult   : 0
NextRunTime      : 02/06/2026 02:00:00
NumberOfMissedRuns : 0

cr0x@server:~$ powershell -NoProfile -Command "(Get-ScheduledTask -TaskName 'NightlyMaintenance').Principal | Format-List"

UserId    : DOMAIN\svc-maint
LogonType : Password
RunLevel  : Highest

Signification : La tâche s’exécute avec les privilèges les plus élevés en utilisant un compte de service. C’est un modèle d’automatisation contrôlé.

Décision : Si vous « devez désactiver l’UAC pour l’automatisation », voici votre modèle de remplacement : principal explicite, moindre privilège, exécution planifiée et traçable.

Task 13: Find which process is failing due to access denied (quick file ACL reality check)

cr0x@server:~$ powershell -NoProfile -Command "icacls 'C:\Program Files' | Select-Object -First 5"
C:\Program Files NT SERVICE\TrustedInstaller:(F)
                 NT SERVICE\TrustedInstaller:(CI)(IO)(F)
                 NT AUTHORITY\SYSTEM:(F)
                 NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
                 BUILTIN\Administrators:(F)

Signification : Les ACL par défaut incluent le contrôle total pour Administrators, mais seulement quand le processus est élevé pour utiliser le jeton administrateur complet. En Medium, vous êtes toujours bloqué par le filtrage de jeton et les règles d’intégrité de l’UAC.

Décision : Ne « réglez » pas un accès refusé en affaiblissant les ACL sur des répertoires système. Corrigez le contexte d’exécution et le comportement de l’app.

Task 14: Check installer behavior: does it request elevation (manifest hint)

cr0x@server:~$ powershell -NoProfile -Command "$p='C:\Temp\legacy-installer.exe'; (Get-Item $p).VersionInfo | Format-List FileDescription,ProductVersion"

FileDescription : Legacy Setup Bootstrapper
ProductVersion  : 3.2.1.0

Signification : Les informations de version ne prouvent pas les paramètres de manifest, mais aident à identifier le binaire exact et le packaging. Les patterns de bootstrapper legacy échouent souvent à déclencher une élévation correcte.

Décision : Si les installations sont instables, reconditionnez avec un installateur moderne qui déclare les privilèges requis, ou déployez via un outil de distribution qui s’exécute élevé par conception.

Trois mini-histoires d’entreprise (ce qui a mal tourné, ce qui a été corrigé)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne disposait d’un cluster de services de fichiers Windows et d’une poignée de « scripts de maintenance » qui faisaient pivoter les logs, nettoyaient les répertoires temporaires et patchaient quelques configs applicatives.
Les scripts étaient lancés par un utilisateur admin qui, bien sûr, faisait partie du groupe Administrators. Tout le monde jurait : « C’est un script admin. Il s’exécute en admin. »

Sauf que non. Il s’exécutait en intégrité Medium, parce qu’il avait été démarré depuis une fenêtre PowerShell non élevée.
La plupart du temps le script « fonctionnait » car il ne touchait que des emplacements modifiables par l’utilisateur. Une fois par semaine il mettait aussi à jour une config sous ProgramData et redémarrait un service.
Ces étapes échouaient silencieusement parce que la gestion d’erreur était… optimiste.

Le redémarrage du service n’a pas eu lieu, donc l’application a continué à tourner avec une config périmée. La config périmée pointait les logs vers un chemin sur un volume presque plein.
Pendant la nuit, la croissance des logs a rempli le disque. Au matin, des services non reliés ont commencé à échouer—les bases de données ne pouvaient plus écrire de fichiers temporaires, Windows Update a stagné, et les connexions RDP sont devenues instables.

L’examen post-incident a été douloureux parce que tout le monde jurait que « le script a des droits admin ». La correction a été simple : exécuter l’automatisation en tant que tâche planifiée avec les privilèges les plus élevés sous un compte de service contrôlé, et faire en sorte que le script échoue vite en cas d’accès refusé.
L’UAC n’était pas le méchant. L’hypothèse l’était.

Mini-histoire 2 : L’« optimisation » qui s’est retournée contre eux

Une autre organisation avait une pipeline d’image golden pour les postes développeurs. Quelqu’un en a eu assez des invites UAC lors des installations d’outils, donc l’image a été construite avec l’UAC réglé sur « Ne jamais notifier ».
La justification sonnait raisonnable : « On utilise déjà un endpoint protection, et les développeurs ont besoin de rapidité. »

En quelques semaines, le support a commencé à voir un motif étrange : les développeurs lançaient un installateur, « ça marchait », mais plus tard leurs environnements se comportaient de façon incohérente.
Certains outils ont été installés au niveau machine alors qu’ils auraient dû être par utilisateur. Certains devs avaient des entrées PATH écrites globalement par des installateurs aléatoires. Quelques machines avaient des paramètres proxy système modifiés par des extensions de navigateur « utiles ».

Le vrai coût est apparu dans le temps d’incident. Quand une machine se comportait mal, l’équipe ne pouvait pas dire quelles modifications étaient des actions admin intentionnelles et lesquelles étaient des élévations involontaires.
La trace locale d’audit était mince, et la boucle de rétroaction humaine avait disparu. Avec les invites coupées, les gens ne remarquaient pas que des frontières de privilège étaient franchies. Tout semblait normal jusqu’à ce que ça ne le soit plus.

Le rollback a été chaotique : réactiver l’UAC, corriger l’image, puis nettoyer la flotte progressivement parce que certains logiciels s’étaient installés dans des contextes système et n’aimaient pas être « dé-adminés ».
La leçon : supprimer la friction sans changer le workflow déplace généralement la friction dans la réponse aux incidents.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe de services financiers gérait un petit ensemble de bastions admin Windows. Rien d’extraordinaire : baseline durcie, patching agressif, et politiques strictes.
Une politique était non négociable : l’UAC reste activé, Secure Desktop reste activé, et les administrateurs utilisent des comptes séparés pour les actions admin.
C’était, selon tous les critères, ennuyeux.

Puis un outil fournisseur est arrivé. Le fournisseur insistait pour que leur mise à jour nécessite l’admin local et recommandait de désactiver l’UAC « pour éviter des problèmes ».
L’équipe a refusé. Au lieu de cela, ils ont exécuté le mise à jour via une tâche planifiée créée pour la fenêtre de maintenance, sous un compte de service dédié disposant juste des droits nécessaires pour les répertoires et services de l’outil.
L’outil s’est mis à jour correctement.

Des mois plus tard, un développeur a accidentellement lancé un binaire de test venu d’une pièce jointe sur un bastion (oui, les politiques ont été mises à jour après).
Le binaire a tenté de modifier des paramètres système et d’installer de la persistance. L’UAC a généré une invite. Secure Desktop est intervenu. L’administrateur a fait une pause, a réalisé que quelque chose clochait, et a arrêté.
Cette seule invite a empêché une semaine de « réimager la couche admin ».

Le compte-rendu post-incident était simple : la baseline ennuyeuse a créé un moment de friction exactement au bon endroit, et l’équipe disposait d’un chemin d’automatisation sûr qui n’exigeait pas d’affaiblir tout le système.

Erreurs courantes : symptômes → cause racine → correction

1) « Je suis admin mais j’ai Accès refusé »

Symptôme : Les commandes échouent à écrire sous C:\Windows, C:\Program Files, ou HKLM. Le contrôle de service échoue. L’installateur ne peut pas enregistrer des composants.

Cause racine : L’utilisateur fait partie des Administrators, mais le processus n’est pas élevé (intégrité Medium). L’UAC fait son travail.

Correction : Lancez un shell élevé (« Exécuter en tant qu’administrateur »), ou utilisez une tâche planifiée/service pour l’automatisation. Ajoutez une gestion d’erreur explicite pour les échecs de permission.

2) « Les invites UAC n’apparaissent jamais »

Symptôme : Les demandes d’élévation échouent silencieusement, ou les actions s’exécutent élevées sans invite.

Cause racine : Configuration « Ne jamais notifier », ou stratégie réglée pour auto-éléver les admins ; parfois Secure Desktop désactivé combiné à des problèmes d’UI en sessions distantes.

Correction : Vérifiez EnableLUA et les politiques de prompt de consentement ; réactivez les invites via GPO. Si l’UX distante est le problème, conservez les invites mais évaluez soigneusement Secure Desktop.

3) « Ma config d’app disparaît ou diffère selon l’utilisateur »

Symptôme : L’app se comporte différemment selon qui l’a lancée. Les fichiers de config sous Program Files ne correspondent pas à ce que vous avez modifié.

Cause racine : La virtualisation UAC a redirigé les écritures vers VirtualStore, créant une config d’ombre par utilisateur.

Correction : Éliminez les écritures vers des chemins protégés. Déplacez la config machine-wide vers %ProgramData% pour les paramètres globaux, ou vers %AppData% pour l’utilisateur. Nettoyez prudemment les artefacts VirtualStore.

4) « Les partages admin et outils distants échouent pour les comptes admin locaux »

Symptôme : Accès à \\host\admin$ échoue, le registre/service distant échoue lorsque vous utilisez un compte admin local.

Cause racine : Filtrage de jeton UAC à distance (comportement par défaut de LocalAccountTokenFilterPolicy).

Correction : Utilisez des comptes de domaine, des patterns Just Enough Administration, ou un outillage de gestion distante adapté. Évitez de désactiver largement le filtrage de jetons.

5) « Nous avons désactivé l’UAC parce qu’un installateur en avait besoin »

Symptôme : Le fournisseur dit « désactivez l’UAC ». L’installation fonctionne après, mais la flotte devient incohérente et plus difficile à sécuriser.

Cause racine : Hypothèses d’installateur cassé et absence d’un chemin d’élévation contrôlé.

Correction : Reconditionnez / déployez via un outil d’installation d’entreprise ; exécutez l’installateur élevé de manière contrôlée ; exigez du fournisseur un support pour la compatibilité en utilisateur standard.

6) « Les invites sont trop fréquentes ; les utilisateurs cliquent oui automatiquement »

Symptôme : Fatigue des invites. Les utilisateurs approuvent l’élévation de façon réflexe.

Cause racine : Mauvaise hygiène logicielle (trop d’installateurs/mises à jour), absence de déploiement centralisé, ou forcer des workflows admin dans des workflows utilisateurs.

Correction : Réduisez les installations ad hoc via une distribution logicielle gérée, retirez l’admin local quand c’est possible, et réservez l’élévation pour des frontières significatives. Le réglage des invites est secondaire.

Listes de contrôle / plan étape par étape

Checklist A: If you find “Never notify” on a production system

Confirmer que c’est réel : vérifier EnableLUA et les valeurs de politique de prompt de consentement (Tâches 1–4).
Identifier pourquoi cela est arrivé : était-ce une baseline, un correctif « temporaire », ou une instruction fournisseur ?
Inventorier les workflows affectés : installateurs, scripts admin, tâches planifiées, outils de gestion distante.
Tester la réactivation de l’UAC sur un clone de staging : valider les apps critiques et les outils admin.
Mettre en place un chemin d’élévation contrôlé : tâches/services planifiés avec comptes dédiés ; supprimer les patterns « lancer depuis l’Explorateur » pour admin.
Déployer via GPO/état désiré : ne modifiez pas manuellement. Suivez la conformité.
Documenter le changement de comportement : ce qui va maintenant générer une invite, et ce que les utilisateurs doivent faire.

Checklist B: Building an admin-safe automation model (no UAC hacks)

Créer un compte de service dédié par domaine d’automatisation (patching, rotation des logs, sauvegardes), pas un compte « dieu » partagé.
Accorder des droits spécifiques : contrôle de service pour des services nommés, accès en écriture à des répertoires définis, permissions de registre uniquement où nécessaire.
Exécuter l’automatisation en tant que tâches planifiées avec RunLevel=Highest et déclencheurs explicites.
Faire échouer rapidement les scripts en cas d’accès refusé et journaliser vers un sink central.
Séparer les actions admin interactives de l’automatisation ; ne réutilisez pas le même contexte d’identifiants.

Checklist C: When an app “requires admin”

Identifier ce à quoi elle écrit (fichiers/registre/services/drivers).
Si elle écrit dans des emplacements protégés, décider : doit-ce être machine-wide ou par utilisateur ?
Déplacer la config machine-wide vers %ProgramData% et la config par utilisateur vers %AppData%.
Vérifier que l’installateur déclare correctement les exigences d’élévation (packaging moderne).
Déployer via un outillage géré ; cessez de traiter les laptops comme des objets artisanaux uniques.

Blague n°2 : « Ne jamais notifier » est le mode ‘YOLO’ de l’administration Windows. Ça marche jusqu’au moment où il faut l’expliquer.

FAQ

1) L’UAC est-il la même chose que « être admin » ?

Non. Faire partie du groupe Administrators signifie que vous pouvez obtenir un jeton élevé. L’UAC décide si votre processus actuel l’utilise réellement.
La plupart des problèmes admin viennent de la confusion entre « je suis admin » et « ce processus est élevé ».

2) Pourquoi « Ne jamais notifier » est-il pire que de simples popups ennuyeux ?

Parce que les invites sont la surface de contrôle : elles forcet une transition explicite de privilèges. Supprimez l’invite et vous supprimez la chance pour l’utilisateur de détecter une élévation accidentelle.
Cela encourage aussi les logiciels négligents à rester négligents.

3) Désactiver l’UAC améliore-t-il les performances ?

Pas de manière significative et mesurable pour des charges réelles. Cela peut réduire quelques transitions d’UI, mais si c’est votre goulot :
vous avez des problèmes plus importants—comme exécuter des installateurs dans vos tests de performance.

4) Puis-je garder l’UAC activé mais réduire les invites ?

Oui. Utilisez la stratégie pour ajuster le comportement de consentement, et concentrez-vous sur la réduction des installations ad hoc et des applications nécessitant l’admin.
La meilleure façon de réduire les invites est d’arrêter de faire des actions qui méritent une invite toute la journée.

5) Pourquoi les invites UAC n’apparaissent-elles parfois pas en RDP ?

Secure Desktop bascule sur un bureau séparé ; certaines configurations de session distante, pilotes graphiques ou outils peuvent donner l’impression que la session a gelé.
Diagnostiquez en vérifiant les valeurs de stratégie et en testant avec une configuration RDP connue comme correcte. Ne « réglez » pas cela en désactivant l’UAC globalement.

6) C’est quoi VirtualStore ? Est-ce un malware ?

C’est une fonctionnalité de compatibilité. Windows redirige certaines écritures d’apps legacy pour qu’elles ne plantent pas en mode utilisateur standard.
Cela devient un problème quand vous croyez modifier la configuration machine-wide alors que vous modifiez une copie d’ombre par utilisateur.

7) Les serveurs doivent-ils avoir des réglages UAC différents des postes de bureau ?

Les serveurs doivent garder l’UAC activé. La différence est opérationnelle : moins de sessions interactives, plus d’automatisation.
Résolvez le travail admin serveur avec des tâches/services explicites et le moindre privilège, pas en « désactivant les invites pour que les scripts fonctionnent ».

8) Si je mets EnableLUA à 0 et que je redémarre, qu’est-ce qui casse ?

Certaines frontières de sécurité et hypothèses applicatives changent. Vous pouvez voir des comportements inattendus dans des apps modernes, outils de gestion et tout ce qui suppose le filtrage de jeton standard.
Traitez cela comme un changement de configuration majeur, pas un réglage.

9) Est-il acceptable de désactiver Secure Desktop tout en gardant les invites UAC ?

Parfois, mais c’est un compromis conscient. Vous réduisez l’isolation autour de l’UI d’invite, ce qui peut augmenter le risque d’usurpation ou de manipulation de l’UI.
Ne le faites que lorsque vous avez validé le modèle de menace et les contraintes opérationnelles, et standardisé la configuration.

10) Quel est le modèle d’entreprise le plus fiable pour le travail admin sans chaos d’invites ?

Comptes admin séparés, bastions durcis, UAC activé, et automatisation contrôlée via tâches planifiées/services utilisant des comptes de service dédiés.
Aussi : réduisez l’appartenance à l’admin local. L’UAC n’est pas un remplacement du principe du moindre privilège.

Prochaines étapes qui ne vous déclencheront pas d’alerte

L’UAC n’est pas là pour vous rendre la vie misérable. Il existe pour rendre les transitions de privilèges explicites et plus difficiles à falsifier.
Le seul niveau que vous ne devriez pas utiliser—parce qu’il supprime cette explicitation—est « Ne jamais notifier ».

Faites ceci ensuite, dans l’ordre :

Auditez votre flotte pour EnableLUA=0 et les politiques de consentement qui auto-élèvent les admins. Corrigez la dérive via la politique de base.
Standardisez les workflows admin : élevez intentionnellement, et transférez l’automatisation vers des tâches planifiées/services avec des principals explicites.
Tuez les patterns d’écriture legacy : empêchez les apps d’écrire sous Program Files et HKLM pour des réglages utilisateur. VirtualStore est votre indice.
Gardez Secure Desktop activé sauf si vous avez une raison opérationnelle testée et documentée de le changer.
Mesurez le temps d’incident après avoir renforcé : la friction des invites est visible ; la friction d’incident est coûteuse. Choisissez la douleur la moins chère.

Une idée paraphrasée qui vaut la peine d’être gardée sur un post-it, attribuée à Richard Cook : idée paraphrasée : les systèmes réussissent au jour le jour parce que les gens s’adaptent et compensent continuellement.
L’UAC est un outil qui soutient cette adaptation en forçant une pause. Ne supprimez pas la pause. Corrigez le workflow.