DIDOES ITEndpoint Engineering← Tous les articles

Recommandation / Modern Management

Windows LAPS avec Intune : déployer, déléguer et auditer la récupération

Windows LAPS réduit le risque d’un mot de passe administrateur local partagé. Sa valeur dépend pourtant du design des comptes, du répertoire de sauvegarde et du contrôle strict de ceux qui peuvent lire ou faire tourner le secret.

À propos des exemples

Je publie les diagnostics en niveau 1 et les exemples de remédiation au minimum en niveau 2. Ils restent pédagogiques, non testés et ne doivent pas être utilisés tels quels. Avant tout essai réel, adaptez-les au contexte, utilisez la simulation quand elle existe et validez le rollback sur un pilote représentatif.

01

Position recommandée

Intune configure le Windows LAPS CSP via Endpoint Security Account protection. Le poste sauvegarde vers Microsoft Entra ID ou Active Directory selon BackupDirectory et son type de jointure, jamais vers les deux simultanément.

Le compte built-in est identifié par RID ; un compte custom doit exister sur les versions antérieures, tandis qu’Automatic Account Management sur Windows 11 24H2+ ajoute de nouvelles capacités à segmenter par version.

La lecture d’un mot de passe déclenche un audit. Je sépare création policy, rotation et lecture avec des rôles minimaux, puis je teste les post-authentication actions et la perte d’un objet device.

Intune configure le Windows LAPS CSP via Endpoint Security Account protection. Le poste sauvegarde vers Microsoft Entra ID ou Active Directory selon BackupDirectory et son type de jointure, jamais vers les deux simultanément.
02

Besoin, cas d’usage et périmètre de la recommandation

BackupDirectory 1 cible Entra et 2 Active Directory ; 0 désactive la sauvegarde et rend les autres réglages sans effet utile. Le type de jointure doit supporter la destination.

AdministratorAccountName n’est pas nécessaire pour le built-in account reconnu par RID. Pour un custom account manuel, LAPS ne le crée pas sur les anciennes versions et peut ne pas signaler clairement son absence.

Je commence par nommer le propriétaire de la décision, la population concernée et la preuve attendue. Cette étape paraît administrative, mais elle évite qu’un réglage technique soit utilisé pour compenser une responsabilité non définie entre identité, sécurité, support et gestion du poste.

La console cloud représente une intention et un état remonté. Je la compare toujours au résultat local, à l’identité réellement utilisée et à l’heure du dernier traitement. Une valeur verte, une affectation ou un HTTP 200 ne suffit pas à prouver tout le parcours.

  • Résultat recherché : comprendre l’architecture et ses limites
  • Résultat recherché : mettre en œuvre un pilote observable
  • Résultat recherché : construire une exploitation avec critères GO/NO-GO
  • Dans le périmètre : Windows LAPS, Intune, Microsoft Entra
  • Dans le périmètre : postes Windows et services Microsoft documentés
  • Dans le périmètre : pilote représentatif avant généralisation
03

Critères de décision et options possibles

Pour « Windows LAPS avec Intune », je formule une position recommandée, mais pas une valeur prétendument universelle. Je la confronte aux licences, au niveau de risque, aux dépendances réseau, aux responsabilités de support, aux populations visées et à la maturité opérationnelle de l’organisation.

Lorsque plusieurs méthodes sont supportées, je compare leur simplicité, leur réversibilité, leur observabilité et le risque d’autorités concurrentes. La méthode retenue doit rendre explicites la propriété du paramètre, les exceptions acceptées et la façon de prouver le résultat.

Le déploiement suit des anneaux avec critères GO et NO-GO, durée d’observation, seuils mesurables et responsable de décision. Une recommandation n’est validée qu’après un pilote représentatif et un rollback réellement exercé.

Je sépare aussi la valeur recommandée de la politique qui permet de la distribuer. Une même intention peut être portée par le Settings Catalog, Endpoint Security, une baseline, un CSP, une GPO ou un autre outil. Le bon choix dépend de l’autorité qui doit rester propriétaire, de la granularité de reporting et du risque de conflit. Je documente la méthode écartée lorsque sa présence future créerait une ambiguïté.

Les exceptions ne sont pas des oublis de ciblage. Elles disposent d’un motif, d’un responsable, d’une mesure compensatoire, d’une date d’expiration ou de revue et d’un moyen de les retrouver. Cette gouvernance évite qu’un pilote temporaire ou une exclusion de dépannage ne devienne silencieusement la configuration permanente du parc.

