12 septembre 2026MDM & Endpoints

LAPS Windows, équivalents Mac et Linux : gérer les mots de passe admin locaux

Un compte administrateur local avec le même mot de passe sur 80 postes, c'est une vulnérabilité latérale qui transforme un incident isolé en compromission totale du parc. Voici comment LAPS, ses équivalents macOS et les solutions Linux adressent ce risque concrètement.

Par ZRS-Holding Sàrl·11 min de lecture·81 lectures
Partager

Le compte admin local : vecteur latéral sous-estimé

Un attaquant qui compromet un seul poste Windows avec le mot de passe Admin2019! partagé sur l'ensemble du parc peut se déplacer latéralement vers les 79 autres machines en quelques minutes via PsExec, SMB ou WMI — sans jamais toucher l'Active Directory. Ce scénario n'est pas théorique : il correspond au mode opératoire de familles de ransomware comme Ryuk ou BlackMatter, documentées par le NCSC dans ses rapports semestriels. La gestion des mots de passe administrateurs locaux est donc un contrôle de sécurité fondamental, pas un luxe réservé aux grandes organisations.

La bonne nouvelle : des solutions matures existent sur chaque plateforme. La mauvaise : leur déploiement est souvent reporté, parfois parce que les équipes ignorent que macOS et Linux disposent d'équivalents fonctionnels à LAPS.

Windows LAPS : la solution native, enfin digne de ce nom

LAPS legacy vs Windows LAPS (2023+)

L'ancien LAPS (Microsoft Local Administrator Password Solution), sorti en 2015, était un add-on gratuit stockant les mots de passe en clair dans un attribut Active Directory étendu. Fonctionnel, mais limité : pas de chiffrement natif de l'attribut, pas de support Azure AD (Entra ID), pas de gestion des comptes autres que celui désigné à l'installation.

