LAPS : Gestion Sécurisée des Mots de Passe : Guide Complet

Dans la grande majorité des environnements Active Directory, un secret honteux persiste : le mot de passe du compte administrateur local est identique sur toutes les machines. Déployé via une GPO, un master image ou un script de provisionnement, ce mot de passe commun constitue l'un des vecteurs de mouvement latéral les plus exploités par les attaquants. LAPS (Local Administrator Password Solution) a été conçu spécifiquement pour résoudre ce problème en attribuant un mot de passe unique, aléatoire et régulièrement renouvelé à chaque compte administrateur local. Ce guide approfondi examine en detail les aspects fondamentaux et avances de LAPS, en proposant une analyse structuree et documentee des enjeux actuels. Les professionnels y trouveront des recommandations concretes, des methodologies eprouvees et des retours d'experience terrain directement applicables en environnement de production.

Le scénario est classique et redoutablement efficace : un attaquant compromet une première machine (phishing, exploitation d'une vulnérabilité, clé USB malveillante), extrait le hash NTLM du compte administrateur local via des outils comme Mimikatz ou secretsdump, puis utilise ce même hash pour se connecter à l'ensemble du parc via Pass-the-Hash. En quelques minutes, l'attaquant dispose d'un accès administrateur sur des centaines, voire des milliers de postes. C'est exactement ce mécanisme qui a permis à NotPetya en 2017 de paralyser des entreprises mondiales en quelques heures.

Les chiffres sont alarmants : lors de nos audits Active Directory, nous constatons que plus de 70 % des organisations utilisent encore un mot de passe administrateur local identique sur la totalité ou une partie significative de leur parc. Parmi celles qui ont déployé LAPS, environ un tiers présentent des erreurs de configuration -- ACL trop permissives, absence de rotation, ou couverture incomplète -- qui annulent en grande partie les bénéfices de la solution.

Avec l'arrivée de Windows LAPS (intégré nativement depuis Windows Server 2025 et les mises à jour d'avril 2023 pour Windows 10/11), Microsoft a considérablement enrichi la solution originale. Sauvegarde dans Azure AD/Entra ID, chiffrement des mots de passe, historique, gestion DSRM, et intégration Intune : Windows LAPS représente une évolution majeure. Ce guide couvre en profondeur les deux versions, le déploiement, la sécurisation et les attaques connues.

Point clé : LAPS n'est pas un luxe réservé aux grandes entreprises. C'est un contrôle de sécurité fondamental, gratuit, et déployable en quelques heures. Ne pas l'implémenter revient à laisser un passe-partout sous le paillasson de chaque machine de votre parc.

2. Comprendre le risque : anatomie du mouvement latéral via comptes admin locaux

2.1 Le scénario d'attaque type

Pour bien comprendre pourquoi LAPS est critique, déroulons un scénario d'attaque réaliste. Un attaquant obtient un premier accès sur un poste de travail -- par exemple via un document piégé envoyé par email. Il exécute son implant et obtient un shell utilisateur standard. Sa première action : tenter une escalade de privilèges locale vers SYSTEM ou Administrateur.

Une fois administrateur local, l'attaquant extrait les credentials stockés en mémoire ou dans la base SAM :

# Extraction des hashes locaux avec secretsdump (Impacket)
secretsdump.py -sam SAM -system SYSTEM -security SECURITY LOCAL

# Résultat typique :
# Administrator:500:aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42:::
# Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

# Pass-the-Hash vers d'autres machines
crackmapexec smb 10.0.0.0/24 -u Administrator -H e19ccf75ee54e06b06a5907af13cef42 --local-auth

Si le mot de passe administrateur local est identique sur toutes les machines, le hash NTLM sera aussi identique. L'attaquant peut alors effectuer un balayage massif du réseau et obtenir instantanément l'accès administrateur sur chaque machine répondant au même hash. C'est la technique du mouvement latéral par Pass-the-Hash, documentée sous MITRE ATT&CK T1550.002.

2.2 Impact concret : études de cas

Les incidents les plus critiques de la dernière décennie ont exploité cette faiblesse :

• NotPetya (2017) : le wiper utilisait EternalBlue combiné au Pass-the-Hash des comptes admin locaux pour se propager. Maersk, Merck, Saint-Gobain ont subi des pertes cumulées de plusieurs milliards d'euros.
• Ryuk / Conti (2020-2023) : les opérateurs de ransomware utilisaient systématiquement CrackMapExec avec le hash admin local pour cartographier et compromettre l'ensemble du parc avant le chiffrement.
• SolarWinds (2020) : bien que l'accès initial ait été via la supply chain, le mouvement latéral interne s'est appuyé en partie sur des comptes admin locaux partagés.