04

Architecture cible et répartition des responsabilités

BackupDirectory 1 cible Entra et 2 Active Directory ; 0 désactive la sauvegarde et rend les autres réglages sans effet utile. Le type de jointure doit supporter la destination.

AdministratorAccountName n’est pas nécessaire pour le built-in account reconnu par RID. Pour un custom account manuel, LAPS ne le crée pas sur les anciennes versions et peut ne pas signaler clairement son absence.

PasswordAgeDays, longueur, complexité ou passphrase et post-authentication actions sont choisis selon support OS. Une valeur non supportée peut revenir à un défaut ; je segmente les policies.

FLUXChaîne fonctionnelle — Windows LAPS avec Intune
  1. PolicyCSP définit compte, durée et actions.
  2. DeviceGénère, applique et fait tourner.
  3. DirectoryEntra ou AD stocke le secret.
  4. OperatorRBAC, audit et usage justifié.

Chaque étape doit produire sa propre preuve. Un succès en amont ne garantit pas que les étapes suivantes ont terminé leur traitement.

05

Prérequis, gouvernance et préparation

Avant de créer la configuration, je définis le propriétaire fonctionnel, le propriétaire technique, la population pilote, les exclusions, la durée d’observation et la personne habilitée à déclencher le rollback.

Je capture aussi l’état initial : licences, versions, affectations, autorités, dépendances et métriques. Cette baseline rend la recommandation mesurable et évite de confondre amélioration réelle et variation naturelle du parc.

  • versions Windows LAPS supportées
  • Entra LAPS activé si nécessaire
  • destination compatible avec join
  • compte géré défini
  • RBAC lecture/rotation séparé
  • audit Entra accessible
  • procédure support avec justification
06

Fonctionnement détaillé et frontières de responsabilité

BackupDirectory 1 cible Entra et 2 Active Directory ; 0 désactive la sauvegarde et rend les autres réglages sans effet utile. Le type de jointure doit supporter la destination.

AdministratorAccountName n’est pas nécessaire pour le built-in account reconnu par RID. Pour un custom account manuel, LAPS ne le crée pas sur les anciennes versions et peut ne pas signaler clairement son absence.

PasswordAgeDays, longueur, complexité ou passphrase et post-authentication actions sont choisis selon support OS. Une valeur non supportée peut revenir à un défaut ; je segmente les policies.

  • versions Windows LAPS supportées
  • Entra LAPS activé si nécessaire
  • destination compatible avec join
  • compte géré défini
07

Mise en œuvre, exploitation et cas limites

Automatic Account Management à partir de Windows 11 24H2 peut créer/gérer et randomiser le nom selon options. Je le pilote séparément des postes downlevel.

Lire le mot de passe exige une permission Entra de deviceLocalCredentials ; la rotation Intune demande Remote tasks: Rotate Local Admin Password, non incluse par défaut dans les rôles built-in indiqués.

Supprimer l’objet Entra détruit aussi le credential LAPS associé. Avant nettoyage de doublons, je vérifie accès local, BitLocker, sauvegarde et procédure de récupération.

  • Tester lecture avec rôle minimal
  • Tester action post-authentification
  • Contrôler audit et perte objet
08

Méthode de validation à l’échelle du parc

Pour windows laps avec intune, je constitue un échantillon qui couvre au minimum deux modèles matériels, plusieurs profils utilisateur, un site réseau contraint et les exceptions métier connues. Un résultat homogène sur des machines de laboratoire identiques ne démontre pas la robustesse de la configuration.

Je mesure la couverture, le taux de succès, le délai de convergence, le nombre d’exceptions, les incidents et le temps de retour à l’état connu. Les seuils sont définis avant le pilote afin de ne pas les adapter après coup pour justifier une généralisation.

Les cas négatifs font partie de la recette : appareil hors ligne, identité non éligible, permission absente, version non supportée, conflit volontaire et rollback. Le système doit échouer de manière visible et sûre, sans exposer de secret ni créer une dérive silencieuse.

La généralisation suit des anneaux dont la composition reste stable pendant l’observation. Chaque vague dispose d’un propriétaire, d’une fenêtre, d’une consigne support et d’un point d’arrêt. Je n’ouvre la vague suivante qu’après la clôture des écarts de la précédente.

