WIN – AD & Windows LAPS

L’une des tâches les plus pénibles d’un SysAdmin à mon sens reste je le crois la gestion des mots de passes d’administrateur locaux. Il faut se connecter sur chacun des serveurs, se rendre dans la gestion de l’ordinateur blablablabla. Quand il n’y a que quelques serveurs ça peut aller vite. Quand le nombre augmente ça devient vite chronophage et semblable au tonneau des danaïdes.

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

/!\Attention : La mise à jour du schéma est irréversible. Il est nécessaire au préalable de s’assurer que la sauvegarde des ADs sont viables et correcte. Ainsi que la sauvegarde Windows Backup.

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]

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.

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.

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 ↩︎