Besoin d’autoriser l’installation/désinstallation de logiciels sur un serveur Windows Server 2019/2022 sans permettre la création ou la modification de comptes ? Voici une méthode opérationnelle, sécurisée et reproductible, basée sur GPO, AppLocker, ACL et, en option, JEA.
Vue d’ensemble de la question
Objectif : permettre à un groupe d’utilisateurs de réaliser des opérations « opérationnelles » (installer/désinstaller des applications, modifier quelques réglages nécessaires au support) tout en leur interdisant strictement la gestion des comptes (création, modification, suppression) et l’accès aux consoles associées.
Réponse & solution (résumé)
| Étape | Actions clés | Effet recherché |
|---|---|---|
| 1. Créer un compte ou un groupe dédié | – Dans Active Directory (ou localement via lusrmgr.msc si le serveur n’est pas joint au domaine), créer un compte ou, mieux, un groupe de sécurité pour ces utilisateurs. – Ajouter les personnes concernées à ce groupe. | Base propre pour attribuer des droits granulaires. |
| 2. Éviter tout rôle d’administrateur | – Ne pas placer le compte/le groupe dans Administrateurs locaux, Domain Admins ou tout autre groupe à privilèges étendus. – Le groupe « Power Users » n’apporte plus de privilèges pertinents ; préférez un groupe personnalisé. | Empêche nativement la création et la gestion d’autres comptes. |
| 3. Déléguer les droits d’installation | – Ouvrir secpol.msc → Stratégies locales > Attribution des droits utilisateur et, si nécessaire, accorder au groupe : • « Charger et décharger des pilotes de périphérique » (cas d’installations de pilotes). • « Remplacer un jeton de niveau processus » (quelques installateurs legacy). – Dans une GPO ou la stratégie locale, activer : Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle d’accès applicatif et autoriser l’exécution de msiexec.exe et des installateurs signés/chemins approuvés via AppLocker (ou SRP). – Pour les applications nécessitant des ACL sur des dossiers (ex. C:\Program Files\MonApp) ou des clés de Registre dédiées, accorder des droits Modify/contrôle total sur ces périmètres uniquement. | Les membres du groupe peuvent installer la majorité des logiciels sans être administrateurs globaux. |
| 4. Bloquer les outils de gestion des comptes | – Dans la même GPO, masquer/interdire les consoles MMC sensibles : dsa.msc (ADUC), lusrmgr.msc, compmgmt.msc. – Avec AppLocker ou la stratégie de restriction logicielle, interdire mmc.exe, net.exe, net1.exe et limiter powershell.exe en mode interactif si nécessaire. – Vérifier que le groupe n’a pas d’autres droits sensibles (« Ajouter une station de travail au domaine », « Gérer les quotas », etc.). | Supprime toute capacité pratique à créer ou modifier des comptes, même si l’utilisateur trouve une console. |
| 5. Tester et ajuster | – Se connecter avec un compte du groupe sur un serveur de test. – Essayer d’installer/désinstaller un logiciel (.msi, .exe, MSIX). – Tenter d’ouvrir ADUC/lusrmgr/ajout de compte : l’opération doit être refusée. – Ajuster la GPO et réappliquer (gpupdate /force). | Validation avant production. |
Périmètre, prérequis et bonnes pratiques
- Type de serveur : ciblez des membres Windows Server 2019/2022. Évitez cette délégation sur un contrôleur de domaine (modèle d’administration différent, risques élevés).
- Approche « moindre privilège » : seul un groupe reçoit la délégation, jamais un compte isolé. Appliquez des GPO filtrées par sécurité et (idéalement) par WMI filter OS.
- UAC activé : ne réduisez pas le niveau UAC. On autorise des processus précis, pas des droits globaux.
- Pas d’« AlwaysInstallElevated » : n’activez pas ce paramètre MSI (très dangereux, élève n’importe quel .msi au niveau système).
Étapes détaillées de mise en œuvre
Créer le groupe dédié et ajouter les utilisateurs
Dans Active Directory, créez par exemple GRP‑OPS‑Logiciels‑SRV (sécurité, global). Ajoutez-y les utilisateurs habilités. Sur un serveur autonome non joint au domaine, créez un groupe local via lusrmgr.msc.
# Domaine (exemples)
New-ADGroup -Name "GRP-OPS-Logiciels-SRV" -GroupCategory Security -GroupScope Global -Path "OU=Groupes,DC=exemple,DC=local"
Add-ADGroupMember -Identity "GRP-OPS-Logiciels-SRV" -Members user1,user2
# Local (serveur non joint)
New-LocalGroup -Name "G_OpLogiciels"
Add-LocalGroupMember -Group "G_OpLogiciels" -Member "SERVEUR\User1"
Éviter toute appartenance à des groupes admins
Assurez-vous que le groupe n’est membre ni d’Administrateurs (local/domain), ni d’Opérateurs de compte, ni d’Opérateurs de serveur. Vérifiez avec :
whoami /groups
net localgroup Administrateurs
Autoriser l’installation de logiciels sans élever l’utilisateur
3A — Autoriser l’exécution d’installateurs approuvés (AppLocker conseillé)
- Créez une GPO « Délégation Installation Logiciels » liée à l’OU des serveurs concernés.
- Dans Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de contrôle d’accès applicatif > AppLocker :
- Activez les règles exécutables, MSI et scripts.
- Créez des règles Publisher (éditeur et certificat) autorisant msiexec.exe, les setup.exe signés par vos éditeurs et, si besoin, des chemins approuvés (ex.
C:\Installers). - Positionnez AppLocker en mode Appliquer pour le groupe cible, et en mode Audit pour une phase d’observation préalable.
- Filtrez la GPO par sécurité : appliquer uniquement à GRP‑OPS‑Logiciels‑SRV (Supprimer « Authenticated Users » si nécessaire).
Alternative : Stratégie de restriction logicielle (SRP) si AppLocker n’est pas disponible. Définissez des règles de chemin/éditeur et ajoutez l’extension .msc dans les « Types de fichiers désignés » pour empêcher l’ouverture de consoles MMC spécifiques (voir plus bas pour le blocage fin).
3B — Ajuster les ACL (fichiers/registre) pour des applications ciblées
Beaucoup d’installateurs échouent car ils écrivent dans C:\Program Files ou dans HKLM\Software. Corrigez à la marge en accordant des droits uniquement sur des répertoires/clé dédiés à vos applis.
| Périmètre | Action | Exemple |
|---|---|---|
| Dossier applicatif | Créer le dossier et donner Modify | icacls "C:\Program Files\MonEditeur\MonApp" /grant "GRP-OPS-Logiciels-SRV:(OI)(CI)M" |
| Dossier de logs/temp | Donner Modify (créer/écrire) | icacls "C:\ProgramData\MonApp\Logs" /grant "GRP-OPS-Logiciels-SRV:(OI)(CI)M" |
| Clé Registre dédiée | Accorder des droits sur la clé éditeur | $path = "HKLM:\SOFTWARE\MonEditeur\MonApp" New-Item $path -Force | Out-Null $acl = Get-Acl $path $rule = New-Object System.Security.AccessControl.RegistryAccessRule( "DOMAINE\GRP-OPS-Logiciels-SRV", "ReadKey,SetValue,CreateSubKey,EnumerateSubKeys,Notify,Delete", "ContainerInherit,ObjectInherit", "None", "Allow" ) $acl.SetAccessRule($rule) Set-Acl -Path $path -AclObject $acl |
Astuce diagnostic : utilisez un outil de traçage (par ex. un moniteur d’accès aux fichiers/Registre) sur un serveur de test pour identifier précisément les accès refusés par l’installateur et n’ouvrir que ces emplacements.
3C — Pilotes et périphériques (optionnel)
Si les utilisateurs doivent installer des pilotes, deux voies :
- Autoriser des classes de périphériques via stratégie de Restriction d’installation de périphériques (GPO), en renseignant les GUID des classes autorisées.
- Accorder le droit Charger et décharger des pilotes de périphérique dans Attribution des droits utilisateur. À réserver aux cas nécessaires.
3D — Paramètres UAC à conserver
- « Comportement de l’invite d’élévation pour les utilisateurs standard » : Demander des informations d’identification.
- « Exécuter tous les administrateurs en mode Approbat. administrateur » : Activé.
Ces réglages empêchent l’élévation silencieuse et obligent à passer par des processus ou règles explicitement autorisés.
3E — Ce qu’il ne faut surtout pas faire
Ne pas activer « Toujours installer avec des privilèges élevés » (cotés Ordinateur et Utilisateur) : tout paquet MSI serait exécuté en SYSTEM, ouvrant une brèche majeure.
Bloquer fermement la gestion des comptes
4A — Interdire les consoles et outils courants via GPO
Dans Configuration utilisateur > Stratégies > Modèles d’administration > Système :
- Ne pas exécuter les applications Windows spécifiées : ajoutez
mmc.exe,lusrmgr.msc,dsa.msc,compmgmt.msc,net.exe,net1.exe. - Ne pas exécuter les fichiers .msc non approuvés : via SRP, ajoutez
.mscaux types désignés et créez des règles « non autorisées » pour les consoles sensibles (tout en laissant des consoles inoffensives si besoin). - Panneau de configuration : « Interdire l’accès » ou « Masquer les éléments spécifiés », notamment la zone « Comptes d’utilisateurs ».
Filtrez cette partie de GPO pour qu’elle ne s’applique qu’au groupe délégué (filtrage sécurité).
4B — AppLocker pour neutraliser la gestion de comptes via scripts
- Créer des règles de refus pour
powershell.exe,pwsh.exe,cmd.exeen interaction utilisateur si les scénarios le permettent, tout en autorisant des lanceurs ou scripts signés spécifiques nécessaires à l’exploitation. - Mettre Constrained Language Mode pour le groupe délégué (via politiques AppLocker) afin de limiter les cmdlets sensibles.
4C — Vérifier l’absence de droits « annexes »
Dans Attribution des droits utilisateur, contrôlez que le groupe n’a pas : « Ajouter une station de travail au domaine », « Gérer les journaux d’audit et de sécurité », « Arrêter le système », etc.
Tester, valider, déployer
- Serveur de test : connectez-vous avec un compte du groupe délégué.
- Essai d’installation : installez un .msi signé depuis
C:\Installers, puis désinstallez viaappwiz.cplou « Applications et fonctionnalités » si disponible. - Essai d’accès interdit : lancez
lusrmgr.msc,dsa.msc,net user→ doit être bloqué. - Journalisation : vérifiez les logs AppLocker (audit/blocage) et les événements d’audit « Gestion des comptes ».
- Passage en production : basculez AppLocker de Audit à Appliquer, déployez sur l’OU cible.
Automatisation : exemples PowerShell prêts à l’emploi
Créer le dossier d’installation approuvé et ajuster les ACL
$group = "DOMAINE\GRP-OPS-Logiciels-SRV"
$installRoot = "C:\Installers"
New-Item -ItemType Directory -Path $installRoot -Force | Out-Null
icacls $installRoot /grant "$group:(OI)(CI)M"
Appliquer des ACL sur un dossier applicatif
$appPath = "C:\Program Files\MonEditeur\MonApp"
New-Item -ItemType Directory -Path $appPath -Force | Out-Null
icacls $appPath /grant "DOMAINE\GRP-OPS-Logiciels-SRV:(OI)(CI)M"
Modèle minimaliste AppLocker par XML (extrait)
Procédure type : générez une politique AppLocker sur un serveur de labo, exportez en XML puis importez via GPO.
# Générez les règles par défaut puis ajoutez des règles Publisher pour vos éditeurs.
New-AppLockerPolicy -DefaultRule -XMLPolicy C:\Temp\applocker-base.xml
# Import côté machine (à exécuter depuis un compte admin)
Set-AppLockerPolicy -XMLPolicy C:\Temp\applocker-base.xml -Merge Option avancée : JEA (Just Enough Administration)
Pour des environnements PowerShell intensifs, JEA permet d’offrir une interface d’administration restreinte où les opérateurs exécutent uniquement des commandes autorisées (ex. Install-Package, Get-Service), sans droits supplémentaires sur le système.
Exemple simplifié de rôle JEA
# 1) Rôle "LogicielsOps" autorisant quelques cmdlets
$rolePath = "C:\Program Files\WindowsPowerShell\Modules\JEARoles\RoleCapabilities\LogicielsOps.psrc"
New-Item -ItemType Directory -Path (Split-Path $rolePath) -Force | Out-Null
@"
VisibleCmdlets = @(
@{ Name = "Install-Package" },
@{ Name = "Uninstall-Package" },
@{ Name = "Get-Service" },
@{ Name = "Restart-Service"; Parameters = @{ Name = "Name" } }
)
"@ | Out-File -FilePath $rolePath -Encoding UTF8
# 2) Session configuration mappant le groupe
$sessionFile = "C:\Program Files\WindowsPowerShell\Modules\JEARoles\OpsSession.pssc"
@"
SessionType = "RestrictedRemoteServer"
RunAsVirtualAccount = $true
RoleDefinitions = @{
"DOMAINE\GRP-OPS-Logiciels-SRV" = @{ "RoleCapabilities" = "LogicielsOps" }
}
"@ | Out-File -FilePath $sessionFile -Encoding UTF8
# 3) Enregistrer la session (nécessite admin)
Register-PSSessionConfiguration -Name "Ops-Logiciels" -Path $sessionFile -Force Les opérateurs se connectent ensuite via Enter-PSSession -ConfigurationName Ops-Logiciels -ComputerName Serveur et ne peuvent exécuter que les cmdlets prévues.
Élévation à la demande (scénarios ponctuels)
- LAPS : gérez le mot de passe administrateur local de façon jetable. Lors d’une opération exceptionnelle, un administrateur autorisé peut effectuer l’installation à sa place ou déléguer un Runas contrôlé.
- Outils tiers de Privilege Management : permettent d’élever un processus précis selon des règles (éditeur, hachage, chemin) sans divulguer un mot de passe admin.
Spécificités Windows Server Core
Sur les éditions Core, l’absence de nombreuses consoles MMC diminue naturellement les vecteurs de gestion des comptes. Les mêmes GPO AppLocker/SRP et ACL s’appliquent. L’exploitation se fait via PowerShell/WinRM et JEA est particulièrement adaptée.
Audit, supervision et traçabilité
- Audit avancé > Gestion des comptes : activez Succès et Échecs pour obtenir des événements lors de la création/suppression/modification de comptes (ex. 4720, 4725, 4726, 4738).
- AppLocker : consultez Journaux des applications et services → Microsoft → Windows → AppLocker (volets EXE & DLL, MSI & Script). Commencez en Audit, puis basculez en Appliquer.
- Correlogramme d’essais : documentez pour chaque appli la liste des répertoires/clé HKLM requis, ainsi que la preuve que la gestion de comptes est bloquée.
Modèle de GPO recommandé (checklist technique)
| Chemin GPO | Paramètre | Valeur conseillée |
|---|---|---|
| Conf. ordinateur > Sécurité > AppLocker | Règles Exécutables, MSI & Scripts | Autoriser éditeurs/chemins approuvés pour installateurs |
| Conf. utilisateur > Système | Ne pas exécuter les applications Windows spécifiées | mmc.exe, lusrmgr.msc, dsa.msc, compmgmt.msc, net.exe, net1.exe |
| Conf. ordinateur > Sécurité > Stratégies locales | Attribution des droits utilisateur | Ajouter si besoin « Charger et décharger des pilotes… », « Remplacer un jeton de niveau processus » |
| Conf. utilisateur > Panneau de configuration | Masquer/Interdire l’accès | Masquer « Comptes d’utilisateurs » et éléments sensibles |
| Conf. ordinateur > Modèles d’administration > Windows Installer | Toujours installer avec des privilèges élevés | Désactivé |
| Conf. ordinateur > Paramètres Windows > Paramètres de sécurité | Restriction d’installation de périphériques | Autoriser classes de périphériques nécessaires (le cas échéant) |
Erreurs fréquentes et comment les éviter
- Ouvrir trop d’ACL (ex. contrôle total sur
C:\Program Files) : servez-vous d’un dossier de base (C:\Installers) et d’emplacements précis par application. - Bloquer
mmc.exesans précaution : vous risquez de gêner d’autres outils légitimes. Filtrez par groupe et testez. - Oublier
net.exe:net userpermet de créer/supprimer des comptes locaux, pensez à l’interdire. - Ne pas auditer : sans journaux AppLocker/audit de comptes, impossible de prouver l’efficacité du dispositif.
- Activer « AlwaysInstallElevated » par facilité : c’est une faille. Ne l’utilisez pas.
FAQ
Q : Les utilisateurs pourront-ils installer n’importe quel logiciel ?
R : Non. Ils ne pourront installer que des installateurs explicitement approuvés (signatures, éditeurs, chemins) et/ou des applications dont les ACL nécessaires ont été ouvertes sur des emplacements précis.
Q : Et les services Windows créés par certains installateurs ?
R : En général, si l’installateur nécessite la création de service (SCM), il demandera une élévation. Dans ce cas, faites exécuter l’installation par un administrateur (via LAPS/JIT) ou utilisez un outil de Privilege Management capable d’élever ce processus uniquement.
Q : Peut-on laisser PowerShell libre pour ces utilisateurs ?
R : À éviter. Même sans modules RSAT, PowerShell peut gérer des comptes locaux/AD. Si vous devez l’autoriser, combinez AppLocker (règles Allow pour scripts signés) et, mieux, JEA pour restreindre aux cmdlets autorisées.
Q : Est-ce compatible avec Server Core ?
R : Oui. Vous y gagnerez même en surface d’attaque, les consoles MMC y étant absentes par défaut. Les GPO/ACL/JEA s’appliquent de la même façon.
Checklist de mise en production
- Groupe GRP‑OPS‑Logiciels‑SRV créé et peuplé.
- GPO « Délégation Installation Logiciels » : filtrage sécurité OK, WMI filter (serveurs membres 2019/2022) appliqué.
- AppLocker en Audit : aucun faux positif critique pendant la recette.
- Règles de blocage (
mmc.exe,*.msc,net*.exe) actives pour le groupe uniquement. - ACL spécifiques appliquées aux applis cibles (dossier, Registre).
- Audit « Gestion des comptes » activé, supervision connectée.
- Documentation d’exploitation mise à jour (qui fait quoi, où, comment).
Informations complémentaires utiles
- Élévation à la demande : pour des besoins ponctuels, LAPS ou des outils dédiés de Privilege Management permettent d’élever un processus précis sans divulguer un mot de passe administrateur.
- Serveur Core : l’absence de MMC limite les vecteurs de gestion de comptes.
- JEA : solution moderne pour des rôles très limités (ex. autoriser uniquement
Install-Package/Uninstall-Package).
Annexe : commandes et snippets utiles
Bloquer des outils via GPO (liste indicative)
mmc.exe
lusrmgr.msc
dsa.msc
compmgmt.msc
net.exe
net1.exe
WMI filter (cibler serveurs membres 2019/2022)
SELECT * FROM Win32_OperatingSystem
WHERE ProductType = 3 AND (Version LIKE "10.0.17763%" OR Version LIKE "10.0.20348%")
Vérifier l’appartenance de groupe et les droits efficaces
whoami /groups
gpresult /r /scope user
gpresult /r /scope computer
Cycle de test rapide
- Copier un .msi signé dans
C:\Installers. - Installer (double‑clic ou
msiexec /i). - Désinstaller.
- Tenter
lusrmgr.msc/net user test /add→ refus attendu. - Consulter les journaux AppLocker et Sécurité.
En suivant cette approche — groupe dédié, droits minimaux via GPO/ACL, blocage explicite des outils de gestion des comptes, tests et journalisation — vous obtenez un équilibre robuste : les opérateurs peuvent installer/désinstaller les logiciels nécessaires sans exposer la sécurité des comptes ni l’intégrité de l’annuaire.