Retirer les droits d'admin local aux utilisateurs sans chaos

Les droits d'administrateur local sont le facilitateur discret de la plupart des compromissions de postes de travail. Une charge d'hameçonnage exécutée en tant qu'utilisateur standard reste confinée : elle ne peut ni installer un pilote, ni désactiver Defender, ni lire la mémoire de LSASS, ni implanter un service. La même charge exécutée dans une session d'administrateur peut faire tout cela, et le fait généralement en quelques minutes. Les rapports de Microsoft sur les mesures d'atténuation montrent depuis longtemps qu'une large part des vulnérabilités critiques est bien moins exploitable sans droits d'administration.

Le pilier Comptes & accès à privilèges couvre le volet architectural : le modèle en tiers et les mots de passe locaux uniques avec LAPS. Ce guide traite du projet concret qui s'inscrit entre les deux : sortir les utilisateurs du quotidien du groupe Administrators local, et les y maintenir, sans submerger le support.

Étape 1 : inventorier qui est administrateur aujourd'hui

On ne peut pas retirer ce qu'on n'a pas mesuré. L'appartenance aux groupes locaux dérive au fil des anciens scripts de masterisation, des raccourcis du support (« je vous ajoute juste pour l'instant »), des installeurs d'éditeurs et des paramètres par défaut de la jonction Microsoft Entra. Collectez-la sur tous les appareils avant de modifier quoi que ce soit.

Sur une seule machine :

Get-LocalGroupMember -Group "Administrators" |
  Select-Object Name, ObjectClass, PrincipalSource

Get-LocalGroupMember renvoie une erreur lorsque le groupe contient des SID orphelins (comptes supprimés du domaine). Dans ce cas, rabattez-vous sur net localgroup Administrators ou interrogez via ADSI, et traitez chaque SID orphelin comme un élément à nettoyer.

Sur l'ensemble du parc, exécutez la même requête via votre outil de gestion (inventaire matériel de Configuration Manager, script de correction Intune, ou Invoke-Command sur une liste de machines) et centralisez le résultat :

$computers = Get-ADComputer -SearchBase "OU=Workstations,DC=corp,DC=example" -Filter * |
  Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $computers -ScriptBlock {
  Get-LocalGroupMember -Group "Administrators" -ErrorAction SilentlyContinue |
    Select-Object @{n="Computer";e={$env:COMPUTERNAME}}, Name, ObjectClass
} | Export-Csv .\local-admins.csv -NoTypeInformation

Classez les résultats en trois catégories :

Domain Users ou Authenticated Users dans le groupe Administrators local est plus fréquent qu'il ne devrait l'être, souvent à cause d'une seule ligne dans un script de démarrage vieux de plusieurs années. Cela fait de chaque utilisateur un administrateur partout : corrigez ce point en premier.

Étape 2 : comprendre pourquoi les utilisateurs sont administrateurs

Pour chaque utilisateur de la catégorie « utilisateurs individuels », identifiez la raison avant de retirer le droit. Raisons typiques, et ce qui les remplace :

• Installer des logiciels. Publiez-les dans Company Portal, le Software Center ou un dépôt winget maîtrisé, déployés en contexte système.
• Imprimantes et pilotes. Déployez les imprimantes et les pilotes empaquetés de manière centralisée. N'affaiblissez pas les restrictions Point and Print pour compenser.
• Outils de développement. Les développeurs ont souvent besoin d'élévation pour une poignée d'outils (fonctionnalités Hyper-V, WSL, certificats locaux, débogueurs). Traitez-les avec des règles d'élévation, une VM de développement dédiée, ou un compte d'administration distinct sur un appareil distinct.
• Applications métier qui « ont besoin d'être admin ». En général, l'application écrit dans Program Files ou HKLM. Process Monitor montre précisément où ; accorder un droit de modification sur un dossier ou une clé est bien plus sûr que des droits d'administration sur toute la machine.
• Modifier les paramètres réseau, le fuseau horaire, le VPN. Les utilisateurs standard peuvent déjà changer de fuseau horaire, et la plupart des clients VPN s'exécutent sous forme de service. Testez avant de supposer.

