Local Administrator Password Solution ? Retour d’expérience sur une intégration technique pas comme les autres

LAPS, kesako ?

Commençons par une petite introduction importante : cet article a pour but de présenter l’outil LAPS (Local Administrator Password Solution) à travers mon retour d’expérience chez un client grand compte. À savoir que l’article n’a pas vocation à recommander ou à ne pas recommander cet outil, il a plutôt pour objectif de raconter l’histoire du projet qui tourne autour de cette technologie.

Pour information et pour faire simple, LAPS est un produit proposé par Microsoft permettant de gérer les mots de passe des comptes « Administrateur » locaux des postes de travail et des serveurs. Comme tout outil, il présente à la fois des avantages et des inconvénients qu’une DSI doit adapter à son organisation.

Premier déploiement et premier retour d’expérience

L’historique est plutôt simple, on m’a demandé de déployer cet outil dans le cadre d’une remédiation associée à un audit de sécurité. En complément d’information, LAPS était déjà déployé sur le périmètre des postes de travail tandis qu’un mot de passe administrateur local fixe était utilisé sur l’ensemble des serveurs : l’incohérence !

Nous le savons tous, utiliser le même mot de passe administrateur local constitue une réelle vulnérabilité de configuration, car cela permettrait à un assaillant de rebondir de serveur en serveur dans le cas où il aurait déjà pris le contrôle d’une machine ou de l’ensemble du système d’information. LAPS permet alors, via le déploiement d’une GPO, de générer des mots de passe uniques et robustes pour chaque compte administrateur local, définir la durée d’expiration des mots de passe associés à ces comptes, définir la complexité des mots de passe associés à ces comptes et de régénérer automatiquement un mot de passe quand il expire : un bon outil !

Le mot de passe est ensuite stocké au sein de l’Active Directory, directement dans l’éditeur d’attributs des propriétés d’un objet (ms-Mcs-AdmPwd). J’ai donc préparé l’ensemble de la configuration nécessaire en amont, à savoir : la création d’une GPO, l’installation de l’exécutable LAPS via notre outil de déploiement : il y a en réalité un peu plus d’étapes, mais j’ai préféré rester générique… sécurité avant tout !

J’avais prévu un calendrier de déploiement par lot sur l’ensemble du système d’information. Malheureusement, je pensais que le déploiement de l’outil était validé, mais lors de la mise en production sur le premier lot de serveur, le projet a été bloqué par les équipes système : début des soucis !

Un brainstorming de longue haleine

Le projet est gelé à la suite de plusieurs problématiques remontées par les équipes : comment récupérer l’ensemble des mots de passe dans le cas d’une indisponibilité des contrôleurs de domaine ? Quelle politique définir pour le compte administrateur local des mêmes contrôleurs ? Doit-on mettre en place un PRA (plan de reprise de l’activité) dédié à LAPS ?

Plusieurs réunions de brainstorming ont été réalisées et nous avons mis en évidence un certain nombre de solutions pouvant s’adapter à l’infrastructure déjà en place et au contexte organisationnel.

• La première solution consiste à réaliser un snapshot de l’Active Directory du contrôleur de domaine principal, mais l’attribut ms-Mcs-AdmPwd peut ne pas être à jour en fonction de la date de restauration de la sauvegarde. De plus, cela restera assez gourmand en termes de ressources et les snapshots ne sont pas vraiment faire pour cela.
• La seconde solution consiste à mettre en place un script qui récupère l’attribut ms-Mcs-AdmPwd et qui l’envoie via API sur l’outil faisant office de coffre-fort. C’est une solution, mais cela rend dépendant d’un PRA associé au serveur coffre-fort et soulève les mêmes problématiques que précédemment (accessibilité en hors du domaine, admin local de PMP, redondance, etc.). On découvre bien après que ce coffre-fort possède aussi un outil capable d’effectuer le même travail que LAPS, mais il n’a jamais été utilisé et configuré.
• La troisième solution consiste à mettre en place un script qui récupère l’attribut ms-Mcs-AdmPwd et qui l’envoie dans un fichier sur un serveur cible. Le serveur aura un mot de passe admin local fixe avec une politique à définir, mais cela rend dépendant d’un PRA associé à ce serveur (accessible hors du domaine, admin local du serveur, redondance, etc.).

Dans l’ensemble des cas, nous serions toujours dépendants de l’accessibilité à la machine hébergeant les mots de passe. Le déploiement standard de LAPS n’est donc pas à mon sens une mauvaise idée : on garde la cape !

Une solution efficace, mais avec de nouvelles contraintes

Finalement, c’est un dérivé de la seconde solution qui a été choisi. À savoir, la configuration d’un outil inhérent au coffre-fort permettant la réinitialisation dynamique des mots de passe : on a changé de cape !

L’objectif est atteint puisque nous répondons aux besoins, mais avec de nouvelles contraintes. Par exemple, s’assurer que l’ensemble des serveurs sont configurés et présents dans le coffre-fort et surtout cela nous rend dépendant de la continuité d’accessibilité à ce serveur coffre-fort. Le mot de passe du compte administrateur local du coffre-fort sera uniquement connu par quelques collaborateurs clés et uniquement communiqué par voie orale : faut-il un coffre-fort pour le coffre-fort ?

Finalement, nous avons centralisé l’ensemble de la gestion de nos mots de passe (comptes administrateurs locaux, comptes locaux, comptes de service, etc.) sur le même serveur ayant le fameux coffre-fort.

Pour conclure, et cela est mon avis à la suite de mon retour d’expérience, générer des mots de passe de manière dynamique pour les comptes administrateurs locaux est une très bonne chose en terme en sécurité. En revanche, dans le cas présenté, la décision prise pour combler le besoin a prolongé inutilement son application pour finalement y répondre, mais avec de nouvelles contraintes sans forcément prendre en compte le niveau de réduction des risques inhérents.