09

Configuration recommandée et déploiement par étapes

La procédure applique la méthode recommandée sur un périmètre pilote. Chaque étape précise où agir, quoi configurer, le résultat attendu, la façon de le vérifier, l’impact et la méthode de retour arrière.

Je ne poursuis pas si le résultat attendu manque. Une extension réalisée sur un état partiellement compris rendrait les écarts plus coûteux à isoler et à corriger.

PROCÉDUREDéploiement contrôlé de la recommandation
  1. 01Qualifier l’état initial
    Emplacement
    Intune, Entra et poste de référence
    Commande / configuration
    Activer LAPS dans Entra si requis.
    Résultat attendu
    Identité, autorité, versions et écarts sont documentés.
    Vérification
    Comparer portail, inventaire local et sources publiques.
    Impact
    Lecture seule.
    Retour arrière
    Aucun.
  2. 02Configurer le pilote
    Emplacement
    Groupe, policy ou service pilote
    Commande / configuration
    Créer policy Account protection pilote.
    Résultat attendu
    Une seule modification ciblée est appliquée à une audience limitée.
    Vérification
    Relire affectations, exclusions, permissions et configuration effective.
    Impact
    Modification limitée au pilote.
    Retour arrière
    Retirer l’affectation et restaurer la configuration précédente.
  3. 03Observer le traitement
    Emplacement
    Rapports cloud et journaux du poste
    Commande / configuration
    Choisir destination et compte.
    Résultat attendu
    Chaque couche produit une preuve corrélée et les écarts sont expliqués.
    Vérification
    Comparer le résultat attendu à deux cycles complets et aux cas négatifs.
    Impact
    Collecte de preuves minimisées.
    Retour arrière
    Aucun pour la lecture ; conserver les traces.
  4. 04Décider la généralisation
    Emplacement
    Comité de changement et runbook d’exploitation
    Commande / configuration
    Vérifier rotation et backup.
    Résultat attendu
    Les seuils GO sont atteints ou le lot reste en NO-GO.
    Vérification
    Vérifier KPI, incidents, rollback et capacité du support.
    Impact
    Extension progressive ou arrêt du changement.
    Retour arrière
    Suspendre la vague et appliquer le rollback documenté.

La généralisation reste conditionnée aux critères d’acceptation et à la stabilité observée sur le pilote.

10

Paramètres, commandes et automatisation

Les commandes présentées servent à vérifier ou illustrer la configuration. Les diagnostics sont des exemples non testés de niveau 1. Toute remédiation est au minimum de niveau 2 avec simulation lorsque l’action s’y prête, puis doit être adaptée et testée avant usage réel.

Je documente le contexte utilisateur ou SYSTEM, les permissions, les valeurs attendues et les effets de bord. Un extrait ne doit jamais introduire un paramètre implicite ou masquer une modification d’état.

POWERSHELLÉtat Windows LAPS sans secret — niveau 1
# Exemple pédagogique non testé — niveau 1
$ErrorActionPreference = 'Stop'
try {
 Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 80 | Select-Object TimeCreated,Id,LevelDisplayName,Message
 Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Policies\LAPS' -ErrorAction SilentlyContinue | Select-Object BackupDirectory,PasswordAgeDays,PasswordLength,AdministratorAccountName
}
catch { Write-Error "Collecte LAPS impossible : $($_.Exception.Message)"; exit 1 }

Ne lit et n’affiche aucun mot de passe LAPS.

11

Validation, indicateurs et critères GO / NO-GO

La validation combine un contrôle technique local, la donnée de service et un indicateur d’usage ou d’exploitation adapté. Un état vert dans le portail ne prouve pas à lui seul que le besoin initial est satisfait.

Le passage à la vague suivante exige des seuils atteints, aucune régression critique, des exceptions documentées et un rollback disponible. Toute divergence inexpliquée maintient la décision en NO-GO.

  • Activer LAPS dans Entra si requis.
  • Créer policy Account protection pilote.
  • Choisir destination et compte.
  • Vérifier rotation et backup.
  • Tester lecture avec rôle minimal
  • Tester action post-authentification
  • Contrôler audit et perte objet
12

Exploitation, journaux et contrôle continu

