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

Le problème concret : un seul mot de passe, 80 machines exposées

Dans la majorité des PME romandes de 20 à 150 postes, le compte Administrateur local Windows ou admin macOS est provisionné une seule fois, lors du déploiement, avec un mot de passe identique sur l'ensemble du parc. Un attaquant qui récupère ce credential — via un phishing réussi, un dump LSASS ou une session RDP mal sécurisée — peut se déplacer latéralement sur l'intégralité des endpoints sans déclencher la moindre alerte liée à un compte de domaine. Le principe de lateral movement via Pass-the-Hash repose précisément sur cette uniformité.

La solution existe depuis 2015 pour Windows (LAPS v1) et a été intégrée nativement dans Windows 11 23H2 et Windows Server 2022 sous la forme de Windows LAPS. Les équivalents existent pour macOS et Linux, mais leur déploiement reste sous-documenté dans le contexte des outils MDM utilisés par les PME suisses. Cet article couvre les trois plateformes de façon opérationnelle.

Windows LAPS : architecture et déploiement

Ce que fait Windows LAPS

Windows LAPS génère un mot de passe aléatoire pour le compte administrateur local désigné, le stocke chiffré dans Active Directory (attribut ms-LAPS-Password) ou dans Azure AD / Entra ID, et le fait tourner automatiquement selon une périodicité configurable. L'accès au mot de passe en clair est protégé par des ACL AD ou des rôles Entra ID dédiés. En cas de compromission confirmée, un administrateur peut forcer la rotation immédiate via PowerShell ou le portail Intune.

Versions et prérequis

• Windows LAPS natif (recommandé) : Windows 11 21H2+ avec KB5025221, Windows 10 20H2+ avec KB5025221, Windows Server 2019/2022 patchés avril 2023. Aucun agent additionnel.
• Legacy LAPS (MSI séparé) : compatible Windows 7/8/Server 2012, mais déprécié. À migrer.
• Intune ou GPO pour la distribution de la policy. Jointure Entra ID (anciennement Azure AD) ou AD on-premises obligatoire.

Configuration minimale via Intune (Endpoint Security)

1. Activer Windows LAPS dans Endpoint Security → Account Protection → Windows LAPS.
2. Définir le compte cible : Administrator (SID S-1-5-21-*-500) ou un compte nommé dédié.
3. Fixer la longueur minimale à 15 caractères, complexité maximale.
4. Rotation : 30 jours maximum, 1 jour minimum post-utilisation (paramètre PostAuthenticationResetDelay).
5. Chiffrement du mot de passe dans le répertoire : activer PasswordEncryptionEnabled avec une liste d'autorisés restreinte (groupe AD dédié, max 3 personnes).
6. Configurer la sauvegarde dans Entra ID si le parc est cloud-only, ou AD si hybride.
7. Tester la récupération via Get-LapsADPassword (PowerShell) ou le portail Intune.

Alerte sur un piège fréquent

Sur un parc Windows Autopilot en jointure Entra ID pure (sans AD on-premises), la sauvegarde dans AD est impossible. Le mot de passe est alors stocké dans Entra ID, lisible uniquement par les membres du rôle Local administrator password reader. Ce rôle doit être attribué à un groupe dédié, jamais au rôle Global Administrator de façon directe.

macOS : LAPS via MDM — Jamf, Mosyle, Kandji ou Fleet

Pas de LAPS natif Apple

Apple ne fournit pas de mécanisme LAPS intégré équivalent. La gestion du mot de passe admin local sur macOS repose sur trois approches, selon l'outil MDM en place.

Approche 1 : extension LAPS dans Jamf Pro

Jamf Pro propose un Extension Attribute combiné à un script de rotation qui stocke le mot de passe haché dans la base Jamf et le communique en clair uniquement aux administrateurs Jamf autorisés. La rotation est déclenchée par une Policy planifiée (ex. : toutes les 72 heures ou à chaque check-in). Le compte cible est typiquement localadmin, distinct du compte utilisateur principal. Prérequis : macOS 12+, Jamf Pro 10.40+.

Approche 2 : Fleet + osquery + script custom

NIST CSF recommande la rotation des credentials privilégiés sous PR.AC-4. Fleet (open source, basé sur osquery) permet d'exécuter des scripts macOS via l'API MDM d'Apple (MDM Commands). Un script Shell génère un mot de passe via /usr/bin/openssl rand -base64 18, appelle sysadminctl -passwd, et pousse le résultat chiffré (via clé GPG ou secret Vault) vers un endpoint d'API interne. Coût infra : quasi nul si Fleet est déjà déployé.