Savez-vous combien de comptes à privilèges existent réellement dans votre domaine ?

3. LAPS Legacy vs Windows LAPS : comparaison détaillée

3.1 LAPS Legacy (Microsoft LAPS)

La version originale de LAPS, publiée en 2015, fonctionne via une Client-Side Extension (CSE) de GPO. À chaque rafraîchissement de stratégie de groupe, la CSE vérifie si le mot de passe du compte administrateur local a expiré. Si oui, elle génère un nouveau mot de passe aléatoire conforme à la politique définie, l'applique au compte local et stocke le résultat dans deux attributs étendus de l'objet ordinateur dans Active Directory :

Attribut AD	Type	Contenu	Sécurité
ms-Mcs-AdmPwd	Confidential String	Mot de passe en clair	ACL restrictive requise
ms-Mcs-AdmPwdExpirationTime	Large Integer	Date d'expiration (FileTime)	Lisible par les machines

Le point critique : le mot de passe est stocké en clair dans l'attribut ms-Mcs-AdmPwd. La sécurité repose entièrement sur les ACL Active Directory. Si un attaquant obtient les droits de lecture sur cet attribut (ce qui est fréquent dans les configurations par défaut), il accède immédiatement au mot de passe de toutes les machines concernées. C'est l'attaque dite du LAPS dump, que nous détaillerons en section 8.

3.2 Windows LAPS (nouvelle génération)

Introduit nativement dans Windows à partir d'avril 2023, Windows LAPS corrige les limitations majeures de la version Legacy et ajoute des fonctionnalités significatives :

Fonctionnalité	LAPS Legacy	Windows LAPS
Stockage du mot de passe	AD uniquement, en clair	AD et/ou Entra ID, chiffré (optionnel)
Chiffrement	Non	Oui (AES-256, nécessite DFL 2016+)
Historique des mots de passe	Non	Oui (configurable)
Compte DSRM	Non	Oui (DC uniquement)
Gestion via Intune	Non	Oui
Sauvegarde Azure AD/Entra	Non	Oui
Post-authentication actions	Non	Oui (reset password + logoff)
Installation requise	MSI + Schema Extension	Natif (KB intégré)

4. Architecture technique de LAPS

4.1 Extension du schéma Active Directory

L'installation de LAPS (Legacy ou Windows LAPS) nécessite une extension du schéma Active Directory. Cette opération est irréversible mais sans risque -- elle ajoute simplement de nouveaux attributs aux objets Computer. Pour LAPS Legacy, l'extension ajoute deux attributs (ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime). Pour Windows LAPS, six attributs sont ajoutés :

# Extension du schéma pour Windows LAPS (exécuter sur le Schema Master)
# Nécessite les droits Schema Admin
Update-LapsADSchema

# Vérification de l'extension
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
  -Filter {name -like "msLAPS*"} -Properties * | 
  Select-Object name, adminDescription, attributeID

# Attributs ajoutés :
# msLAPS-PasswordExpirationTime     - Date d'expiration
# msLAPS-Password                   - Mot de passe (clair, JSON)
# msLAPS-EncryptedPassword           - Mot de passe chiffré (AES-256)
# msLAPS-EncryptedPasswordHistory    - Historique chiffré
# msLAPS-EncryptedDSRMPassword       - Mot de passe DSRM (DC)
# msLAPS-EncryptedDSRMPasswordHistory - Historique DSRM

4.2 Client-Side Extension (CSE) et cycle de vie du mot de passe

Le composant client de LAPS s'exécute en tant que Client-Side Extension de la stratégie de groupe. À chaque cycle de rafraîchissement GPO (par défaut toutes les 90 minutes + offset aléatoire de 0-30 minutes), la CSE effectue les étapes suivantes :

1. Vérification de l'expiration : la CSE compare l'heure actuelle avec msLAPS-PasswordExpirationTime stocké dans AD.
2. Génération du nouveau mot de passe : si expiration atteinte, un mot de passe aléatoire est généré selon la politique (longueur, complexité, jeu de caractères).
3. Application locale : le mot de passe est appliqué au compte administrateur local ciblé via l'API NetUserSetInfo.
4. Sauvegarde dans AD/Entra : le mot de passe (et optionnellement sa version chiffrée) est écrit dans les attributs de l'objet Computer dans AD et/ou Entra ID.
5. Post-authentication actions (Windows LAPS uniquement) : si configuré, après utilisation du mot de passe, la machine effectue automatiquement un reset et déconnecte les sessions actives.

