20 août 2026MDM & Endpoints

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

Un compte administrateur local avec le même mot de passe sur 80 postes, c'est une surface d'attaque latérale prête à l'emploi. LAPS, macOS Local Password, Linux PAM : voici comment industrialiser la rotation des credentials admin sur tout type d'endpoint.

Par ZRS-Holding Sàrl·10 min de lecture·62 lectures
Partager

Un mot de passe local partagé : la faille la plus sous-estimée du parc endpoint

Dans la majorité des PME romandes auditées, le compte Administrator ou admin local porte le même mot de passe sur l'ensemble du parc — parfois depuis le déploiement initial, plusieurs années auparavant. Une seule machine compromise suffit : l'attaquant dispose immédiatement d'un credential valide pour se déplacer latéralement sur tous les postes Windows, macOS ou Linux de l'organisation, sans jamais toucher Active Directory ou Entra ID.

La réponse technique existe depuis 2015 pour Windows (LAPS), et des équivalents solides couvrent macOS et Linux. Ce guide détaille l'architecture, la configuration et le déploiement concret, avec les seuils et versions OS qui comptent.

Windows LAPS : architecture et déploiement

Ce que fait LAPS

Local Administrator Password Solution (LAPS) génère un mot de passe aléatoire par machine, le stocke dans Active Directory (attribut ms-MCS-AdmPwd) ou dans Microsoft Entra ID (anciennement Azure AD), et le fait tourner selon une période configurable. Depuis Windows 11 22H2 / Windows Server 2022 (mise à jour avril 2023), LAPS est intégré nativement dans l'OS — plus besoin du MSI distinct. La version legacy (basée sur l'extension CSE) reste supportée mais ne reçoit plus d'évolutions.

Prérequis et périmètre

  • Windows 10 20H2 minimum pour LAPS natif via Intune (canal Windows LAPS CSP)
  • Windows 11 22H2 recommandé pour le chiffrement de l'attribut AD (AES-256) et la sauvegarde vers Entra ID
  • Hybrid Join ou Entra ID Join obligatoire pour la sauvegarde cloud
  • Rôle Intune Device Configuration ou GPO pour l'application de la policy

Configuration via Intune (Entra ID Join)

Dans le portail Intune :

  1. Endpoint Security → Account Protection → Create Policy → Windows LAPS
  2. Paramètre Backup Directory : Azure Active Directory
  3. Password Complexity : Large letters + Small letters + Numbers + Special characters (complexité maximale)
  4. Password Length : 20 caractères minimum (seuil CIS Benchmark Windows 11 : ≥ 15)
  5. Password Age Days : 30 jours. Pour les postes à haute sensibilité (finance, RH) : 14 jours
  6. Post Authentication Actions : Reset password + Log off the managed account — invalide le credential dès la fin de session admin

La lecture du mot de passe s'effectue via le portail Intune (Devices → device → Local Admin Password) ou PowerShell (Get-LapsAADPassword -DeviceIds <id>). L'accès est logué dans les journaux d'audit Entra ID — conservez ces logs au minimum 90 jours pour répondre aux exigences de la nLPD en cas d'incident impliquant un compte privilégié.

Cas hybride : domaine AD + Intune

Pour les parcs en Hybrid Join (domaine AD on-premise + Intune co-management) :

  • Étendre le schéma AD avec les attributs LAPS natifs (msLAPS-Password, msLAPS-PasswordExpirationTime)
  • Déléguer la lecture de l'attribut uniquement aux groupes AD Helpdesk et RSSI, jamais au groupe Domain Users
  • Activer le chiffrement DPAPI de l'attribut (option ADPasswordEncryptionEnabled = True) — clé détenue par le groupe Domain Admins ou un compte de service dédié

macOS : rotation du compte admin local sans LAPS natif

Le problème spécifique macOS

Apple ne fournit pas d'équivalent natif à LAPS. Sur un parc de 30 MacBook gérés via Apple Business Manager et un MDM (Jamf Pro, Mosyle, ou une solution MDM unifiée), le compte admin local — souvent créé lors du DEP enrollment — reste statique si aucune procédure n'est mise en place.

Option 1 : script MDM + escrow dans le MDM

La méthode la plus courante pour un parc de 20 à 100 endpoints macOS :

  1. Déployer un script shell signé via le MDM, exécuté en root, qui génère un mot de passe aléatoire de 20 caractères (OpenSSL ou /dev/urandom)
  2. Appliquer le mot de passe au compte admin via sysadminctl -resetPasswordFor ou dscl . -passwd
  3. Envoyer le mot de passe chiffré vers un endpoint API du MDM ou un vault (HashiCorp Vault, Bitwarden Secrets) via HTTPS/TLS 1.3
  4. Planifier l'exécution via un LaunchDaemon (interval : 2592000 secondes = 30 jours)
  5. Auditer la réception côté vault : toute machine sans rotation depuis > 35 jours déclenche une alerte

