LAPS Windows, Mac, Linux : gestion accès admin local

Un mot de passe administrateur local identique sur 80 postes Windows, c'est une seule compromission qui ouvre tout le parc. LAPS, macOS LAPS et les solutions Fleet/MDM Linux résolvent ce problème — à condition de les déployer correctement.

Un mot de passe admin local partagé, c'est un mouvement latéral offert

Dans la majorité des PME romandes, le compte Administrator local (ou admin sur macOS) est configuré une fois lors du déploiement, puis oublié. Même mot de passe sur les 40 laptops d'un bureau d'études lausannois, sur les serveurs de fichiers, sur les postes de la réception. Quand un attaquant obtient ce credential — via phishing, dump LSASS, ou simple trouvaille dans un script de déploiement — il se déplace latéralement sans friction. Les référentiels CIS Benchmarks et le NIST Cybersecurity Framework classent tous deux la rotation automatique des credentials locaux comme contrôle prioritaire. Voici comment l'implémenter sur les trois plateformes présentes dans un parc mixte typique.

Windows : LAPS et Windows LAPS (2023)

Deux générations, un même principe

Microsoft a publié le LAPS original (legacy) en 2015 : un agent MSI stocke un mot de passe aléatoire dans l'attribut ms-Mcs-AdmPwd de l'objet ordinateur Active Directory, avec une ACL granulaire. Depuis avril 2023, Windows LAPS est intégré nativement dans Windows 11 22H2+ et Windows 10 22H2+, sans agent supplémentaire. Il supporte trois backends de stockage : Active Directory (on-premise), Azure AD (Entra ID), et — nouveau — un backup local chiffré. La rotation par défaut est de 30 jours, configurable de 1 à 365 jours via GPO ou stratégie Intune (./Device/Vendor/MSFT/LAPS/Policies/PasswordExpirationProtectionEnabled).

Prérequis et déploiement étape par étape

Schéma AD étendu (legacy LAPS uniquement) : exécuter Update-AdmPwdADSchema depuis un Domain Admin. Windows LAPS utilise de nouveaux attributs (msLAPS-Password, msLAPS-PasswordExpirationTime) qui nécessitent une extension via Update-LapsADSchema sur un DC Windows Server 2022 ou 2019 patchés post-avril 2023.
Droits de lecture : déléguer la lecture de msLAPS-Password aux seuls groupes autorisés (ex. Helpdesk-L2). Ne jamais accorder GenericRead sur l'OU entière.
Politique de mot de passe : longueur minimale recommandée par CIS = 15 caractères, complexity = LargeLetters+SmallLetters+Numbers+SpecialCharacters. Dans Intune : profil Endpoint Security > Account Protection > Local Admin Password Solution.
Compte ciblé : par défaut Windows LAPS gère le compte Administrator (RID 500). Si le parc utilise un compte admin renommé, spécifier son nom exact dans la clé AdministratorAccountName.
Vérification : Get-LapsADPassword -Identity PCNOM -AsPlainText depuis un poste admin. En Intune, la console affiche le mot de passe et la date d'expiration dans Devices > [Device] > Local admin password.
Rotation forcée post-utilisation : après chaque intervention helpdesk, déclencher Reset-LapsPassword -Identity PCNOM ou via le bouton Rotate local admin password dans le portail Intune. Ce point est systématiquement oublié dans les procédures terrain.

Points d'attention sécurité

Le mot de passe LAPS circule en clair dans la réponse LDAP si TLS n'est pas forcé sur le port 636. Vérifier que LDAPEnforceChannelBinding et ldapserverintegrity sont à 2 sur tous les DC. Pour les environnements Entra ID (Azure AD join), le mot de passe transite via HTTPS (port 443) et est chiffré au repos dans Entra ; l'accès nécessite le rôle Cloud Device Administrator ou une délégation custom.

macOS : pas de LAPS natif, plusieurs alternatives solides

Le problème spécifique à macOS

Apple n'a pas d'équivalent natif au LAPS AD. Le compte admin local créé via Apple Business Manager (ABM) + MDM (Jamf, Mosyle, Kandji, ou solution maison) est souvent un compte «managed administrator» avec un mot de passe statique défini dans le profil de configuration — scénario à risque identique à Windows sans LAPS.

Option 1 : script de rotation via MDM (Fleet ou autre)