Approche 3 : Apple Business Manager + Configuration Profile

Apple Business Manager seul ne gère pas les mots de passe locaux. Un profil MDM peut en revanche forcer la Managed Local User Account et en restreindre les usages, mais la rotation du mot de passe reste à la charge d'un script distribué via le MDM. Sans MDM tiers, la couverture est incomplète.

Compte admin dédié, pas le compte utilisateur

Sur macOS, l'erreur classique est de donner les droits admin au compte principal de l'utilisateur. La bonne pratique CIS Benchmarks macOS (section 5.6) impose un compte admin local séparé (localadmin), invisible à l'écran de connexion (IsHidden=1), avec rotation LAPS. L'utilisateur final travaille en standard user.

Linux : gestion des credentials root et sudo locaux

Le contexte PME suisse

Sur un parc de 20 à 150 endpoints, les postes Linux sont souvent minoritaires (5 à 15 % des endpoints, typiquement des développeurs sous Ubuntu 22.04 LTS ou Fedora 40). La gestion du compte root et des accès sudo locaux est rarement formalisée, alors que les risques sont identiques à Windows.

Deux approches viables

Fleet + osquery : Fleet supporte les scripts Linux (Bash) via l'agent osquery. La logique est identique à macOS : script de rotation du mot de passe root, chiffrement du résultat, envoi vers un Vault (HashiCorp Vault, ou un secret manager cloud). La rotation peut être planifiée ou déclenchée à la demande depuis la console Fleet.

Ansible + AWX : Pour les parcs Linux gérés par Ansible, un rôle dédié génère un mot de passe via le module ansible.builtin.password, l'applique via user module, et stocke la valeur chiffrée dans Ansible Vault. La rotation est déclenchée par un schedule AWX (toutes les 30 jours, ou après chaque intervention d'un prestataire externe). Cela couvre aussi les serveurs, pas uniquement les endpoints.

sudo : une surface souvent négligée

La majorité des compromissions Linux en PME n'exploitent pas le mot de passe root directement, mais une entrée sudoers trop permissive (ALL=(ALL) NOPASSWD:ALL). CIS Benchmarks Linux section 5.3 impose des entrées sudoers granulaires, un fichier de log dédié (Defaults logfile=/var/log/sudo.log), et l'absence de NOPASSWD sauf exceptions documentées et auditées trimestriellement.

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 mot de passe admin local partagé ou non rotatif constitue une lacune de contrôle d'accès directement documentable lors d'un audit de conformité ou lors de la notification d'une violation de données au PFPDT (Préposé fédéral à la protection des données).

Concrètement, si un incident de sécurité implique une élévation de privilèges via un compte admin local non géré, le rapport post-incident devra justifier l'absence de contrôle compensatoire. Pour les entreprises régulées (banques, assurances), la FINMA attend une traçabilité des accès privilégiés dans ses circulaires sur la gouvernance des risques opérationnels. Le NCSC recommande dans ses guides PME la suppression des comptes partagés et la rotation des mots de passe à privilèges comme mesure de base.

Sur le plan de la traçabilité : chaque accès à un mot de passe LAPS doit être logué (qui, quand, quel endpoint). Windows LAPS logge nativement dans l'Event Log (Event ID 10020-10027). Les solutions macOS/Linux custom doivent implémenter ce logging explicitement.

Cas pratique : fiduciaire vaudoise, 65 endpoints mixtes

