Changer les mots de passe des comptes c’est un fait, mais ensuite où les stocker ? Dans un gestionnaire de coffre fort, un excel ? Comment s’assurer que le mot de passe saisie et celui copier dans le fichier/gestionnaire est identique ?

Ca nous fait tous de même un ch*ée de question… Et je termine avec une petite dernière, en cas de compromission du support de stockage des mots de passe, quel temps nous accordons pour tout changer ?

C’est bon Père Fouras, tu as terminé ? Oui je crois. 🙂

J’ai une mélodie qui me vient en tête…

C’est petit joli c’est doux c’est fort, C’est plein de sécu… Pour l’amour l’ennui ou pour la mort. Pour éviter les pleurs. Les Passwords…
LAPS pour Windows

Un IT fan de StarMania – Lien

Nous aborderons donc comment éviter le casse tête de la gestion et le stockage des mots de passe du compte administrateur local des environnements WINDOWS (joint à un domaine) avec Windows LAPS¹.

Je n’aborderai pas la partie LAPS Legacy père de Windows LAPS.

Prérequis

• SE : Windows 2019 minimum (niveau fonctionnel/domain 2016 et plus)
• Apps : Powershell
• Autres :
  • SMTP

Avant-Propos

Dans un temps Far Far Away où WS2016 n’était pas encore présent, la gestion des mots de passe administrateurs locaux serveur et ordinateur pouvait se faire par GPO². Malheureusement, cela impliquait d’être moins regardant sur l’aspect sécuritaire du SI :

• Mot de passe en clair dans la GPO
• Pas de rotation de mot de passe
• Mot de passe identique pour tous les CIs³ lié à la GPO

Ainsi pour chaque changement de mot de passe, il fallait se connecter sur chaque serveur pour modifier ce dernier ou modifier la GPO ordinateur, appliquer la GPO etc. C’était toujours mieux que rien, toutefois cette époque est révolu et aujourd’hui il n’est pas envisageable ni concevable d’aborder la gestion des accès dans ce sens.

L’arrivée de LAPS à permis de répondre à ce point bien plus tard courant 2016. C’est en 2021 que LAPS devient LAPS Legacy. Ce dernier étant déprécié pour les SE W11 23h2. LAPS Legacy est remplacé par Windows LAPS.

De plus, si LAPS Legacy est un composant tiers à déployer sur chaque poste pour gérer le mot de passe administrateur local, Windows LAPS est dorénavant inclu directement à partir de la Tuesday Update d’Avril 2023 à partir des SEs Serveur 2019 et SEs Computer W10.

Néanmoins, pour bénéficier pleinement de toutes les fonctionnalités de LAPS, il est nécessaire d’avoir un DFL⁴ 2016 ou plus (ce qui à cette heure n’existe pas encore. Peut être avec WS 2025 ???) .

Microsoft résume tout cela dans un joli tableau.

Dans mon cas et le périmètre que je souhaite traiter, l’ensemble de mon SI est constitué de SE pris en charge par Windows LAPS (comme par hasard) et mon DFL est en 2016 (encore une coïncidence). Je ne toucherai donc pas à la parti émulation de LAPS Legacy à travers Windows LAPS (et en plus il est fainéant le gazier…).

Théories

Cette partie (sans vouloir la paraphraser et m’attribuer ce qui appartient à Caesar) relève d’un synthèse et de ma compréhension du sujet. Il est possible naturellement de sauter cette partie où de lire l’intégralité de l’article technet.

Il est également important que je vous précise (une nouvelle fois ?) que je ne traiterai pas non plus de la partie Azure AD/Entra ID. Je ne possède pas de tenant de test Microsoft O365. C’est pourquoi tous schéma d’origine abordant les composants Azures seront modifiés pour faciliter la lecture et se limiter au périmètre que je souhaite traiter.

Architecture

Une image vaut bien milles mots parait il…

Scénario Windows Serveur AD

La gestion des mots de passe administrateur locaux à travers un Serveur AD va se dérouler par GPO.

Dans mon approche, je souhaite protéger l’ensemble des ordinateurs du domaine ainsi que les contrôleurs de domaine.