La solution la plus répandue en PME sans Jamf Pro consiste à déployer un script shell rotatif via le MDM. Le script génère un mot de passe aléatoire de 20 caractères (openssl rand -base64 20 | tr -d '=+/' | cut -c1-20), le change avec sysadminctl -adminUser adminref -adminPassword OLDPW -resetPasswordFor localadmin -newPassword NEWPW, puis l'escrowe dans un vault (HashiCorp Vault, SecretServer, ou Azure Key Vault via API). Fréquence recommandée : 7 jours. Limite : le script doit connaître l'ancien mot de passe pour en changer un autre, ce qui crée une dépendance circulaire si le compte est verrouillé.

Option 2 : suppression du compte admin local, élévation à la demande

Approche plus radicale et alignée sur le principe du moindre privilège : supprimer le compte admin local permanent et implémenter une élévation temporaire via PPPC / UAMDM (User Approved MDM). Des outils comme Privileges (open-source, SAP) permettent à l'utilisateur de s'auto-élever admin pour 10 minutes, avec log dans le MDM. Compatible avec la politique ABM + DEP. Les événements d'élévation sont journalisés dans /var/log/com.sap.privileges.log et peuvent être envoyés vers un SIEM.

Option 3 : Fleet + osquery pour l'inventaire et la détection

Même sans rotation automatique intégrée, Fleet avec osquery permet de détecter en continu les comptes admin locaux non attendus :

SELECT username, uid, gid FROM users WHERE gid = 80;

GID 80 = groupe admin sur macOS. Toute entrée inattendue déclenche une alerte. À coupler avec la stratégie MDM de rotation scriptée.

Linux : des outils variés pour un besoin identique

Sudoers et PAM : la brique de base

Sur Linux (Ubuntu 22.04 LTS, Debian 12, RHEL 9), le compte root local est rarement utilisé directement en environnement managé. Le risque se situe sur les comptes de service ou les comptes locaux créés lors du provisioning (Ansible, Terraform) avec un mot de passe statique dans un playbook versionné. Les CIS Benchmarks Linux imposent : PasswordMaxDays 90, PasswordMinDays 1, PasswordWarnAge 7 dans /etc/login.defs, et la désactivation du login root SSH (PermitRootLogin no).

Rotation automatique avec HashiCorp Vault ou Ansible

Pour un parc Linux managé, deux approches dominantes :

HashiCorp Vault SSH Secrets Engine : génère des credentials éphémères signés par une CA interne. Durée de vie configurable (ex. 4 heures). Aucun mot de passe statique sur le poste ; le serveur vérifie la signature via TrustedUserCAKeys dans sshd_config. Idéal pour serveurs, moins adapté aux postes interactifs.
Ansible + AWX : playbook planifié (cron, 7 jours) qui génère un mot de passe via ansible.builtin.password, met à jour le compte local, et stocke le secret dans Vault ou un coffre-fort compatible (Bitwarden Secrets Manager, AWS Secrets Manager). Traçabilité dans AWX job logs.

Détection Fleet/osquery sur Linux

Requête osquery pour détecter les comptes UID 0 non attendus :

SELECT username, uid, shell FROM users WHERE uid = 0 AND username != 'root';

À intégrer dans les packs Fleet comme règle d'alerte critique.

Cas pratique : fiduciaire vaudoise, 65 endpoints mixtes

Contexte : cabinet fiduciaire à Morges, 45 postes Windows 11 22H2 joints à un domaine AD on-premise (Windows Server 2022), 12 MacBook Pro sous macOS 14 Sonoma gérés via MDM léger, 8 serveurs Ubuntu 22.04 hébergeant les outils comptables. Parc total : 65 endpoints. Aucune rotation de mot de passe admin local en place. Audit interne janvier 2025 : mot de passe Admin2019! retrouvé sur 43 des 45 postes Windows.

Phase 1 — Windows (semaine 1-2) :

Extension du schéma AD par le DSI : Update-LapsADSchema depuis le DC principal. Durée : 15 minutes.
Création d'un groupe AD GRP-LAPS-Readers avec les deux techniciens helpdesk. Délégation de lecture sur l'OU OU=Postes,DC=fiduciaire,DC=local.
Déploiement GPO : Computer Configuration > Administrative Templates > System > LAPS. Paramètres : longueur 20 caractères, rotation 14 jours, compte ciblé Administrator.
Test sur 5 postes pilotes, vérification via Get-LapsADPassword. Constat : 5 mots de passe uniques générés en moins d'une heure après application GPO.
Déploiement sur l'ensemble du parc : 43 postes migrés en 48 heures via gpupdate /force scripté. Coût : 0 CHF de licence (Windows LAPS intégré). Temps DSI : ~6 heures au total.