4.3 Modèle de permissions (ACL)

4. Architecture technique de LAPS : analyse approfondie

La sécurité de LAPS repose fondamentalement sur les ACL Active Directory. Les machines doivent pouvoir écrire leur propre mot de passe (permission SELF WRITE sur les attributs LAPS), tandis que seuls les utilisateurs autorisés doivent pouvoir le lire. La configuration des permissions est critique :

# 1. Accorder aux machines le droit d'écrire leur propre mot de passe
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"

# 2. Accorder les droits de lecture à un groupe spécifique
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=local" `
  -AllowedPrincipals "CORP\LAPS-Password-Readers"

# 3. Accorder les droits de reset à un groupe (forcer le renouvellement)
Set-LapsADResetPasswordPermission -Identity "OU=Workstations,DC=corp,DC=local" `
  -AllowedPrincipals "CORP\LAPS-Password-Resetters"

# 4. AUDIT : vérifier qui a les droits de lecture actuellement
Find-LapsADExtendedRights -Identity "OU=Workstations,DC=corp,DC=local"
# CRITIQUE : cette commande révèle souvent des surprises (droits hérités trop larges)

Votre modèle de Tiering est-il réellement appliqué ou seulement documenté ?

5. Déploiement step-by-step de Windows LAPS

5.1 Prérequis et planification

Avant de déployer Windows LAPS, vérifiez les prérequis suivants :

• Niveau fonctionnel du domaine : DFL 2016 minimum pour le chiffrement des mots de passe (recommandé). DFL 2003+ pour le mode non chiffré.
• Systèmes d'exploitation clients : Windows 10 21H2+ / Windows 11 avec la mise à jour d'avril 2023 (KB5025221 pour Windows 10, KB5025239 pour Windows 11), ou Windows Server 2019+ avec les mises à jour correspondantes.
• Droits Schema Admin : pour l'extension du schéma (opération ponctuelle).
• GPO ou Intune : infrastructure de distribution des politiques.
• Connectivité Entra : si sauvegarde Azure AD souhaitée, Entra Connect ou Entra ID Join requis.

5.2 Étape 1 : Extension du schéma

# Sur le contrôleur de domaine Schema Master
# PowerShell en tant qu'administrateur (membre de Schema Admins)

Import-Module LAPS
Update-LapsADSchema -Verbose

# Vérification
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext `
  -Filter {name -like "msLAPS*"} | Select-Object name

5.3 Étape 2 : Configuration des permissions

# Créer les groupes de sécurité dédiés
New-ADGroup -Name "LAPS-Readers-Workstations" -GroupScope DomainLocal `
  -Path "OU=Security Groups,DC=corp,DC=local" `
  -Description "Lecture des mots de passe LAPS - Postes de travail"

New-ADGroup -Name "LAPS-Readers-Servers" -GroupScope DomainLocal `
  -Path "OU=Security Groups,DC=corp,DC=local" `
  -Description "Lecture des mots de passe LAPS - Serveurs"

New-ADGroup -Name "LAPS-Resetters" -GroupScope DomainLocal `
  -Path "OU=Security Groups,DC=corp,DC=local" `
  -Description "Forcer la rotation des mots de passe LAPS"

# Configurer les permissions par OU
# Postes de travail
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=local"
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=local" `
  -AllowedPrincipals "CORP\LAPS-Readers-Workstations"
Set-LapsADResetPasswordPermission -Identity "OU=Workstations,DC=corp,DC=local" `
  -AllowedPrincipals "CORP\LAPS-Resetters"

# Serveurs
Set-LapsADComputerSelfPermission -Identity "OU=Servers,DC=corp,DC=local"
Set-LapsADReadPasswordPermission -Identity "OU=Servers,DC=corp,DC=local" `
  -AllowedPrincipals "CORP\LAPS-Readers-Servers"