Afin de garder un certain niveau de sécurité, je vais créer 3 GPOs ayant chacun un périmètre défini d’application et d’exploitation.

• LAPS_Computers : Pour la gestion des ordinateurs du domaine (comprendre poste utilisateurs) avec les droits de lecture et de déchiffrement du mot de passe aux équipes opérationnelles (Centre de service, technicien et administrateurs délégués)
• LAPS_Serveurs : Pour la gestion des ordinateurs du domaine (comprendre les serveurs du domaine hors Contrôleurs de domaine) avec les droits de lecture et de déchiffrement uniquement des administrateurs du domaines.
• LAPS_ServeursDCs : Pour la gestion des Contrôleurs de domaine avec les droits de lecture et de déchiffrement uniquement des administrateurs du domaines.

Il reste néanmoins important de garder en tête le principe fondamental de moindre privilège et d’usage lié à LAPS. Résumé trop joliment comme ci-dessous :

Une fois la stratégie configurée et appliquée, lorsque le mot de passe va expirer, un nouveau mot de passe va être générer selon les critères de complexité défini puis être stocké et chiffré dans l’AD avant d’être appliqué sur l’équipement concernée.

Question ? Comment le mot de passe est il chiffré en base ?

Il faut pour rappel avoir un DFL en 2016. Pour la suite, l’ensemble d’outil cryptographique DPAPI CNG⁵ via l’algorithme AES-256⁶ assurera de chiffrer notre mot de passe.

Il est également possible de définir un historique des mots de passe et de forcer le renouvellement du mots de passe avant la date d’expiration.

Dans la même philosophie, Windows LAPS inclus également une protection contre la falsification de compte. C’est à dire que si un outil ou un individu vient à modifier le mot de passe Administrateur local sans passer par l’AD, Windows LAPS va rejeter la tentative de modification :

• STATUS_POLICY_CONTROLLED_ACCOUNT (0xC000A08B)
• ERROR_POLICY_CONTROLLED_ACCOUNT (0x21CE\8654)

Illustré par l’évènement suivant côté poste ordinateur.

Cycle de vie

Le cycle de vie est plutôt simple. Le logigramme ci contre résume parfaitement le fonctionnement. Si le mot de passe a atteint ça date d’expiration. Le DC va générer un nouveau mot de passe selon les critères établis. Stocker ce dernier dans l’AD le chiffrer (si les prérequis sont présents) avant d’appliquer ce dernier sur l’équipement concernée. Dans le cas contraire où la date d’expiration n’est pas atteinte, aucun changement n’est réalisé.

Maintenant, je pense que nous pouvons passer à la pratique.

Pratiques

Vérifications

Vérification de la présence de LAPS sur nos DC⁷ :

> Import-Module LAPS
> Get-Command -Module LAPS

Les commandes sont bien présentes sur notre DC concernant le module LAPS. Pour autant, ce dernier n’est pas présent dans le Schéma de notre AD⁸. Il sera donc nécessaire d’ajouter celui-ci en mettant jour le Schéma.

Mise à jour du Schéma

La mise à jour nécessite d’avoir les privilèges Administrateur du Schéma. Dans le cas du respect des bonnes pratiques de sécurité, vérifier au préalable que l’utilisateur qui va être utilisé pour réaliser l’opération de mise à jour soit bien membre de ce groupe. A la fin de la mise à jour il sera nécessaire de retirer celui-ci pour des raisons de sécurité.

> Update-lapsADschema

La mise à jour du Schéma réalisée, actualisons notre console de gestion AD. Regardons les propiétés d’un objet computer.

Un onglet supplémentaire est apparu (non par magie mais grâce à la mise à jour du Schéma). L’ajout d’attribut ayant été apporté aux objets de type computer.

LAPS TAB	LAPS Attributs

Si nous rentrons dans le détails des attributs et de l’onglet ?