Les solutions MDM commerciales intègrent cette fonctionnalité nativement sous le nom Local Administrator Password Management ou LAPS for Mac, avec interface de consultation et log d'accès.

Option 2 : compte admin désactivé, élévation à la demande (PPPC/sudo)

Pour les organisations qui appliquent le CIS Benchmark macOS 14 Sonoma niveau 2, une alternative consiste à supprimer le compte admin local permanent et à gérer l'élévation via :

  • Sudo avec NOPASSWD limité à des commandes whitelistées dans /etc/sudoers.d/
  • Un outil d'élévation temporaire déployé par MDM (expiration automatique de l'accès admin après N minutes)
  • La PPPC (Privacy Preferences Policy Control) MDM profile pour restreindre les accès système

Cette approche réduit la surface mais nécessite un workflow helpdesk plus mature — adaptée aux MSP avec SLA de réponse < 2h.

FileVault et le compte admin local

Sur macOS, le compte admin local est souvent aussi le compte de déverrouillage FileVault. Lors de la rotation du mot de passe admin, il faut mettre à jour la clé FileVault via fdesetup changerecovery ou via le MDM (profil FileVault avec escrow de la clé de récupération institution). Négliger ce point laisse un compte orphelin capable de déverrouiller le disque avec l'ancien mot de passe.

Linux : PAM, sudo et rotation des credentials locaux

Spécificités Linux en PME suisse

Les endpoints Linux en PME romande se concentrent sur les postes développeurs, les serveurs de fichiers internes et les Raspberry Pi industriels. La gestion centralisée passe généralement par Ansible, Chef, ou — pour les postes — FleetDM avec osquery.

Rotation via Ansible + Vault

  1. Générer le mot de passe avec le filtre Ansible password (longueur 24, complexity full) et le stocker dans Ansible Vault
  2. Appliquer via le module ansible.builtin.user : update_password: always, hash bcrypt via password_hash('sha512')
  3. Exécuter le playbook selon un cron ou un pipeline CI/CD (GitLab CI, Jenkins) — cadence : 30 jours
  4. Loguer chaque rotation dans un fichier d'audit centralisé (syslog → SIEM) avec horodatage et hostname

Contrôle sudo : ségrégation des privilèges

La rotation du mot de passe root ne suffit pas si /etc/sudoers contient ALL=(ALL) NOPASSWD: ALL. Appliquer les règles CIS Benchmark Linux :

  • Interdire NOPASSWD sauf exception documentée et approuvée par le RSSI
  • Configurer Defaults logfile=/var/log/sudo.log pour traçabilité
  • Utiliser sudoreplay (sudo ≥ 1.8) pour rejouer les sessions admin — utile post-incident
  • Restreindre le groupe sudo/wheel aux comptes strictement nécessaires, vérifiable via osquery : SELECT * FROM groups JOIN user_groups USING(gid) WHERE groups.groupname = 'sudo';

PAM et verrouillage de compte

Configurer pam_faillock (ou pam_tally2 sur les distros plus anciennes) : verrouillage après 5 échecs, unlock manuel par admin. Couplé à la rotation Ansible, cette mesure limite les attaques par force brute locale sur les postes non exposés à Internet mais accessibles en LAN.

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

La nLPD (nouvelle Loi fédérale sur la protection des données), en vigueur depuis le 01.09.2023, impose des mesures techniques et organisationnelles appropriées pour protéger les données personnelles. Un compte admin local non géré constitue un vecteur de violation de données : en cas d'incident, l'absence de rotation documentée aggrave la qualification de la violation et complique la notification au PFPDT (Préposé fédéral à la protection des données et à la transparence).

Pour les organisations du secteur financier régulées par la FINMA, la traçabilité des accès privilégiés est une exigence explicite de la Circulaire 2023/1. Chaque consultation d'un mot de passe LAPS doit être loguée avec : identité du demandeur, horodatage, hostname concerné, justification si workflow d'approbation activé.

En cas de suspicion d'intrusion impliquant un compte admin local, signalez l'incident au NCSC via le formulaire de signalement — obligatoire pour les infrastructures critiques, recommandé pour toutes les PME.

Cas pratique : fiduciaire vaudoise, 45 endpoints mixtes

Contexte