Set-LapsADResetPasswordPermission -Identity "OU=Servers,DC=corp,DC=local" `
  -AllowedPrincipals "CORP\LAPS-Resetters"

5.4 Étape 3 : Création de la GPO

Créez une GPO dédiée (ne mélangez pas les paramètres LAPS avec d'autres GPO) et configurez les paramètres sous Computer Configuration > Administrative Templates > System > LAPS :

# Configuration recommandée via GPO :

# 1. Configure password backup directory = Active Directory (ou les deux AD + Entra)
# 2. Password Settings :
#    - Complexity: Large letters + small letters + numbers + specials
#    - Length: 24 characters (minimum recommandé)
#    - Age (days): 30
# 3. Name of administrator account to manage: Administrator (ou nom personnalisé)
# 4. Enable password encryption: Enabled (nécessite DFL 2016+)
# 5. Configure size of encrypted password history: 12
# 6. Post-authentication actions:
#    - Grace period (hours): 8
#    - Actions: Reset password and logoff managed account
# 7. Configure authorized password decryptors: CORP\LAPS-Readers-Workstations

5.5 Étape 4 : Vérification du déploiement

# Vérifier le statut LAPS sur une machine spécifique
Get-LapsADPassword -Identity "PC-USER01" -AsPlainText

# Résultat attendu :
# ComputerName        : PC-USER01
# DistinguishedName   : CN=PC-USER01,OU=Workstations,DC=corp,DC=local
# Account             : Administrator
# Password            : x7#kQ9!mN2pR5&wL8*bV3$jF
# PasswordUpdateTime  : 01/03/2026 07:15:42
# ExpirationTimestamp : 31/03/2026 07:15:42
# Source              : EncryptedPassword
# DecryptionStatus    : Success

# Vérification en masse
Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=corp,DC=local" `
  -Properties msLAPS-PasswordExpirationTime | 
  Select-Object Name, @{N="LAPSExpiration";E={
    [datetime]::FromFileTime($_.'msLAPS-PasswordExpirationTime')
  }} | Sort-Object LAPSExpiration

6. Windows LAPS avec Intune et Entra ID

6.1 Scénarios cloud et hybrides

Windows LAPS s'intègre nativement avec Microsoft Entra ID pour les machines jointes à Azure AD (Entra ID Join) ou hybrides (Hybrid Entra ID Join). Cette intégration permet de stocker les mots de passe LAPS directement dans le cloud, sans dépendance à un Active Directory on-premises, et de les gérer via le portail Entra ou Intune.

Trois scénarios de stockage sont possibles :

Scénario	Stockage	Gestion	Cas d'usage
AD uniquement	Active Directory	GPO + PowerShell	Environnement on-premises pur
Entra ID uniquement	Azure AD/Entra	Intune + Portail Entra	Cloud-only, AAD Join
Hybride (les deux)	AD + Entra ID	GPO/Intune + Portail	Hybrid Join, migration progressive

6.2 Configuration Intune

Pour gérer LAPS via Intune, créez une politique de configuration dans Endpoint Security > Account Protection > Local Admin Password Solution (Windows LAPS) :

# Paramètres Intune recommandés :

# Backup Directory: Backup the password to Azure AD only
#   (ou "Backup to both Azure AD and Active Directory" en hybride)
# Password Age (Days): 30
# Administrator Account Name: (laisser vide pour RID 500 par défaut)
# Password Complexity: Large + Small + Numbers + Special characters
# Password Length: 24
# Post Authentication Actions:
#   Grace Period (Hours): 8
#   Action: Reset password and logoff the managed account

# Attribution : assigner la politique à un groupe d'appareils

La consultation du mot de passe se fait via le portail Entra ID : Devices > All Devices > [Device] > Local administrator password, ou via le portail Intune : Devices > [Device] > Local admin password. Les rôles Entra requis pour la lecture sont Cloud Device Administrator ou un rôle personnalisé avec la permission microsoft.directory/deviceLocalCredentials/password/read.

6.3 RBAC et audit dans Entra ID

L'un des avantages majeurs de l'intégration Entra est l'auditabilité. Chaque consultation de mot de passe LAPS est enregistrée dans les Entra ID Audit Logs. Vous pouvez créer des alertes automatiques pour détecter les lectures suspectes :

# Requête KQL dans Microsoft Sentinel pour détecter les lectures LAPS suspectes
AuditLogs
| where OperationName == "Recover device local administrator password"
| project TimeGenerated, InitiatedBy.user.userPrincipalName, 
          TargetResources[0].displayName, ResultDescription
| where InitiatedBy.user.userPrincipalName !in ("admin-t0@corp.onmicrosoft.com",
                                                  "helpdesk-lead@corp.onmicrosoft.com")
| sort by TimeGenerated desc

7. Audit, monitoring et détection

7.1 Événements Windows à surveiller

Windows LAPS génère des événements dans le journal Microsoft-Windows-LAPS/Operational. Les événements clés à collecter dans votre SIEM sont :