• Expiration actuelle du mot de passe LAPS : Date d’expiration actuelle du mot de passe. Une fois la date atteinte, le mot de passe sera changé automatiquement.
• Définit l’expiration du nouveau mot de passe LAPS : Date de la prochaine expiration du mot de passe. Il est possible de réaliser le changement du mot de passe immédiatement en réalisant une action sur le bouton Expirer maintenant.
• Nom du compte d’administrateur local LAPS : Nom du compte concerné
• Mot de passe du compte d’administrateur local LAPS : Le mot de passe du compte est defacto chiffré et ne peut être déchiffré que par les utilisateurs autorisés.

Configuration

Computers Objects

Mon avis sur le sujet est de faire la différence entre les postes utilisateurs, les serveurs divers et les serveurs AD. Soit, de réaliser une politique pour chaque rôle tiers. Il est nécessaire d’inscrire ces politiques dans la PSSI (oui c’est chiant, mais au moins comme ça c’est carré.).

Commençons par donner les autorisations aux ordinateurs membres de l’OU Rebond de venir écrire les attributs LAPS.

> Set-LapsADComputerSelfPermission -Identity "OU=Rebond,OU=Computers,OU=_root,DC=ronelab,DC=lan"

Maintenant que les permissions sont défini il est nous faut faire une petite GPO 🙂 [Ne pas oublier de copier le fichier C:\Windows\PolicyDefinitions\laps.{admx,adml} dans le magasin central]

1 – Emplacement de Sauvegarde

Il est possible de définir l’emplacement de sauvegarde du mot de passe local du compte adminitrateur dans l’AD (OnPremise) ou dans AAD (Cloud) voir le laisser désactivé.

2 – Politiques et Complexité du MDP

Nous définissons selon ce qui est décrit dans la PSSI la politique de mot de passe local ainsi que sa complexité.

Devons nous faire une distinction entre les postes utilisateurs et les serveurs par exemple ?

Il s’agit d’un compte Administrateur local donc la politique doit être la plus forte possible. Aucun besoin pour qu’un utilisateur utilise le compte d’administration local.

Pour cela j’aime bien me référer à cette image fournit par Hive SYSTEMS et repris par l’ANSSI.

Donc pour ma part, c’est 26 caractères, Majuscule, Minuscule, Chiffre et Spéciaux. J’ai choisi de faire expirer, renouveller le mot de passe tous les 30 jours.

3 – Chiffrement du mot de passe

Par défaut le mot de passe est chiffré avant d’être stocké. Toutefois, je pense (et c’est mon point de vu) que forcer l’activation est une bonne chose. Nous ne sommes jamais assez prudent.

/!\ Attention : Car le chiffrement est pris en compte pour un niveau fonctionnel Windows Server 2016. En dessous, cela ne sera pas pris en compte.

4 – Historique

Il est possible de garder un historique des mots de passe générer. Je pense par sécurité que garder 12 entrées est une bonne chose.

En lien avec la complexité du mot de passe est la fréquence de renouvellement défini, cela permet de vérifier que le changement a bien eu lieu et de remonter en cas d’avarie sur le mot de passe Administrateur local actuel à ceux défini précédemment.

365 Jours = Fq Renouvellement x Nb Retention Historique

5 – Compte Administration Local

Il nous faut spécifier le compte local dont nous souhaitons manager la rotation des mots passe.

Si le compte reste Administrateur, nous pouvons passer notre route. Toutefois cela ne représente pas selon moi une bonne pratique. Le compte Administrateur local doit être désactivé est un compte doit être créé, membre du groupe Administrateur.

6 – Habilitation, gestion des MDP

Questions, qui peut lire et déchiffrer les mots de passe ?

Par défaut c’est uniquement le groupe Administrateur du Domaine qui a ce privilège. Mais voilà, nous nous retrouvons à un carrefour sécuritaire.

Admettons (et c’est une bonne raison) que je souhaite donner les droits à mes équipes d’accéder au mot de passe chiffré des comptes administrateurs locaux des postes utilisateurs uniquement.

• Soit je fais de la délégation sur les attributs en plus de la délégation en place sur l’AD
• Soit je les passe membre du groupe Administrateur du domaine
• Soit je ne leur donne pas les droits et je surcharge l’équipe d’administration avec ce genre de requête.