Contexte : Cabinet fiduciaire à Lausanne, 45 collaborateurs, 65 endpoints (48 Windows 11 22H2, 12 MacBook Pro sous macOS 14 Sonoma, 5 postes Ubuntu 22.04 LTS pour les développeurs d'outils internes). Parc géré via Intune (Windows) et un MDM macOS tiers. Pas de LAPS en place avant l'audit initial.

Constat de l'audit (J0) : Mot de passe Administrateur identique sur les 48 postes Windows, positionné lors du déploiement Autopilot via un script d'onboarding non mis à jour depuis 18 mois. Sur macOS, le compte admin utilise le prénom du responsable IT + année de création. Sur Ubuntu, sudo accordé avec NOPASSWD à 3 développeurs.

Plan de remédiation en 4 semaines :

1. Semaine 1 — Windows (DSI + ingénieur Intune) : Activation Windows LAPS via Endpoint Security dans Intune. Policy déployée sur les 48 machines via un groupe Entra ID dédié. Paramètres : longueur 20 caractères, complexité maximale, rotation 30 jours, post-auth reset delay 24 h. Rôle Local administrator password reader attribué à 2 administrateurs IT nommés. Vérification de la remontée des mots de passe dans Entra ID sur 10 machines pilotes. Déploiement complet J+5.
2. Semaine 2 — macOS (ingénieur MDM) : Création d'un compte localadmin masqué sur les 12 MacBook via script MDM. Script de rotation (openssl rand, sysadminctl) configuré en Policy planifiée toutes les 30 jours. Stockage du mot de passe chiffré dans un secret Vault interne (accès restreint à 2 personnes). Droit admin retiré au compte utilisateur principal sur 10 des 12 machines (2 exceptions documentées pour raisons métier, revue trimestrielle). Durée estimée : 6 heures de travail.
3. Semaine 3 — Linux (ingénieur système) : Révision des fichiers sudoers sur les 5 postes Ubuntu : suppression de NOPASSWD, définition de commandes autorisées granulaires. Mise en place d'un rôle Ansible de rotation du mot de passe root (fréquence : 30 jours). Activation du log sudo dans /var/log/sudo.log, intégré au SIEM existant. Durée : 4 heures.
4. Semaine 4 — Validation et documentation : Test de récupération LAPS simulé (scénario : poste verrouillé, utilisateur absent). Mise à jour du registre des traitements (nLPD) pour inclure le traitement des mots de passe admin en tant que données à accès restreint. Formation de 30 minutes pour les 2 administrateurs sur la procédure de récupération. Coût total estimé : 3 500 CHF (consulting + heures internes), zéro coût de licence supplémentaire.

Résultat mesurable : Surface d'attaque latérale réduite à zéro sur le vecteur « credential admin local partagé ». En cas d'incident sur un poste, le rayon de blast est limité à ce seul endpoint. La prochaine rotation automatique est planifiée à J+30 sans intervention manuelle.

Récapitulatif opérationnel

• Windows : Déployer Windows LAPS natif (KB5025221+) via Intune ou GPO. Éviter Legacy LAPS. Stocker dans Entra ID (cloud-only) ou AD (hybride). Longueur minimale : 15 caractères. Rotation : 30 jours max.
• macOS : Créer un compte localadmin dédié, masqué, distinct du compte utilisateur. Implémenter la rotation via script MDM (Fleet, Jamf, Mosyle). Retirer les droits admin du compte principal sauf exception documentée.
• Linux : Auditer et restreindre les entrées sudoers (supprimer NOPASSWD). Implémenter la rotation du mot de passe root via Ansible ou Fleet. Logger toutes les commandes sudo.
• Traçabilité : Loguer chaque accès à un mot de passe LAPS (qui, quand, quel endpoint). Conserver les logs 12 mois minimum (nLPD, art. 8 OPDo).
• Accès restreint : Maximum 2 à 3 personnes habilitées à récupérer un mot de passe LAPS. Groupe ou rôle dédié, jamais le rôle Global Admin ou équivalent.
• Post-intervention : Forcer la rotation immédiate après toute intervention d'un prestataire externe ou tout départ d'un administrateur.
• Audit trimestriel : Vérifier que 100 % des endpoints remontent un mot de passe LAPS actif. Signaler les écarts dans le registre des risques.
• Documentation nLPD : Inclure la gestion LAPS dans le registre des traitements comme mesure technique de protection des accès privilégiés.

SynGuard accompagne les PME romandes dans la mise en œuvre de ces contrôles dans le cadre de ses offres MDM et sécurité endpoints.

Sources

• nLPD — Fedlex — Texte consolidé de la nouvelle Loi fédérale sur la protection des données, en vigueur dès le 01.09.2023.
• PFPDT / EDÖB — Préposé fédéral à la protection des données et à la transparence, autorité de surveillance nLPD.
• NCSC — Centre national pour la cybersécurité — Recommandations et guides pour PME suisses, signalement d'incidents.
• CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée pour Windows, macOS et Linux.
• NIST Cybersecurity Framework — Cadre de référence pour la gestion des risques cyber, dont PR.AC-4 (gestion des accès privilégiés).