Phase 2 — macOS (semaine 3) :

Création d'un script shell de rotation (20 lignes) déployé via MDM comme policy hebdomadaire.
Escrowe du nouveau mot de passe dans Azure Key Vault (déjà utilisé par la fiduciaire pour ses secrets M365). Coût Key Vault : ~2 CHF/mois pour 12 secrets.
Déploiement de l'app Privileges sur les 12 MacBook, désactivation du compte admin permanent 30 jours après validation.

Phase 3 — Linux (semaine 4) :

Audit Ansible : identification de 3 playbooks contenant des mots de passe en clair. Remplacement par des références Vault ({{ lookup('hashi_vault', 'secret=...' }}).
Déploiement d'un playbook de rotation mensuelle sur les 8 serveurs. Journalisation dans AWX.
Activation des règles osquery Fleet pour détecter les comptes UID 0 anormaux.

Résultat à J+30 : 0 mot de passe admin partagé sur le parc. Temps total de remédiation : ~20 heures DSI + 4 heures technicien. Coût licences additionnel : ~25 CHF/mois (Key Vault + Fleet Cloud). L'audit de conformité suivant, réalisé en mars 2025, ne relève aucune non-conformité sur ce point de contrôle — un critère direct dans le cadre de la nLPD (art. 8, mesures techniques appropriées) et des recommandations du NCSC pour les entreprises.

Récapitulatif opérationnel

Windows AD on-premise : déployer Windows LAPS natif (Windows 11 22H2+/10 22H2+) via GPO. Extension de schéma obligatoire. Rotation 14 jours minimum. Délégation de lecture stricte (groupe dédié helpdesk L2).
Windows Intune-only (Entra ID) : activer la stratégie LAPS dans Endpoint Security. Rôle Cloud Device Administrator requis pour lire le mot de passe. Forcer la rotation post-intervention via le portail.
macOS ABM + MDM : pas d'équivalent natif. Choisir entre script MDM + escrowe vault (rotation automatique) ou suppression du compte admin permanent + élévation temporaire (Privileges SAP). Les deux approches sont cumulables.
Linux managé : éliminer les mots de passe statiques dans les playbooks Ansible. Implémenter Vault SSH Secrets Engine ou rotation Ansible planifiée avec escrowe. Appliquer CIS Benchmark L1 sur login.defs et sshd_config.
Détection continue : Fleet + osquery sur les trois plateformes. Requêtes pour UID 0 inattendus (Linux), GID 80 (macOS), comptes locaux admin non LAPS (Windows via SELECT * FROM users WHERE is_admin = 1).
Procédure post-incident : après tout incident impliquant un credential admin local, forcer immédiatement la rotation sur l'ensemble du parc (pas seulement le poste compromis). Documenter l'événement conformément aux obligations de la nLPD si des données personnelles sont concernées.
Traçabilité : journaliser chaque accès au mot de passe admin (qui, quand, depuis quel poste d'administration). LAPS AD et Intune le font nativement ; pour macOS/Linux, instrumenter le vault.
Tests périodiques : vérifier trimestriellement qu'aucun poste n'a de mot de passe expiré non renouvelé (LAPS peut échouer silencieusement si le poste est hors réseau depuis plus longtemps que la période de rotation).

SynGuard accompagne les PME romandes dans l'audit et le déploiement de ces contrôles dans leurs environnements MDM mixtes.

Sources

CIS Benchmarks — Center for Internet Security — Référentiels de durcissement pour Windows, macOS et Linux, incluant les contrôles sur les comptes locaux.
NIST Cybersecurity Framework — Cadre de gestion du risque cyber ; fonction Protect, catégorie Identity Management and Access Control.
Nouvelle loi fédérale sur la protection des données (nLPD) — Fedlex — Art. 8 : obligation de mesures techniques et organisationnelles appropriées pour la protection des données personnelles.
NCSC — Informations pour les entreprises — Recommandations pratiques du Centre national pour la cybersécurité suisse, dont la gestion des accès privilégiés.

LAPS Windows, équivalents Mac et Linux : maîtriser les accès admin locaux