Une enquête de deux semaines demandant aux utilisateurs disposant de droits d'administration à quoi ils leur ont servi, croisée avec les journaux d'installation de logiciels, montre généralement que la plupart n'en ont jamais eu besoin.

Étape 3 : imposer l'appartenance par stratégie de groupe

Retirer les utilisateurs une fois ne suffit pas : une stratégie doit être propriétaire du groupe pour qu'il ne puisse pas dériver à nouveau.

Option A : préférences de stratégie de groupe. Sous Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups, créez un nouvel élément Local Group :

• Action : Update
• Nom du groupe : Administrators (built-in)
• Cochez Delete all member users et Delete all member groups
• Ajoutez les membres souhaités : votre groupe d'admin Tier 2 et, si vous le gérez par son nom, l'Administrateur intégré

À chaque actualisation, le groupe est vidé puis reconstruit à partir de la liste. Plusieurs éléments GPP peuvent cibler le même groupe, et le ciblage au niveau de l'élément permet par exemple d'ajouter un groupe d'admin de laboratoire uniquement sur les machines du laboratoire.

Option B : Restricted Groups. Sous Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups, ajoutez Administrators et renseignez Members of this group. L'appartenance est entièrement remplacée. C'est simple et fiable lorsqu'une seule GPO gère le groupe, mais quand plusieurs GPO définissent Members of this group pour le même groupe, seule la dernière appliquée l'emporte, ce qui piège souvent les équipes.

Choisissez un seul mécanisme, liez-le à l'UO des postes de travail et assurez-vous qu'il s'applique avant de retirer quiconque manuellement. Sinon, la prochaine actualisation d'une ancienne GPO risque de rajouter des utilisateurs.

Étape 4 : imposer l'appartenance avec Intune

Pour les appareils joints à Microsoft Entra et en jonction hybride gérés par Intune, utilisez Endpoint security > Account protection > Local user group membership. Ce paramètre s'appuie sur le CSP de stratégie LocalUsersAndGroups. Chaque règle a une action :

Pour standardiser le groupe Administrators, Add (Replace) est l'équivalent de Restricted Groups. Incluez tout ce que vous voulez conserver, y compris l'Administrateur intégré et votre groupe de support, car tout ce qui n'est pas listé est supprimé.

Empêchez ensuite la création de nouveaux administrateurs lors de la jonction :

• Dans le centre d'administration Microsoft Entra, sous Devices > Device settings, réglez Registering user is added as local administrator on the device during Microsoft Entra join sur None (ou Selected pour un petit groupe). Cela ne concerne que les appareils joints après la modification.
• Dans les profils de déploiement Windows Autopilot, réglez User account type sur Standard.
• Utilisez le rôle Microsoft Entra Joined Device Local Administrator pour le personnel du support plutôt que d'ajouter des individus sur chaque appareil. Il s'applique à tous les appareils joints à Entra, ne peut pas être limité à un sous-ensemble, et les modifications ne prennent effet qu'après l'émission d'un nouveau Primary Refresh Token (jusqu'à 4 heures) et une déconnexion/reconnexion de l'utilisateur.

Pour un ciblage par groupe d'appareils, ajoutez des groupes Microsoft Entra (par SID) au groupe Administrators avec la stratégie Local user group membership ci-dessus. Windows évalue au maximum 20 groupes Entra pour les droits d'administration, et cette méthode par groupe ne s'applique pas aux appareils en jonction hybride Microsoft Entra.

Étape 5 : fournir un chemin d'élévation contrôlé

Certains utilisateurs auront toujours besoin d'élever des fichiers précis. Microsoft Intune Endpoint Privilege Management (EPM), disponible via l'Intune Suite, Intune Plan 2 ou en module complémentaire, et inclus dans Microsoft 365 E5 depuis juillet 2026, permet à un utilisateur standard d'exécuter un fichier approuvé avec élévation sans être administrateur. Vous configurez deux types de stratégies :

