Logique dans un sens puisque le certificat auto-généré par ce même équipement ne peut-être juge est parti. Le certificat doit être demandé par l’équipement à une autorité certifiant que c’est bien lui.

M’enfin comme le dirai notre bon vieux LAGAFFE, j’ai défait fait un billet dans ce sens et je ne vais donc pas user de la combinaison Ctrl+C, Ctrl+V. Et gardons à l’esprit jeune damoiseau (plus encore pour longtemps) les bonnes résolutions de rédaction de cette année 2025.

Nous voilà en route pour aborder le sujet des certificats d’infrastructure à clé publique (PKI¹) dans un environnement windows avec domaine pour renforcer la sécurité de nos SIs², ménager nos WebBrowser quant à l’affichage de ce type d’avertissement.

Et surtout, préparons nous à nous arracher les cheveux par moment.

Mais alors pourquoi faire de nouveau un article sur ce sujet si tu as déjà couvert ce même sujet ? Difficile de tester et de traiter de certain sujet sans avoir de serveur PKI. Implémenter des fonctionnalités c’est bien. Les sécuriser c’est mieux.

Cet article permettra par la suite de pouvoir traiter de sujet comme (et ce n’est qu’un exemple) :

• WinRM Over HTTPS
• SMB OverQuick
• Applications en HTTPS
• etc

Une autre raison, reste d’avoir de maintenir un niveau technique cohérent avec mon cercle professionnel et non pas rester sur le banc de touche. Si la théorie est acquise, la pratique ne l’est pas, du moins ne l’était pas avant la rédaction de ce papier.

Prérequis

• SE : Windows Server 2k19 et version ultérieures
• Apps : N/A
• Autres :
  • Domaine AD
  • Applications supportant TLS/SSL

Avant Propos

Avant de rentrer dans le vif du sujet et d’aborder ce qui est propre Windows, je pense utile de faire un rappel des bases de la cryptographie moderne aussi loin qu’il m’est possible de me remémorer mes cours de cryptographie.

Sinon à quoi bon aborder le sujet de certificat sans en piper le moindre mot ? Et croyez moi, je fume bien la pipe….

Déjà, le pourquoi de chiffrer une information ? Pour cela nous devons faire appel à CAIN.

Rien à voir avec Abdel se faisant tuer par Cain premier meurtrier, mais il me faisait plaisir de partager l’œuvre de Sebastiano RICCI que je trouve magnifique (la confiture c’est comme la culture, moins on en a plus on l’étale). Plus sérieusement : C : Confidentialité des informations stockées ou manipulées A : Authentification des protagonistes lors des des communications I : Intégrité des informations stockées ou manipulées N : Non-Répudiation des informations

En complément du premier principe fondamental, j’enchainerai avec un second qui est précieux pour mon petit cœur, le principe de Kerckhoffs.

• La sécurité repose sur la clé de chiffrement et non sur le secret de l’algorithme
• Le déchiffrement d’un contenu chiffré doit être impossible dans un temps raisonnable
• Déterminer la clé à partir du contenu en clair et du contenu chiffré doit être impossible dans un temps raisonnable

Soit, toute attaque doit être envisagée en supposant que l’attaquant connait tous les détails du cryptosystème.

Je pense qu’avec ces deux principes, nous pouvons faire un grand pas en avant et plonger dans le monde de la cryptographie moderne. [Je ne suis pas un spécialiste de la question, je laisse à mes pères le droit de me sabrer sur le sujet.]

La cryptographie moderne tourne autour du chiffrement asymétrique et de plusieurs algorithmes. Tout est régis dans notre bas monde par ces algorithmes et la capacité et puissance des nombres premiers. Toutefois l’émergence de la technologie quantique et de l’age d’or de l’IA³ va remettre assez rapidement en cause ce paradigme.

L’un des derniers en date. Cela fait froid dans le dos hein ?

Bref, parlons peu mais parlons bien. Qu’est que le chiffrement asymétrique ?

Le chiffrement asymétrique consiste à la génération d’une clé dite privée et d’une clé publique. A travers de fonction unique, il n’est pas possible de déchiffrer un message chiffré par la même clé.

Ainsi, la clé privée est l’élément sensible et doit rester connu que de la source et non de la cible. Seule la clé publique et communiqué. Ainsi, prenons le cas d’un échange entre Alice et Bob (sacré Robert et Alice, toujours là depuis des décennies à s’envoyer des messages sans jamais arriver à conclure ou pécho pour les millénials… Tout ça car Charlie veut pécho Alice ou Bob. C’est un peu l’Antigone 3.0 de notre temps… Je laisse à Jean Anouilh la version 2.0).

Ainsi, si nous regardons un échange entre Alice et Bob sans inclure Charlie :

Alice étant folle amoureuse de Bob, elle a communiqué sa clé publique (mais pas à Charlie) mais garde sa clé publique. Si Alice veut écrire un message à Bob (1), elle va chiffrer son message avec sa clé publique et déposer son fichier dans le grand tuyau qu’est l’internet. Charlie qui est caché derrière son écran et qui veut de la thune (et pas que) ne voit passé qu’un message incompréhensible car il n’a pas la clé publique d’Alice. Bob, lui reçoit le message chiffré, qu’il pourra déchiffrer grâce à la clé publique qu’Alice lui a transmis. Mais voilà (2), Bob est un peu beauf et ne comprend pas l’amour que lui porte Alice et lui répond qu’il aime les moules frites et les soirées tunnings. Il chiffre sa réponse avec la clé publique et la retourne à Alice. Charlie, lui aime le tunning mais il ne pourra jamais déchiffrer à temps le message… Alice reçoit la réponse de Bob, est malgré la clé privée ne devrait pas déchiffrer le message de Bob.

