Windows LAPS et Intune - Sécurisez vos comptes locaux

Quand je mets en place LAPS avec Microsoft Intune, je cherche surtout à résoudre un problème simple: garder un compte administrateur local récupérable sans laisser un mot de passe identique traîner sur tous les postes. Ce sujet touche à la sécurité, au support et à l’exploitation quotidienne, donc je vais aller droit à ce qui compte: ce que fait vraiment Windows LAPS, où stocker les secrets, comment créer la politique dans Intune et quels pièges évitent les blocages en production.

Pourquoi je préfère Windows LAPS à un mot de passe local figé

Le compte administrateur local intégré est pratique, mais il devient vite une faiblesse si son mot de passe reste stable d’un poste à l’autre. Avec Windows LAPS, je ne cherche pas à multiplier les comptes: je veux un mot de passe unique, fort, renouvelé et récupérable quand le support en a besoin. C’est exactement ce que LAPS apporte: réduction du risque de pass-the-hash, meilleure réponse pour le support à distance et capacité à reprendre la main sur un appareil devenu difficile à ouvrir.

Le point que beaucoup sous-estiment, c’est que Windows LAPS n’est pas un outil “en plus” qu’on ajoute par habitude. C’est une fonctionnalité native de Windows, et c’est important parce que l’ancien Microsoft LAPS est désormais dépassé sur les versions récentes. En pratique, si je démarre un déploiement aujourd’hui, je pars sur Windows LAPS et pas sur une ancienne chaîne de gestion que je vais devoir migrer plus tard.

Je résume l’intérêt opérationnel ainsi: si un poste a besoin d’un compte local de secours, ce compte ne doit jamais avoir un mot de passe immuable. Cette logique devient encore plus solide quand elle est pilotée par Intune, parce que la politique suit l’état réel du parc plutôt qu’une configuration isolée sur chaque machine. La vraie question devient alors: où stocker ce mot de passe et comment l’exploiter proprement?

Choisir entre Microsoft Entra ID et Active Directory local

Le premier choix sérieux n’est pas technique au sens strict, il est architectural. Je dois décider si le mot de passe sera sauvegardé dans le cloud Microsoft Entra ID ou dans Active Directory local. Ce choix dépend moins d’une préférence que du type de jointure des appareils et de la manière dont votre support travaille au quotidien.

Le point décisif, c’est que vous ne pouvez pas sauvegarder le mot de passe à la fois dans Entra ID et dans Active Directory local. Sur un appareil Entra-only, le cloud est la voie naturelle. Sur un parc encore très lié au domaine, AD local reste pertinent. Mais si vous essayez de forcer une configuration qui ne correspond pas au mode de jointure, la politique peut être acceptée par Intune tout en échouant côté LAPS sur le poste. C’est le genre de détail qui crée des tickets inutiles.

Je recommande aussi de penser au support plutôt qu’au seul stockage. Si votre équipe doit régulièrement récupérer des mots de passe depuis le portail, Entra ID est plus simple. Si votre organisation garde encore une chaîne de gestion locale avec des contrôles stricts on-prem, AD local reste cohérent. La suite logique consiste donc à vérifier les prérequis avant de toucher à la console.

Vérifier les prérequis avant de créer la politique

Quand je prépare un déploiement, je valide toujours les bases avant de créer le moindre profil. C’est plus rapide de corriger un prérequis que de diagnostiquer une politique “verte” qui ne produit aucun effet. Pour Windows LAPS avec Intune, les vérifications essentielles sont assez nettes.

Je garde aussi une règle simple en tête: les appareils workplace-joined ne sont pas pris en charge pour LAPS dans Intune. Et si vous maintenez encore Windows 10 dans le parc, il faut le regarder comme un cas de transition, pas comme la base d’un nouveau design. Microsoft a d’ailleurs indiqué la fin de support de Windows 10 au 14 octobre 2025, ce qui pousse clairement les nouveaux déploiements à se construire autour des versions Windows plus récentes.