Ou alors, je leurs créé uniquement les droits que pour les objets computers concernés par cette politique.

Au préalable, nous avons créé un GLS⁹ propre au déchiffrement des mots de passe ayant pour membre les utilisateurs. Récupérons l’objectSID et collons la valeur dans le champs du paramètre de la GPO Déchiffreurs de mdp autorisés.

Sauf que voilà, avec l’utilisateur qui à la délégation, cela ne fonctionne pas… Pourtant le groupe est bien le bon ?

Alors là, il suffit de RTFM. Nous pouvons faire deux constats.

• Le compte Administreur du domaine (celui que j’utilise actuellement) n’est PLUS de facto autorisé à lire les mots de passe. Donc il va être nécessaire d’ajouter le groupe Admin du Domaine comme membre de notre GLS.
• Il nous manque les autorisations de lecture sur l’OU, comme nous l’avons fait initialement. Sans quoi, le groupe n’a pas le droit de venir lire les attributs

> Set-LapsADReadPasswordPermission -Identity "OU=Rebond,OU=Computers,OU=_root,DC=ronelab,DC=lan" -AllowedPrincipals "RONELAB\GLS_SECU_LAPS_REBOND_DECRYPT"

Domain Controllers Objects

Tout comme ce que nous avons pu voir précédemment l’une des grandes puissances de Windows LAPS est la capacité de pouvoir sauvegarder et de réaliser une rotation du mot de passe DSRM pour les DCs.

Ce mot de passe n’est que trop peu modifié et même j’ose le dire quasiment jamais modifié. Cela entrainant une vulnérabilité de sécurité importante pour l’ensemble de notre SI.

Si nous regardons de nouveau les propriétés de l’un de nos ADs, nous remarquerons que l’onglet LAPS est également présent, bien que différent dans son affichage.

Définition donc notre stratégie DSRM 🙂

Attribuons les droits pour autoriser nos AD à écrire le mot de passe DSRM.

> Set-LapsADComputerSelfPermission -Identity "OU=Domain Controllers,DC=ronelab,DC=lan"

Configurons notre GPO.

1 – Emplacement de Sauvegarde

Il est possible de définir l’emplacement de sauvegarde du mot de passe local du compte adminitrateur dans l’AD (OnPremise) ou dans AAD (Cloud) voir le laisser désactivé.

2 – Politiques et Complexité du MDP

Nous définissons selon ce qui est décrit dans la PSSI la politique de mot de passe local ainsi que sa complexité.

Devons nous faire une distinction entre les postes utilisateurs et les serveurs par exemple ?

Il s’agit d’un compte Administrateur local donc la politique doit être la plus forte possible. Aucun besoin pour qu’un utilisateur utilise le compte d’administration local.

Pour cela j’aime bien me référer à cette image fournit par Hive SYSTEMS et repris par l’ANSSI.

Donc pour ma part, c’est 26 caractères, Majuscule, Minuscule, Chiffre et Spéciaux. J’ai choisi de faire expirer, renouveller le mot de passe tous les 30 jours.

3 – Chiffrement du mot de passe

Par défaut le mot de passe est chiffré avant d’être stocké. Toutefois, je pense (et c’est mon point de vu) que forcer l’activation est une bonne chose. Nous ne sommes jamais assez prudent.

/!\ Attention : Car le chiffrement est pris en compte pour un niveau fonctionnel Windows Server 2016. En dessous, cela ne sera pas pris en compte.

4 – Historique

Il est possible de garder un historique des mots de passe générer. Je pense par sécurité que garder 12 entrées est une bonne chose.

En lien avec la complexité du mot de passe est la fréquence de renouvellement défini, cela permet de vérifier que le changement a bien eu lieu et de remonter en cas d’avarie sur le mot de passe Administrateur local actuel à ceux défini précédemment.

365 Jours = Fq Renouvellement x Nb Retention Historique

5 – Compte DSRM

Le prérequis pour réaliser la sauvegarde du mot de passe DSRM dans l’AD réside dans la réalisation du point N°3 Chiffrement du mot de passe.