• Elevation settings policy : active EPM sur l'appareil et définit la réponse d'élévation par défaut pour les fichiers qui ne correspondent à aucune règle (refus, confirmation par l'utilisateur ou approbation par le support).
• Elevation rules policy : règles par fichier, basées sur le nom du fichier, le hash, le certificat de signature et la version, avec un type d'élévation automatique, confirmé par l'utilisateur (avec justification et authentification Windows facultatives) ou approuvé par le support.

Privilégiez les règles certificat + nom de fichier pour les outils signés des éditeurs, et les règles par hash pour les utilitaires internes. Évitez les règles qui élèvent des hôtes de script, cmd.exe, powershell.exe, mmc.exe ou des installeurs capables de lancer des processus enfants arbitraires : un shell élevé, c'est de l'admin local sous un autre nom.

Sans EPM, la solution de repli est une procédure du support dans laquelle un technicien saisit le mot de passe LAPS de l'appareil dans l'invite UAC. Le mot de passe est ensuite renouvelé automatiquement par l'action post-authentification.

Étape 6 : conserver un accès d'urgence

Préparez le jour où un appareil perd la relation d'approbation avec le domaine ou ne peut plus joindre Entra ID. Le compte d'urgence d'un poste de travail est son administrateur local géré par LAPS : unique par appareil, récupérable par le groupe de lecteurs du support, renouvelé après usage. Vérifiez que ce compte est inclus dans la stratégie d'appartenance appliquée aux étapes 3 et 4, et qu'il se voit refuser l'ouverture de session réseau et RDP, afin de ne fonctionner qu'à la console.

Ce qui casse

• Les logiciels et extensions de navigateur auto-installés qui s'installent au niveau de la machine. Attendez-vous à un pic de demandes les deux premières semaines ; le catalogue de l'étape 2 en absorbe la majorité.
• Les applications qui écrivent dans des emplacements protégés à l'exécution. Elles échouent, ou écrivent silencieusement dans le magasin virtualisé (voir UAC et Administrator protection). Corrigez les permissions sur le chemin concerné.
• Les tâches planifiées et scripts créés par les utilisateurs qui s'exécutaient avec les privilèges les plus élevés. Basculez les tâches légitimes dans un déploiement géré.
• Les habitudes du support. Les techniciens habitués à saisir leur propre compte Domain Admin sur la machine d'un utilisateur doivent passer à LAPS ou à un compte Tier 2. Ce changement est en soi un gain de sécurité.

Vérifier

1. Relancez l'inventaire de l'étape 1 une fois la stratégie appliquée. Seuls les membres définis par la stratégie doivent apparaître.
2. Auditez les modifications. Activez Audit Security Group Management dans Advanced Audit Policy Configuration. Le journal Security enregistre alors l'événement 4732 (un membre a été ajouté à un groupe local de sécurité) et 4733 (un membre a été supprimé). Déclenchez une alerte sur les 4732 concernant le groupe Administrators en dehors de votre processus de changement.
3. Consultez les rapports Intune. Pour la stratégie Local user group membership, l'état par appareil montre les conflits et les échecs, généralement dus à une GPO qui s'oppose à la règle Intune sur les appareils en cogestion.
4. Vérifiez le jeton de l'utilisateur. Sur l'appareil d'un utilisateur, whoami /groups ne doit pas du tout lister BUILTIN\Administrators pour la session de l'utilisateur.

Liste de contrôle

• Inventaire de l'appartenance au groupe Administrators local collecté sur tout le parc
• Domain Users, Authenticated Users et SID orphelins supprimés
• Raisons des droits d'administration recensées et remplacées (catalogue logiciel, imprimantes, permissions de dossiers)
• Une seule stratégie propriétaire du groupe Administrators (GPP, Restricted Groups ou Intune Replace)
• La jonction Entra et Autopilot ne font plus des utilisateurs des admins locaux
• EPM ou procédure du support basée sur LAPS pour l'élévation, aucun compte d'administration partagé
• Compte LAPS inclus dans la stratégie comme accès d'urgence, ouverture de session réseau refusée
• Événement 4732 sur le groupe Administrators local surveillé

Retirer les droits d'admin local est l'un des projets les moins spectaculaires et les plus efficaces d'un plan de durcissement Windows. Une fois les utilisateurs devenus standard, des contrôles comme le contrôle des applications deviennent applicables, car un utilisateur standard ne peut plus les désactiver.