Event ID	Description	Criticité
10018	Mot de passe mis à jour avec succès dans AD	Information
10019	Mot de passe mis à jour avec succès dans Entra ID	Information
10020	Échec de mise à jour du mot de passe	Critique
10021	Post-authentication action exécutée	Information
10022	Échec de la post-authentication action	Élevée
10029	LAPS policy processing started	Information

7.2 Détection des accès non autorisés aux mots de passe LAPS

L'audit des accès aux attributs LAPS dans Active Directory nécessite l'activation du Directory Service Access Auditing. Configurez une SACL (System Access Control List) sur les OUs contenant vos machines pour auditer les lectures des attributs msLAPS-Password et msLAPS-EncryptedPassword :

# Activation de l'audit Directory Service Access via GPO :
# Computer Configuration > Policies > Windows Settings > Security Settings
# > Advanced Audit Policy Configuration > DS Access
# > Audit Directory Service Access : Success, Failure

# Requête KQL pour Microsoft Sentinel
SecurityEvent
| where EventID == 4662
| where ObjectType contains "bf967a86-0de6-11d0-a285-00aa003049e2" // Computer object
| where Properties contains "msLAPS" or Properties contains "ms-Mcs-AdmPwd"
| project TimeGenerated, SubjectUserName, SubjectDomainName, 
          ObjectName, Properties, AccessMask
| where SubjectUserName !in ("SYSTEM", "NT AUTHORITY")
| sort by TimeGenerated desc

7.3 Dashboard de couverture LAPS

Un point fondamental souvent négligé : vérifier que LAPS couvre effectivement 100 % du parc. Les nouvelles machines, les machines récemment jointes au domaine ou les machines dans des OUs non couvertes sont autant de trous dans le dispositif :