Alors il suffit d’activer le paramètre.

6 – Habilitation, gestion des MDP

Contrairement à la partie précédente concernant les Computers Objects, il est impensable d’ouvrir et de déléguer l’accès au mot de passe DSRM à toutes autres personnes que les membres du groupe Admin du domaine. Et quand bien même l’information doit être accessible par le mois de personne possible.

Dans mon cas, ayant mis un semblant de RBAC Tiers 3 sur l’AD, je laisserai le groupe Admin du Domain.

Une fois la GPO appliqué sur notre OU Domain Controllers, jetons un œil sur les valeurs de nos attributs LAPS (en powershell ce coup ci).

> Get-LapsADPassword -Identity "EGSRV-AD01" -IncludeHistory

With -AsPlainText	Without -AsPlainText

J’ai volontairement demandé un rotation du mot de passe manuellement. Force est de constater que tout fonctionne. Egalement, étant avec un compte Administrateur du domaine, je peux déchiffrer le mot de passe. Néanmoins, si nous ne précisons pas le classique -AsPlainText, ce dernier n’affichera que le type SecureString.

Mise en garde

Il est important de noter qu’il y a un risque à automatiser la rotation des mots de passe locaux. Surtout dans le cas des comptes DSRM. Prenons l’exemple ci-dessous.

Admettons que nous ne pouvons plus nous connecter à notre contrôleur de domaine hébergeant les rôles FSMO. Nous envisageons la procédure classique de passer par une restauration à partir du mot de passe DSRM. Nous saisissons le mot de passe et normalement nous devrions commencer à suer du CIF (et je parle pas de SQL…). Hé oui, le mot de passe a changé dans le cadre de la rotation que nous avons paramétrés. Alors que faire ?

Je me suis posé la question de vérifier s’il était possible de récupérer ce dernier depuis VEEAM dans les attributs.

Standard Objects Computers	DC Objects Computers

Pour les objets ordinateurs « standards » ou « communs », le mot de passe local est bien présent mais chiffré Toutefois, il est surprenant de se rendre compte qu’il n’existe aucun objet ordinateur dans l’OU Domain Controllers (normal au vu de la criticité du rôle et logiquement, cela reviendrait à faire une restauration du serveur lui-même en non autoritaire/autoritaire selon le scénario envisagé).

Bref, pour réinitialiser un mot de passe local pour un serveur ou un poste, nous avons toujours la bonne vieille méthode du média d’installation. Pour l’AD, c’est compromis… Restera alors à passer par un autre DC et de reset si possible le mot de passe DSRM de notre DC impacté (avec ce bon vieux ntdsutils).

Je recommande donc dans la logique de ne pas instancier la rotation des mots de passe DSRM s’il n’y a pas de procédure en place. Dans le cas contraire, il est nécessaire d’être d’une rigueur extrême dans le MCO des mots de passe.

Journalisation

Ce qui m’a tapé dans l’œil avec LAPS c’est quelques choses de très simple mais souvent négligé dans certains outils. Les actions sont loggées dans l’Observateur d’évènements ! Comme quoi il suffit certaines fois de pas grand chose… 🙂

Journaux d’applications > Microsoft > Windows > LAPS

MCO

Comme toutes solutions, c’est bien beau d’avoir une application qui sécurise et administre les comptes d’administrations locaux, mais comment s’assurer que les politiques sont bien appliquées sur les postes et qu’il n’y a pas de trou dans la raquette pouvant amené à rendre vulnérable notre SI ?

Si j’ai fait les louanges dans la partie précédente concernant la journalisation. Là c’est je pense un gros manque pour assurer un niveau de sécurité du système d’information.

Je pense qu’il existe des outils sur le net développé par d’autres SysAdmins consciencieux de leurs jobs et de leurs postes. Toutefois, et si aucune solution existe, il serait pas mal de se faire un petit outil non ? Et si cet outil nous envoyait un rapport par mail ? Ca serait merveilleux et nous pourrions hurler sans bruit !

Implémentation LAPS Audit