Une autre vérification utile concerne les rôles. Pour créer ou gérer une politique, les droits de la catégorie Security baselines sont requis, avec par défaut le rôle Endpoint Security Manager. Pour afficher ou faire tourner les mots de passe, les permissions sont encore plus précises. J’y reviens tout de suite, car c’est souvent là que les équipes bloquent au moment où elles veulent valider le fonctionnement réel.

Configurer la politique Windows LAPS dans Intune

À ce stade, je privilégie une configuration simple et lisible. L’idée n’est pas de remplir tous les champs “par principe”, mais de définir une politique stable, cohérente avec le type de poste et facile à dépanner. Une bonne politique LAPS est une politique que l’on comprend encore six mois plus tard.

1. Je vais dans Endpoint security > Account protection, puis je crée une nouvelle policy Windows LAPS.
2. Je choisis la plateforme Windows et le profil Local admin password solution (Windows LAPS).
3. Je renseigne un nom explicite et, si besoin, une description courte mais utile.
4. Dans la configuration, je définis le Backup Directory selon le contexte: Entra ID ou Active Directory local.
5. Je vérifie le nom du compte administrateur si je ne veux pas utiliser le compte local intégré par défaut.
6. J’ajuste les paramètres de mot de passe, notamment la complexité, la longueur et l’âge du mot de passe.
7. J’assigne la politique à des groupes d’appareils, pas à des groupes d’utilisateurs.
8. Je termine par un contrôle de cohérence avant création.

Le point qui mérite d’être martelé, c’est celui-ci: Intune ne crée pas de nouveaux comptes ni de nouveaux mots de passe. Il gère un compte déjà présent sur l’appareil. Si vous indiquez un nom de compte qui n’existe pas, aucun compte ne sera géré. Et si vous laissez le champ vide, la politique s’appuie sur le compte administrateur local intégré identifié par son RID connu.

J’insiste aussi sur l’assignation. Microsoft recommande d’utiliser des groupes d’appareils. C’est une bonne pratique, parce qu’un LAPS assigné à des groupes d’utilisateurs peut suivre la personne d’un PC à l’autre et faire varier le comportement au pire moment. En environnement réel, c’est une source classique d’incohérence: le compte géré change, la rotation se décale ou les conflits apparaissent sans raison visible pour l’équipe support. La surveillance et la lecture des secrets viennent ensuite, et c’est là que la visibilité opérationnelle devient utile.

Contrôler l’état, lire le mot de passe et faire tourner l’accès

Une politique qui s’applique ne suffit pas. Je veux pouvoir voir ce qui se passe, savoir si la rotation a réussi et intervenir manuellement si un poste doit être sécurisé plus vite. Intune propose justement ces contrôles, à condition d’avoir les bons droits et le bon mode de sauvegarde.

Pour lire le mot de passe dans Intune, il faut les permissions Microsoft Entra adaptées, par exemple microsoft.directory/deviceLocalCredentials/password/read. Si vous n’avez que la lecture des métadonnées, vous verrez les informations utiles sans révéler le mot de passe lui-même. Pour la rotation manuelle, les droits Intune doivent couvrir Managed devices: Read, Organization: Read et Remote tasks: Rotate Local Admin Password.

La rotation manuelle est utile quand un incident de support a rendu l’accès plus sensible que d’habitude. Mais je la traite comme une action ciblée, pas comme un réflexe de masse. Le dispositif fonctionne, mais il reste soumis à deux règles simples: l’appareil doit avoir bien remonté sa politique LAPS et, pour les appareils Entra join, il doit être en ligne au moment de la demande. Une fois la rotation lancée, le délai jusqu’à la prochaine rotation planifiée est recalculé selon le paramètre PasswordAgeDays. C’est propre, mais il faut le savoir pour ne pas s’étonner d’un nouveau cycle qui repart plus tôt que prévu.

