Pourquoi abandonner les comptes administrateurs locaux permanents
Dans de nombreuses organisations, les équipes IT accordent des droits d'administrateur local aux utilisateurs pour répondre à des besoins ponctuels : installation d'une application métier, mise à jour d'un pilote, exécution d'un outil de diagnostic. Cette pratique génère une surface d'attaque importante et contredit directement le principe de moindre privilège (Least Privilege Access), pilier de toute stratégie Zero Trust.
Endpoint Privilege Management (EPM), intégré à Microsoft Intune, répond à cette problématique. Il permet aux utilisateurs de fonctionner en tant que comptes standard et d'obtenir une élévation de privilèges uniquement pour des applications ou des actions explicitement autorisées, de façon contrôlée et auditée.
Les bénéfices concrets sont les suivants :
- Suppression des droits administrateur local permanents sur les postes Windows
- Élévation ciblée pour des exécutables ou des actions spécifiques
- Workflow de validation IT pour les élévations non couvertes par une règle
- Traçabilité complète de chaque demande et de chaque élévation accordée
- Renforcement de la posture Zero Trust sans dégrader l'expérience utilisateur
Prérequis techniques et licences
Avant tout déploiement, plusieurs conditions doivent être réunies.
Licences requises — EPM n'est pas inclus dans les offres Intune de base. La fonctionnalité est disponible avec :
- Microsoft Intune Suite
- Microsoft Intune Plan 2
- Une licence Endpoint Privilege Management standalone
Point de vigilance licence
Vérifiez votre modèle de souscription avant de configurer EPM. L'activation du service sur un appareil sans licence valide bloquera le déploiement des règles d'élévation.
Environnement poste de travail :
- Windows 10 ou Windows 11 dans une version officiellement supportée par Microsoft
- Appareils inscrits dans Intune et joints via Microsoft Entra joined ou Microsoft Entra hybrid joined
Ces prérequis conditionnent la réception des stratégies EPM, la remontée des événements d'audit et la cohérence de l'application des règles sur le parc.
Architecture de la solution EPM
EPM repose sur deux couches de configuration dans Intune :
- Elevation Settings policy — Active le service EPM sur les appareils ciblés et définit le comportement par défaut pour les élévations non couvertes par une règle.
- Elevation Rules policy — Définit des règles précises par application (chemin, hash, certificat éditeur) pour autoriser ou bloquer automatiquement une élévation.
Cet article couvre la mise en place de la stratégie Elevation Settings, point d'entrée obligatoire de tout déploiement EPM.
Configurer la stratégie Elevation Settings dans Intune
Accéder à la section Endpoint Privilege Management
Dans le portail Microsoft Intune (intune.microsoft.com), naviguez vers Endpoint Security > Endpoint Privilege Management, puis cliquez sur Policies.
Créer une nouvelle stratégie
Cliquez sur Create policy. Sélectionnez Windows comme plateforme, puis choisissez le profil Elevation Settings policy. Donnez un nom explicite à la stratégie, par exemple EPM - Elevation Settings - Pilote.
Activer le service EPM
Dans la section Configuration settings, activez le paramètre Endpoint Privilege Management. Cette action déclenche le déploiement automatique des composants EPM sur les appareils ciblés.
Configurer le comportement par défaut (Default Elevation Response)
Le paramètre Default elevation response détermine ce qui se passe lorsqu'un utilisateur tente d'exécuter une application pour laquelle aucune règle EPM n'existe. Trois options sont disponibles :
- Deny all requests : toute demande d'élévation non couverte par une règle est refusée.
- Require support approval : l'utilisateur soumet une demande ; un administrateur IT doit l'approuver avant l'exécution. Option recommandée pour les projets pilotes.
- Require user confirmation : l'utilisateur peut s'auto-élever après avoir fourni une justification métier et/ou s'être authentifié via Windows Authentication.
Pour un premier déploiement, choisissez Require support approval afin de garder la main sur chaque élévation non planifiée.
Configurer le reporting
Activez la collecte des événements d'élévation, y compris les élévations gérées et les informations de diagnostic. Ce niveau de remontée est indispensable en phase pilote pour cartographier les applications nécessitant régulièrement des privilèges élevés et alimenter les futures règles EPM.
Affecter la stratégie à un groupe pilote
Assignez la stratégie à un groupe Microsoft Entra contenant un échantillon restreint d'utilisateurs ou d'appareils Windows. Validez la configuration et créez la stratégie.
Bonne pratique de déploiement
Commencez toujours par un groupe pilote de 10 à 20 appareils. Analysez les remontées de reporting pendant deux à quatre semaines avant d'étendre le périmètre et de créer des règles d'élévation spécifiques.
Paramètres clés de la stratégie Elevation Settings
| Paramètre | Valeur | Impact |
|---|---|---|
| Endpoint Privilege Management | Enabled | Déploie les composants EPM sur l'appareil |
| Default elevation response | Require support approval | Toute élévation hors règle passe par validation IT |
| Default elevation response | Require user confirmation | L'utilisateur s'auto-élève avec justification ou authentification |
| Default elevation response | Deny all requests | Blocage total des élévations non couvertes par une règle |
| Reporting scope | Managed elevations + diagnostics | Remontée complète pour audit et affinement des règles |
Expérience utilisateur : scénario d'installation avec validation IT
Voici le parcours concret d'un utilisateur standard souhaitant installer le navigateur Brave sur son poste Windows.
L'utilisateur télécharge le programme d'installation de Brave. Lorsqu'il tente de l'exécuter, Windows détecte l'élévation requise. Grâce à EPM, une nouvelle option apparaît dans le menu contextuel :
Clic droit sur le fichier d'installation > Run with Elevated Access
Une fenêtre EPM s'affiche. Aucune règle spécifique n'existant pour Brave, la stratégie Default elevation response s'applique — ici, Require support approval. L'utilisateur renseigne une justification métier, puis soumet sa demande.
Du côté administrateur, la demande apparaît dans Endpoint Security > Endpoint Privilege Management > onglet Elevation requests, avec le statut Pending. L'administrateur consulte la justification, vérifie que Brave est autorisé dans l'entreprise, puis clique sur Approve en ajoutant un commentaire de validation.
L'utilisateur reçoit une notification Windows indiquant que sa demande est approuvée. Il effectue à nouveau un clic droit > Run with Elevated Access. EPM accorde temporairement les privilèges nécessaires au seul processus d'installation. Une fois l'installation terminée, les privilèges élevés sont automatiquement révoqués.
Élévation temporaire et ciblée
EPM n'accorde jamais des droits administrateur globaux sur le poste. L'élévation est limitée au processus concerné et à la durée de l'opération. L'utilisateur reste un compte standard à l'issue de chaque élévation.
Audit et reporting des élévations
Toutes les demandes d'élévation, qu'elles soient approuvées, refusées ou auto-validées, sont enregistrées dans Intune. Les données remontées incluent :
- L'identité de l'utilisateur ayant soumis la demande
- Le nom et le chemin de l'exécutable concerné
- La justification métier saisie
- La décision prise (approuvée, refusée) et l'identité de l'administrateur ayant statué
- L'horodatage de chaque étape
Ces événements alimentent les rapports EPM disponibles dans le portail Intune et peuvent être exportés vers Microsoft Sentinel ou tout autre SIEM via les connecteurs de diagnostic d'Intune pour une corrélation avec d'autres signaux de sécurité.
Limites et points d'attention avant le déploiement
- EPM ne remplace pas une Elevation Rules policy : sans règles spécifiques par application, chaque installation hors périmètre génère une demande manuelle, ce qui peut saturer l'équipe IT en production.
- Les appareils non inscrits dans Intune ne reçoivent aucune stratégie EPM. Les postes en workgroup ou gérés uniquement par GPO ne sont pas compatibles.
- La fonctionnalité est distincte de Windows LAPS (Local Administrator Password Solution) : les deux solutions sont complémentaires mais répondent à des besoins différents.
- Testez le comportement de l'UAC sur vos applications métiers critiques avant un déploiement large : certaines applications anciennes gèrent mal les élévations par jeton plutôt que par compte.
Ne supprimez pas les admins locaux sans règles EPM en place
Retirer les droits administrateur local d'un utilisateur sans avoir préalablement déployé et validé les règles d'élévation EPM bloquera des usages légitimes. Procédez toujours par phases : pilote EPM actif, cartographie des besoins, création des règles, puis retrait des droits.