Dans un premier temps, il convient de définit notre infrastructure. Notre outil (script) sera exécuté directement sur le serveur AD hébergeant les rôles FSMO pour plus de sécurité.

Dans le respect des bonnes pratiques, nous bénéficions d’une infrastructure 3 tiers. Du fait de cette infrastructure nous n’autorisons pas notre tiers 0 (nos DCs) à communiquer vers l’extérieur. Pour envoyer le rapport par mail, nous utiliserons un serveur SMTP dans notre tiers 1 qui jouera le rôle de relai SMTP vers notre serveur SMTP externe.

Je considère que nous avons déjà un serveur relai SMTP configuré et fonctionnel sur notre infrastructure (Mutt ou Windows). Il sera nécessaire également de réaliser sur l’UTM les policies interlans et outbounds.

Analyse du script

Le script (SS_040_WIN_LAPS-Audit) dans sa version 1.0 est plutôt simple et comporte quatre fonctions :

getADComputersObject : Fonction qui permettra de retourner l’ensemble des objets ordinateurs joint à notre domaine. Je prends soins de faire une distinction entre les Contrôleurs de Domaines, les Serveurs et les Ordinateurs. getLAPSAudit : Fonction qui permettra de retourner les attributs Microsoft LAPS des objets ordinateurs du domaine indiquant si LAPS est appliqué sur les objets et l’échéance de rotation des mots de passe du compte Administrateur local. getLAPSHTML_Report: Fonction qui va générer le rapport HTML pour chaque objet ordinateur et l’état LAPS associé. sendSMTPMail : Fonction qui va envoyé le mail, notre rapport à notre serveur SMTP.

Il convient d’éditer le script est d’adapter les constantes suivantes :

$From : De type string, l’adresse mail de l’émetteur. Généralement le nom de votre serveur AD. $To : De type string, l’adresse mail du récepteur. $SMTPServer : De type string, le FQDN ou l’IP du serveur SMTP interne. $Port : De type int, à voir si le serveur interne accepte le protocole SMTP, SMTPS ou TLS.

Et c’est tout. Il n’y a rien d’autre à faire. Si ce n’est implémenter ce dernier. Sur notre serveur AD.

Implémentation

Avant toutes choses, la méthode reste libre quant à l’exécution de la tâche. Certains dirons j’aime faire de la MSA¹⁰, d’autre de la gMSA¹¹ et d’autres les puristes qui n’ont pas été mise à jour depuis longtemps des comptes utilisateurs restreints. (Il existe aussi une autre catégorie de SysAdmin du Dimanche qui utilisent des comptes non restreints. Mais il faut le dire doucement pour ne pas réveiller leurs impérities).

Il est important de préciser avant de prendre ma dernière aparté pour une réflexion condescendante de ma part et remplie d’orgueil que je ne suis pas dans le jugement. Le manque de compétence se corrige en se remettant en cause chaque jour. Ce qui a pour conséquence de venir palier et combler les impérities. Pour le reste, c’est toujours la question classique du « Quelle est la différence entre le bon et le mauvais SysAdmin« . Restons dans la dynamique du Plan-Do-Check-Act. 🙂

Bref, chacun voit midi à sa porte et nous sommes responsable de nos décisions et de nos choix. Je passe donc la partie compte dédié.

Sous C:\ créer un répertoire scripts avec pour sous répertoire SS_040_WIN_LAPS-Audit contenant notre script. Modifions les ACLs comme ci dessous en prenant soin de désactiver l’héritage.

Ouvrons le TaskManager et créons notre tâches.

1 – Général

Comme d’accoutumé, je reprends En nom de tâche le nom du répertoire racine du projet. Je renseigne le compte utilisateur qui va exécuter la tâche (ici un compte restreint avec une sécurité qui m’est propre). Naturellement nous n’enregistrons pas le mot de passe et nous configurons la tâche pour les Windows Server 2022 (nous sommes sur notre DC et ce dernier Dieu m’en est témoin, ce n’est pas un 2008 !).

2 – Triggers

Point un peu plus sensible et singulier, quand recevoir le rapport d’audit ? Ayant définit la rotation des mots de passe à 30 jours au plus bas, il me semble logique de réaliser un déclencheurs tous les mois.