Depuis avril 2023, Windows LAPS est intégré nativement à Windows 10 22H2, Windows 11 22H2 et Windows Server 2019/2022. Les changements structurels sont significatifs :

  • Chiffrement des mots de passe dans l'attribut AD (msLAPS-EncryptedPassword) via DPAPI-NG, avec déchiffrement uniquement par les entités autorisées.
  • Support Azure AD / Entra ID en mode cloud-only, sans contrôleur de domaine on-premise.
  • Gestion de comptes arbitraires, pas uniquement Administrator.
  • Historique des mots de passe (jusqu'à 12 entrées) pour les audits post-incident.
  • Rotation forcée après utilisation, configurable via GPO ou Intune CSP (./Device/Vendor/MSFT/LAPS).

Déploiement via Intune / Windows Autopilot

Dans un contexte Entra ID + Intune (typique des PME passées à Microsoft 365 Business Premium), la configuration s'effectue sans GPO :

  1. Dans le portail Intune, créer un profil Endpoint Security > Account Protection > Local Admin Password Solution.
  2. Définir la complexité du mot de passe (minimum 14 caractères, recommandation CIS Benchmarks Windows 11 L1 : 15 caractères).
  3. Configurer la durée de validité : 7 jours pour les postes sensibles (finance, direction), 30 jours pour les postes standard.
  4. Activer la rotation post-authentification (Post Authentication Actions) : le mot de passe est invalidé dès qu'il a été utilisé pour une session admin locale.
  5. Assigner le profil aux groupes de devices via Autopilot enrollment ou ciblage dynamique.

La lecture des mots de passe se fait depuis le portail Intune (onglet Local admin password sur la fiche device) ou via PowerShell (Get-LapsAADPassword -DeviceIds <DeviceId> -IncludePasswords). L'accès est contrôlé par RBAC Intune : seuls les rôles Helpdesk Operator et supérieurs peuvent récupérer le mot de passe, avec journalisation de chaque accès dans les logs d'audit Azure AD.

Environnement hybride AD on-premise

Pour les PME conservant un DC local (Windows Server 2019 ou 2022), Windows LAPS s'active via Update-LapsADSchema puis GPO. L'attribut msLAPS-EncryptedPassword est lisible uniquement par les comptes membres du groupe LAPS Admins défini lors de la délégation (Set-LapsADComputerSelfPermission, Set-LapsADReadPasswordPermission). Le chiffrement repose sur des groupes de sécurité AD : le déchiffrement échoue si l'entité n'est pas membre du groupe cible, même avec des droits Domain Admin.

macOS : pas de LAPS natif, mais des équivalents structurés

Le problème spécifique à macOS

Sur macOS, le compte administrateur local (premier compte créé, souvent nommé localadmin ou calqué sur l'identité de l'utilisateur) est fréquemment identique sur toutes les machines provisionnées via Apple Business Manager (ABM) + MDM. Les scripts de provisioning Jamf Pro, Mosyle ou Kandji créent cet account avec un mot de passe défini dans le profil d'enrôlement — statique, identique, rarement changé.

macOS ne dispose pas d'un équivalent LAPS natif intégré à l'OS. Trois approches couvrent ce besoin :

1. Rotation par script MDM (approche minimale)

Un script shell exécuté périodiquement via MDM (Jamf, Mosyle, Kandji) génère un mot de passe aléatoire, le définit pour le compte local (dscl . passwd /Users/localadmin <newpassword>), et le stocke dans un attribut d'inventaire ou un secret manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault). La récupération se fait via API depuis le portail MDM ou le vault.

Limitation : la transmission du mot de passe généré vers le vault doit être sécurisée (mTLS, token MDM signé). Un script mal conçu expose le secret en clair dans les logs MDM.

2. LAPS for macOS (laps4macos / Jamf LAPS)

Jamf Pro intègre depuis la version 10.46 un module LAPS natif qui reproduit la logique Windows : génération côté client, stockage chiffré dans la base Jamf, rotation configurable, audit des accès. La rotation s'active via une politique Jamf planifiée ou déclenchée après utilisation (via webhook ou Smart Group). Le mot de passe est récupéré depuis la console Jamf ou l'API REST (GET /v2/local-admin-password/{clientManagementId}/account/{username}/password).

Pour les MDM non-Jamf, des outils open source comme laps4macos (GitHub) ou le script SupportApp LAPS assurent une fonctionnalité équivalente, mais nécessitent un backend (Vault, Azure Key Vault) pour stocker les secrets de manière sécurisée.

3. Suppression du compte admin local partagé

L'approche la plus propre pour les parcs entièrement ABM : ne pas créer de compte admin local partagé du tout. L'élévation de privilèges passe par un mécanisme de temporary admin (Privileges.app d'LAPS for Mac, ou équivalents) qui accorde des droits admin pour une durée limitée (15 à 30 minutes), journalisée dans les logs MDM et SIEM. C'est la recommandation du CIS Benchmark macOS 14 Sonoma (contrôle 5.6).

Linux : gestion des comptes root locaux dans un parc hétérogène

Enjeux spécifiques

Linux présente une complexité supplémentaire : la diversité des distributions (Ubuntu 22.04 LTS, Debian 12, RHEL 9, Rocky Linux), des mécanismes d'authentification (PAM, SSSD, Kerberos) et des paradigmes d'accès root (sudo, polkit, compte root direct). Dans les PME tech romandes, les postes Linux sont souvent des machines de développeurs, avec des pratiques de sécurité hétérogènes.

Solutions par niveau de maturité

Niveau 1 — Centralisation via LDAP/AD : Intégrer les postes Linux à Active Directory via SSSD + Kerberos. L'accès admin passe par des groupes AD dédiés (linux-admins), et sudo est configuré via /etc/sudoers.d/ ou SSSD sudo_provider = ldap. Pas de compte root local partagé.

Niveau 2 — Rotation par Ansible : Un playbook Ansible exécuté depuis un bastion ou un CI/CD génère des mots de passe aléatoires (module password Ansible, longueur 20 caractères, charset alphanumérique + spéciaux), les définit sur les hosts cibles (user module avec password: "{{ vault_hash }}"), et stocke le clair dans Ansible Vault ou HashiCorp Vault. La rotation peut être planifiée (cron ou AWX/Tower scheduler) ou déclenchée post-incident.

Niveau 3 — FleetDM + osquery : FleetDM (MDM open source pour Linux/macOS/Windows) permet d'inventorier les comptes locaux avec droits sudo via osquery (SELECT * FROM users JOIN user_groups ON users.uid = user_groups.uid WHERE user_groups.groupname = 'sudo'). Couplé à des scripts de rotation, il assure visibilité et remédiation depuis une console unifiée. Pour les PME souhaitant éviter un MDM commercial, c'est une alternative crédible.

Sur Ubuntu 22.04 et RHEL 9, le compte root direct devrait être désactivé (passwd -l root) au profit de sudo exclusivement, conformément aux recommandations du NIST Cybersecurity Framework (fonction Protect, catégorie PR.AC-4).

Cadre légal suisse et exigences de traçabilité

La nouvelle loi sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose des mesures techniques et organisationnelles appropriées pour protéger les données personnelles (art. 8 nLPD). Un compte administrateur local non sécurisé qui permettrait une compromission du SI traitant des données personnelles constitue une lacune de sécurité pouvant engager la responsabilité du responsable du traitement.

En cas de violation de données résultant d'un mouvement latéral via des comptes admin locaux partagés, le délai de notification au PFPDT (Préposé fédéral à la protection des données) est de 72 heures dès la connaissance de la violation, si celle-ci présente un risque élevé pour les personnes concernées. La traçabilité des accès aux mots de passe admin (logs LAPS, logs Jamf, logs Vault) est un élément clé de la preuve de diligence lors d'un audit.

Pour les entreprises soumises à la FINMA (banques cantonales, gestionnaires de fortune à Genève ou Lausanne), la circulaire FINMA 2023/1 sur les risques opérationnels exige des contrôles explicites sur la gestion des comptes privilégiés, y compris les comptes locaux. L'absence de rotation documentée des mots de passe admin locaux est un finding récurrent lors des audits ISAE 3402.

Cas pratique : fiduciaire vaudoise, 65 postes Windows et 8 Mac

Contexte : Une fiduciaire à Lausanne emploie 72 collaborateurs, dont 65 sur Windows 11 23H2 (enrôlés Entra ID + Intune via Autopilot) et 8 Mac M-series sous macOS 14.4 (enrôlés ABM + Mosyle Business). Tous les postes Windows partagent le même compte localadmin avec mot de passe défini lors du provisioning en 2021 et jamais changé. Les Mac n'ont pas de compte admin local dédié — l'utilisateur est admin de sa propre machine.

Risque identifié : Lors d'un test de pénétration interne, le prestataire a démontré un mouvement latéral complet sur les 65 postes Windows en 11 minutes depuis un poste compromis, en utilisant le hash NTLM du compte localadmin (pass-the-hash). Coût estimé d'une compromission totale : entre CHF 80'000 et CHF 150'000 (recovery, notification clients, pertes d'exploitation sur 5 jours).

Plan de remédiation — 4 semaines :

  1. Semaine 1 — Windows LAPS Intune : Le DSI crée un profil Account Protection dans Intune. Configuration : longueur 15 caractères, validité 14 jours, rotation post-authentification activée, chiffrement Entra ID. Déploiement en ring (10 postes pilotes d'abord, puis les 55 restants). Coût : 0 CHF (inclus dans la licence Microsoft 365 Business Premium à CHF 22/mois/utilisateur déjà en place).
  2. Semaine 2 — Validation et monitoring : Vérification via Intune que tous les devices remontent un msLAPS-PasswordExpiryTime valide. Création d'une alerte Azure Monitor si un device ne rapporte pas de rotation dans les 20 jours.
  3. Semaine 3 — macOS : Activation du module LAPS Mosyle Business (disponible depuis Mosyle v5.x, inclus dans la licence Business à CHF 3/device/mois). Création d'un compte mgmtadmin dédié sur chaque Mac via Mosyle, avec rotation quotidienne. Les 8 utilisateurs qui étaient admins sont rétrogradés en utilisateurs standard — l'élévation temporaire passe par Privileges.app déployé via Mosyle.
  4. Semaine 4 — Audit et documentation : Le RSSI documente la procédure de récupération d'un mot de passe admin (qui peut demander, via quel ticket, quel log est généré) dans la politique de gestion des accès privilégiés (PAM policy). Cette documentation est versée au registre des mesures de traitement au sens de l'art. 12 nLPD.

Résultat : Le test de pénétration de validation, 6 semaines après la remédiation, n'a plus pu effectuer de mouvement latéral via les comptes locaux. Chaque poste a un mot de passe admin local unique, inconnu des utilisateurs et des techniciens sauf consultation tracée.

Récapitulatif opérationnel

  • Windows + Intune (Entra ID) : Activer Windows LAPS nativement via profil Endpoint Security. Longueur ≥ 15 caractères, validité ≤ 14 jours pour postes sensibles, rotation post-authentification obligatoire.
  • Windows + AD on-premise : Migrer du LAPS legacy vers Windows LAPS (schéma AD v2). Déléguer la lecture des mots de passe à un groupe dédié, pas aux Domain Admins en bloc.
  • macOS (Jamf Pro ≥ 10.46) : Activer le module LAPS natif Jamf. Pour les autres MDM (Mosyle, Kandji, Addigy), utiliser le module LAPS intégré ou un script vers Azure Key Vault.
  • macOS (approche avancée) : Supprimer le compte admin local partagé. Utiliser Privileges.app pour l'élévation temporaire (15-30 minutes max), avec journalisation MDM.
  • Linux : Désactiver le compte root direct (passwd -l root). Centraliser via SSSD/AD ou automatiser la rotation via Ansible + Vault. Inventorier les comptes sudo avec FleetDM/osquery.
  • Traçabilité : Journaliser chaque accès à un mot de passe admin local (qui, quand, depuis quel poste). Conserver les logs 12 mois minimum pour les audits nLPD/FINMA.
  • Tests : Vérifier trimestriellement qu'aucun mot de passe admin local n'est partagé entre devices (osquery ou script Intune PowerShell comparant les hashes).
  • Incident : En cas de compromission suspectée, déclencher une rotation forcée immédiate sur l'ensemble du parc (Rotate password now Intune ou équivalent MDM) avant toute autre action de remédiation.
  • Documentation PAM : Formaliser la procédure de demande/accès aux mots de passe admin dans la politique PAM, avec validation par le RSSI pour tout accès hors ticket incident.

SynGuard accompagne les PME romandes dans l'évaluation et le déploiement de ces contrôles dans le cadre de projets MDM multi-plateformes.

Sources

Noter cet article

Pas encore de note