Le diagnostic de « Windows LAPS avec Intune » relie l’heure de la demande, l’identité, l’objet cloud, le poste et le résultat final. Je conserve les identifiants de corrélation utiles, mais je masque UPN, DeviceId, TenantId, noms internes, secrets, certificats privés et contenus métiers avant tout partage.

Je différencie absence de configuration, non-applicabilité, attente, erreur transitoire, refus d’autorisation et échec du composant local. Ces états n’appellent pas la même correction. Répéter une synchronisation ne transforme pas une politique non applicable en politique valide.

La collecte initiale reste en lecture seule. Une remédiation réelle doit être écrite au minimum au niveau 2, proposer une simulation, borner sa cible et restaurer l’état précédent. Pour une opération tenant-wide, privilégiée ou critique, les niveaux 3 ou 4 et une approbation formelle sont nécessaires.

  • Activer LAPS dans Entra si requis.
  • Créer policy Account protection pilote.
  • Choisir destination et compte.
  • Vérifier rotation et backup.
  • Tester lecture avec rôle minimal
  • Tester action post-authentification
  • Contrôler audit et perte objet
MATRICELecture structurée des preuves
CoucheQuestionPreuve attendueDécision
CiblageL’objet devait-il recevoir la configuration ?Affectation, filtre, groupe et licenceCorriger le ciblage avant le client
TransportLa demande a-t-elle atteint le service ou le poste ?Horodatage, événement, request-id ou check-inTraiter réseau, identité ou service
TraitementLe composant a-t-il évalué et appliqué ?Journal, état par setting ou résultat APICorriger le composant ou la valeur
RésultatL’objectif métier est-il atteint ?Contrôle local et rapport corréléValider ou maintenir NO-GO
13

Exceptions, erreurs connues et traitement

Une recommandation exploitable doit prévoir les exceptions et les échecs. Je relie chaque symptôme à une cause à confirmer et à une preuve ; la correction n’est appliquée que lorsque cette preuve est obtenue.

Les exceptions durables ont un propriétaire, une justification, une date de révision et une mesure compensatoire. Elles ne sont pas dissimulées dans un groupe d’exclusion sans gouvernance.

MATRICEMatrice de diagnostic
SymptômeCause à confirmerPreuve recherchéeCorrection ciblée
Policy réussie, aucun secretCompte absent/destination incompatibleLAPS Operational et joinCréer compte ou corriger directory
Bouton griséPermission rotation absenteRBAC IntuneCréer rôle minimal
Lecture refuséePermission Entra absenteAudit/role assignmentAccorder standard/password read selon besoin
Rotation ne se fait pasDevice disabled/offlineDevice state et LAPS logRéactiver/connecter
Ancien secret perduObjet Entra suppriméAudit device deletionSuivre procédure de récupération locale

Une cause reste une hypothèse tant qu’elle n’est pas confirmée par une preuve locale ou une donnée de service corrélée.

14

Rollback, gestion du changement et points de vigilance

Le rollback est préparé avant le pilote et restaure explicitement la valeur, l’affectation ou l’autorité précédente. Je vérifie ensuite la convergence locale et la remontée du nouvel état au lieu de m’arrêter à la suppression de la configuration.

La recommandation doit être réévaluée lors d’une évolution de licence, de version, de support ou de responsabilité. Une validation locale ne constitue jamais une qualification de production.

  • Rollback : retirer policy pilote
  • Rollback : restaurer ancien mécanisme LAPS pendant transition
  • Rollback : désactiver compte custom seulement après preuve d’accès
  • Point de vigilance : ne jamais copier mot de passe dans ticket
  • Point de vigilance : suppression device perd le credential
  • Point de vigilance : une seule destination
  • Point de vigilance : segmenter Automatic Account Management
R

Repères d’utilisation

Cette analyse propose une méthode opérationnelle et un cadre de décision. Avant toute application à grande échelle, vérifiez les versions, les licences et les comportements sur un environnement pilote représentatif de votre contexte.

Références techniques publiques

J’ai privilégié la documentation Microsoft pour les comportements contractuels. Les retours terrain complètent l’observation, sans remplacer la documentation de support.

Windows LAPSIntuneMicrosoft EntraLocal adminRBACPassword rotation

Continuer la lecture

Modern Workplace LabOMA-DM et WinDC en double inscriptionEndpoint LabDiagnostic complet des applications Win32