C’est pourquoi, je configure la tâche à s’exécuter tous les Premiers Lundis de chaque mois sans échéance de fin.

3 – Actions

Call me, call me any, anytime ! Nous allons préciser que l’action a réaliser et d’exécuter notre script avec l’argument -File Path utilisant le programme powershell.exe.

4 – Conditions

Décochez ou cochez selon vos envies les conditions. Pour ma part, pas de conditions particulières.

5 – Settings

J’autorise la possibilité d’exécuter cette tâche manuellement et d’arrêter la tâche si cette dernière au bout de 3 jours. Surtout, et je crois que c’est important (du moins pour moi) de ne pas démarrer une nouvelle instance si la tâche est déjà en cours d’exécution.

En résumé, si nous attendons patiemment la prochaine exécution de la tâche planifiée ou que nous exécution manuellement cette dernière, nous devrions recevoir dans notre BAL le rapport ci-dessous.

Nous n’allons pas nous mentir et vous pouvez rameuter vos collègues FrontEnd, mon CSS et HTML sont plus que nauséeux. Mais mon avocat tiens à vous rappeler que je déteste faire du HTML et CSS, et qu’au vu de l’effort fournit vous devriez plutôt m’encourager (et initier une troisième mi-temps. Car n’oublions pas, On voit quand j’ai bu, on voit pas quand j’ai soif. <3).

Oui, il y a de quoi penser à une version 1.0.1 en ajoutant des fonctionnalités telles qu’un peu de forme, des statistiques sur le périmètre protégé par LAPS, un suivi d’Azure AD etc. Toutefois, je vais laisser un peu de temps avant de pousser ces bugs, ou features [rayer la mention utile].

GitHub

La première version stable de mon petit outils. Toutefois il sera nécessaire de suivre la partie précédente pour implémenter ce dernier.

Miaou

Conclusion

Je vais être honnête et vous dire que je me suis éclaté sur cette technologie. C’est un outil puissant, simple et complet. Le seul bémol que je pointe (et que j’ai pointé) reste la partie audit et reporting.

Il est également important de prendre avec précaution la rotation des mots de passe DSRM. Il est nécessaire d’aborder ce point dans la PSSI et de définir le rythme ainsi que tous les caractéristiques de son renouvellement et de l’emplacement de stockage de ces derniers.

N’oublions pas néanmoins que nous ne traitons que des comptes d’administration local des postes qui sont joint au domaine et non des postes, serveurs qui n’y sont pas. Il faudra en cas d’avarie définir la procédure de rotation des mots de passe et des ressources non concernés par cette automatisation d’être traitées en priorité selon leurs criticités.

L’un des points qui me frustre et que je n’ai pas détaillé car je me suis cassé les dents (pour l’instant) reste de ne pas avoir pu déchiffrer un mot de passe LAPS depuis la restauration de l’attribut VEEAM. Mais je ne désespère pas et vais y passer d’avantage de temps. Je reviendrai plus tard sur ce billet 🙂

Le mot de la fin

Le mot de passe ? Comment est votre blanquette. Caput Draconis? Nous avons un gagnant. Vous repartez avec votre point en gratin dauphinois sur un air latinos ! OH-oh-OH

Erwan GUILLEMARD

Sources

• Windows LAPS : Guide
• Windows LAPS : Concept Guide
• Windows LAPS : DPAPI CNG
• ANSSI : Politique et complexité des MDPs

1. LAPS : Local Administrator Password Solution ↩︎
2. GPO : Group Policy Object ↩︎
3. CIs : Configurations Items ↩︎
4. DFL : Domain Forest Level ↩︎
5. DPAPI CNG : DataProtection API New Generation ↩︎
6. AES-256 : Advanced Encryption Standard 256 bits ↩︎
7. DC : Domain Controler ↩︎
8. AD : Active Directory ↩︎
9. GLS : Group domain Local Security ↩︎
10. MSA : Managed Service Accounts ↩︎
11. gMSA : Group Managed Service Accounts ↩︎