# Script PowerShell : rapport de couverture LAPS
$AllComputers = Get-ADComputer -Filter {Enabled -eq $true} -Properties `
  msLAPS-PasswordExpirationTime, OperatingSystem, whenCreated

$Results = foreach ($Computer in $AllComputers) {
    $Expiry = $Computer.'msLAPS-PasswordExpirationTime'
    [PSCustomObject]@{
        Name           = $Computer.Name
        OS             = $Computer.OperatingSystem
        Created        = $Computer.whenCreated
        LAPSManaged    = if ($Expiry) { "Oui" } else { "Non" }
        LAPSExpiry     = if ($Expiry) { [datetime]::FromFileTime($Expiry) } else { "N/A" }
        LAPSExpired    = if ($Expiry) { 
            [datetime]::FromFileTime($Expiry) -lt (Get-Date) 
        } else { "N/A" }
    }
}

# Statistiques
$Total = $Results.Count
$Managed = ($Results | Where-Object { $_.LAPSManaged -eq "Oui" }).Count
$Unmanaged = $Total - $Managed
$Expired = ($Results | Where-Object { $_.LAPSExpired -eq $true }).Count

Write-Host "=== Rapport Couverture LAPS ==="
Write-Host "Total machines actives : $Total"
Write-Host "Gérées par LAPS : $Managed ($([math]::Round($Managed/$Total*100,1))%)"
Write-Host "NON gérées : $Unmanaged" -ForegroundColor Red
Write-Host "Mots de passe expirés : $Expired" -ForegroundColor Yellow

# Export des machines non gérées
$Results | Where-Object { $_.LAPSManaged -eq "Non" } | 
  Export-Csv -Path "LAPS-Unmanaged.csv" -NoTypeInformation

8. Migration de LAPS Legacy vers Windows LAPS

8.1 Stratégie de migration

La migration de LAPS Legacy vers Windows LAPS doit être planifiée soigneusement. Les deux solutions peuvent coexister temporairement, mais un seul système doit gérer un compte donné à un instant T. Voici la stratégie recommandée :

1. Phase 1 - Préparation (1-2 semaines) : mettre à jour le schéma AD pour Windows LAPS, configurer les permissions, créer les GPO Windows LAPS mais ne pas les appliquer.
2. Phase 2 - Pilote (2-4 semaines) : appliquer Windows LAPS sur une OU pilote (50-100 machines), vérifier le fonctionnement, valider les outils de lecture et les workflows helpdesk.
3. Phase 3 - Déploiement progressif (4-8 semaines) : migrer OU par OU. Pour chaque OU, retirer la GPO LAPS Legacy AVANT d'appliquer la GPO Windows LAPS.
4. Phase 4 - Décommissionnement (1-2 semaines) : désinstaller le MSI LAPS Legacy de toutes les machines, supprimer les GPO Legacy, documenter la migration.

# Vérification : identifier les machines encore gérées par LAPS Legacy
Get-ADComputer -Filter * -Properties ms-Mcs-AdmPwdExpirationTime |
  Where-Object { $_.'ms-Mcs-AdmPwdExpirationTime' -ne $null } |
  Select-Object Name, DistinguishedName |
  Sort-Object Name

# Désinstallation silencieuse du MSI LAPS Legacy (via SCCM/GPO)
msiexec /x {97E2CA7B-B657-4FF7-A6DB-30B36EC8C9C2} /quiet /norestart

9. Attaques contre LAPS et défenses

9.1 LAPS Dump : extraction massive des mots de passe

L'attaque la plus courante contre LAPS est le LAPS dump -- l'extraction en masse des mots de passe stockés dans AD. Un attaquant ayant compromis un compte avec des droits de lecture sur les attributs LAPS peut extraire tous les mots de passe en une seule requête LDAP :

9. Attaques contre LAPS et défenses : analyse approfondie

# Attaque : LAPS dump avec CrackMapExec
crackmapexec ldap dc01.corp.local -u compromised_user -p 'P@ssw0rd' --module laps

# Attaque : LAPS dump avec LAPSDumper (Python)
python laps.py -u compromised_user -p 'P@ssw0rd' -d corp.local

# Attaque : LAPS dump avec PowerView
Get-DomainComputer -Properties ms-Mcs-AdmPwd,ms-Mcs-AdmPwdExpirationTime |
  Where-Object {$_.'ms-Mcs-AdmPwd' -ne $null} |
  Select-Object dnsHostName, ms-Mcs-AdmPwd

# Attaque : LAPS dump via ADExplorer / ldapsearch
ldapsearch -x -H ldap://dc01.corp.local -D "compromised_user@corp.local" \
  -w 'P@ssw0rd' -b "DC=corp,DC=local" "(objectClass=computer)" \
  ms-Mcs-AdmPwd ms-Mcs-AdmPwdExpirationTime

9.2 Contournement des Post-Authentication Actions

Les post-authentication actions de Windows LAPS (reset + logoff) peuvent être contournées si l'attaquant agit rapidement. Techniques observées :

• Persistence avant reset : l'attaquant utilise le mot de passe LAPS pour se connecter, puis installe une persistence (service, tâche planifiée, technique de persistance) avant que la post-authentication action ne se déclenche.
• Désactivation du service LAPS : un attaquant avec les droits SYSTEM peut arrêter le traitement de la CSE en modifiant la registry ou en bloquant les GPO.
• Interception réseau : dans le cas de LAPS Legacy (mot de passe en clair), un attaquant en position MitM sur le réseau peut intercepter la communication LDAP si le LDAP signing n'est pas enforced.

9.3 Défenses et durcissement

10. Checklist de déploiement LAPS

Cette checklist synthétise les actions essentielles pour un déploiement LAPS robuste et sécurisé. Utilisez-la comme référence lors de vos projets de sécurisation Active Directory :

Pour approfondir ce sujet, consultez notre outil open-source ad-attack-simulator qui facilite la simulation d'attaques Active Directory en environnement contrôlé.

Questions frequentes

11. Conclusion : LAPS comme fondation de la sécurité AD

LAPS n'est pas un contrôle de sécurité optionnel ou un "nice-to-have" -- c'est un fondamental absolu de toute stratégie de sécurisation Active Directory. La gestion des mots de passe administrateur locaux est l'un des premiers contrôles évalués lors de nos audits de sécurité AD, et son absence ou sa mauvaise configuration constitue systématiquement un finding critique.

Avec Windows LAPS, Microsoft a considérablement relevé le niveau de protection : chiffrement natif, historique, post-authentication actions, intégration cloud -- les excuses pour ne pas déployer LAPS n'existent plus. Le déploiement peut être réalisé en quelques jours pour un parc de plusieurs milliers de machines, et l'impact opérationnel est quasi nul une fois les workflows helpdesk adaptés.

LAPS s'inscrit dans une stratégie plus large de sécurisation des privilèges. Combiné à un modèle de tiering rigoureux, à une gestion des comptes à privilèges via PIM/Entra, et à un monitoring continu via MITRE ATT&CK, LAPS élimine l'un des vecteurs de mouvement latéral les plus exploités et réduit drastiquement la surface d'attaque de votre environnement.