Objectif : donner à un compte Active Directory le pouvoir d’installer/désinstaller des logiciels sur un périmètre de serveurs sans lui conférer la moindre capacité d’administration d’objets AD. La méthode s’appuie sur la séparation stricte des privilèges, des GPO ciblées et des contrôles d’usage.
Problématique
Dans de nombreux environnements, des équipes d’exploitation doivent installer, mettre à jour ou supprimer des applications sur des serveurs membres du domaine (fichiers, applicatifs, web, etc.). Pourtant, leur octroyer un rôle d’administrateur du domaine serait contraire au principe du moindre privilège et ouvrirait des risques majeurs (modification d’OU, création/suppression de comptes, délégations incontrôlées). L’enjeu est donc de créer un compte ou groupe capable d’agir localement sur une liste de serveurs, tout en restant incapable d’administrer des objets AD.
Principe de la solution
- Pas de privilèges AD globaux (jamais de Domain Admins / Enterprise Admins).
- Un groupe AD dédié (ex. :
Software Installers) auquel on ajoute le ou les comptes nominatifs. - Élévation locale seulement : ce groupe est injecté via GPO dans le groupe Administrators local des serveurs cibles.
- Contrôles complémentaires : interdiction d’outils sensibles, absence totale de délégation AD, audit renforcé et, si possible, JEA (Just Enough Administration) pour n’exposer que les cmdlets d’installation.
Solution pas‑à‑pas
| Étape | Action essentielle | Objectif atteint |
|---|---|---|
| 1. Créer le compte | Via Active Directory Users and Computers ou PowerShell (New‑ADUser). | Disposer d’un identifiant dédié, distinct de tout compte administratif global. |
| 2. Séparer les privilèges | Ne jamais ajouter ce compte à Domain Admins / Enterprise Admins. Créer un groupe AD (ex. : Software Installers), y ajouter le compte. | Empêcher toute escalade AD par appartenance de haut niveau. |
| 3. Octroyer les droits locaux nécessaires | a) Pour les serveurs membres : via une GPO Group Policy Preferences ► Local Users & Groups, ajouter Software Installers au groupe local Administrators. b) Éviter les installations sur DC. À défaut, utiliser un compte à durée de vie courte et une supervision renforcée (voir plus bas « GPO de déni sur DC »). | Permettre l’installation/désinstallation sur les serveurs ciblés sans droit AD élargi. |
| 4. Limiter l’administration d’objets AD | Ne déléguer aucun droit sur les OU. Vérifier les ACL (onglet Security) : pas de permissions Create/Delete sur utilisateurs, groupes, OU. | Bloquer toute gestion d’identité. |
| 5. Contrôler l’accès aux outils sensibles | Dans la même (ou une nouvelle) GPO : • Software Restriction Policies (SRP) pour interdire les consoles .msc AD (dsa.msc, adsiedit.msc) et scripts non approuvés.• AppLocker pour limiter powershell.exe/pwsh.exe à un mode restreint et autoriser seulement des outils de déploiement approuvés.• User Rights Assignment : refuser « Add workstations to domain », « Create a token object », etc. | Empêcher l’usage de consoles/cmdlets AD et limiter la surface d’attaque. |
| 6. Tester et valider | Connexion sur un serveur cible : installation/désinstallation d’un MSI signé → OK. Tentative d’ouvrir ADUC ou d’exécuter New‑ADUser → doit échouer. | Vérification fonctionnelle et de sécurité. |
Implémentation détaillée (GUI & PowerShell)
Création du compte et du groupe
Privilégiez un compte nominatif (traçabilité) ou un compte technique uniquement si nécessaire. Activez une authentification forte (MFA si disponible) et désactivez tout droit inutile (Smart‑card optional, Delegation not trusted, etc.).
# 1) Créer le compte
New-ADUser `
-Name "svc-softinstall" `
-SamAccountName "svc-softinstall" `
-UserPrincipalName "svc-softinstall@contoso.local" `
-Enabled $true `
-AccountPassword (Read-Host "Mot de passe" -AsSecureString) `
-PasswordNeverExpires $false `
-ChangePasswordAtLogon $true
# 2) Créer le groupe dédié (global, sécurité)
New-ADGroup -Name "Software Installers" -GroupScope Global -GroupCategory Security
# 3) Ajouter le compte au groupe
Add-ADGroupMember -Identity "Software Installers" -Members "svc-softinstall" Injection du groupe dans les Administrators locaux (GPO)
Deux approches existent :
- Group Policy Preferences (GPP) ► Local Users & Groups : ajoute/retire des membres d’un groupe local sans écraser les autres. C’est l’option la plus souple.
- Restricted Groups : impose une liste stricte (risque d’écraser des membres légitimes si mal utilisée). À réserver aux environnements très contrôlés.
Procédure GPP (recommandée)
- Créer une GPO « Local Admin – Software Installers » et la lier à l’OU contenant vos serveurs (pas les DC).
- Éditer : Computer Configuration ► Preferences ► Control Panel Settings ► Local Users and Groups.
- Ajouter un Local Group : Group name = Administrators (Built‑in), Action = Update puis Add → DomainName\Software Installers.
- Filtrer les cibles si besoin (Item‑level Targeting, WMI filter par OS/nom d’ordinateur).
GPO de déni sur les Contrôleurs de domaine
Sur l’OU « Domain Controllers », créez une GPO « Deny – Software Installers on DCs » :
- Computer Configuration ► Windows Settings ► Security Settings ► Local Policies ► User Rights Assignment :
- Deny log on locally : ajouter DomainName\Software Installers
- Deny log on through Remote Desktop Services : ajouter le même groupe
- Deny access to this computer from the network (selon politique interne)
- Option : Security Options → renforcer UAC et l’accès réseau anonyme.
Rappel : évitez l’installation d’applications tierces sur les DC. En cas d’exception, préférez des fenêtres de privilège temporaires (expiring membership), une supervision en temps réel et des logiciels authentifiés.
Bloquer les outils AD et réduire la surface d’attaque
Pourquoi SRP et AppLocker ? SRP gère nativement les types .msc (consoles MMC), ce qui permet de bloquer des consoles AD précises (dsa.msc, adsiedit.msc). AppLocker, lui, contrôle finement les exécutables/scripts et permet de cadrer powershell.exe/pwsh.exe et les outils d’installation.
SRP – règles typiques
- Créer une GPO « SRP – Block AD MMC » et la lier à l’OU des serveurs cibles.
- Computer Configuration ► Windows Settings ► Security Settings ► Software Restriction Policies :
- Security Level : Unrestricted (par défaut)
- Additional Rules :
- Path Rule :
%windir%\System32\dsa.msc→ Disallowed - Path Rule :
%windir%\System32\adsiedit.msc→ Disallowed - Option : ajouter des règles Disallowed pour
ActiveDirectoryPowerShell shortcut si présent.
- Path Rule :
- Confirmer que l’extension
.mscest incluse dans Designated file types (valeur par défaut).
AppLocker – garde‑fous d’exécution
- Créer une GPO « AppLocker – Installers Only ».
- Computer Configuration ► Windows Settings ► Security Settings ► Application Control Policies ► AppLocker :
- Activer l’application des règles (service Application Identity en Automatic).
- Règles Executable et Script : autoriser uniquement les outils de déploiement approuvés (ex. :
msiexec.exe,DISM.exe,winget.exesi présent,choco.exesi utilisé en interne) pour le groupe Software Installers. - Règles PowerShell : basculer en Constrained Language Mode (via stratégie de contrôle des applications) et/ou n’autoriser que des scripts signés.
Bon réflexe : initialiser AppLocker en Audit only, collecter les événements, puis passer en Enforce rules une fois la liste d’autorisations stabilisée.
Just Enough Administration (JEA) – Option recommandée
Pour limiter l’espace de manœuvre, exposez uniquement les cmdlets d’installation aux membres de Software Installers. Exemple de session PowerShell restreinte :
# 1) Définir une configuration JEA
New-PSSessionConfigurationFile `
-RunAsVirtualAccount `
-TranscriptDirectory "C:\JEA\Transcripts" `
-VisibleCmdlets @(
'Microsoft.PowerShell.PackageManagement\Find-Package',
'Microsoft.PowerShell.PackageManagement\Install-Package',
'Microsoft.PowerShell.PackageManagement\Uninstall-Package',
'Get-Package','Get-Command','Get-Help'
) `
-SessionType RestrictedRemoteServer `
-Path "C:\JEA\SoftwareInstallers.pssc"
# 2) Enregistrer l'endpoint
Register-PSSessionConfiguration -Name "JEA-SoftwareInstallers" -Path "C:\JEA\SoftwareInstallers.pssc"
# 3) Utilisation (depuis un poste d'admin)
Enter-PSSession -ComputerName APP-SRV01 -ConfigurationName "JEA-SoftwareInstallers" -Credential "CONTOSO\svc-softinstall" Résultat : même un membre local Administrators ne peut exécuter que les cmdlets explicitement autorisées dans cette session contrôlée, avec journalisation systématique.
Exemples d’installation/désinstallation
| Scénario | Commande | Notes |
|---|---|---|
| MSI signé | msiexec /i "C:\Packages\App.msi" /qn /norestart | Exiger un package signé et une source approuvée. |
| Désinstallation MSI | msiexec /x {GUID-PRODUIT} /qn | Récupérer le GUID via Get-Package ou registre. |
| PackageManagement | Install-Package ContosoApp -Source ContosoRepo -Force | Nécessite un dépôt interne contrôlé. |
| Winget (si présent) | winget install --id Contoso.App --silent | Contrôlez les sources et la version (en entreprise). |
Sécurité : contrôles, audit et conformité
- Audit avancé : activez
- Process Creation (événement 4688) avec ligne de commande ;
- Privilege Use (événements dont 4717) ;
- Policy Change (modifications GPO) ;
- Object Access sur les répertoires de packages.
- Traçabilité : conservez des journaux centralisés (SIEM) et les transcripts JEA.
- Workstation d’administration : utilisez un poste durci (PAW) dédié aux tâches privilégiées.
- Mots de passe : rotation régulière, secrets dans un coffre (pas de partage entre opérateurs).
- LAPS / LAPS Cloud : pour éviter la dépendance au compte, sécurisez les comptes Administrateur local avec LAPS (gestion des mots de passe uniques par machine).
Périmètre et ciblage
Utilisez des OU par rôle (ex. : OU=Servers-Apps) et liez les GPO uniquement là où elles sont nécessaires. Les filtres WMI ou le Item‑level Targeting permettent de viser un OS précis, une étiquette de registre (tag applicatif) ou un sous-ensemble de machines.
Validation : check‑list opérationnelle
- Le compte svc‑softinstall n’est membre d’aucun groupe AD à privilège élevé (vérifier MemberOf).
- Le groupe Software Installers est injecté uniquement dans les Administrators locaux des serveurs cibles.
- Les GPO SRP/AppLocker sont en Enforce (après période d’audit) et testées.
- Impossible d’ouvrir
dsa.msc/adsiedit.msccôté serveurs cibles pour ce compte. - Les cmdlets AD (
New-ADUser,Set-ADGroup, etc.) renvoient des erreurs d’autorisation. - Les événements 4688/4717 sont collectés pour ce compte et corrélés dans le SIEM.
Gestion du cycle de vie & accès temporaires
Idéalement, l’appartenance au groupe Software Installers est temporaire. Si votre forêt le permet, activez l’optional feature de « Privileged Access Management » afin d’utiliser des expiring links (expiration d’appartenance) :
# Activer la fonctionnalité PAM au niveau forêt (opération ponctuelle par un admin AD)
# Enable-ADOptionalFeature "Privileged Access Management Feature" -Scope ForestOrConfigurationSet -Target "contoso.local"
# Ajouter un membre au groupe pour 8 heures (format TTL)
Add-ADGroupMember -Identity "Software Installers" -Members "alice" -MemberTimeToLive (New-TimeSpan -Hours 8) À défaut, mettez en place des processus d’accès à durée limitée : ticketing approuvant l’ajout au groupe, script d’ajout puis tâche planifiée de retrait, rapports quotidiens d’appartenance.
Bonnes pratiques complémentaires
- Intune / Configuration Manager : préférez un déploiement centralisé non interactif lorsque c’est possible (collections ciblées, anneaux de déploiement, maintenance windows), ce qui réduit la surface d’exposition.
- Signatures et contrôle d’intégrité : n’acceptez que des binaires signés provenant de dépôts d’entreprise.
- Principe du moindre privilège : révisez trimestriellement la liste des serveurs où le groupe est admin local.
- Segmentation réseau : autorisez RDP/WinRM uniquement depuis les postes d’administration, pas depuis tout le LAN.
Erreurs fréquentes… et comment les éviter
| Erreur | Conséquence | Prévention |
|---|---|---|
| Ajouter le compte à Domain Admins | Contrôle total du domaine → risque critique | Créer un groupe dédié et auditer MemberOf |
| Appliquer la GPO sur l’ensemble du domaine | Élévation locale involontaire partout | Lier uniquement aux OU serveurs ciblées |
| Activer AppLocker directement en « Enforce » | Blocages applicatifs imprévus | Phase « Audit only » + revue des logs |
| Installer sur un DC « par commodité » | Augmentation du risque d’attaque et d’instabilité | Interdire via GPO de déni + procédure d’exception strictement contrôlée |
| Scripts non signés / sources non maîtrisées | Infection par supply chain | Exiger des signatures et dépôts internes, SRP/AppLocker |
Procédure opératoire (SOP) prête à l’emploi
- Créer/mettre à jour le compte nominatif et l’ajouter au groupe Software Installers (avec TTL si disponible).
- Vérifier la présence des GPO :
- Local Admin – Software Installers (GPP) appliquée aux serveurs cibles
- SRP – Block AD MMC et AppLocker – Installers Only en vigueur
- Deny – Software Installers on DCs liée à l’OU des DC
- Effectuer l’installation/désinstallation selon la procédure (MSI/PackageManagement/winget interne).
- Contrôler les journaux (4688, 4717, transcripts JEA) et valider l’état du service.
- Retirer l’appartenance (ou laisser expirer le TTL) et clore le ticket avec preuves.
FAQ rapide
Faut‑il un compte « service » partagé ? Non. Préférez des comptes nominatifs, traçables, membres d’un groupe dédié. Un compte technique se justifie seulement pour des moteurs d’automatisation, avec coffre à secrets et rotation.
Pourquoi ne pas déléguer des droits AD « minimes » ? Parce que l’objectif est de ne jamais toucher aux objets AD. Les installations se font avec des droits locaux uniquement.
Et si l’application requiert des droits de service de domaine ? Créez un compte de service distinct, à permissions minimales et cloisonnées (SPN si nécessaire), sans lien avec Software Installers.
Peut‑on automatiser sans RDP ? Oui : via JEA + WinRM/PowerShell Remoting, pipelines CI/CD, ou outils MDM/ECM (Intune/ConfigMgr), ce qui est préférable à l’interactif.
Conclusion
En combinant groupe AD dédié, élévation locale ciblée via GPO, blocage des outils AD, JEA et audit, vous obtenez un dispositif simple et robuste : le compte peut gérer les applications sur des serveurs spécifiés, tout en restant totalement inapte à administrer des utilisateurs, groupes ou OU du domaine. Cette architecture respecte la séparation des tâches et le principe de moindre privilège, indispensables aux environnements exigeants.
Annexe : script d’évaluation rapide
Exemple de vérification sur un serveur cible pour le groupe Software Installers :
$Group = 'CONTOSO\Software Installers'
# 1) Appartenance au groupe Administrators local
(Get-LocalGroupMember -Group 'Administrators' | Where-Object { $_.Name -eq $Group }) -ne $null
# 2) Test d'accès aux consoles AD (doit échouer par SRP)
$adConsoles = @("$env:windir\System32\dsa.msc","$env:windir\System32\adsiedit.msc")
$adConsoles | ForEach-Object {
try { Start-Process mmc.exe $_ -ErrorAction Stop; "Unexpected: $_ launched" }
catch { "OK: $_ bloquée ($($_.Exception.Message))" }
}
# 3) Tentative de cmdlet AD (doit échouer)
try { New-ADUser -Name 'TestUser' -WhatIf -ErrorAction Stop }
catch { "OK: cmdlet AD refusée ($($_.Exception.Message))" } Récapitulatif des décisions de design
- Identité : comptes nominatifs + groupe Software Installers
- Portée : serveurs membres uniquement (jamais DC)
- Contrôle : GPP pour l’admin locale, SRP pour
.mscAD, AppLocker pour le reste - Réduction : JEA et langage PowerShell restreint
- Surveillance : audit 4688/4717 + transcripts
- Temporalité : appartenance avec TTL si possible, sinon processus d’octroi/retrait
Modèle de documentation (à copier dans votre wiki)
| Rubrique | Contenu modèle |
|---|---|
| But | Permettre aux opérateurs d’installer/désinstaller des logiciels sur les serveurs du périmètre Apps‑Prod sans droits AD. |
| Comptes | Comptes nominatifs « svc-* » membres du groupe Software Installers. |
| GPO | Local Admin – Software Installers (GPP) – OU : OU=Servers-Apps,DC=contoso,DC=local SRP – Block AD MMC – OU : OU=Servers-Apps AppLocker – Installers Only – OU : OU=Servers-Apps Deny – Software Installers on DCs – OU : OU=Domain Controllers |
| Processus | Demande via ticket, approbation manager+sécu, ajout au groupe (TTL 8h), exécution, retrait/expiration, preuves jointes. |
| Audit | Collecte 4688/4717 + transcripts JEA, revue hebdomadaire. |
Résultat attendu
Le compte/groupe dédié peut gérer les applications uniquement sur les serveurs définis, sans aucun pouvoir sur les objets du domaine. Vous respectez ainsi la séparation des tâches, réduisez l’impact d’une compromission et facilitez les audits de conformité.