Mais à l’inverse, si nous admettons qu’Alice échange également avec Charlie (donc que Charlie possède la clé publique d’Alice), Charlie peut pas échanger des menaces de morts à Bob de manière sécurisé MAIS Bob ne sera pas dans la capacité de déchiffrer le message de Charlie. Bob, petit conseil d’ami, compose le numéro de police secours, j’dis ça, j’dis rien.

Bref, Alice finira dans sa baignoire à écouter « Avril Lavigne » (a prononcer avec l’accent) avant d’être de nouveau figurante dans un schéma d’explication d’un échange cryptographique.

Nous avons donc l’idée du fonctionnement. Et bien les certificats c’est presque pareil dans le fonctionnement, mais en complément nous allons retrouver des informations permettant d’identifier le fournisseur, la source. Afin de garantir la sécurité, une durée de vie est définie dans le temps. Ce dernier devra être regénéré. Les certificats sont uniques et intrinsèques à une entreprise, une personne.

J’espère donc avec cette courte introduction ne pas avoir dit d’ânerie. C’est que 2013 ce n’est plus si proche que ça. Sinon, je corrigerai ou supprimerai l’article. J’assumerai l’entière responsabilité de cet échec en me retirant définitivement de la cryptographie… Non, je retournerai en khôls sur les bancs de la fac (#IUTdeLens #StadeBollaert #RinceCochon #Frites).

Théorie

Je pense que nous sommes assez armés pour aborder la suite. Comment construire et définir correctement son architecture PKI dans son SI.

La première vraie question est qu’est ce que je souhaite implémenter et comment je souhaite gérer les inscriptions et demande de certificat ?

C’est à cette question que nous allons tâcher de répondre.

Architecture & Best Pratices

La documentation Microsoft est pour le coup pas mal gaulé. Et deux architectures sont proposées. Bien que l’une convienne plus à une autre en termes de sécurité, il est important de définir le temps et la complexité à passer par l’équipe en place pour administrer la solution.

Sortir une architecture autonome pour 4 serveurs, utilisé par 30 personnes et administré par 1 seul SysAdmin c’est un peu surdimensionné. Oui c’est une bonne pratique mais quand même. Alors qu’une architecture d’entreprise serait plus appropriée.

Oh Pt’ain le con il a lâché les deux types d’infrastructures comme ça ! T’es un précoce de la vie non ?

T’inquiète, j’ai encore une balle dans la chambre lapin.

Peu importe le type d’architecture, nous devons considérer qu’un serveur ADCS⁴ (ou avec les rôles PKIs) est critique pour l’organisation du SI. Donc il passe directement en case T0 du modèle de tiering.

Ainsi, il est primordial que ce serveur ADCS ne soient pas accessible de n’importe qui et de n’importe où. Si ce dernier se fait compromettre, c’est l’ensemble de notre SI qui sera hors service. Vous pouvez toujours dire ce n’est pas moi et aller pointer au France Travail. Blague à part, notre serveur va nous servir à délivrer les certificats de notre SI. Le serveur certifiera ces derniers comme valider par lui, autorité de confiance. Or, ce même serveur s’appuie sur ADDS5. Donc, nous n’avons pas à exposer ce dernier (mais je reviendrai sur ce point car il y a des exceptions).

Le modèle ci-dessus représente clairement l’architecture d’autorité d’entreprise. Cette architecture convient au petit système d’information et donc au PME⁶. Il convient donc de joindre le serveur ADCS à notre domaine. Notre serveur d’autorité de certification sera donc disponible et validera les demandes d’inscriptions ains que les différents modèles. Le problème réside dans la sécurité de ce dernier. Si nous voulons nous assurer que notre autorité de certification racine ne soit pas compromis, il serait bien de la rendre inaccessible. Microsoft, recommande clairement d’éteindre ce dernier. Toutefois, ce n’est pas possible car ce dernier est unique et en plus joint au domaine…

C’est ainsi que rentre en jeu l’architecture d’autorité autonome. Comme son nom l’indique, cette architecture est indépendante de notre domaine, mais nécessite un serveur dit d’autorité secondaire ou d’autorité intermédiaire. Ce qui concrètement nous donne le modèle suivant de tiering.

Nous déployons hors domaine dans une bulle à part notre serveur d’autorité de certification racine. Nous définissons notre certificat racine. Dans notre bulle T0, nous allons créer un nouveau serveur dit d’autorité intermédiaire ou secondaire. Ce dernier va avoir un certificat que va être certifié par l’autorité racine. Ainsi, ce dernier aura dérogation pour délivrer les certificats et les inscriptions sur notre SI. Dérogation et délégation oui, mais pas les pleins pouvoirs. C’est là que ça devient fun. Niveau sécurité, il ne reste plus qu’à éteindre notre serveur d’autorité racine. Il n’est pas au domaine donc qu’est qu’on en a à fo***re ? Si nous en avons besoin, nous le remettrons sous tension et pas de risque de tombstone.

Nous pouvons descendre d’un niveau hiérarchique supplémentaire en parlant d’une autorité de certification émettrice. Mais je n’irai pas jusqu’à ce niveau là d’architecture. Dans le cas commun des entreprises, un niveau de hiérarchie voir deux sont suffisantes.

• Niveau 1 : Autorité de Certification Racine
  • Niveau 2 : Autorité de Certification Secondaire/Intermédiare (ou de Stratégie)
    • Niveau 3 : Autorité de Certification émettrice

Dans les architectures les plus complexes il est également possible de réaliser des approbation inter-certificat, comme nous pourrions le faire avec une relation d’approbation inter-domaine. Mais je n’ai jamais vu, ni même penser cela possible jusqu’à ce que je mette ma truffe dans la documentation. Je vais déposer les armes devant cette architecture car je ne pense pas que cela soit monnaie courante (quoi que…). Joker, je fais appel à mon droit de véto pour cette fois.

Bien, mais alors vu que le serveur qui porte les rôles d’autorité de certification racine n’est pas au domaine, les fonctionnalités et services proposés ne peuvent être les mêmes qu’une autorité de certification d’entreprise ? Tout juste.

Clairement, je ne vais pas me faire ch**r et vais donc reprendre le tableau de Microsoft. J’ai une flemme de montrer ma maitrise en paraphrase.

Concernant la méthode d’inscription, ou plutôt les méthodes d’inscriptions il est nécessaire de considérer le besoin. Personnellement, je réalise l’ensemble des demandes si ce n’est la totalité manuellement. L’inscription via les services WEB (à travers IIS⁷) est compromise depuis la découverte de PetitPotam et bien qu’un KB⁸ soit disponible pour renforcer la sécurité cela représente un risque trop certains (et surtout, j’ai jamais été foutu de le faire fonctionner avec mon serveur core. L’arroseur arrosé en somme 🙂 ).

Bien, je pense que niveau théorie, la boucle est bouclée. Si besoin je reviendrai dessus mais entre deux poses déjeuner et le travail nocturne (si je peux nommer ça travail) j’ai la fâcheuse tendance à perdre le fil. 🙂 Enfin bon, place à la pratique.

Pratique

Pour répondre à la partie théorique, je resterai sur une inscription manuelle ainsi que dans de rare cas un inscription des postes. Naturellement et comme souligné plusieurs fois, je déploierait une architecture type autorité de certification d’entreprise à un niveau de hiérarchie.

Okay, let’s go…

Installation

Pour cette partie je veux réaliser deux approches, l’approche sur un serveur classique soit avec l’expérience utilisation et sur un serveur core (bye bye la GUI⁹). A la liberté de chacun de choisir son type d’installation.

Or je me permets de citer (après je dis ça je dis rien hein ?).

Un autre point à prendre en compte est le type d’installation du système d’exploitation. L’Expérience utilisateur et les scénarios d’installation Server Core prennent en charge AD CS. Server Core minimise la surface potentielle du pirate et la surcharge de maintenance du système d’exploitation, ce qui en fait le choix optimal pour AD CS dans un environnement d’entreprise.

Un rédacteur chez MS

Comme indiqué précédemment, mon serveur de certification racine sera joint au domaine par manque de ressource, naturellement si les ressources étaient présentes, j’aurais déployé une architecture Intermédiaire avec le serveur CA¹⁰ hors domaine.

Je considère donc que l’environnement est à jour et préalablement durci.

GUI

1 – Add me if you can

Les actions se passent comme d’accoutumé via le gestionnaire de serveur en ajoutant un rôle. Nous devons choisir le rôle Services de certificats Active Directory.

2 – Fonctionnalités

Facultatif, mais utile de mon point de vue, l’installation des outils d’administrations distant pour administrer le service de certificat AD¹¹.

3 – Wizard

Une petite explication de ce que nous allons installer. Naturellement et comme 99% de la population nous cliquerons sur Suivant comme pour les conditions générales d’utilisations et autres droits d’usage. (Sauf qu’ici nous ne vendrons pas nos données et notre c*l ne sera pas considéré comme une base de loisir).

4 – Sélection du rôle

Enfin, cela devient intéressant. Dans le déploiement de notre rôle nous avons la possibilité d’ajouter des services supplémentaires. Dans mon cas, je n’utiliserai que la partie Autorité de certification mais il est possible d’ajouter d’autres services plus particulièrement des services d’inscription pour faciliter les demandes de création et d’inscriptions.

Toutefois et attention, certains services ouvrent des angles de vulnérabilités de par la criticité de notre serveur et surtout de ces rôles. De plus les services web ont été challengé il y a peu par PetitPotam (2022 c’était bien hier non ? Azy t’abuse gros…). Donc la prudence est de mise, pour plus d’information sur le sujet, je vous renvoie vers le KB MS traitant de la CVE¹².

(Pour le coup, je me suis bien fait fi*t* la gueule en CORE car je n’ai aucune souplesse en IIS avec mon powershell. Tiens Monsieur JDO, vous marquez un point pour le coup 🙂 ).

5 – Confirmation du déploiement

Comme chez le notaire, nous acceptons le redémarrage automatique, et nous validons les émoluments compensatoires (Merci Didier !).

6 – Installation en cours, Coffee break

L’installation se débute, se poursuit et normalement se termine par un succès. Voilà, notre rôle ajouté. Elle est pas belle la vie ?

CORE

Comme toujours (pour ne pas dire enGORE et enGORE, je vous la sorts bonne hein ! Vous l’avez SORBONNE #TESLOURD), l’installation du rôle sur un serveur core et de loin plus facile et efficace que via l’interface graphique…

Jugeons plutôt.

Et puis voilà… L’inconvénient encore une fois, c’est qu’en cas de dysfonctionnement il faudra être agile du powershell et de la ligne de commande pour se sortir de la merde. Pas question de compter sur ce bon Samsagace GAMEGIE face à SHELOB…

Configuration

Si l’installation du rôle est plutôt simple, la configuration nécessite un tantinet plus de réflexion. Naturellement, j’aborde les deux méthodes de déploiement de notre rôles ADCS pour un environnement GUI et CORE.

Important, pour la base de données et les journaux d’événement, nous stockerons ces derniers sur un volume dédié indépendamment du volume système (C:\). La raison me semble évidente et je ne m’attarderai pas sur ce point.

GUI

1 – On montre patte blanche

Les opérations pour configurer le rôle nécessite un compte Administrateur local et Administrateur d’entreprise.

Deux approches possibles :

• Rien à fo***e du principe de tiering et de moindre privilège : J’utilise le compte administrateur du domaine. Ce dernier ayant tous les droits nécessaires. Perso, c’est pas ma philosophie, mais chacun voit midi à sa porte.
• Je suis consciencieux de la sécurité : Je crée un compte dans mon domaine membre du groupe Administrateur d’Entreprise et membre du Groupe Local d’administration de notre serveur. Je désactiverai par la suite ce compte.

Tout le monde sait que je défendrai bec et ongles le premier point 🙂

2 – Choix du service à configurer

Quel rôle souhaitons nous configurer ? Sans grande surprise, vu que nous n’avons installer que le service d’Autorité de certification… La question est vite répondue.

3 – Type d’installation, croisé des chemins

Je parle de croisé des chemins car selon moi il y a ici un choix crucial. Le choix entre plus de sécurité mais plus de contrainte et un choix plus standard.

J’ai écrit un peu plus tôt que pour des raisons de ressources mon serveur serait joint au domaine. Cela rentre donc dans le choix Autorité de certification d’entreprise.

Dans le cas contraire où, nous aurions pris le parti de ne pas joindre notre serveur d’autorité de certification ce dernier aurait été autonome et nous devrions déployer un serveur de certification intermédiaire.

J’essaierai de maquetter cette architecture. Reste néanmoins à trouver quel serveur je dois sacrifier sur l’autel de la connaissance. (Le type qui se la joue clerc au XVI).

4 – Génération de la clé privée

La génération de la clé privée est une étape importante de la configuration. Aux prémices de cette dernière, nous avons le choix de générer un nouvelle clé ou d’importer une clé existante.

Le second choix étant généralement dans le cadre d’une réinstallation ou d’une migration.

5 – Chiffrement

Le chiffrement ce n’est pas compliqué (bien que si en réalité). Nous gardons Windows comme générateur et fournisseur de notre chiffrement.

Plus c’est long, plus c’est bon… Je parle de la longueur de la clé de chiffrement naturellement. Je vous vois venir avec votre œil lubrique. Concernant l’algorithme de hachage, le plus complexe proposé donc SHA512¹³.

Je dis donc complexe car il est nécessaire de prendre en compte des applications ou OS¹⁴ obsolètes (ou ayant des dépendances obsolètes), qui ne prennent malheureusement pas en charge certaines longueurs de clé ou d’algorithme. Un petit renseignement est nécessaire en amont. Dans le doute et cela passe quasiment tout le temps SHA256/2048 en paramètre de chiffrement.

6 – Nom de l’Autorité de Certification

Le nom va permettre non seulement d’identifier rapidement notre certificat mais également de garantir sa singularité.

Ici mon certificat d’autorité portera le nom ronelab-CA-Root et couvrira le suffixe de mon domaine soit ronelab.lan, d’où DC=ronelab,DC=lan.

7 – Durée de vie

La durée de vie de mon autorité racine… Plus c’est grand dans le temps moins c’est bien. A l’inverse de la durée de vie d’un être vivant. Cherchez l’erreur… Toutefois et comme spécifié, la durée de vie de notre AC doit être supérieur à la durée de vie des certificats qui seront délivrés (logique).

Ici, je ne vais pas mentir en disant que je ne veux pas trop m’emmerder avec une échéance trop courte. Je n’ai jamais en toute franchise été confronté aux cas où le CA d’entreprise a expiré. Faudra tester…

8 – BDD et Journaux

Depuis les prémices de mes études dans l’IT, il m’a toujours été dit que ce qui doit être sur la partition système va sur le système, ce qui peut être déplacé vers un disque dédié ou partition doit être réalisé. C’est le cas ici.

9 – Récap

Comme d’habitude avec le wizard de configuration nous avons un récapitulatif de la configuration qui va être mis en place.

Le rôle est maintenant configuré. Reste plus qu’à faire un petit check up avant de se lancer dans la génération de certificat et de modèle.

CORE

En core, c’est plus simple. Pour mieux comprendre l’unicité de l’étape de configuration, il faudrait repartir de la partie 9-Récap précédente.

Le plus compliqué reste selon moi, de trouver quel argument appelé et quelle valeur lui définir.

Je glisse le lien dans les sources.

Nous retrouvons également les mêmes informations que ce qui a été présenté précédemment dans la partie GUI. Je ne passerai donc pas plus de temps sur ce sujet.

Le rôle est maintenant configuré. Reste plus qu’à faire un petit check up avant de se lancer dans la génération de certificat et de modèle.

Contrôles

L’une des premières questions que nous pouvons nous poser, est ce que notre certificat d’autorité est bien présent ?

Mon serveur étant en CORE, je vais donc à travers mon rebond d’administration user des RSAT¹⁵s lié au certificat ou à travers une console MMC¹⁶ :

• Autorité de certification
• Modèle de certificats

Ce qui est bon signe, nous constatons que notre serveur apparait en ligne et fonctionnel. Mais vérifions plus loin que ce dernier est bien présent sur notre domaine. Logique car nous avons déployé une autorité de certification d’entreprise.

Pour ce contrôle là, il est nécessaire de passer par la console ADSI¹⁷. Personnellement je ne suis jamais à l’aise dans cette console de gestion et je pense ne jamais l’être. La gymnastique d’esprit est différente de ce que nous pouvons entreprendre opérationnellement au quotidien dans la console de gestion des utilisateurs et ordinateurs AD. Bref, la navigation dans le gestionnaire ADSI se résume dans la navigation par « Qu’est ce que je recherche dans la configuration ? »

Donc nous pouvons conclure que de ce côté, je ne me suis pas iech dessus niveau configuration. Ce qui me semble une bonne chose.

Nous sommes en droit de nous poser la question, « Comment je vais pouvoir accéder à des ressources sécurisées si je n’ai pas le certificat d’autorité racine sur mon poste ? » Si le poste est au domaine (et sauf cas spécifique il l’est), ce dernier étant dans l’AD, le certificat est automatiquement ajouté comme Certificat de certification racines de confiance.

Nous pouvons double tap pour afficher les propriétés et caractéristiques de notre certificat.

Là nous sommes certains qu’il n’y a pas de loup dans le déploiement de notre service et de sa configuration. Nous pouvons donc nous pencher sur la partie Modèle de certificat.

Modèles

Lorsque nous avons déployé notre rôle, un certain nombre de modèle ont été déployé dans l’AD pour couvrir le cas échéant le domaine d’application nécessaire à la sécurisation des différents services (Ordinateur, Exchange, Serveur WEB, Utilisateurs, etc).

Ces différents modèles peuvent être utilisés pour générer nos certificats. Toutefois, il est d’usage et recommandé de dupliquer ces modèles pour les services que nous souhaitons protéger. Cela nous permet de faciliter la gestion et de garantir un niveau de sécurité en ne se basant pas sur les propriétés et paramètres par défaut des modèles.

Moi pas comprendre…

En gros, si je duplique mes modèles (qui ont les mêmes propriétés du SI de M. TUCHMUCHE) et que je custom les attributs par rôle ou service que je veux procéder, en cas de vulnérabilité, je limite mon exposition. De même que si mon SI est vulnérable par l’un de ces services, il sera plus facile de limiter le périmètre d’exposition et donc en conséquence le risque qu’il en découle.

Dupliquons un modèle pour comprendre les tenants et aboutissants des paramètres.

1 – Compatibility Tab

Lors de la duplication du modèle, le premier onglet portera sur la compatibilité de notre certificat. Personnellement et bien sûr c’est intrinsèque. Qui peut le plus ne peut pas forcément le moins.

Mon cas, avec mon lab en WS 2k22 et WS 2k25 (je crois avoir un WS 2k19 mais surement perdu quelque part) je partirai sur le niveau de compatibilité le plus haut. Mais encore une fois tout s’étudie.

J’aime à afficher les modifications résultantes pour prendre pleinement connaissance des modifications qui vont être apportés sur mon nouveau modèle. Cela peut permettre d’identifier clairement une dépendance que nous aurions omis de prendre en compte dans notre analyse. Bord*l de Dieu, il faut être curieux ! <3

2 – General Tab, Name & EOL

L’onglet Général permettra d’attribuer un nom à notre modèle ainsi que la période de validité de notre modèle. Attention il en va de soi la durée de validité doit être inférieur strict à la durée de notre certificat d’autorité racine.

Logique mon père ne peux pas être plus âgé que mon grand père. Quoi que dans certaines régions…. Alalala, les préjugés ont la vie dure…

La notion de publication dans l’Active Directory dépendra clairement du type de modèle que nous souhaitons implémenter. Pour une application WEB non Windows et non jointe au domaine, pas besoin par exemple.

3 – Subject Name

Le nom du sujet, comprendre le client. Il convient de définir les informations lorsqu’une demande est réalisée. Je n’ai pas eu à ce moment eu le besoin de modifier la valeur par défaut. En d’autres termes, Joker ?

4 – Extension

Les extensions c’est plutôt un onglet intéressant. C’est dans cette partie que nous allons pouvoir définir les stratégies d’applications, les contraintes liées à notre modèle, les stratégies d’émissions et d’utilisation de la clé. Pour plus d’informations et bien choisir l’action ou non de telles ou telles options je renvoie à la page de caractéristiques des extensions standards x509.

Soit dans le cas de la stratégie de définir dans quel contexte le certificat va être utilisé. L’authentification Serveur ? Client ? Pour du RDP¹⁸ ? Une liste est déjà présente et nous pouvons ajouter au besoin de nouvelle stratégies d’application avec des codes définit par Microsoft (ce qui sera le cas plus bas avec la sécurisation de RDP).

Les contraintes sont là pour définir les usages qui doivent être fait des clés. Pour se faire, comme dit précédemment il faut se rapprocher de la documentation sur les certificats x509. Dans le cas des contraintes, nous pouvons refuser que la clé publique valide les empreintes par exemple.

5 – Security

L’onglet que l’on retrouve sans grande surprise dans beaucoup de menu de configuration. Il est important de définir les droits et les permissions avec réflexion. Les options les plus critiques restent naturellement l’écriture et le control total. Attention également aux permissions d’inscription et d’inscription automatique.

6 – Publish a template

Une fois le modèle de certificat dupliquer, il sera nécessaire d’activer ce dernier afin de l’utiliser.

Par sécurité, il est recommandé une fois le ou les certificats générés de désactiver, désinscrire les modèles de certificats du gestionnaire de certificat. Ainsi, il sera difficile pour un assaillant de générer un certificat depuis un modèle.

Exemple d’implémentation

Il existe une multitude d’implémentation. Je ne traiterai ici que deux exemples, l’un hors domaine et sur un SE non Windows et l’autre dans un environnement windows.

Toutefois, je pense pour ne pas faire un article à rallonge aborder l’implémentation des certificats dans les articles dédiés.

De plus, il y a plusieurs moyens d’effectuer une demande d’inscription de certificat.

• Fournit par l’appliance ou application
• Via IIS
• Via le gestionnaire de certificat

Dans l’ensemble des cas, nous partirons toujours d’un fichier CSR¹⁹ (ou REQ²⁰ je ne suis pas obtus) afin de générer notre CRT²¹.

VMWare : VCSA

1 – Génération du fichier CSR

Sur notre appliance VCSA²², à partir du menu il faut se rendre dans le menu d’administration partie Certificat. Pour le reste, il suffira de suivre les captures ci-dessous pour générer notre CSR.

Renseigner les informations d’authentification, puis valider.

2 – Inscription et génération du fichier CRT

Sur notre serveur ADCS, il est nécessaire d’exécuter la commande suivante :

> certreq.exe -submit -attrib "CertificateTemplate:WebServer" "‪C:\monFichier.csr"

L’inscription en GUI à travers les RSATs ne semble pas fonctionner chez moi sans retourner au préalable une erreur relatif au modèle. Un collègue m’a donné cette astuce. Je trouve d’ailleurs logique au vu de ma radinerie d’utiliser une commande powershell sur mon serveur CORE !

Commande Powershell tu es certain de toi ? Tu paries combien ?

Effectivement il s’agit bien là d’une commande cmd. Et ayant poussé le vice plus loin, cette commande ne fonctionnera pas si vous êtes :

• Authentifié sur le serveur avec un compte local
• Via une session PowerShell distante à travers WAC²³
• Via une session PowerShell distante

Une petite interface graphique est appelé vous demandant de sélectionner une autorité de certification… Seule solution, réaliser l’opération directement en powershell à travers la console VMWare.

3 – Autorité de certification racine de confiance CER

Depuis un poste du domaine, nous exportons notre certificat d’autorité racine CER au format base 64.

Naturellement, on laisse pas trainer ça n’importe où hein et nous supprimerons ce dernier une fois l’opération terminée.

Pourquoi ? Avez vous déjà essayé de laisser un billet de 50 balles sur un banc public ? Voilà vous avez votre réponse 🙂

4 – Import du certificat et reboot des services

De retour dans notre VCSA, Administration > Certificates > Certificate Management. Choisir pour le Certificat Machine SSL²⁴ l’import et le remplacement du certificat.

Ayant préalablement réalisé une demande CSR, la clé privé est donc connu de notre appliance.

Nous importons notre fichier CRT généré par notre serveur de certificat dans le champ Machine SSL Certificate et dans le champ Chain of Trusted root certificates notre certificat d’autorité racine.

Plus qu’à cliquer sur Replace.

Si toutes les actions se passe bien, vous êtes expulsés mani millitari de l’interface VCSA. Normal puisque le processus de mise à jour des services vient de s’enclencher pour appliquer le nouveau certificat. Vous pouvez aller prendre un café, voire deux.

Pour les curieux, vous ne pourriez plus non plus accéder à la plateforme de VMCA²⁵. Pas de panique c’est normal. Il gambade dans le couloir, il va revenir rapidement. Patiente est mère de vertu.

En conclusion, nous arriverons au résultat suivant.

L’absence de l’encarts rouge sur le protocole HTTPS n’est plus présent. Après contrôle du certificat ce dernier est bien valide. Ce qui nous amène donc à nous dire que si nous accédons à cette ressource un jour et que l’encarts rouge reviens nous sommes dans le scénario :

• Mon certificat a expiré je suis un boulet
• Charlie tente de nous piéger avec un site qui ressemble mais n’est pas notre site. Qui s’appelrio phising

Dans le cas de la VCSA, bien penser aux dépendances tierces. Changement de certificat implique de facto de renouveler les empreintes et poignée de main.

Donc qu’est ce qu’on fait ?

Par exemple, on se connecte sur notre serveur VEEAM (et oui encore et toujours… Vous aurez compris mon amour inconditionnel pour cet éditeur et solution <3 ) et on réalise de nouveau un paramétrage pour prendre en compte le nouveau certificat ? Très bien. Tu gagnes une tagada #PASCALDUB.

Windows : RDP

L’un des usages les plus fréquents sur un SI pour les SysAdmins, l’usage du protocole RDP pour se connecter d’un server, ordinateur à un autre. Mais alors, il est fréquent de se retrouver en permanence avec le même avertissement nous informant que la connexion n’est pas sécurisé du fait de l’utilisation du certificat auto-signé.

Il est donc temps de remédier à ça. 🙂

1 – Modèle

Direction, la création d’un nouveau modèle en dupliquant le modèle Ordinateur. Je n’invente rien, je ne fais que suivre le guide MS. Je ne fais pas le choix de publier le certificat dans l’AD. La raison est qu’en activant cette case, cela va avoir pour conséquence de stocker les certificats dans l’AD afin de faciliter la gestion, l’inscription et la consultation des certificats. Ce qui me semble un peu risqué… Mon POV comme disent les jeunes de nos jours.

Pour la durée (je ne parle pas des macarons, et pourtant je vous confirme qu’ils sont bons), 2 ans me semblent pas mal. D’ici là, j’ai le temps de perdre mon LAB à la maison (si ma conjointe qui n’est pas encore mon épouse ne l’a pas accidentellement accompagnée vers le paradis des machines. C’est qu’il prend dans la buanderie le bougre).

Dans l’onglet Extensions, nous devons ajouter une nouvelle stratégie d’application. Pour une raison étrange l’application RDP n’est pas présente dans la liste des applications par défaut. Nous supprimerons l’authentification du client et du serveur.

Ce qui nous donne une fois configurée, le résultat ci-dessous. Les permissions sont importantes. J’ai choisi de limiter les droits d’inscriptions uniquement aux ordinateurs nécessaires. D’où la présence du groupe local de sécurité GLS_CERT_RDP.

Si le groupe n’est pas présent, pas de panique. Un petit switch dans la console AD users & computers et le tour est joué. La nomenclature m’est propre à vous de faire parler votre créativité.

Validez la création du modèle et activer ce dernier.

2 – GPO

Bien maintenant il faut bien déployer notre certificat. Du moins plutôt dire quel certificat doit être utilisé par notre service de bureau à distance.

Soit le gestionnaire de stratégie de groupe 🙂

Toutefois, il subsiste un petite subtilitée lors de l’ajout du nom du modèle de certificat. Comme l’indique le guide, nous pouvons préciser :

• Le nom du modèle
• Le nom de l’objet identificateur (ce que nous avons ajouté précédemment dans la stratégie d’application)

Selon Microsoft, l’usage du nom du modèle inscrira avec succès le service de configuration de bureau à distance (SessionEnv) mais en contrepartie, à chaque application de la stratégie une nouvelle inscription aura lieu. De facto cela peut engendrer une sursollicitions de l’autorité de certification.

Je cours le risque car mon SI est petit et même si mon ADCS ou mes ADDS ont des ressources plus que limités (c’est voulu, c’est du core) cela reste un banc de test. Mais attention toutefois. Je pense que c’est bon à savoir.

Je vous résume la stratégie ordinateur.

J’ai été choqué. Pas vous ? Regardez bien…

Pour une raison que m’échappe en parcourant les paramètres, nous pouvons spécifier une couche de sécurité spécifique pour les connexions par distante. En lisant la description nous avons le choix entre deux méthodes :

• SSL
• RDP

Le chiffrement RDP étant déconseillé, il est recommandé de forcer le type de chiffrement sur SSL. Sauf que cela ne prend en compte que TLS²⁶ 1.0… Voilà voilà… Un petit TLS 1.2 aurait été bien mais non. Espérons que cela va évoluer.

En bonus, j’aime a activer la saisie du mot de passe à chaque session en plus du mot de passe saisie dans le client RDP.

Une fois la GPO terminée, je lis cette dernière à un bon niveau de mon OU et ne l’applique que sur mon GLS_CERT_RDP. L’objectif étant à l’avenir de pouvoir jouer sur la flexibilité et ajouter des membres si besoin à mon groupe. Pour appliquer la GPO, cette dernière étant ordinateur elle s’appliquera au bout de 15 minutes. Sinon un petit gpupdate /force des familles et le tour est joué.

3 – Tests et Vérification

Vérifions que cela fonctionne bien. J’ouvre depuis mon réseau domestique une session RDP sur ma bulle d’administration/management (Ne vous inquiétez pas, il y a bien une règle de parfeu en Inbound).

Une petite consultation dans notre console d’autorité de certification dans les certificats délivrées et…. Oh surprise, nous retrouvons nos objets ordinateurs #COEURAVECLESMAINS.

Force et de constater que cela fonctionne. <3 Que d’amour dans cette partie 🙂 Je dirai que c’est le plaisir du devoir accomplie.

En inspectant le certificat présenté depuis mon poste domestique, nous retrouvons bien les informations d’inscriptions ainsi que le tampon de notre autorité de certification racine.

Mais alors pourquoi cet avertissement ?

Simplement que mon poste, lui ne connait en aucun cas l’autorité de certification de confiance ronelab.lan. Normal car il n’est pas dans le domaine. Donc mon poste considéré ce dernier comme non légitime puisqu’il ne peut vérifier l’authenticité de ce dernier.

Bien… Cela aurait peut-être mérité un article dédié. M’enfin ça me plait comme ça.

Conclusion

Et voilà le terminus, tel Jesus je claque ma portière en descendant de ma croix. Encore un pari non tenu quant à la longueur excessif de ce billet…

Il reste difficile de parler de sécurité sans savoir comment cela fonctionne (et encore je ne suis pas rentré dans les détails des algorithmes de chiffrement). Je pense qu’il est important et nécessaire déployer le rôle d’infrastructure ADCS sur les systèmes d’informations pour jouir et bénéficier des avantages des services qu’il propose.

Naturellement, cela permet de sécuriser les services et de garantir l’authenticité de l’accès de l’information sur des ressources le plus souvent visibles comme des sites web internes ou applications, mais également indirect (comprendre non visible) comme des protocoles et services LDAPS, WinRM over SSL, SMB over Quick, RDP etc.

Malheureusement, ce rôle est sous-estimé par les AdminSys qui voit en ce dernier plus une source de problème à venir et des difficultés de gestion que de la première pierre qui sert de socle à la sécurité du système d’information.

Voyons plutôt les avantages et inconvénients.

Le jour où ça déconne, le SysAdmin peut vite se sentir seul et démuni avec comme arme uniquement sa b**e et son couteau…

Pas de serveur ADCS, pas de serveur Radius. Pas de serveur Radius, pas de sécurité. Pas de sécurité, Pas de serveur ADCS. Pas de serveur ADCS…

J’ai donc été confronté à cette problématique qui m’a pour le coup empêché de publier plusieurs articles considérés comme inachevé. Il est certain que plus nous avançons dans le temps plus ce qui était considéré comme « optionnel » en termes de sécurité devienne un standard.

J’ai également en toute honnêteté rencontré un point de blocage qui a nécessité une aide extérieure quant à l’implémentation. La théorie c’est bien, mettre en pratique cette dernière est parfois plus délicat. Je remercie donc ce collègue amateur d’andouillette 5A pour le quart d’heure de pratique concernant VMWare. D’ailleurs est il incompatible de parler IT autour d’une table de brasserie ou semi-gastro ? L’idée est à débattre, je pense qu’il y a quelque chose à faire.

Vous l’aurez compris, il ne faut pas avoir peur de ADCS et de PKI. Il est impératif de sécuriser un maximum les services et ce rôle. Sans eux, et je crois en avoir dit assez long tout au long de ce papier je vais pouvoir étudier et présenter d’autres technologies.

Le mot de la fin ?

Je chiffre les paroles d’une chanson et paume ma clé privée, qui suis je ? George Alain bien sûr. Mais c’est pas un SHAOne ? Non un SHA d’IRAN. Okay cool, merci R-One.

Erwan GUILLEMARD

Sources

• RFC
• X509 : Extension
• Windows : ADCS Guide
• Windows : CVE PetitPotam
• Windows : ADCS Configuration CA
• Windows : RDP Certificat Settings

1. PKI : Public Key Infrastructure ↩︎
2. SI : Système d’Information ↩︎
3. IA : Intelligence Artificielle ↩︎
4. ADCS : Active Directory Certificate Services ↩︎
5. ADDS : Active Directory Domain Services ↩︎
6. PME : Petites et Moyennes Entreprises ↩︎
7. IIS : Internet Information Services ↩︎
8. KB : Knownledge Base ↩︎
9. GUI : Graphic User Interface ↩︎
10. CA : Certification Authority ↩︎
11. AD : Active Directory ↩︎
12. CVE : Common Vulnerabilities and Exposures ↩︎
13. SHA512 : Secure Hash Algorithms ↩︎
14. OS : Operating System ↩︎
15. RSAT : Remote Server Administration Tools ↩︎
16. MMC : Microsoft Management Console ↩︎
17. ADSI : Active Directory Service Interfaces ↩︎
18. RDP : Remote Desktop Protocol ↩︎
19. CSR : Certificate Signing Request ↩︎
20. REQ : Request ↩︎
21. CRT : Certificate ↩︎
22. VCSA : vCenter Server Appliance ↩︎
23. WAC : Windows Administration Center ↩︎
24. SSL : Secure Sockets Layer ↩︎
25. VMCA : vCenter Management Appliance ↩︎
26. TLS : Transport Layer Security ↩︎

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