Depuis juillet 2024, de nombreuses organisations voient l’installateur de Windows 11 refuser de démarrer avec un message sur les autorisations. Voici une méthode fiable pour identifier la GPO fautive et corriger durablement l’erreur.
Symptômes et contexte
Au lancement de setup.exe depuis une image ISO, un dossier extrait ou une clé USB (Windows 11 23H2 et versions antérieures), l’exécution échoue immédiatement avec :
This user does not have the required permissions to run Setup. Please run Setup elevated or with a different user that has the required permissions.
Le message apparaît même si vous :
- utilisez un compte membre du groupe Administrateurs (local ou domaine) ;
- exécutez setup.exe via Exécuter en tant qu’administrateur ou depuis un processus élevé ;
- changez de source d’installation (ISO officielle montée, extraction locale, support Media Creation Tool) ;
- créez un nouvel administrateur local ;
- dépassez les contrôles habituels (désactivation temporaire antivirus, politiques Windows Installer, etc.).
Le symptôme disparaît dès que la machine est retirée du domaine, ce qui oriente vers une stratégie de groupe (GPO) comme cause racine.
Cause racine confirmée
Dans les environnements touchés, une GPO modifie l’attribution du droit utilisateur Gérer l’audit et le journal de sécurité (Manage auditing and security log / identifiant interne SeSecurityPrivilege) et retire le groupe « Administrateurs ».
Or, pendant ses pré‑vérifications, l’installateur de Windows requiert SeSecurityPrivilege pour interroger et écrire des informations d’état dans les journaux d’événements, dont le journal Sécurité. Sans ce droit, il s’arrête immédiatement et affiche l’erreur ci‑dessus.
Procédure de correction (GUI)
- Ouvrir la gestion des stratégies de groupe
Sur une console d’administration : lancezgpmc.msc(Gestion des stratégies de groupe). Éditez la GPO appliquée aux postes concernés (OU des postes, ou GPO de durcissement sécurité). - Localiser l’attribution de droits
Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Attribution des droits utilisateur. - Ouvrir « Gérer l’audit et le journal de sécurité » (
SeSecurityPrivilege) et réintroduire « Administrateurs » (groupe local intégré).
Remarque : n’ajoutez aucun groupe non privilégié (pas d’« Utilisateurs », « Domain Users », etc.). Limitez‑vous aux groupes légitimes (Administrateurs, éventuellement Opérateurs de sécurité selon vos standards). - Appliquer et propager
Forcez la mise à jour de la stratégie sur un poste de test :
gpupdate /force
ou redémarrez. Rejouez setup.exe : l’installeur démarre désormais normalement pour tout compte membre d’Administrateurs.
Procédure alternative (ligne de commande, poste isolé)
Si vous devez rétablir SeSecurityPrivilege en local (p. ex. hors domaine pour valider l’hypothèse), vous pouvez utiliser un modèle de sécurité (INF) avec secedit.
- Créez
C:\Temp\restore-SeSecurity.infavec le contenu :
[Version]
signature="$CHICAGO$"
[Privilege Rights]
; S-1-5-32-544 = BUILTIN\Administrators
SeSecurityPrivilege = *S-1-5-32-544 - Appliquez le modèle et rechargez les droits :
secedit /configure /db C:\Windows\security\local.sdb ^
/cfg C:\Temp\restore-SeSecurity.inf /areas USER_RIGHTS
gpupdate /force Important : si une GPO de domaine réécrit l’attribution, la prochaine actualisation revertira la modification locale. Utilisez cette méthode seulement pour diagnostiquer ou contourner temporairement.
Vérifier rapidement le diagnostic
| Test | Commande / Action | Attendu si GPO fautive |
|---|---|---|
| Résultat de stratégie | gpresult /r /scope computer | La GPO de durcissement est appliquée à l’ordinateur. |
| RSOP | rsop.msc → Attribution des droits utilisateur | « Gérer l’audit et le journal de sécurité » ne contient pas « Administrateurs ». |
| Export des droits | secedit /export /cfg C:\Temp\secpol.inf | La ligne SeSecurityPrivilege = manque *S-1-5-32-544. |
| Vérifier vos privilèges | whoami /priv | SeSecurityPrivilege absent pour le jeton courant, malgré l’appartenance à Administrateurs. |
| Test hors domaine | Retirer temporairement du domaine (ou déplacer dans une OU sans GPO) | setup.exe démarre sans erreur → confirme l’origine GPO. |
Pourquoi l’élévation UAC ne suffit pas ?
L’élévation UAC octroie un jeton d’administrateur, mais n’ajoute pas des privilèges révoqués au niveau système par une GPO. Si SeSecurityPrivilege est explicitement retiré aux Administrateurs via l’attribution de droits, aucune élévation ne peut combler ce manque.
Détails techniques utiles
- À quoi sert SeSecurityPrivilege ? Il permet de gérer l’audit et le journal Sécurité : lecture de certaines entrées protégées, écriture/suppression, et paramétrage. Windows Setup s’en sert durant ses vérifications et la journalisation de l’état d’installation.
- Pourquoi le problème est apparu « soudainement » en 2024 ? Nombre d’équipes ont mis en place (ou durci) des GPO de sécurité globales ; un modèle « strict » peut avoir écrasé le jeu par défaut et retiré Administrateurs de SeSecurityPrivilege.
- Logs : quand l’erreur se produit très tôt, les journaux d’installation (
setupact.log,setuperr.log) dansC:\$WINDOWS.~BT\Sources\Pantherpeuvent être absents ou laconiques puisque l’installeur s’arrête avant la création complète des traces.
Matrice de dépannage (symptômes → décision → action)
| Observation | Interprétation | Action recommandée |
|---|---|---|
| setup.exe échoue même en « Exécuter en tant qu’administrateur » | Privilège requis manquant au jeton admin | Vérifier SeSecurityPrivilege dans l’attribution de droits |
| Fonctionne hors domaine | Origine GPO quasi certaine | Identifier la GPO affectant l’OU poste via gpresult et rsop.msc |
| UAC, Antivirus, MCT, ISO : sans effet | Pistes « environnement runtime » non pertinentes | Concentrez l’analyse sur GPO de sécurité / modèles INF |
| Compte admin local neuf : même erreur | Attribution des droits s’applique au niveau machine | Corriger la GPO, pas le compte |
Automatiser la remédiation
Option A — Remise en conformité via GPO
- Dans la GPO de durcissement, rétablissez SeSecurityPrivilege en y ajoutant Administrateurs.
- Limitez la portée (liaisons de sécurité) à l’OU adéquate. Évitez les liaisons au niveau domaine entier si l’intention est de viser uniquement des serveurs spécifiques.
- Appliquez un filtre WMI si nécessaire (ex. cibler seulement des versions de Windows Server).
Option B — Correctif ponctuel par script (postes pilotes)
REM Rétablit SeSecurityPrivilege pour Administrateurs (local)
@echo off
set "INF=%TEMP%\restore-SeSecurity.inf"
> "%INF%" echo [Version]
>> "%INF%" echo signature="$CHICAGO$"
>> "%INF%" echo [Privilege Rights]
>> "%INF%" echo SeSecurityPrivilege = *S-1-5-32-544
secedit /configure /db C:\Windows\security\local.sdb /cfg "%INF%" /areas USER_RIGHTS
gpupdate /force
Ce script sert à valider la solution sur un échantillon avant d’opérer la GPO.
Bonnes pratiques de prévention
- Documenter toute modification GPO et sauvegarder l’état précédent (sauvegarde GPO, script de configuration).
- Surveiller les privilèges critiques : SeSecurityPrivilege, SeBackupPrivilege, SeRestorePrivilege, etc., lors des durcissements.
- Tester les ISO/Upgrades hors domaine avant diffusion : isolez l’ISO du facteur GPO pour distinguer un support corrompu d’une politique perturbatrice.
- Séparer les cibles : utilisez filtres WMI, ciblage par groupe de sécurité et liaisons d’OU adaptées. Évitez qu’une GPO « serveur » s’applique aux postes clients qui doivent exécuter
setup.exe. - Contrôle de conformité : intégrez l’attribution de droits dans vos baselines (CIS/benchmarks internes) et auditez la présence d’Administrateurs sur SeSecurityPrivilege pour les postes membres.
- Change freeze pendant les campagnes d’upgrade : stabilisez les GPO le temps des déploiements in‑place.
FAQ et cas particuliers
Est‑il acceptable d’ajouter « Opérateurs de sécurité » ?
Selon votre politique, oui ; mais ce n’est pas nécessaire pour corriger le lancement de setup.exe. L’essentiel est que Administrateurs figure bien dans SeSecurityPrivilege sur les postes.
Et si je ne peux pas modifier la GPO centrale ?
- Créez une GPO correctrice plus proche de l’OU des postes (liée avec une priorité supérieure) qui définit l’attribution de droits avec Administrateurs.
- À défaut, déplacez temporairement les machines dans une OU d’exception le temps de l’upgrade, puis réappliquez la politique finale.
Le retrait du domaine est‑il sûr ?
Comme test de validation, oui, à condition de respecter vos procédures et d’utiliser un poste pilote. En production, préférez corriger la GPO.
Puis‑je contourner avec un compte « Système » ?
Exécuter l’installateur sous Local System (via planificateur ou outil tiers) peut démarrer, mais c’est non recommandé : complexifie le support, biaise les journaux et dévie des prérequis officiels. Corrigez plutôt l’attribution des droits.
Antivirus/EDR et UAC sont‑ils en cause ?
Dans les cas observés, ces composants n’étaient pas la cause. La suppression d’Administrateurs de SeSecurityPrivilege suffit à expliquer l’arrêt précoce de setup.exe.
Checklist de remédiation
| Étape | Action | Critère de succès |
|---|---|---|
| Identifier | gpresult, rsop.msc pour lister les GPO appliquées | GPO candidate localisée |
| Confirmer | Vérifier SeSecurityPrivilege dans l’attribution des droits | « Administrateurs » manquant confirmé |
| Corriger | Ajouter « Administrateurs » dans la GPO | GPO sauvegardée et publiée |
| Propager | gpupdate /force ou redémarrage | Poste reçoit la nouvelle stratégie |
| Valider | Relancer setup.exe et contrôler l’absence d’erreur | Installateur démarre, journaux se créent |
| Prévenir | Filtrage WMI / liaisons ciblées, documentation, baseline | Risque de régression réduit |
Encadré sécurité
- Surface d’attaque : SeSecurityPrivilege doit rester limité à des rôles d’administration. Ne jamais l’ouvrir à des groupes génériques.
- Traçabilité : ajustez les cas d’alerte SOC (lecture/effacement du journal Sécurité) si vos workflows d’upgrade déclenchent des événements supplémentaires.
- Conformité : consignez la décision de design dans votre référentiel (CAB/Change) avec justification et fenêtre de déploiement.
Annexe A — Chemins, noms et identifiants
| Élément | Valeur |
|---|---|
| Nom de stratégie (FR) | Gérer l’audit et le journal de sécurité |
| Nom de stratégie (EN) | Manage auditing and security log |
| Identifiant interne | SeSecurityPrivilege |
| SID Administrateurs | S-1-5-32-544 |
| Chemin GPO | Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Stratégies locales → Attribution des droits utilisateur |
| Outils de vérif | gpresult, rsop.msc, secedit, whoami /priv |
Annexe B — Modèle INF minimal (référence)
; Rétablir SeSecurityPrivilege pour Administrateurs
[Version]
signature="$CHICAGO$"
[Privilege Rights]
SeSecurityPrivilege = *S-1-5-32-544 Conclusion
Si setup.exe refuse de démarrer avec « This user does not have the required permissions to run Setup », considérez en priorité une mauvaise attribution de droits liée à SeSecurityPrivilege. Rétablir le groupe Administrateurs dans « Gérer l’audit et le journal de sécurité », propager la GPO puis relancer l’installateur résout durablement le blocage. En complément, des tests hors domaine, une documentation claire des GPO et un ciblage précis (WMI, sécurité, OU) évitent les régressions lors des futures vagues d’upgrade Windows 11.