Quand la visibilité est bonne, les problèmes deviennent plus faciles à isoler. Justement, il y a quelques erreurs récurrentes que je vois revenir dans presque tous les déploiements ratés, et elles sont assez prévisibles.

Les pièges qui reviennent dans les déploiements réels

Je considère cette partie comme la plus utile pour éviter les retours en arrière. Les échecs LAPS ne viennent pas toujours d’une panne. Le plus souvent, ils viennent d’une incohérence de conception ou d’un détail de configuration qui a l’air mineur au départ.

• Le Backup Directory ne correspond pas au type de jointure. Un poste non domain-joined ne peut pas réussir une sauvegarde vers Active Directory local, même si la politique semble acceptée côté Intune.
• Plusieurs politiques se contredisent. LAPS ne tolère pas bien les configurations concurrentes pour un même réglage. Si deux profils fixent des valeurs différentes, le conflit est probable.
• La politique est assignée à des utilisateurs plutôt qu’à des appareils. Le comportement suit alors la personne, pas le poste, ce qui crée des variations difficiles à lire.
• Le compte ciblé n’existe pas sur l’appareil. Dans ce cas, aucun compte n’est géré, et l’on croit parfois à tort que la politique est cassée.
• Le poste n’a pas encore check-in avec Intune. Tant que la machine n’a pas appliqué la politique, les détails du compte local restent invisibles dans le portail.
• On essaie encore de faire cohabiter l’ancien Microsoft LAPS et le nouveau Windows LAPS sans stratégie de migration. Cela finit souvent par un conflit de source et une maintenance inutilement complexe.
• Le device est désactivé dans Entra. Dans ce cas, la rotation et la sauvegarde ne peuvent pas s’appliquer correctement.

Le piège le plus sous-estimé reste à mon avis la coexistence des sources. Intune prend la main via le CSP Windows LAPS, et cette couche écrase les configurations LAPS venant d’ailleurs, comme des GPO ou l’ancien outil Microsoft LAPS. Si vous n’avez pas décidé quelle source fait foi, vous finirez avec des écarts entre ce que vous croyez pousser et ce qui s’applique réellement sur le terrain.

Autre point de vigilance: la gestion automatique du compte, qui simplifie beaucoup la vie, n’est disponible qu’à partir de Windows 11 24H2. Si votre parc n’est pas homogène, je vous conseille de ne pas bâtir toute la stratégie autour de cette option. Mieux vaut un déploiement simple qui marche partout qu’une configuration “moderne” qui ne couvre qu’une partie des machines. C’est précisément cette logique de pragmatisme que j’applique avant de basculer en production.

Ce que je ferais avant de passer en production

Si je devais poser une stratégie propre, je ferais simple et robuste. Je commencerais par un pilote sur un petit groupe de machines représentatives, puis je validerais la lecture du mot de passe, la rotation planifiée, la rotation manuelle et le comportement après redémarrage. Tant que ces quatre points ne sont pas clairs, je n’élargis pas.

• Je standardise le stockage sur Microsoft Entra ID dès que le parc est Entra join ou hybride et que le support doit agir vite.
• Je garde une seule politique LAPS par appareil et je la distribue via des groupes d’appareils.
• Je documente séparément les rôles qui créent la politique, ceux qui lisent le mot de passe et ceux qui déclenchent une rotation.
• Je teste le comportement sur des versions Windows réellement présentes dans le parc, pas sur une machine de labo isolée du reste.
• Si je migre depuis l’ancien Microsoft LAPS, je prévois la bascule comme un chantier à part, pas comme un simple changement de case à cocher.

En pratique, LAPS avec Intune devient très solide quand on le traite comme un contrôle de sécurité et non comme un réglage de confort. C’est ce cadrage qui fait la différence entre un déploiement qui rassure le support et un déploiement qui multiplie les conflits. Si je devais résumer la bonne approche en une phrase, je dirais ceci: partez du type de jointure, choisissez le bon emplacement de sauvegarde, gardez une seule source de vérité et laissez Intune faire ce pour quoi il est fait.