Cabinet fiduciaire à Lausanne, 38 collaborateurs, 45 endpoints : 30 PC Windows 11 22H2 (Entra ID Join, Intune), 12 MacBook Pro sous macOS 14 Sonoma (Apple Business Manager + MDM), 3 Ubuntu 22.04 LTS pour les développeurs outils internes. Données clients sensibles (bilans, déclarations fiscales) : qualification nLPD catégorie sensible. Aucune politique LAPS ou équivalent en place avant l'audit de janvier 2025. Mot de passe admin local Windows : Fiduciaire2019! identique sur les 30 postes depuis 6 ans.

Déroulement du déploiement

Phase 1 — Windows LAPS (J1 à J5)

  1. DSI : création du groupe Entra ID LAPS-Readers-Helpdesk (3 membres), délégation de lecture dans Intune
  2. DSI : création de la policy Intune Windows LAPS — longueur 20 caractères, rotation 30 jours, post-auth action : reset + logoff
  3. DSI : assignation de la policy au groupe dynamique All-Windows-Devices (30 appareils)
  4. DSI : vérification après 24h via PowerShell — 28/30 appareils remontent un mot de passe. 2 postes hors ligne (télétravail) : suivi à J+3
  5. RSSI : activation des alertes Entra ID Audit Logs pour l'event Read LAPS local administrator password — export vers SIEM (Microsoft Sentinel, licence P1)

Phase 2 — macOS (J5 à J15)

  1. DSI : déploiement d'un script shell signé via MDM — génération mot de passe 20 chars, escrow dans le coffre MDM, LaunchDaemon à 30 jours
  2. DSI : mise à jour du profil FileVault MDM pour escrow de clé institutionnelle — 12/12 MacBook conformes sous 48h
  3. RSSI : test de rotation manuelle sur 2 MacBook, vérification cohérence vault vs compte réel

Phase 3 — Linux (J15 à J20)

  1. DSI : écriture du playbook Ansible, stockage du vault dans GitLab (repo privé, accès restreint)
  2. DSI : exécution initiale — rotation du mot de passe root sur les 3 Ubuntu, log centralisé dans syslog
  3. RSSI : audit sudoers — suppression de 2 entrées NOPASSWD non justifiées, ajout Defaults logfile

Résultat : en 20 jours ouvrés, les 45 endpoints disposent de credentials admin locaux uniques, rotatifs et auditables. Coût humain interne : environ 3 jours DSI + 0,5 jour RSSI. Coût outillage supplémentaire : CHF 0 (fonctionnalités incluses dans les licences Intune P1 et MDM existantes).

Lors d'un test de phishing simulé réalisé 3 mois plus tard, un poste Windows a été compromis (credential de l'utilisateur, pas du compte admin). L'analyse post-incident a confirmé que le mouvement latéral via l'admin local était impossible : chaque poste avait un mot de passe distinct, et l'attaquant simulé ne pouvait pas réutiliser le credential capturé sur une autre machine.

Récapitulatif opérationnel

  • Windows 11 22H2+ / Intune : activer Windows LAPS natif, backup Entra ID, longueur ≥ 20 caractères, rotation ≤ 30 jours, post-auth reset+logoff. Déléguer la lecture au seul groupe helpdesk.
  • Windows hybride (AD + Intune) : étendre le schéma AD, activer le chiffrement AES-256 de l'attribut, restreindre l'ACL AD en lecture.
  • macOS (ABM + MDM) : déployer un script de rotation signé via MDM, escrow dans le vault MDM, synchroniser la clé FileVault. Cadence 30 jours minimum.
  • macOS alternatif : désactiver le compte admin permanent, gérer l'élévation via sudo whitelist + outil MDM d'élévation temporaire.
  • Linux : rotation via Ansible + Ansible Vault, update_password: always, hash sha512. Activer pam_faillock, auditer sudoers, activer sudoreplay.
  • Traçabilité universelle : chaque consultation d'un credential admin local doit générer un log avec identité, horodatage, hostname. Conservation ≥ 90 jours.
  • nLPD / FINMA : documenter la politique de gestion des comptes privilégiés dans le registre des activités de traitement. En cas d'incident, signaler au NCSC et évaluer l'obligation de notification au PFPDT.
  • Vérification périodique : audit trimestriel — nombre d'appareils sans rotation depuis > 35 jours, nombre de consultations de mots de passe LAPS non justifiées, sudoers Linux non conformes.
  • Intégration MDM unifiée : si le parc est géré par une plateforme MDM multi-OS (comme SynGuard), centraliser les alertes de rotation et les logs d'accès dans un tableau de bord unique pour éviter les angles morts entre Windows, macOS et Linux.

Sources

Noter cet article

Pas encore de note