Robot : nom masculin, du tchèque robota, travail forcé, mot créé en 1920 par K. Capek.

Dans les œuvres de science-fiction, machine à l’aspect humain, capable de se mouvoir, d’exécuter des opérations, de parler.

Appareil automatique capable de manipuler des objets ou d’exécuter des opérations selon un programme fixe, modifiable ou adaptable.

Définition Larousse

Au vu du titre de cet article et de la définition posée précédemment, difficile de ne pas deviner le sujet qui va être abordé.

Hé oui, moi le puriste, je vais parler d’IA¹ et pire que cela l’utiliser de manière récurrente. Je me sens en ce moment comme le capitaine Haddock face au lama dans l’œuvre d’Hergé, Tintin et le temple du soleil.

Naturellement, au vu de mes précédents écrits, c’est vous lecteurs et l’ensemble des solutions IA qui me crachent dessus. C’est l’arroseur arrosé en somme, moi qui ne voulais pas entendre parler de ça…

Mais alors pourquoi un tel revirement de situation M’sieur GUILLEMARD ?

Je pense qu’il faut vivre avec son temps et ignorer cet outil technologique serait signer mon arrêt de mon mort d’ici quelques années et devenir un être never been à défaut d’has been…

Après tout Errare humanum est, perseverare diabolicum² non ?

Avant-Propos

J’ai pris le parti d’être méfiant vis à vis des outils d’IA en ligne gratuit ou du moins libre d’utilisation.

• ChatGPT
• Gemini
• Copilot
• Claude
• …

Je ne me mouille pas trop dans les moteurs d’IA…

Dire que je n’ai jamais utilisé l’un de ces moteurs serait me parjurer et il faut reconnaitre qu’il y a un côté pratique. Difficile une fois avoir gouter à la simplicité pour ne pas l’utiliser à tout va pour tout et rien. C’est là pour moi le piège de la pauvreté intellectuelle. Comme toutes les bonnes choses il faut savoir ne pas en abuser.

En dehors de l’aspect social et sociétal qui me préoccupe tant, se pose la question des données saisies dans le moteur de recherche ou plutôt de prompt.

• Que deviennent les données saisies ?
• Que deviennent les données retournées ?
• Combien de temps sont conservés ces données ?
• A qui profitent ces données ?
• Qui sur surveillent les données ?

Cela fait un bon nombre de question non ? Surtout qu’un grand nombre des acteurs de l’IA sont aux US, Chine etc avec une législation bien singulière. Qui de nos jours lis encore les CGUs³ (et qui les a déjà lus) ?

C’est ainsi que grâce à mon directeur j’ai découvert la solution OLLAMA. Solution open-source qui exécute des modèles d’intelligence artificielle (aussi appelé LLM⁴) localement. Tout de suite, le projet m’a séduit et je me suis demandé

Et pourquoi pas ?

Dans le pire des cas, je mourrai moins c*n ce soir comme dirait un philosophe du cercle familial.

Naturellement, j’ai choisi d’user de OLLAMA sur ma distribution favorite RockyLinux. L’environnement a été préalablement durci.

On se lance dans la théorie puis dans la pratique mes petits Lamas ?

Prérequis

• SE :
  • Rocky Linux 9.x et version ultérieures (pour ma part ça sera du 10.x)
  • macOS
  • Windows
• Apps : 
  • Ollama
• Autres :
  • GPU⁵
  • Minimum 4 CPU⁶
  • Stockage rapide (SSD⁷ ou Nvme)

Théorie

Je vais essayer d’être le moins rassoir possible. Toutefois et encore il est nécessaire d’où nous partons pour en être là maintenant avec l’IA.

Un peu d’histoire

La notion d’intelligence artificielle vient de loin dans notre histoire, puisque l’homme depuis l’antiquité rêve d’objets animés intelligents qui pourraient répondre à ces besoins.

Ce qui est fascinant ce trouve dans les différentes cultures à travers les âges. Que ce soit :

• Les automates d’Héphaïstos dans la mythologie grecque
• La tentation de créé l’Homme servi par l’alchimie aux moyen âge comme la science Talkim du grand savant islamique Jabir ibn Hayyan (Geber en latin), des homoculus par le médecin suisse de conviction chrétienne Paracelse qui s’inspirera des travaux de Zosime de Panopolis sans oublier l’un des plus connue de tous ces automates, le Golem d’argile présent dans le Talmud du judaïsme, créé par le rabbin Maharal pour protéger la communauté juive de Prague face aux multiples pogroms (j’ai d’ailleurs eu la possibilité de visiter le cimetière juif de Prague et de comprendre tout cela).
• Plus tard, nous retrouverons des œuvres telles que
  • Les Aventures de Pinocchio de Carlo Collodi avant d’être adapté en dessin animé par Disney
  • Frankenstein de Mary Shelley
  • Ou encore Deep Blue qui viendra à bout de Garry Kasparov aux échecs.

Bref, tout cela pour dire que depuis l’origine de l’humanité, nous Homme recherchons à créer des objets autonomes et intelligents à notre services. Pour de multiples raisons, défensives, assistanat etc. Le plus troublant, cette pensée de création pourtant contre religieuse et présente dans toutes les cultures et religions portées par ces savants et lettrés (et ça, voyez-vous je trouve ça beau, très beau).

Enfin, il faudra attendre le XXème siècle et l’arrivée des premiers ordinateur programmable pour que l’IA se développe pleinement.

C’est le pionnier et j’oserai dire le père de l’IA John McCarthy qui ouvre la voie, notamment par cette citation :

C’est la science et l’ingénierie de la fabrication de machines intelligentes, en particulier de programmes informatiques intelligents. Elle est liée à la tâche similaire qui consiste à utiliser des ordinateurs pour comprendre l’intelligence humaine, mais l’IA ne doit pas se limiter aux méthodes qui sont biologiquement observables.

John McCarthy – Wikipédia

Le sujet étant réellement complexe, il est difficile de concrétiser et de répondre aux attentes des investissements privés et étatiques durant la période 70 à 80. Ce qui vaudra un ralentissement dans la rechercher et la montée en puissance de l’IA que nous connaissons ce jour en 2026. Et pourtant les théories et grands principes mathématiques et logiques sont établis et adopté par la DARPA⁸. C’est ainsi que s’affronte deux grands systèmes :

Le système logiciste VS Le système neuronale

C’est en 2010, que l’IA fait réellement son entrée dans nos vies du quotidien et dans les différents secteurs d’activités.

Pour entrer davantage dans le détail je vous invite à lire la page wikipédia (cf les sources). J’ai promis de faire court. 🙂

Les modèles d’IA

Les modèles d’IA, c’est un peu comme un oignon, il y plusieurs couches.

Déjà il est important de dissocier le Machine Learning du Deep Learning.

Machine Learning

Le process pourrait se décrire de la manière suivante :

• Phase 1 : Identifier les mots clés fournit en entrée les plus pertinents afin de préparer ces derniers à être analysé. Nous parlons généralement de datasets.
• Phase 2 : Choisir le bon modèle ou algorithme qui sera le plus pertinent à être utilisé selon l’identification des datasets identifiés et analysés.
• Phase 3 : Construire le modèle d’analyse basé sur l’algorithme choisie lors de l’étape précédente.
• Phase 4 : Jouer le modèle sur un ensemble de jeux de données afin d’obtenir plusieurs jeux de données.
• Phase 5 : Utiliser le modèle pour attribuer une note à l’ensemble des jeux de données retournés et fournier des patterns pertinents adaptés aux datasets initiaux.

Deep Learning

Le process pourrait se décrire de la manière suivante :

• Phase 1 : Comprendre le contexte présenté par l’utilisateur et décider ou non si le Deep Learning est nécessaire ou non.
• Phase 2 : Identifier les mots clés fournit en entrée les plus pertinents afin de préparer ces derniers à être analysé. Nous parlons généralement de datasets.
• Phase 3 : Choisir le bon modèle ou algorithme qui sera le plus pertinent à être utilisé selon l’identification des datasets identifiés et analysés.
• Phase 4 : Jouer le modèle sur un ensemble de jeux de données afin d’obtenir plusieurs jeux de données.
• Phase 5 : Compare le modèle ainsi que ces performances face aux données existantes identifiés ou non identifiées avec notre contexte initial.

Pour le comprendre au mieux, il convient de reprendre le Diagramm de Venn pour comprendre comment s’imbriquent ces différentes notions d’apprentissage.

IA : a pour objectif de comprendre le langage humain, de réaliser les analyses prédictives offrir une IHM9 et AGI10. Machine Learning : se compose de l’apprentissage automatique, la clustérisassions, les arbres décisionnels, le SVM11, LLM et NLP12. Réseaux Neuronales : comprend les RAG13 / Finetuning ainsi que les Feed Forward. Deep Learning

Bien que rapide dans la présentation, de ce qu’est l’IA, je pense que nous avons suffisamment d’éléments pour aborder les différents types d’IA.

Toutefois, je suis loin d’être spécialiste de l’IA et mes connaissances théoriques remontent de mes cours de 2014 et de ce que j’ai pu lire et apprendre depuis ces dernières semaines. Je vous invite donc à lire plus en détails son fonctionnement en profondeur.

Bon allez ça sera tout pour l’instant. Regardons de plus prêt Ollama. 🙂

Architecture et Best-Pratices

Ollama étant cross plateform, j’ai pris le parti de déployer ce dernier sous RHEL. Donc le guide va suivre dans ce sens. Ce choix est motivé par mes soins pour garder une meilleure maitrise des ressources qui vont être consommées par le système. Pour MacOS, je ne me prononce pas car je n’utilise pas ce dernier. Sous Windows, je voyais déjà mon petite dernier faire du rodéo sur l’hyperviseur qui gambade dans le couloir au premier prompt soumis… 🙂

Comme énoncé ci-haut, il faut au minimum en ressource : * 4 vCPUs * 16 Gio de RAM * 2 Gio de GPU * Stockage Rapide Malheureusement pour moi, je n’ai pas les ressources nécessaires, mais cela ne m’empêchera pas d’aller au bout des choses. Je propose toutefois de dissocier les modèles et une partie de l’architecture OLLAMA sur un disque dédié pour des raisons de performances lors de la soumissions des prompts et ne pas saturer le disque système. L’accès à l’application se fera par des call API14 sur le port 11434/tcp.

Si nous voulions aller plus loin il serait bien de dédié un disque pour les logs et ainsi améliorer les performances.

Niveau sécurité, je suis resté sur mon durcissement classique et divulgâchage alerte ça fonctionne (Jacques TOUBON, le retour aurait été fier de moi pour ce coup-là !).

Je ne vois plus qu’un dernier point à aborder et nous pouvons passer à la pratique. Oui comme toute bonne chose, il faut faire durer le plaisir. #sendkisses

Conséquences de l’IA

L’IA est à ce jour (2025) adopté par environ 2/3 de la population mondiale que ce soit à des fins professionnels ou personnels dont environ 73% dans le contexte pro. Ainsi, difficile de nier que l’usage particulier et bien au-dessus des institutions organisationnelles.

Comme énoncé bien plus tôt dans cette partie, l’usage est principalement à destination des centres de services et à destination des utilisateurs (chatbots, service clients) 60%, l’automatisation des ventes et marketings 13%, l’optimisation des systèmes IT 9%, l’aide à la décision entre 5 et 10% et la production de contenu entre 5 et 10% également. Bien que mes chiffres date de 2023-2024.

Dans son usage concrets, l’IA est utilisée à 46% pour la recherche d’informations, 43% pour la rédaction de textes et 33% pour de l’analyse ou traduction.

Les estimations à venir d’ici 2030 seraient un usage de l’IA par 80 à 85% de la population mondiale. Cette escalade et course n’est pas sans conséquence sur le plan économique et disponibilité des ressources en termes de composants électroniques.

Qui dit plus d’usage, dit plus de ressource de calcul et donc plus de composants et plus d’énergie. Le système peine à suivre. C’est ainsi qu’en moyenne, l’évolution des couts entre 2024 et 2026 (estimé sur le plan mondial) et de :

• RAM (DDR5) : +170 à +250 %
• SSD : +60 à +100 %
• GPU : +10 à 25 %
• CPU : +0% à +10%

Cela entraine donc une hausse des offres Cloud et service SaaS/IaaS/PaaS/BaaS et j’en passe ainsi que des couts équipements embarquant ce type de composants. Difficile de faire sans IA de nos jours.

Bon c’est promis, passe à la pratique, je ferme la parenthèse que je n’ai jamais ouverte.

Pratique

Avant de se lancer dans l’installation, si je reprends les prérequis énoncés ci-haut, sachez que :

• Je n’ai pas de GPU
• Je n’ai pas de stockage rapide
• Mon hypervisieur est monoprocesseur

Tout pour bien fonctionner en somme 🙂

Installation

L’installation va se dérouler en 2 parties. Une partie pour installer Ollama, une partie pour l’installation des modèles d’intelligence artificielle.

Ollama

Installation

La documentation fournit sur le site est simple et claire. Il suffit alors de télécharger et d’exécuter le contenu du script install.sh.

Vérifier en amont que le paquet zstd est installé sur notre environnement.

$ sudo dnf install zstd

Si nous rentrons plus en détail, les arguments :

• -f : ignore les redirections en cas de retour autre que le code 200 du protocole HTTP¹⁵
• -s : supprime la barre de suppression et rend l’exécution de la commande silencieuse
• -S : indique les erreurs
• -L : permet de suivre les redirections HTTP

$ sudo curl -fsSL https://ollama.com/install.sh | sh

L’installation c’est bien passée. Toutefois, le script nous informe qu’aucun équipement GPU n’a été détecter et donc que les calculs seront effectués par notre CPU. Ce qui va donc être plutôt lent dans mon cas personnel.

Service au démarrage

Nous retrouvons une commande maintenant bien connue dans les environnements RHEL. Ainsi à chaque démarrage de notre système notre daemon ollama va être démarré.

$ sudo systemctl enable ollama

Firewalling

Encore une fois et comme toujours, il est nécessaire d’ouvrir le port 11434/tcp si nous souhaitons joindre l’API depuis l’extérieur (comprendre hors localhost).

$ sudo firewall-cmd --permanent --add-port=11434/tcp
$ sudo firewall-cmd --reload

On est d’accord que si nous souhaiterions mieux faire en termes de sécurité, il serait plus intelligent de créer la policy suivante :

$ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.127.50.0/24" port port="11434" protocol="tcp" accept'
$ sudo firewall-cmd --reload

Ayant un UTM¹⁶ en amont, je me permets donc de me contenter de la première solution.

HTTP ou HTTPS ?

Un doute m’habite… Le port 11434/tcp, ça ne serait pas du http ?

Bien vu l’aveugle ! Effectivement et niveau sécurité c’est pas super, il faudrait mieux user du protocole https. Pour ça, j’ai une solution passons par un reverse proxy 🙂

Je suis partagé quant à la rédaction de cette sous partie. Oui il est important de sécuriser l’accès à l’interface Web, mais j’ai peur d’être hors sujet et d’alourdir l’article. Mais d’un autre côté, je ne veux pas non plus bâcler la chose… Encore un pu**n de choix cornélien…

Bref, je vais faire au plus simple et si besoin écrirai un billet sur Nginx.

Installation

L’installation et activation du service, je passe mon tour.

$ sudo dnf install nginx
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

Certificats

Là encore une fois je rencontre un petit problème. Je n’ai pas de certificat public que je pourrais utiliser, ma topologie réseau ne me permet pas d’utiliser un certificat Let’s Encrypt et sans vouloir spoiler je n’ai pas envie de me prendre la tête. Donc ça va finir avec un bon vieux certificat autosigné 🙂

La génération n’est pas bien compliquée et si besoin, j’ai déjà rédigé un article sur le sujet.

Créons le répertoire qui va contenir nos éléments de sécurité :

$ sudo mkdir -p /etc/nginx/ssl

Générons notre certificat :

$ sudo openssl req req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/nginx/ssl/ollama.key \
-out /etc/nginx/ssl/ollama.crt

Configuration

Créons et éditons notre fichier de configuration. Je prendrai le temps d’expliquer l’intégralité du fichier de configuration.

$ sudo vim /etc/nginx/conf.d/ollama.conf

#server {
#    listen 80;
#    server_name 10.227.250.11;
#
#    return 301 https://$host$request_uri;
#}

server {
    listen 11444 ssl;
    http2 on;
    server_name 10.227.250.11;

    ssl_certificate /etc/nginx/ssl/ollama.crt;
    ssl_certificate_key /etc/nginx/ssl/ollama.key;

    # TLS sécurisé
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;

    # sécurité headers
    add_header X-Frame-Options SAMEORIGIN;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    # taille upload
    client_max_body_size 100M;

    # compression
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

    location / {

        proxy_pass http://10.227.250.11:11434;

        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_buffering off;

        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

La première section permet de réaliser la redirection du protocole HTTP vers HTTPS de manière permanente. Ainsi si je contacte l’url http://10.227.250.11, je serais automatiquement redirigé vers https://10.227.254.11. Toutefois, la section est commentée car elle entre en conflit avec une autre configuration d’un billet à venir 😉
Le second bloc indique que nous écoutons sur le port 11444 sur l’interface 10.227.250.11. L’emplacement des fichiers contenant la clé privée ainsi que le certificat sont spécifiés pour activer la couche de sécurité (j’ai l’impression d’enfoncer des portes ouvertes…). J’indique qu’elles sont les versions des protocoles TLS17 autorisées et laisse le serveur choisir le chiffrement le plus sûr. Côté en-tête, j’ai repris les suggestions de sécurité implémentée pour ITOP. Soit la restriction de mettre le site en iframe externe, de restreindre le navigateur à deviner le tye MIME qui est utilisé et surtout d’activer la protection anti-cross-site scripting. Niveau upload, j’ai vu large et j’ai autorisé le téléversement de fichier de 100 Mio. Côté performance, j’ai activé la compression des flux pour optimiser un peu les performances réseaux.
Le troisième bloc concerne la partie Reverse Proxy. Toutes les requêtes qui sont envoyées sur https://10.227.250.11 sont redirigées vers le port 11434. Concernant les en-têtes il est nécessaire d’utiliser les websockets car seront transmis l’ip du client, le protocole utilisé et le NDD18 ou l’IP demandé.

Une fois la configuration faite, il est important de réaliser un petit contrôle de notre petit fichier afin de s’assurer que ce dernier ne comporte pas d’erreur.

$ sudo nginx -t 
$ sudo systemctl restart nginx

Tiens une erreur 🙂 Regardons ça dans la partie suivante…

Sécurité

Nous souhaitons toujours publier notre interface web en HTTPS. Donc il va falloir jouer avec nos UTMs !

Sur le plan interne, autorisons nos flux https :

$ sudo firewall-cmd --permanent --add-port=11444/tcp
$ sudo firewall-cmd --reload

Toutefois lors de la relance du service on se tape une bonne grosse erreur. C’est lié au SELinux. Nginx n’est pas autorisé par le SELinux a écouter sur le port 11444. Donc il faut l’autoriser.

#Install semanage
$ sudo dnf install policycoreutils-python-utils

#Ajout du port comme autorisé à l'écoute
$ sudo semanage port -a -t http_port_t -p tcp 11444

#Relance du service nginx
$ sudo systemctl restart nginx

Normalement nous ne devons plus avoir d’erreur. Toutefois si nous essayons de joindre l’url https://egapl-ollama-01:11444 nous devons avoir un jolie 502 Bad Gateway dans notre navigateur 😀

Ca vous fait la b**e hein ? Je vous rassure je me suis pris la même rouste. J’ai oublié d’autoriser le contexte de mon SELinux pour autoriser les services http à accéder aux réseaux 😀

$ sudo setsebool -P httpd_can_network_connect 1

Un petit F5 et hop c’est tout bon <3

Normalement avec toutes nos actions, nous devons joindre notre interface web depuis un navigateur de manière sécurisée (hormis l’erreur liée à notre certificat autosigné).

Emplacement des modèles

Lors de ce benchmark, j’ai été confronté à un problème d’espace disque lié aux modèles. Effectivement, les modèles sont au minimum supérieur à 3 Gio. Et c’est là que c’est le drame car « pouf » je me tape un message d’erreur…

La solution est donc de déplacer le répertoire de modèle vers un autre disque. J’ai vu large, j’ai provisionné 100 Gio. Je pars du principe que le disque est monté et formaté.

$ sudo chown -R ollama:ollama /mnt/ollama

Le changement de l’emplacement du répertoire du modèle va se faire par surcharge du service qui démarre Ollama. Naturellement, on ne modifie pas le service de base car les changements ne seront pas persistants. D’où la surcharge…

$ sudo mkdir /etc/systemd/system/ollama.service.d
$ sudo vim /etc/systemd/system/ollama.service.d/override.conf

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_MODELS=/mnt/ollama/ollama-models"
Environment="OLLAMA_HOST=0.0.0.0"

Notons que le mode Debug est actif et que le chemin de nos modèles est défini. J’ai également défini la variable OLLAMA_HOST qui va nous permettre de joindre notre application depuis une source externe à notre machine.

Il convient alors de recharger, forcer le gestionnaire de services à recharger l’ensemble de ses configurations. Dans un second temps nous redémarrerons le daemon ollama afin de prendre en considération les changements présents dans notre fichier de surcharge. Par mesure de sécurité (car la confiance n’exclut pas le contrôle) j’aime à vérifier que le service est bien actif.

$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama
$ sudo systemctl status ollama
$ sudo ls -al /mnt/ollama/ollama-models/

Dans les sources, nous pouvons constater la présence de nos variables surcharger. Néanmoins nous pouvons afficher le contenu de notre répertoire cible pour les modèles afin de vérifier que l’arborescence est bien présente.

Installer des modèles

J’ai fait le parti car c’est « un peu » l’objectif de base de ce billet d’avoir des modèles locaux qui vont être utilisés. Je ne souhaite pas utiliser des connexions avec des sources externes afin de garder un contrôle sur mes recherches et usage.

J’ai fait le choix d’étudier 4 modèles LLM :

• Llama3
• Qwen
• Mistral
• DeepSeek-Coder

Je propose dans un premier temps de faire un comparatif de ces modèles.

Avec ce tableau, je pense que nous avons un bon récapitulatif. Toutefois et pour les curieux il existe une centaine de modèles compatible avec Ollama (Lien). J’ai fait mon choix, à vous de faire le vôtre. Vous êtes des grands garçons et des grandes filles hein ? #bisous

L’installation pour les modèles choisies, suivent tous la même logique. Pas de quoi épiloguer pendant 107 ans….

Llama3

$ sudo ollama pull llama3

Qwen

$ sudo ollama pull qwen

Mistral

$ sudo ollama pull mistral

DeepSeek-Coder

$ sudo ollama pull deepseek-coder:6.7b

Pour voir l’ensemble des modèles il est possible de lister ces derniers grâce à la commande suivante :

$ sudo ollama list

Démarrage de Ollama

Maintenant que tout est fonctionnel, démarrons Ollama et c’est parti pour un périple des possibles comme Heinrich Harrer à l’assaut du Nanga Parbat (l’élévation n’étant pas celle que l’on croit 🙂 ).

$ ollama

Dans le menu qui s’offre à nous, la première option permet de démarrer, lancer un de nos modèles localement. Toutefois, en dessous de cette première option de navigation, nous retrouvons la possibilité d’établir des connexions externes vers des moteurs en ligne tel que : * Claude Code * Codex * OpenClaw * Droid * Pi * Cline Si vous possédez un compte, vous pouvez réaliser la jonction, mais alors à quoi bon avoir un moteur d’IA interne ?

Si nous cliquons sur le premier choix, il nous est alors demandé de choisir un modèle. Il est possible de télécharger un modèle directement depuis ce menu ou de choisir un modèle précédemment installé tout en bas de cette interface.

Tests

Et si on se lançais un petit benchmark de nos 4 modèles pour voir le fonctionnement ? 🙂

Amusons-nous tel un lamastico <3

Pour le test, j’ai décidé de partir sur quelque chose de simple et ISO sinon cela ne sert strictement à rien.

La question sera :

Peux-tu évaluer et me proposer une version plus robuste de cette fonction powershell s’il te plait ? [Suivie d’une petite fonction maison qui peut être amélioré]

Llama

Qwen

J’ai du tronquer la partie de la réponse en anglais car cela aurait pris énormément d’espace. Toutefois la réponse retournée est plus que satisfaisante pour celui qui sait parler la langue de Shakespeare

Mistral

DeepSeek-Coder

Je pense que cela est évident en termes de conclusions. Pour 1 prompt identique, nous avons quartes réponses différentes et un point commun. Si certains modèles mettent plus de temps de réponse il est indéniablement contestable que ça chauffe niveau calcul. Dans certains cas, j’aime même du SWAP ! Bref, côté consommation électrique, ça consomme… Mais bon je m’y attendais ce n’est pas la première fois que je fais des étincelles avec ma b*te…

Plus sérieusement, je sais quitte à me répéter ou pas ce que je dois faire pour améliorer ma fonction. Et je suis un peu déçu du résultat. Néanmoins en modifiant légèrement le prompt, en précisant :

Peux-tu évaluer et me proposer une version plus robuste, sécurisé de cette fonction powershell s’il te plait comme si tu étais un développeur sénior avec un regard plus critique et sévère ? [Suivie d’une petite fonction maison qui peut être amélioré]

Résultat Prompt initial (qwen)	Résultat Prompt plus précis (qwen)

/!\ Attention : J’ai volontairement gardé que la suggestion de la fonction et non le blabla d’en-tête qui explique tout ce qui va être appliqué.

Encore une fois pas de magie, il suffit de bien rédiger son prompt et là j’obtiens un retour plus précis à mes attentes.

Si je résume la situation sur le test à iso périmètre selon le contexte :

• RAM : 8 Go
• vCPU : 4
• Processeur Physique : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz (Mono)
• Contexte : Coding

Durée des réponses	Qualité des réponses

En conclusion Qwen est de loin celui qui met le plus de temps à délivrer la réponse. Cela s’explique par une explication plus poussée ce qui prends un certain temps à l’affichage. Cependant la qualité de la réponse retournée est de loin supérieur aux trois autres LLMs.

Il serait intéressant de pousser la comparaison sur un prompt de réflexion pur.

De tous les tests de modèles (du moins sur les quatre déployés) c’est qwen qui me convient le mieux. Néanmoins tout dépendra encore une fois du contexte et de ce que je souhaite réaliser avec l’IA.

Conclusion

Je suis plutôt satisfait bien que sans répondre aux prérequis il faut savoir s’armer de patiente. Dans l’ensemble Ollama est une bonne solution mais cette dernière doit être utilisé avec un certain contrôle selon les LLMs que l’on pourrait être amené à utiliser. Naturellement le retour de prompt vient de la qualité de celui que l’utilisateur aura exprimé.

De ce fait, Ollama ne garantit pas une fiabilité aussi conséquente que les géants du Cloud. Toutefois il permet d’assurer la confidentialité, sécurité des données localement et de nos recherches contrairement aux outils en ligne.

Ce qui pourrait toutefois rebuter son usage serait de passer par l’interface CLI dans le terminal. Effectivement c’est loin d’être ergonomique pour un usage quotidien d’un utilisateur n’ayant pas d’expérience dans ce domaine. Mais il existe toutefois des alternatives à cette problématique par des outils intermédiaires qui viennent se placer entre l’utilisateur et Ollama. Ce sujet sera abordé dans un prochain billet.

Initialement, je souhaitais aborder le sujet dans ce billet mais cela aurait été trop indigeste. Donc j’ai CUT comme on dit dans notre milieu 🙂

Ollama fournissant une documentation riche et simple il sera alors possible de jouer avec son API. Vous me connaissez avec le temps, s’il y a une documentation, une API… Que vais-je bien pouvoir faire avec le framework .NET et Powershell ? 🙂 L’objectif serait de proposer par exemple un petit client de bureau Windows pour les utilisateurs. Il serait également possible de mettre en place des passerelles d’automatisation inter applicatives intelligente comme L’ouverture d’un incident sur un event VEEAMOne dans ITOP ou une fonction de contrôle de code depuis PowerShell ISE par exemple.

Cette étude m’ouvre un nombre de porte considérable en guise de projet et de sujet d’étude et ce malgré les contraintes matérielles. Est-ce que je vais utiliser longtemps la solution, je ne pense honnêtement pas car cette dernière est assez énergivore pour mon petit lab et je ne travaille pas chez EDF ni n’habite Versailles. Mais cela peut (pour ne pas dire m’a) réconcilié avec l’utilisation de l’IA. Comme quoi il n’y a que les cons qui ne changent pas d’avis et nous sommes tous le con d’un autre.

Le mot de la fin :

J’ai cherché votre nom sur Ollama ? Comme ça vous êtes triple champion du monde de descente de Guiness catégorie galopin ?

Vous devez faire erreur avec une autre personne, je suis un DC10 fantôme sortant d’une tempête codéinée.

Milles excuses M’sieur Ollama.

Erwan GUILLEMARD

Sources

• Définition Larousse
• Wikipédia : IA
• DataBird : Type d’IA
• Ollama : Documentation
• Ollama : Téléchargement
• Ollama : Bibliothèque de modèle
• OpenWebUI : Documentation
• OpenWebUI : Intégration Ollama
• Comparatif : Modèles performances
• Comparatif : Modèles usages
• Usage de l’IA : DAFMag
• Répartition de l’usage : BPIFrance
• Usage de l’IA : LeMonde

1. IA : Intelligence Artificielle ↩︎
2. L’erreur est humaine, persévérer diabolique ↩︎
3. CGU : Conditions Générales d’Utilisations ↩︎
4. LLM : Large Language Models ↩︎
5. GPU : Graphics Processing Unit ↩︎
6. CPU : Central Processing Unit ↩︎
7. SSD : Solid State Drive ↩︎
8. DARPA : Defense Advanced Research Projects Agency ↩︎
9. IHM : Interface Homme Machine ↩︎
10. AGI : Artificial General Intelligence ↩︎
11. SVM : Support Vector Machine ↩︎
12. NLP : Natural Language Processing ↩︎
13. RAG : Retrieval Augmented Generation ↩︎
14. API : Application Programming Interface ↩︎
15. HTTP : Hypertext Transfer Protocol ↩︎
16. UTM : Unified Threat Management ↩︎

Je rassure le lecteur qui s’est égaré ici, ce billet va être simple.

Bref, j’ai la problématique suivante, lorsque je déploie une nouvelle machine Linux (RHEL¹ ou Debian) je suis le guide d’hygiène et sécurité de l’ANSSI². Ce qui se traduit par le partitionnement strict des points de montage système et de données. Sauf que lorsque la taille de notre disque varie, difficile de définir de tête quelle volumétrie doit être provisionnée pour chaque partition…

C’est donc là que j’ai pris un coup de sang.

En voiture Simone, c’est parti !

Avant-Propos

Je ne vais pas rentrer dans le détail du code qui compose mon application, ce n’est pas l’objectif. Si l’on souhaite comprendre ce dernier, un peu de réverse engineering et le tour est joué (surtout que j’ai commenté le code).

Je n’aborderai pas non plus la partie de durcissement des systèmes GNU Linux. Pourquoi ?

1. Ce n’est pas le sujet de ce billet
2. Je traite le sujet dans un de mes premiers articles que je ne partage que sur contact et échange
3. Je pars du principe que cela sera fait après déploiement du SE³.

L’objectif est vraiment de comprendre ou du moins rappeler la structure d’un système GNU quant à son arborescence d’organisation de fichier. Et donc outre à mesure à comprendre pourquoi nous devons allouer plus ou moins d’espace de stockage.

Concernant l’application que j’ai développé, bien que je revienne sur ce point plus bas dans ce billet, cette dernière n’est pas fonctionnelle sur les environnements GNU Linux du fait de la GUI⁴.

Il est également important de souligné que cette application n’est compatible qu’avec la version 5.X de powershell.

Prérequis

• SE : Environnement Windows non obsolète
• Apps : Non Applicable
• Autres :
  • PowerShell version 5.X

Théorie

Si nous devons commencer par la base, il serait bon de se poser la question

« Comment est structurer un environnement GNU Linux ? »

Contrairement à certaines connaissances que j’ai pu fréquenter, oui c’est un point important. Cela évite de faire n’importe quoi et dans une outre mesure d’apprendre quelques choses. (Toutes ressemblances avec des personnes existantes et purement fortuite).

T’es un peu chafouin en ce moment non ? Tu ne voudrais pas ton petit suppositoire à la verveine ?

Légèrement agacé avec une pointe de colère et donc de sarcasme il est vrai. L’hypocrisie des uns fait le désespoir des autres. Mais OKLM comme disent les d’jeuns je prends un sacré recul. Cependant, je suis partant pour la verveine mais pas en suppositoire, plus en pousse café 🙂 Et puis Monsieur, Madame, Mademoiselle, je suis bien fatigué… J’en ai marre…

Regardons alors de plus près l’architecture n à n-1.

(Pas de panique je vais prendre le temps de décrire chaque répertoire).

Nous avons le répertoire parent de notre arborescence, communément appelé « la Racine » (et non rien à voir avec l’organisation de l’ombre de Konoha dans Naruto [super référence…]) ou root. C’est sous ce répertoire / que nous allons retrouver les répertoires qui organise notre SE.

J’en peux plus. C’est que c’est long comme retour aux bases… J’espère ne pas avoir oublié de répertoire.

L’une des mauvaises pratiques lors du déploiement d’un SE Linux est d’allouer l’ensemble de l’espace disponible à /, de ce fait si par exemple je viens à blinder le /var/tmp ou /var/log mon système est à genoux. Donc sur un disque il convient de partitionner les répertoires.

Oui mais quels répertoires ?

En réponse à cette question, je mets en 3/4 face et je réponds par un Uraken des familles en sortant le guide de l’ANSSI.

Cela offre également une autre possibilité concernant la sécurité. Au-delà d’assurer le fonctionnement du système quant au potentiel risque de saturation de stockage, il est possible de définir des options sur les points de montage de nos répertoires. Ainsi il est possible de limiter l’accès au device ou l’exécution de programme. Je préconise également d’ajouter le répertoire /var/log/audit. Je ne rentre volontairement pas dans le détail car j’explique ce point de recommandation (R12) dans mon billet concernant le durcissement d’un système GNU Linux.

Ok pour ce qui est de la segmentation, mais du coup, quel doit être la répartition niveau stockage ?

C’est plutôt simple. Encore une fois, il suffit de chercher un peu. Malheureusement il n’y a pas de recommandation empirique. C’est donc à nous de définir les seuils par répertoire en tenant compte des critères énoncés précédemment.

Pour ma part cela donne :

Voilà ce qui est pour la théorie. Comme ça me soule de ne pas savoir quel espace allouer pour 30 Gio, 40 Gio, 50 Gio de disque, j’ai été contraint de faire une petite application en Powershell… Pourquoi changer une équipe qui gagne ?

Application

Je reste un puriste en termes de développement et je ne peux me passer de Windows Powershell ISE⁷. Je sais qu’il existe mieux comme IDE⁸ (Visual Studio Code par exemple) mais je n’arrive pas à me faire à l’idée de quitter ISE…

Cela fait-il de moi un vieux réactionnaire ? Un dev de l’ancien temps ?

Bref, je laisse cette question existentielle en suspens.

Je me suis amusé pour une fois à réaliser une interface GUI⁹ via WindowsForm. Moi l’amoureux du CLI¹⁰ je reconnais mettre amusé. Encore une fois je sais que je ne savais rien et j’ai donc encore appris.

Réaliser une application GUI en plaçant les items au pixel c’est marrant mais vite casse gueule. Cela demande une gymnastique d’esprit qui ne me rebute pas.

Il y a toutefois un bémol non négligeable à l’utilisation de WindowsForm, cela ne permet pas l’opérabilité multiplateforme. Logique puisque WindowsForm fait partie intégrante de Windows, donc pas possible de faire fonctionner ce dernier sous Linux.

Il faudrait donc que je compose un mode de fonctionnement CLI pour assurer l’opérabilité. Cela n’est qu’au final que le développement d’une fonction d’affichage.

La première version de mon application ne se base pas pour l’instant sur un fichier de configuration ce qui implique que les seuils minimums et maximums sont défini en dur dans le code (en tant que constante global tout de même je ne suis pas un sauvage !).

J’offre également la possibilité de définir la taille minimum ou maximum à provisionner.

Pour bien comprendre (c’est un grand mot) je propose la courte vidéo de présentation de la version béta de mon app.

Démonstration

GitHub

Miaou

Conclusion

Qu’il est bon de revenir aux bases. Sans cela, je pense que je n’aurai pas eu l’idée de faire du GUI en powershell depuis mon ISE. Il est vrai que cela permet également de revenir peut-être aux prémices de ce blog qui étaient :

• L’aspect pédagogique
• Aborder les bases
• Réaliser des petits projets
• Sortir des sentiers battus

Ainsi, je renoue avec certaines valeurs laissées de côté dans le cadre des derniers gros projets que j’ai pu mener. Toutefois, je reste une tête de c*n à laisser transparaitre ma désinvolture, sarcasmes et autres tournures de phrases et expressions vitriolés 🙂 (Ce blog et mes articles restent un loisir personnel et cela m’amuse d’user de ma liberté d’expression tout en tachant de rester respectueux).

Bref, il est temps de clôturer ce billet et d’attaquer d’autres thématiques 🙂

Le mot de la fin :

J’ai évalué et calculé mon incompétence, elle est à la hauteur de vos mensonges et de votre lâcheté. Un petit partitionnement de prime et de service ? Vous méritez bien convenablement un pâté lorrain en cadeau ?

Erwan GUILLEMARD

Sources

• Debian : Recommanded Partitioning
• Ubuntu : DiskSpace

1. RHEL : RedHat Entreprise Linux ↩︎
2. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
3. SE : Système d’Exploitation ↩︎
4. GUI : Graphical User Interface ↩︎
5. GRUB : GRand Unifier Bootloader ↩︎
6. BDD : Base De Données ↩︎
7. ISE : Integrated Scripting Environment ↩︎
8. IDE : Integraded Development Environment ↩︎
9. GUI : Graphical User Interface ↩︎
10. CLI : Command Line Interface ↩︎

Alors de quel mécanisme de sécurité vais-je aborder ?

Dans l’ère du temps, nous parlons sans cesse de PAM¹, PIM², ZTNA³, termes qui jusqu’il y a quelques années étaient obscurs et commençaient tous justes à émerger. Si aujourd’hui ces termes sont incontournables, je m’interroge à implémenter ces derniers dans un environnement OnPremise (pour ne pas dire mon environnement) en tenant compte :

• Du modèle de tiering de l’infrastructure
• De la segmentation en place des rôles et permissions
• Du durcissement de sécurité

Toutefois et encore une fois, comme le disait un ancien collègue la sécurité ce n’est pas pratique et je souhaite mettre en place une certaine souplesse à certains comptes utilisateurs bien identifiés.

Pif, PAM, Pouf, Je suis informaticien ; Pif, PAM, Pouf ça c’est vraiment trop bien !

Donc me voilà parti pour l’étude et l’implémentation d’une des fonctionnalités PAM fournit par Windows, l’appartenance temporaire à un groupe ou Temporary Group Membership (TGM⁴).

Avant-Propos

Je pars du principe que nous avons un environnement Windows avec un contrôleur ADDS⁵. Ce dernier est OnPremise est non hybride (pas de jonction avec AAD⁶).

Notre architecture se base sur la segmentation en tiering de notre SI⁷ et notre ADDS est durci selon les préconisations de l’ANSSI⁸.

L’objectif que je me fixe est donc de mettre en place la fonctionnalité d’attribution de droit d’administration temporairement à un utilisateur sans à avoir de :

• Créer un compte d’administration dédié à un usage ponctuel
• D’attribuer les droits d’administration (domaine ou local) permanent

Comme d’accoutumé (car nous ne changeons pas les bonnes vieilles habitudes) l’environnement Windows sera durci selon les bonnes pratiques et j’utiliserai mes deux contrôleurs de domaine 2025 en CORE.

Prérequis

• SE :
  • Windows Server : 2k16 et version ultérieures
• Apps :
  • ADDS
• Autres :
  • Non applicable

Théorie

Il est important de comprendre comment fonctionne et ce qu’apporte l’ajout de la fonctionnalité « Privileged Access Management Feature ».

Il est impératif et primordial que l’ensemble des serveurs AD soit au minima en version WS 2k16 et donc que le schéma de la forêt soit en version 2016.

Au vu des derniers propos énoncés, nous pouvons nous douter que nous allons altérer le schéma de notre AD. Ce qui est implicite (mais enfonçons une porte ouverte), l’installation de cette fonctionnalité sera irréversible (oui c’est une extension du schéma… La base j’en encore envie d’écrire. Oups c’est fait).

Extension du schéma Active Directory

Je juge important de savoir ce qui va être ajouté. C’est pourquoi une sous partie va être nécessaire pour regarder plus en détail la liste des nouveaux objets et attributs.

La liste n’est pas longue. Toutefois il convient de rappeler que « ce n’est pas le nombre d’objet qui fait la force » mais leur usage.

Et avec tous les points, quand est-il des risques ? Oh quasi rien (#MDR)

Risques

Structurels

L’un des premiers risques seraient lors du déploiement de la fonctionnalité. Il est important de bien prendre en compte le côté irréversible de l’opération. Je recommanderai de vérifier en amont l’état de santé des DCs et de la topologie souhaitée. L’objectif étant de ne pas se coltiner une dette technique des familles à la suite d’une mauvaise conception.

Délégations

Attention à la délégation sur notre container (CN=Shadow Principal Configuration). Si ces derniers sont trop larges un type comme Waldo peut se définir Admin du Domain en créant un ShadowPrincipal. Et hop ! Une escalade invisible…

Sécurités

Continuons de parler d’escalade (perso, moi c’est le bloc jusqu’à ce que je ni**e deux ménisques), le risque d’une escalade furtive et temporaire…

Les mécanismes PAM octroyant des droits temporaires, l’usage d’un compte admin temporaire serait peu visibles dans les journaux d’audit et sont souvent peu, voire mal surveillés. Ainsi, un attaquant peut devenir Admin du Domain pour 1 heure réaliser une opération de type DCsync plus la création d’une backdoor et ce je la jouer à la David Copperfield…

Une attaque directe par ShadowPrincipals à travers un compte compromis ayant les droits PAM. De cette manière, notre Charlie ou Waldo peut créer un ShadowPrincipal ajoutant un TTL à un groupe d’administration (Tiers 0) sans à avoir besoin de modifier directement le groupe. Cette méthode permettrait de contourner un grand nombre de mécanisme de sécurité en place.

L’attaque par SID, le classique des classiques. Comme vu précédemment, l’attribut msDS-ShadowPrincipalSid accepte des SID internes et externes (dans le cas de forêt approuvé). Ainsi, une mauvaise gestion des relations d’approbations ou la compromission d’une forêt externe donnerait automatiquement un accès privilégié au SI local.

Opérationnels

La perte d’un accès administrateur qui aurait été délégué sur une mauvaise évaluation de la durée du TTL pourrait être lourd de conséquence. Risque de ne plus être administrateur durant une opération critique nécessitant les droits d’administrations par exemple et donc de se retrouver totalement bloqué.

Une complexité trop élevée peut également relever d’un frein. Cela peut rendre les débogages longs et fastidieux (un peu comme ma b**e… Très très drôle M’sieur…) ainsi que des comportements inattendus. La pire chose possible reste la mauvaise formation des équipes et le risque d’erreurs fréquentes par les équipes de Niveau 0 ou 1.

Gouvernances et Humains

De la mauvaise formation des équipes relèvent souvent de processus non définis ou totalement ignoré. Ainsi il ne serait pas rare d’assigner des TTLs trop longs dans le temps pour avoir la paix (qu’est-ce que la sécurité peut être pénible) ou de définir des TTLs trop courts et d’enchainer les élévations temporaires.

Se pose alors la question de « Mais à quoi sert le PAM finalement ? »

L’excès de confiance et son mauvais usage peut entrainer un faux sentiment de sécurité. Le PAM a été implémenté, nous ne risquons rien. Sauf que les comptes d’administrations ne sont pas protégés correctement et dans le cas de compromission d’un poste admin… Je ne fais pas de dessin hein ?

Audits et Conformités

Comme inscrit précédemment, les journaux d’évènements sont assez difficiles à identifier et à corréler dans le cadre d’attribution temporaire des droits. Ainsi, l’expiration d’un TTL n’est pas un évènement clair pour l’audit. Ce qui peut facilement limiter l’analyse et le diagnostic de la part des équipes.

C’est pourquoi il va être nécessaire de porter une vigilance particulière sur les événements suivants :

Event ID	Description / Rôles / Types
4728	Ajout à un groupe global
4732	Ajout à un groupe local
4756	Ajout à un groupe universel
4729	Expiration ou Suppression à un groupe global
4733	Expiration ou Suppression à un groupe local
4757	Expiration ou Suppression à un groupe universel
5137	Création d’un objet
5136	Modification d’un objet
5141	Suppression d’un objet
4672	Attribution de privilège élevés
4624	Logon d’un compte ayant des droits d’administration
4634	Logoff d’un compte ayant des droits d’administration
4648	Logon explicite d’un compte ayant des droits d’administration
4662	Accès d’objets AD sensibles
4719	Modification audit policy
1102	Effacement des journaux
4768/4769	Kerberos (corrélation des TTLs)

A cela s’ajoute les diverses solutions du marché qui viennent auditer la santé des SIs et notamment celui des AD. Ces derniers ne prennent pas en compte l’attribut member;TTL et ShadowPrincipal. Les SIEMs¹⁴ valant paroles d’évangiles pour les SOCs¹⁵, hop ni une ni deux l’informations passent à la trappe.

Recommandations

Les objectifs sont de pouvoir garantir AUCUN accès administrateur permanent afin d’obtenir une élévation temporaire, traçable et approuvée (je reviendrai sur ces points dans la partie pratique). Tout cela afin de contenir et maitrisé en cas de compromission l’impact ainsi que la surface d’exposition.

Il est également primordial de comprendre que l’usage du PAM au sens windows du terme ne doit servir que pour :

• Admin du Domaine
• Administrateur de l’entreprise
• Administrateur du schéma
• Administrateurs DC¹⁶
• Autres (Comptes ADCS¹⁷, ADFS¹⁸, AAD Connect)

L’usage pour du helpdesk ou pour des serveurs applicatifs doit être proscrit. Ce qui est logique car il revient à Services Informatiques d’arbitrer sur les demandes utilisateurs. Néanmoins, pour octroyer des droits d’administrateur à un stagiaire ou prestataire ça fonctionne très bien mais encore une fois sous réserve DE certains mécanismes.

Cela passe donc par plusieurs axes.

Architecture

Il est important de noter qu’avant toutes choses, les serveurs en Tiers 0 ne doivent pas avoir accès à internet en dehors des URLs approuvés (et c’est non négociable) et ne doivent contenir QUE les logicielles d’architecture et de sécurité (donc vous me virez vos salop***ies de NinjaRMM, LogMeIn, TeamViewer et compagnie).

• URLs des serveurs antivirus (genre TrendMicro etc)
• URLs des serveurs de mises à jour Microsoft

Il va de soi qu’étant en Tiers 0, le réseau est isolé et filtré en entrée et sortie. Il n’y a pas d’administration direct depuis une ressources de Tiers 1 ou 2.

Ci-contre, la topologie comme cette dernière devrait l’être avec MIM et PAM. Le fait d’intercaler un server MIM-PAM entre notre ADDS et nos postes clients permettent d’user comme dit précédemment des mécanismes d’approbations de workflow et d’automatisation. Le serveur PAM doit être vu comme un bastion dans un réseau isolé de niveau T0.

La mise place d’une telle architecture va être relativement complexe pour moi au vu des ressources disponibles niveau homelab. Je vais donc me passer du serveur intermédiaire MIM PAM.

Cette topologie est compatible et valide bien qui moins recommandée quant aux risques accrus relatif à l’audit et d’un contrôle moins efficace. Cela nous demandera donc en contrepartie d’être irréprochable sur les groupes, droits et permissions lié à la délégation. Il sera nécessaire d’avoir un regard et contrôle réguliers des scripts Powershell.

Donc me concernant je resterai sur mon modèle en place de tiering T0-T1-T2 avec segmentation et contrôle des flux.

Comptes & IDs

Cela me semble logique, mais important de le répéter il ne faut en aucun cas user d’authentification interactif et de ne pas utiliser de compte administrateur. Et cherry on the cake, les comptes sont TOUJOURS nominatifs (oui même pour vous les éditeurs).

Ainsi, pas de compte admin permanent. 🙂

Néanmoins, il est important d’avoir des comptes brises-glaces afin de ne pas se couper l’herbe sous le pied. Dans la logique il en faudrait minimum deux et selon l’ANSSI maximum deux (Décidemment la sécurité c’est borderline). Naturellement ces comptes doivent être utilisés en cas d’extrême urgence et lors de leurs usages une alerte doit être notifiée.

Ce qu’il faut comprendre avec PAM, nous ne mettons pas tous nos œufs dans le même panier.

Nomenclatures des groupes

Après ce qui a été dit dans le volet ci-haut, il est nécessaire de définir des GGS¹⁹ propres au PAM et d’ajouter ces derniers en tant que membre des groupes adéquates.

Ainsi pour ma part j’userai de la nomenclature suivante :

GGS_PAM_NOM_Elevation

Simple et efficace.

Durée de vie

Crucial dilemme de la définition de la durée de l’élévation de droit temporaire… Dans la logique une intervention standard est de 30 à 60 minutes en cas de crise nous pourrions définir 120 minutes maximum. Toute durée supérieure à 2 heures et donc interdit.

Oui mais voilà, je dois faire une opération sensible en tant que SysAdmin sur un SI sur la journée comment je fais ?

Excellente question à laquelle je répondrai, nous sommes SysAdmin et donc nous avons l’accréditation pour intervenir sur notre SI. Donc je n’utiliserai pas PAM mais le système classique de mon compte utilisateur avec élévation de droit avec mon compte administrateur délégué ou super administrateur.

Mon presta doit faire une montée de version de la solution applicative sur l’un de nos serveurs pour la journée soit 7 heures de boulot. Comment tu réponds à ça Monsieur jesaistout ?

J’ai pour habitude de ne jamais laissé un prestataire intervenir seul sur mon SI ou un SI sous ma responsabilité. Donc je passe ma journée à surveiller d’un coin de l’œil ces actions. Et dans son cas, je me note de renouveler personnellement toutes les deux heures ça durée de vie. Généralement il n’y a pas trop besoin car le prestataire est administrateur local du serveur mais certaines fois il est nécessaire de lui octroyer les droits d’administrations du domaine (et ça, ça fait froid dans le dos et en dit long sur la topologie de la solution applicative…).

En complément, il en va de soi mais la tacite reconduction des renouvellements des TTLs et à bannir et encore une fois pas de TTL trop long par ne pas être emme**é toutes les deux minutes.

Bien je pense qu’avec tout ça nous en savons assez pour passer à la pratique non ?

Pratique

Installation

Commençons par vérifier le niveau fonctionnel de notre forêt. Nous retrouvons la commande qui devient normalement un automatisme maintenant 🙂

> Get-ADForest

La preuve à l’appui, ci-contre la preuve que pour l’attribut ForestMode la valeur Windows2016Forest est présente. Donc les prérequis sont atteints. Néanmoins, je recommande un petit contrôle de santé de l’AD par précaution et actions avant de poursuivre.

Vérifions maintenant si la fonctionnalité est déjà présente ou non sur notre SI.

> Get-ADOptionalFeature -Filter "name -eq 'Privileged Access Management Feature'"

Si la valeur de l’attribut EnabledScopes est vide, la fonctionnalité n’est pas déployée sur le système. Sinon ba elle l’est déjà. Evident Cap’taine Obvious !

Activons alors cette fonctionnalité.

/!\Attention : C’est à ce moment que l’opération devient irréversible. Et deuxième point de vigilance il faut que nous soyons administrateur du schéma temporairement

> Enable-ADOptionalFeature 'Privileged Access Management Feature' -Scope ForestOrConfigurationSet -Target ronelab.lan

Il suffira de valider le déploiement en activant la touche T pour oui pour tout. Et quelques secondes plus tard, c’est terminé. Oui tous ces mots pour ça… Il faut bien faire durer le plaisir non ? <3

Si nous voulons vraiment valider le bon déploiement de notre fonctionnalité, nous pouvons rappeler la seconde commande ci-haut pour vérifier les paramètres d’activation de notre scope.

Nous constatons donc que cette dernière n’est plus vide ou $null. Nous pourrions également aller nous balader dans la configuration de notre AD pour trouver notre container.

Place à l’assignation temporaire des droits 🙂

Attribution temporaire

Bhin alors comment qui font qu’on fait pour assigner des droits temporaires ?

De la manière la plus simple du monde gazier, même si au passage il faudrait parler un langage au minima courant plutôt que familier.

Pour se faire, un compte admin et un accès à l’un de nos DCs en powershell (où au DC en lui même). Je proscris volontairement les RSATs. Pourquoi ? Parce qu’un DC doit être le plus isolé possible.

# Définir notre TTL en secondes en tant que variable de type Timespan
> $ttl=New-TimeSpan -Hours 1 -Minutes 15
# Ajouter notre utilisateur temporairement au groupe
> Add-ADGroupMember -Identity "GGS_PAM_AdminDomain_Elevation" -Members "john.doe" -MemberTimeToLive $ttl

Et c’est tout. Je vous l’avais dit, rien de bien difficile. Un peu de RTFM et de ligne de commande… Ce qui est intéressant c’est de s’attarder sur les événements de sécurité. Nous retrouvons avec exactitude ce que nous avons énoncé dans la partie théorie concernant le périmètre d’audit.

Ouai mais alors comment vérifier que notre utilisateur à bien des droits qui court dans le temps ?

Vérifications et Analyses

Soyons un peu curieux et penchons nous dans les attributs de notre objets utilisateurs, groupe d’élévation (auquel appartient notre utilisateur) et notre groupe final.

No Surprise ! Il n’y a rien !

Etonnant non ? 🙂 J’ai été surpris et j’ai donc reparcouru la documentation en long, large diagonale… Pourquoi pouvons nous obtenir l’information en powershell (oups j’ai divulgâché la suite) et pas en GUI ?

C’est là que c’est malin. La durée de vie se trouve sur le lien entre l’objet utilisateur et le groupe d’appartenance (rien sur le groupe cible ce qui est logique).

> Get-ADGroup -Filter * -Properties members -ShowMemberTimeToLive | Where-Object {$_.members -match "TTL*"}

Et donc côté Kerberos qu’est ce qui se passe ? La documentation en parle et nous invite à être vigilant sur ces événements (4768 et 4769). Naturellement comme tout ajout à un groupe, il est nécessaire de fermer et d’ouvrir de nouveau la session pour prendre en compte le changement.

#Dans le contexte de l'utilisateur
> klist

Nous pouvons donc constater (modulo mon temps d’ouverture de session) que notre TGT20 à une durée de 1h11 / 1h15. Ce qui correspond à la durée définit dans notre délégation. Une fois le temps imparti passé, le ticket sera renouvelé et donc les droits temporaires d’administrations retirés.

Et alors côté journaux d’événements qu’elles sont les nouvelles ma sœur Anne (#BARBEBLEU) ?

J’ai envie de dire il suffit de parcourir les journaux d’évènement de sécurité.

Bon par contre ne nous cachons pas c’est un peu pénible pour ne pas dire casse-cou***e de taper les requêtes powershell. Il faut définir le TTL, connaitre les SAMs des utilisateurs, connaitre les groupes. Bref, source d’erreur à gogo. Alors à votre avis en tant que fainéant qu’ais je bien pu faire ? 🙂

Applications

Oui, cela peut paraitre étrange, mais j’ai réalisé une application GRAPHIQUE. Un jour à marquer dans les calendriers FOR SURE d’une bière blanche !

J’ai commencé à faire l’outil en PS CLI, mais j’ai vite trouvé que cela n’était pas ergonomique. Alors je me suis demandé pourquoi ne pas réaliser une application en VB.NET ? Flemme monstrueuse. Puis pourquoi pas reprendre une frustration passé du GUI en powershell ?

Hé bien voilà, que je réouvre une vieille blessure et alors quel pied put**n ! Je me suis éclaté.

Bon il reste quelques points à améliorer :

• Multitâche pour retourner les valeurs de l’AD
• Ajouter des petites icones sympas
• Ajouter un petit About (j’ai droit à mes droits d’auteur)
• Publier l’application en certifiant cette dernière
• Quelques contrôles d’erreurs ? :p

Bref pas mal de petite chose mais rien de bien méchant.

Démonstration

Rien de telle qu’une petite démonstration en images successives pour comprendre, aussi appelé vidéo.

Github

Miaou

Conclusion

Je mettais attaqué à ce morceau en ne pensant à la base ne pas y consacrer autant de temps. Je me suis rendu compte une nouvelle fois que ce sont les choses les plus simples qui requiert davantage de recul et de réflexion.

Je lutte encore entre les bonnes pratiques et recommandations contre mon usage et le périmètre d’applicabilité. Dans un certaine mesure PAM, PAM, PAM je me mettrai bien une cartouche pour ne pas avoir connu plus tôt cette fonctionnalité. Bref, il est nécessaire d’étudier avec sérieux son implémentation et son usage.

Je n’ai volontairement pas abordé le système de délégation des droits AD et sur les GPOs. Mais cela reste un impondérable car tout va reposer sur cette base. Ouvrir d’un côté pour mieux fermer de l’autre, dilemme cornélien que la sécurité. Et honnêtement si j’avais traité ce point, l’article serait insoutenable (comme la poitrine de PAMELA dans Alerte à Malibu ; Franchement tu devais la faire celle-là espèce de 90tard, tu ne pouvais pas t’en empêcher ?).

Je suis conscient qu’il reste des axes d’améliorations (notamment sur le code). Toutefois, je pense que si suite il doit y avoir cela plus sur PIM ce qui ouvrira la voie vers l’environnement Azure.

Le mot de la fin :

Si je PAM sur PAMELLA ? J’offre un CADEAU en infogérance ? Malheureusement vous ne pouvez pas Jean-Pat il y a une « couille dehors » en diagonale. Vous retournez en case magouille. Un partout PAM au centre…

Erwan GUILLEMARD

Sources

• Microsoft : Fonctionnalités WS 2k16
• Microsoft : PAM
• Microsoft : Class ShadowPrincipal
• Microsoft : Class Container ShadowPrincipal

1. PAM : Privilege Access Manager ↩︎
2. PIM : Privilege Identity Manager ↩︎
3. ZTNA : Zero Trust Network Access ↩︎
4. TGM : Temporary Group Membership ↩︎
5. ADDS : Active Directory Domain Service ↩︎
6. AAD : Azure Active Directory ↩︎
7. SI : Système d’Information ↩︎
8. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
9. SID : Security IDentifier ↩︎
10. AD : Active Directory ↩︎
11. TTL : TimeToLive ↩︎
12. MIM : Microsoft Inditity Manager ↩︎
13. PIM : Privileged Identity Manager ↩︎
14. SIEM : Security Information Event Management ↩︎
15. SOC : Security Operation Center ↩︎
16. DC : Domain Controler ↩︎
17. ADCS : Active Directory Certificates Services ↩︎
18. ADFS : Active Directory Federation Services ↩︎
19. GGS : Groupe Global de Sécurité ↩︎
20. TGT : Ticket Granting Ticket ↩︎

Alors non je ne vais pas abandonner MariaDB. Ce billet simple et efficace traitera de la SGBD¹ PostgreSQL. Le pourquoi de cet intérêt soudain se justifie par la rupture technologique de nombreux éditeurs du marché vers ce moteur puissant. Ne nous voilons pas la face, ce jour les grands acteurs de BDDs² proposent des versions communautaires qui sont limités en termes de volumétrie et de fonctionnalité. Pour jouir de l’ensemble des fonctionnalités il faut passer à la caisse.

$$$ Bonjour le bandit manchot $$$

Les bases de données étant de plus en plus volumineuse et l’évolution que nous utilisateurs nous en faisons facilite auprès de ces mêmes éditeurs la mise à jour de leurs tarifications. C’est de bonne guerre (ou pas). Ce « ou pas » laisse donc la voie à d’autres alternatives. Plus simple, moins complexes et parfois plus puissante en s’alignant sur le principe de la philosophie OpenSource.

Je laisse une version communautaire, tu passes à la caisse si tu veux un service d’assistance ou de maintenance.

Il y aura toujours chez certains éditeurs quelques fonctionnalités en moins. Toutefois, je pense que c’est dans cette approche et la bonne et je réfléchis à adopter le même principe dans un projet de vie d’une plus grande dimension.

Bref, après cette marche de l’éléphant (sans prendre de LSD³ ou autres acides). Je me fais un petit guide sur PostreSQL 🙂

Avant-Propos

Il me semble important une nouvelle fois de préciser que ce billet portera sur le déploiement d’un environnement PostgreSQL dans sa dernière version stable à ce jour (release 18 en ce mois de grace Octobre 2025). Sur Windows, le déploiement ne m’intéresse pas des masses. Par contre sur un système GNU/LINUX, j’écris un OUI majuscule (gras, italique, souligné rouge !).

Bien que les chiffres ne soient pas réellement suivis, PostgreSQL estime la part d’environnement de production d’environ (lien) :

• 52 % l’usage sur les systèmes GNU/LINUX
• 23% l’usage sur les systèmes Windows

La raison de mon choix est que nous retrouvons un grand nombre d’appliance qui utilise PostgreSQL dans des environnements GNU/UNIX. Donc en tant que SysAdmin il faut bien savoir se positionner 🙂 (franchement, quelle remarque de me*de…).

Je considère que l’environnement sera durci selon les recommandations de l’ANSSI⁴ concernant les systèmes GNU/LINUX et comme d’accoutumé, je pars sur ma distribution RHEL favorite RockyLinux.

Prérequis

• SE :
  • Rocky Linux 9.4 et version ultérieures
• Apps : 
  • PostgreSQL 18.4
• Autres :
  • Non applicable

Théorie

L’implémentation d’un SGBD passe forcément par une réflexion de sa topologie. Nous ne balançons pas une application 1-tiers, on essaie à minima d’adopter une architecture 2-Tiers. Soit 1 serveur Frontend et 1 serveur Backend.

Pour des raisons qui sont évidentes (enfonçage de porte ouverte) une application publiée ne doit pas héberger la BDD. L’application doit être en DMZ⁵ et la BDD dans une autres bulles avec un contrôle des flux entrants et sortants interlans.

M’sieur? Et pour l’identification des flux ? Pour l’attribution des ressources ? Comment on fait ?

Donnez moi un R, un T, un F et un M… RTFM⁶ ! Il suffit encore une fois d’avoir le courage de se palucher le wiki de l’éditeur applicatif. Un peu d’huile de coude n’a jamais fait de mal.

Une fois la topologie bien pensée, passons à l’architecture de notre serveur BDD.

Comme tout SGBD déployé il convient au minima d’implémenter la topologie ci-contre. Soit, un disque dédié au système UNIQUEMENT. Un disque dédié au stockage des données de notre SGBD et en dernier lieu un disque dédié au dump de nos BDDs avec une périodicité définie. J’ajouterai également un quatrième disque quant aux journaux de la BDDs et les journaux de transaction (les fameux transaction logs). Toutefois, ayant une petite infrastructure, je m’octroie le luxe de laisser ces derniers dans le /var/log.

Hardware Requirements

Niveau des ressources là c’est une autre histoire… Si la documentation officielle nous communique les ressources et interopérabilités avec les dépendances tierces, je n’ai malheureusement pas trouvé d’informations sur les ressources matérielles. Dans un sens logique car cela va dépendre de ce que nous souhaitons traiter comme données etc.

J’ai donc décidé d’appliquer de mon plein gré et non sous la contrainte de calquer les recommandations MariaDB (lien). Toutefois, cela fait un peu beaucoup pour moi…

Je partirai donc pour un minimum 2 vCPU et 4 Gio de RAM. Dans l’idéal, je serai je pense sur du 4 vCPU et 8 Gio de RAM. Comme écrit plus haut, tout dépendra de ce que notre application va consommer en termes de traitement. Il faudra alors raisonner en bon père de famille (spéciale dédicasse) et ajuster les ressources afin d’éviter la sur ou sous allocation.

Côté réseau, la documentation nous indique que le port 5432/tcp est le port de communication par défaut. Surprise, nous pouvons changer le port dans le fichier de configuration…

Je pense qu’avec le peu de base énoncée, nous pouvons passer à la pratique.

Pratique

Un dernier point pour faire une magnifique transition entre la théorie et cette partie. Il est à noter que les dépôts officiels des distributions contiennent une version de la solution PostgreSQL. Toutefois, il ne s’agit généralement pas de la dernière version. Il est recommandé d’ajouter le dépôt de l’éditeur et de ne pas utiliser le dépôt système pour PostgreSQL.

Installation

Franchement, je trouve là la démarche super-mega overcool de proposer un webwizard pour définir comment déployer PostgreSQL selon les différents OS⁷ et distributions (nous noterons au passage un excellent usage de la figure de style hyperbolique) (lien).

Je ne vais pas copier bêtement le script proposé. Mais reprendre chacune des lignes. Ce que je trouve admirable, c’est la simplicité du déploiement. Pas besoin d’installer 10k de dépendance en amont et de configurer ces dernières.

1 – Ajout du repo

A partir du lien fournit par le webwizard installer le nouveau repo :

$ sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

2 – Désactivation du package de la source de distribution

Comme indiqué précédemment, il convient de désactiver la version de postgreSQL contenu dans le repo par défaut. Ainsi, nous aurons une plus grande flexibilité dans le choix de version de nos composants.

A noter que mon système étant durci j’ai été contrait de réaliser l’opération en tant que root.

# dnf -qy module disable postgresql

3 – Installation du Server PostgreSQL

Rien de plus simple, il suffit de faire une petite recherche par précaution puis une installation de notre package.

# dnf search postgresql18-server
# dnf install postgresql18-server

4 – Initialisation et démarrage

Comme tous SGBDs, il convient d’initier la première installation. Puis de s’assurer que le service va être lancer automatiquement au démarrage du système en cas de reboot.

Pour conclure, le traditionnel démarrage de notre daemon.

# /usr/pgsql-18/bin/postgresql-18-setup initdb
# systemctl enable postgresql-18
# systemctl start postgresql-18

Pour le fun, une petite vérification 🙂

Notre daemon PostgreSQL étant déployé, j’arrive toujours à ce point d’application des bonnes pratiques systèmes. C’est là que ça peut être délicat si on se plante dans la configuration car cela peut mener à repartir de zéro. D’où l’importance de lire la documentation encore une fois.

C’est qu’un éléphant ça trompe énormément !

Et voilà comment on casse tout 😀

Déplacement de la BDD Location

Si nous gardons la topologie mis en place ci-haut, il sera nécessaire de déplacer le répertoire data stocké sur /var/lib/pgsql/18/data vers notre répertoire /mnt/database/postgresql/data monté sur notre disque /dev/sdb.

Je ne vais pas mentir, je me suis pris les pieds dans le tapis une fois et j’ai dû restaurer ma VM. Toutefois, les étapes ci-dessous sont bien éprouvées et valide.

1 – Arret du service

La base de la base est donc d’arrêter le service postgresql :

$ sudo systemctl stop postgresql-18.service
$ sudo systemctl status postgresql-18.service

Il est primordiale de s’assurer que le service ne tourne plus.

2 – Création de l’architecture cible

Sur notre partition /dev/sdb1 préalablement configurée et montée sur /mnt/database, nous allons créer et définir les droits et permissions pour autoriser notre compte postgres à accéder à ce dernier.

$ sudo mkdir /mnt/database/postgresql
$ sudo mkdir /mnt/database/postgresql/pg_sock
$ sudo mkdir /mnt/database/postgresql/data
$ sudo chown postgres:postgres /mnt/database/postgresql
$ sudo chmod 755 /mnt/database
$ sudo chmod 700 -R /mnt/database/postgresql

Mais alors pourquoi 700 ? La base de donnée ainsi que l’ensemble des fichiers de ressources doivent être accessible uniquement de l’application par sécurité.

3 – Déplacement des données

Comme j’ai pris l’habitude de faire comme pour MariaDB, je vais copier le contenu du répertoire data puis renommer la source afin d’éviter tous dysfonctionnements.

$ sudo rsync -av /var/lib/pgsql/18/data/ /mnt/database/postgresql/data/
$sudo mv /var/lib/pgsql/18/data /var/lib/pgsql/18/data.ori

Une erreur classique lors de l’usage de la commande rsync reste l’oublie du /. Cela entrainera la copie du répertoire et non de son contenu uniquement. En gros, ça va bégayer dans les chemins (../postgresql/data/data/…).

4 – Modification de la configuration du service

Le service est configuré pour démarrer le daemon sous /var/lib/psql/18. Pour prendre en charge le nouveau chemin, il faut modifier ce dernier. La philosophie et de surcharger la configuration.

Créer le répertoire qui va contenir la surcharge de notre daemon psql :

$ sudo mkdir -p /etc/systemd/system/postgresql-18.service.d

Créer un fichier de surcharge qui va contenir le chemin du répertoire data :

$ sudo tee /etc/systemd/system/postgresql-18.service.d/override.conf > /dev/null <<'EOF'
[Service]
Environment="PGDATA=/mnt/database/postgresql/data/"
EOF

Par acquis de conscience, j’aime vérifier que le fichier est bien présent ainsi que le contenu de ce dernier.

$ sudo cat /etc/systemd/system/postgresql-18.service.d/override.conf

Le daemon ‘system’ a été altéré (puisque j’ai ajouté une configuration) et donc ? Un petit reload des familles pour prendre en compte le changement et zou.

$ sudo systemctl daemon-reload

5 – SELinux

Un étape un peu border avec la sécurité (comme un excès de Delirium un jeudi soir pour oublier une semaine compliqué).

Toutefois, il est important de noter un petit point et non des moindres sur notre fichier /etc/fstab. Il va être nécessaire d’ajouter le contexte sur notre partition et de relabeliser notre point partition.

Editons le fichier avec VIM, VI ou NANO puis modifier la ligne comme ci-dessous en ajoutant au niveau des droits defaults,context=system_u:object_r:postgresql_db_t:s0

Ce qui veut dire en SELinux :

• Defaults : Activation des droits standards
• Context=
  • system_u : Identité SELinux, sans impact concernant notre SGBD
  • object_r : Rôle d’objet de type fichier
  • postgresql_db_t : Match avec le type de données PostgreSQL autorisé par SELinux. Ainsi, SELinux interdit à PostgreSQL d’accéder à des fichiers qui ne sont pas dans le contexte.
  • s0 : Le niveau de sécurité par défaut.

Il sera nécessaire de définir le bon contexte sur notre nouveau répertoire.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

6 – Démarrage du service

Le moment de vérité.

Vais je vomir l’ensemble de mes bières et commander une nouvelle tournée pour noyer mon échec ou commander une nouvelle tournée pour célébrer le succès de cette opération ? 🙂

$ sudo systemctl start postgresql-18
$ sudo systemctl status postgresql-18

Il faut noter que le service fonctionne. Néanmoins, il convient de se demander si nous pouvons requêter notre BDD à la suite de ce changement.

$ sudo -u postgres psql -c "SELECT version();"

Vérifions également que le chemin du PGDATA a bien été pris en compte.

$ sudo -u postgres psql -c "SHOW data_directory;"

Ouf ça fonctionne 🙂

Place à l’étape suivante ! BA-BA-BAR POM POM POM POM

Sécurisation & Configuration

Nous revenons encore et toujours au même point. Qui dit données implique la sensibilité de ces dernières. Aujourd’hui braquer une banque ne rapporte pas grand-chose. Le rapport bénéfices/risques n’est pas bon… Mais braqué des données, utiliser ces dernières et les revendre apporte un bien meilleur rapport en termes de bénéfices / risques.

Donc, je me retrousse les manches car je ne suis pas un manche !

Si du côté MariaDB il existe le fameux mysql_secure_installation, ce n’est malheureusement pas le cas chez PostgreSQL.

Il se pose alors de dresser un inventaire rapide des points que nous souhaitons sécuriser :

1. Mot de passe du compte postgres
2. Restreindre l’accès réseaux
3. Mettre en place une stratégie d’authentification
4. Utiliser des algorithmes de chiffrement fort
5. Supprimer les BDDs inutiles
6. Droits sur les fichiers
7. SELinux
8. Firewall embarqué (même si je préfère le terme embedded)
9. Audit et Journaux d’événements

Ca fait une petite tripoté n’est-il pas ? Naturellement, certains des points ci-haut ont déjà été traité lors du déploiement et du changement d’emplacement de la base de données.

1 – Password Account DB

Comme pour MariaDB (compte root), l’utilisateur postgres ne possède pas de mot de passe. Il convient par sécurité de définir ce dernier afin qu’il ne vienne une idée à un individu malveillant (comme un RSSI ⁸lors d’un audit ou pire un SysDBA⁹) de mettre sa truffe humide dans notre BDD.

$ su - postgres
$ psql -c "alter user postgres with password 'MyP@ssw0rd'"

Il est important de faire un petit clear de l’historique de frappe. Un mot de passe en clair c’est pas cool.

2 – Network Restrictions

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf.

Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION.

Se pose alors la question, depuis où je peux consulter ma BDDs et sur quel port ? Personnellement, le port je le laisse par défaut soit 5432/tcp. Toutefois, la source, il est bien de spécifier le subnet ou les adresses IPs qui sont autorisé à se connecter à notre SGBD. Naturellement, la valeur ‘*’ est proscrite.

Ce paramétrage va de pair avec la configuration de notre UTM¹⁰ embedded (cf le point plus bas).

3 – Authentification Policies

On va changer de fichier. L’objectif est de définir qui va se connecter à quoi, comment et depuis où.

Direction /mnt/database/postgresql/data/pg_hba.conf

La logique de lecture est la suivante TYPE correspond à la nature de l’authentification (local? hôte ?) pour quelle DATABASE (all ? replication ? db_test ?) pour quel USER (all ? r-one ?) depuis quelle ADDRESS (127.0.0.1/32 ? 0.0.0.0/0 ? 10.36.16.0/24 ?) et par quel METHOD (peer ? scram-sha-256? MD5?).

Il est certain qu’il faut limiter l’usage au maximum du all comme du masque 0.0.0.0/0. Toutefois, il n’y a pas de base les paramètres « implicites » de refus des connexions. C’est donc à implémenter (dernières lignes de la capture d’écran).

On sauvegarde, puis on reload le service.

$ sudo systemctl reload postgresql-18

4 – Suite de chiffrement

Toujours dans le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION et activez l’algorithme de chiffrement scram-sha-256. Le MD5, nous passons notre tour hein ? Autant allez aux champignons sans capotes, c’est du pareil au même.

5 – Nettoyage des BDDs inutiles

Il est important de lister les bases présentes sur notre SGBD et de supprimer les bases qui ne servent à rien.

$ su - postgres  -c "\l"
$ psql

postgres=#\l
postgres=# DROP DATABASE NAME_BDD;

Attention : Il ne faut en aucun cas supprimer les bases template0 et template1. Ces dernières permettent (pour la 1) de générer les futurs BDDs) et (pour la 0) de regénérer la BDD de modèle.

6 – Permissions et ACLs

Comme expliqué ci haut et pour des raisons évidentes. L’accès aux données doivent être accessible uniquement du compte utilisateur postgres et root. Pas de quoi foutez milles éléphants…

Je glisse toutefois les commandes.

$ sudo chown -R postgres:postgres /mnt/database/postgresql/data
$ sudo chmod 700 /mnt/database/postgresql/data

7 – SELinux <3

Nous retrouvons la commande saisie ci-haut si nous avons modifié le database location.

Ainsi nous définissons le contexte de fichier de type postgresql_db_t à l’ensemble des éléments qui sont situer sous /mnt/database/postgresql. Puis on restore le contexte.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

8 – Firewall

Avant c’était iptables maintenant c’est firewalld ou ufw. Personnellement je reste sur la configuration de firewalld.

Il convient d’autoriser les flux 5432/tcp dans notre firewall si des connexions se font depuis un autre réseau ou une autre machine.

$ sudo firewall-cmd --permanent --add-service=postgresql
$ sudo firewall-cmd --reload

Cela étant, il serait également plus précis de filtrer les connexions entrantes sur un réseau ou une adresse ip uniquement sur le port 5432/tcp.

J’assume cette configuration du fait de mon UTM en amont qui filtre l’ensemble des flux inter-lans.

9 – Logs & Audits

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

# vim /mnt/database/postgresql/data/postgresql.conf

Se rendre ensuite dans la section REPORTING AND LOGGING. Puis vérifiez que la configuration suivante est active.

Activation de logging_collector sur on afin de récupérer les erreurs sous la forme json ou csv. L’emplacement où va être stocké les journaux. Par défaut celui-ci se trouve dans le répertoire log. Il faudra renseigner si l’emplacement est différent le chemin absolu, le chemin relatif si c’est un cluster. log_directory = ‘log’ Le nom du fichier, par défaut ce dernier est sous le format postgresql-%Y-%m-%d_%H%M%S.log. log_filename = ‘postgresql-%a.log’ Activer la journalisation pour l’ensemble des événements de connexion et de déconnexion. log_connections = on log_disconnections = on En guise de traitement des logs, nous choisirons ddl pour avoir les définitions des commandes utilisés. Attention, l’usage de all peut être dangereux vis à vis des ressources. log_statement = ‘ddl’

Une fois les modifications apportées, n’oubliez pas que notre serveur PostgreSQL à besoin d’être redémarré :

$ sudo systemctl restart postgresql-18

Pour une configuration spécifique comme la gestion de la mémoire allouée, les fonctionnalités et j’en passe. Je pense qu’il est inutile d’aborder cela dans ce billet.

Pourquoi ? Parce que cet aspect-là et intrinsèquement lié aux dépendances des applications qui nécessite le SGBD PostgreSQL.

Premiers Pas

Cette sous partie vise plus à entrevoir les commandes de bases pour instancier une BDD dans le cadre de déploiement d’une application (spoiler Odoo par exemple ?).

Je n’ai pas la prétention de réinventer la roue, il existe la documentation pour cela et je n’ai pas non plus la prétention de devenir SysDBA. J’ai juste envie de faire les choses bien et surtout en suivant la doctrine des 3S, Simple, Standard et Sécurisé (14 ans d’ESN¹¹ ça vous forge un homme !).

Création d’un user

La création d’un utilisateur suit un paradigme différent de MariaDB. La finesse de l’application du contexte d’un utilisateur se fera dans le fichier pg_hba.conf.

$ psql -U postgres

postgres=# CREATE USER user_odoo WITH PASSWORD 'MyPassw0rd';

Création d’une BDD

La création d’une BDD nécessite qu’un utilisateur (de la SGBD naturellement) ait le privilège CREATEDB ou d’utiliser un compte super utilisateur. Cela parait logique mais pas pour tout le monde. La documentation nous rappelle que la création d’une nouvelle base de données sera effectué en réalisant un clone de la BDD template1 (si, le truc qui ne fallait pas supprimer).

postgres=# CREATE DATABASE bdd_odoo;

Toutefois, nous pouvons allez plus loin en définissant le propriétaire de la BDD, le jeu de caractère de la BDD ainsi que la collation locale afin de faciliter le tri des chaines. Par exemple :

postgres=# CREATE DATABASE bdd_odoo_18
			WITH OWNER user_odoo
			ENCODING 'UTF8'
			LC_COLLATE 'fr_FR.UTF-8'
			LC_CTYPE 'fr_FR.UTF-8'
			TEMPLATE template0;

/!\ ARTUNG /!\ Bicyclette et petit vélo !

Il n’est pas impossible que vous tombiez sur une erreur de ce type « invalid LC_COLLATE locale name« . Cela signifie que tu vivras ta vie sans aucun soucis. (Tes vraiment sûre ?) En gros, il manque le fichier de mappage de caractère au niveau système. Soit il n’est pas présent, soit il n’est pas généré.

Afin de vérifier si ce dernier est présent :

$ sudo locale -a | grep fr

Si cela ne retourne rien c’est que le packet ne doit pas être installé. Alors installons le vin diou !

$ sudo dnf install glibc-langpack-fr
$ sudo locale -a | grep fr

Surprise le fichier de mappage est présent ! Si nous rejouons la requête, cela fonctionne.

Attribution des privilèges et rôles

Comme tous systèmes de base de données, un incontournable reste la notion de rôle et de privilège.

Dans la pratique, il convient et je sais que j’enfonce une porte ouverte d’adopter la bonne pratique de créer des rôles et d’affecter les rôles aux utilisateurs. Un rôle sur la BDD en modification, en lecture, superutilisateur ect.

Ainsi et c’est d’une logique implacable, si modification il doit avoir, je ne modifierai QUE le rôle et non utilisateur par utilisateur. MALINX le LYNX…

Rôles

Par défaut, nous retrouvons :

Toujours dans le spoil (parce que je suis un mec underground moi. MOUMOUNIGAN !) je vais créer un rôle pour ODOO qui permettra uniquement de se connecter, de créer une bdd avec un mot de passe.

postgres=# CREATE ROLE r_odoo LOGIN CREATEDB;

Pour attribuer le rôle à un utilisateur (en prenant toujours le cas ODOO avec notre role r_odoo et user_odoo) :

postgres=# GRANT r_odoo TO user_odoo;

Privilèges

La notion de privilèges que ce soit sur la BDD, les tables où les schémas suivent le principe de SQL. Ainsi il suffira d’user des commandes GRANT accompagner de :

• CONNECT ON
• USAGE
• SELECT ON ALL
• SELECT, INSERT, UPDATE, DELETE
• ALTER
• DROP
• …

Il est important de prendre en compte que le propriétaire de la BDD a tous les droits.

Toujours dans notre exemple ODOO, il n’y aura donc pas de privilèges à appliquer.

PostgreSQL Client

Il existe un outil que j’ai découvert à travers un case chez VEEAM pour un problème de protection O365 du nom de pgAdmin. Cette solution officielle est l’outil graphique pour administrer PostrgreSQL.

Je pense important de présenter cette dernière car dans le cas où nous ne nous serions pas SQL native language ou seconde langue. Cela nous permettrait de bien comprendre certains dysfonctionnements ou structures.

L’installation n’est pas en soi bien complexe… Ma grand-mère y arriverait sans difficulté. Toutefois, je glisse le tips…

Certains pourrait dire, oui c’est un PHPMyAdmin. Oui c’est un fait. C’est une IHM¹² en GUI¹³ pour faciliter l’expérience quotidienne.

Pour se connecter, il suffira de renseigner les informations de connexion et de s’assurer au préalable que la politique de communication est bien présente sur notre UTM concernant les flux interlans. Sans oublier de vérifier :

• La configuration du fichier pg_hba.conf est compliante
• Les adresses d’écoutes dans le fichier postgresql.conf ne sont pas restreinte cas localhost et que le bind d’interface est bien configuré. (Le bind c’est l’ip de l’interface du serveur, pas l’adresse ip du client… Je dis ça parce que je vous vois venir hein !)

Et si nous jetions un coup d’œil dans le viseur pour observer nos logs voir si on voit notre pachyderm numérique ?

$ sudo tail -f /mnt/database/postgresql/data/log/postgresql-Wed.log

Impeccable. Tout fonctionne 🙂

Conclusion

Ce billet revient aux prémices des premiers articles rédigés il y a maintenant quasiment deux ans. Quelques choses de simple qui vise à jouer les aides mémoires de ma cafetière qui commence à s’effriter.

Je ne tenais pas à me lancer dans un benchmark de « Est ce que l’otarie et plus fort que l’éléphant ? » cela ne m’intéresse pas le moindre du monde. Toutefois et comme j’ai pu l’aborder en avant propos, le tournant des éditeurs vers la solution PostgreSQL mérite de s’intéresser à cette dernière.

• VEEAM enchaine sa rupture technologique avec Windows (SE¹⁴ et/ou MSSQL) pour RHEL et PostgreSQL
• ODOO qui reste dans la philosophie du libre
• La Société Générale (faut bien renflouer les caisses après le passage de Jérôme KERVIEL… Ok, la blague est mauvaise, mais il fallait la faire. Trop tentante).
• Patrick BALKANY pour gérer son patrimoine non déclaré. Ah non autant pour moi c’est une fake news… Que je suis naïf 🙂

Au delà des deux derniers points douteux, il est bien je pense de se garder deux SGBDs relationnels sous le coude les solutions MariaDB et PostgreSQL. L’implémentation de la couche de sécurité relève d’un défi parfois mais reste nécessaire et plus qu’indispensable de nos jours.

Il manque toutefois un point que je n’ai pas développé ici. La possibilité de sauvegarder une base de manière périodique. J’avais traité le sujet pour MariaDB à la suite d’une connerie de ma part un vendredi aprem sur l’environnement de production. Je pense qu’il serait bien de reprendre ce projet et de l’adapter pour PostgreSQL 🙂

Ca fait un sujet supplémentaire à traiter d’ici la fin d’année. Mais surtout, le levé de voile ayant été fait un poil plus tôt ce billet est le tremplin pour l’implémentation d’ODOO comme mon ERP à venir.

Le mot de la fin :

Egaré dans la base de données infernale, le sysadmin se nomme R-ONE. A la recherche du datalocation, le problème s’appelle la durcification. Avec la solution VEEAM, il a pu rollback super vite. Dérivant à dos d’éléphant, R-ONE arrivera toujours dans l’étang… (faut bien se mouiller un peu qu’ils disaient les anciens)

Erwan GUILLEMARD

Sources

• PostgreSQL Secteur par OS
• PostgreSQL – Main Apps Guide
• PostgreSQL – Download
• PGAdmin – Download
• MariaDB – Hardware Requirements

1. SGBD : Système de Gestion de Base de Données ↩︎
2. BDD : Base De Données ↩︎
3. LSD :  LySergique Diéthylamide ↩︎
4. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
5. DMZ : Demilitarized Zone ↩︎
6. RTFM : Read The Fuck*ng Manual ↩︎
7. OS : Operating System ↩︎
8. RSSI : Responsable Sécurité des Systèmes d’Informations ↩︎
9. SysDBA : Administrateur des Systèmes de Bases de Données ↩︎
10. UTM : Unified threat management ↩︎
11. ESN : Entreprise des Services Numériques ↩︎
12. IHM : Interface Homme Machine ↩︎
13. GUI : Graphical User Interface ↩︎
14. SE : Système d’Exploitation ↩︎

Plus sérieusement et sans détour, il se trouve que ce sont les choses les plus simples dans la vie qui sont le plus souvent bâclées ou négligées. C’est pourquoi je me suis dit, et si je m’attardais un peu plus sur les politiques de mots de passe dans un environnement WINDOWS ?

Il relève de nombreux articles déjà sur le net qui traite ce sujet, mais voyez-vous encore une fois je pense aller un peu plus loin que les excellents articles déjà présents. Difficile de parler de ce que j’ai fait sans toutefois présenter les bases 🙂

Mais alors jusqu’où es-tu allé cette fois ci ?

Je suis parti de la politique classique de définition de la politique de mot de passe dans un domaine AD¹ et du traitement des événements de verrouillage de compte. Sujet traité par mon précédent mentor et qui m’a demandé un peu de recherche pour arriver à mes fins (je voulais faire ma propre solution, comprendre et maitriser le sujet).

Bref, cela sera je le pense un petit billet avec du script, des schémas et naturellement du powershell avec une pointe de désinvolture et assurément de sécurité.

Avant-Propos

Comme rédigé légèrement plus tôt, je n’ai pas la volonté de faire un article détaillé qui reprend la majorité des articles déjà présent sur le NET. Il me faut néanmoins une base de départ.

Mon mentor, dans le cadre d’une esquisse de PSSI² il y a un certain nombre d’année c’est dit qu’il serait bien d’informer l’équipe du SI interne (ou externalisé) d’un potentiel blocage, verrouillage de compte sur un AD. La première question que nous pourrions nous poser serait d’abord quel cas pourrait entrainer un verrouillage d’un compte ?

• Un dysfonctionnement de la couche 8 du modèle OSI³ :
  • Je suis méchant avec cette couche, je sais bien. Nous parlons ici (ou plutôt je parle car cela n’engage que ma responsabilité ET ma personne) du dysfonctionnement entre le siège du bureau et le clavier. Soit en un mot et un seul ? L’utilisateur bien sûr !! Mais qu’est ce que ce mec est condescendant… C’est affligeant. Généralement, le verrouillage de compte est généré par une erreur de frape lors de la saisie et dans certains cas (compte non nominatif utilisé par plusieurs collaborateurs) de la saisie d’un mauvais mot de passe.
• Une tentative de Charlie qui veut « poutrer » le compte de Bob pour récupérer le cœur d’Alice
  • On comprend assez aisément le brute force d’un intru pour s’infiltrer dans le SI⁴ est tout casser…
• Un dysfonctionnement de la couche 7 du modèle OSI :
  • Oui celle-là existe officiellement et concerne la couche applicative :). Je ne peux pas non plus raconter des conneries en permanence tout de même. Pour faire simple une application a des informations qui ne sont pas à jour (un client de messagerie qui pete un plomb par exemple).

Donc l’intérêt de notifier l’équipe interne ? S’assurer que notre utilisateur ne veut pas s’octroyer une pause-café supplémentaire ou que nous avons un petit malin dans la place qui veut nous faire passer nos prochains jours à la première place de l’enfer dans le plus beau des pandémoniums <3

Mon côté brun ténébreux qui ressort avec les vilains corbeaux de Sir Alan Edgar Poe… Alors comment faire pour déceler un verrouillage de compte et comment notifier les équipes ? Spoiler ? La suite dans les parties ci-dessous.

Prérequis

• SE : 
  • Windows Server 2k16 et version ultérieures
• Apps : 
  • Rôle ADDS
• Autres :
  • PowerShell version 5 et supérieure
  • SMTP
  • Domaine AD

Théorie

Avant de commencer, posons nous la question de comment fonctionne l’authentification dans poste dans une domaine (pour faire simple, nous restons dans une forêt avec un seul domaine).

Authentification, comment ça marche ?

En tous lieux, je dirai avec des chaussures… Ok, je sors…

Nous pourrions résumer le cycle de vie de l’authentification en 7 étapes (encore la magie du nombre 7…) l’authentification d’un utilisateur.

1. Saisie des identifiants login et mot de passe
   • Rien de bien sorcier, CONTOSO\John.Doe et mon superpassword (si tenter que le mot de passe soit bien celui attendu dans l’AD pour l’utilisateur John DOE…
2. Localisation du DC via DNS
   • Notre poste va alors à travers l’enregistrement DNS⁵ _ldap._tcp.dc._msdcs.contoso.x pour trouver un DC⁶ disponible
3. Négociation, KERBEROS ou NTLM ?
   • Deux mots protocoles qui peuvent faire peur. Je ne rentre pas dans le détail des deux protocoles. Gardons à l’esprit toutefois que KERBEROS est supérieur au protocole NTLM⁷ (d’ailleurs KERBEROS est utilisé comme protocole par défaut).
   • Cas de KERBEROS, le poste demande un TGT⁸ auprès du KDC⁹ du DC à travers une requête. Si le couple d’authentification saisie est correct le KDC retournera en réponse le TGT chiffré ainsi qu’une clé de session. Le poste à travers le TGT va demander un TGS¹⁰ afin d’accéder aux différentes ressources du SI (fichiers, imprimantes etc…).
   • Cas de NTLM, le poste va réaliser un challenge au DC en attendant une réponse.
4. Validation du compte
   • Une fois la négociation réussi (Où est-ce qu’il a appris à négocier ?), le DC va vérifier le mot de passe haché, le compte doit être actif (soit pas verrouillé, expiré ou désactivé), récupérer les groupes de sécurité de l’utilisateur ainsi que les stratégies de connexion et de mot de passe.
   • C’est marrant, c’est cette étape qui nous intéresse 🙂
5. Chargement du profil
   • Si la vérification du compte utilisateur est ok, alors c’est réussi. HIGH FIVE ! Le poste va alors charger le profil local ou selon la configuration un profil itinérant. Dans le pire des cas, un profil temporaire.
6. Application des GPO
   • Dans la logique, ensuite sont téléchargées et appliquées les GPO¹¹ utilisateurs, ordinateurs…
7. Ouverture de session
   • Hé nous voilà normalement sur notre bureau.

Bon j’avoue que la partie négociation, j’avais dit que je ne rentrerai pas dans le détail. J’effleure la technicité et croyez moi, nous pourrions aller beaucoup plus loin. Toutefois, demander à vos Admins Systèmes et Réseaux ou Techniciens Systèmes et Réseaux, je ne suis pas certains qu’ils vous expliquent clairement le cycle de vie d’authentification d’un utilisateur…

Stratégie de mot de passe

Avant de rentrer plus dans le détail de ce qui nous intéresse, il est important de parler de la stratégie de mot de passe. Cela s’est plutôt bien démocratisé car nous retrouvons sur la grande majorité des sites web à ce jour le traditionnel message :

Votre mot de passe doit répondre aux critères minimaux ci-dessous :

• 16 caractères minimum
• 1 Majuscule
• 1 Minuscule
• 1 caractère numérique
• 1 caractère spécifique

Je vous vois déjà hurler, ou vos utilisateurs vous ont gueulé dessus… Quant à la politique mis en place. Mais alors que devons nous appliquer et à qui ? L’objectif est de sécuriser les SIs sans pour autant être un vrai tyran avec ces utilisateurs. Gardons toujours à l’esprit que « Trop de sécurité tue la sécurité ». A quoi bon exiger 26 caractères pour retrouver le mot de passe sur un post-it ou AZERTY123456AZERTY123456azerty123456azerty123456$…

Pour cela, j’aime me référer à l’ANSSI¹² comme ça je peux dire haut et fort, « C’est pas moi, c’est eux qui veulent. » 🙂 Je suis courageux n’est ce pas ? 🙂

Dans le guide de Recommandation relatives à l’authentification multi-facteurs et aux mots de passe, il est recommandé d’appliquer la politique de mot de passe suivante (R20):

• Catégorie des mots de passe
• Longueur des mots de passe (Entre 9 et 11, c’est faible. Entre 12 et 14 c’est moyen. Au-delà de 15 c’est fort)
• Règles de complexité des mots de passe (le nombre de caractère utilisable)
• Délais d’expiration des mots de passe (la fréquence de renouvellement)
• Mécanisme de limitation d’essais d’authentification
• Mécanisme de contrôle de la robustesse des mots de passe
• Méthode de conservation des mots de passe
• Méthode de recouvrement d’accès en cas de perte ou de vol des mots de passe
• Mise à disposition d’un coffre-fort de mot de passe

Dans notre cas, seuls les points en vert nous intéressent. Pour définir techniquement notre GPO ou notre FGPP.

D’où tu dis que je suis un FDP ?! Gros Tarba va ! Je vais….

STOP ! En aucun cas je vous insulte ! FGPP¹³ ou Fine Grained Password Policy permettent de manière plus simple de définir plusieurs politiques de mots de passe dans une organisation selon les services et criticité de ces derniers. Croyez-moi, c’est bien plus simple que la gestion par GPO. Ca nous le verrons rapidement dans la pratique quant au déploiement.

Dans tous les cas, j’aime définir la stratégie de mot de passe « par défaut » dans la GPO (vous pouvez me jeter des petits cailloux au visage et du sable dans les yeux), Default Domain Policy : HERESIE ! BLASPHEME ! AU BUCHET ! (Oui ba c’est bien la seule chose que je modifie dans la Default Domain Policy) :

J’ouvre un aparté, dans le cas d’un poste hors domaine que nous souhaiterions durcir, il suffira de faire de même. Il faut que je pose la question de scripter cela. Aparté fermée.

J’ai donc une politique de mots de passe qui s’appliquent (sans verrouillage de compte) par défaut pour l’ensemble des utilisateurs de mon parc, de mon domaine. Néanmoins, je vais définir par FGPP une politique par groupe utilisateur.

Dans ma logique, je choisie de faire trois politiques par défaut en respectant le tiering d’administration des comptes utilisateurs.

Administrateur du domaine > Utilisateurs avec pouvoir > Utilisateur du domaine

La puissance des FGPPs résident dans la possibilité de définir une pondération sur chaque politique. Ainsi, un utilisateur peut se retrouver avec une ou plusieurs politiques liées. Les politiques ne pouvant se cumuler, la politique avec la pondération la plus forte sera minoritaire par rapport à une politique avec une pondération plus faible.

« Unbelievable » diraient nos voisins outre-manche ! Nous retrouvons les mêmes paramètres que dans notre GPO… A noter et point important, la FGPP vaut sur la GPO si cette dernière est lié à un utilisateur ou un groupe d’utilisateur.

Authentification & events

Pour bien comprendre le fonctionnement de l’authentification, nous avons vu ci-haut que tout se passe sur nos DCs. Comme le système n’est pas trop mal foutu (et qu’accessoirement l’authentification à un système relève de la plus grande criticité) tout est consigné dans les journaux d’événements de sécurité.

Elle est pas belle la vie ?

Alors la question est la suivante, qu’elle est ou plutôt qu’elles sont les événements qui nous sont important ? Microsoft est vraiment sympa car ils ont pour nous référencier les événements à surveiller…

Mon cœur cogne un truc esthétique ! Vous voyez tout ce qu’il est possible de faire en termes de sécurité et de suivi, gestion du SI ? Limite ça me fait ba**er. Je vais soumettre l’ID d’un nouveau projet au comité qui vie dans ma cafetière.

Dans notre cas, précis il y a deux événements qui nous intéressent :

• 4624 : Hérité des événements 528 et 540, je cite « L’ouverture de session d’un compte s’est correctement déroulée. »
• 4740 : Hérité de l’événements 644, je cite « Un compte d’utilisateur a été verrouillé. »

Il est important de comprendre dans l’annexe que la notion de criticité est celle qui remonte dans les journaux d’événements. Personnellement certains événements pourraient être revu à la hausse. Enfin, c’est mon opinion personnelle qui n’a de crédit que pour le type qui écrit ces mots…

C’est donc dans le déclenchement de l’évent 4740 que nous trouverons notre bonheur.

Approche

La question est comment récupérer l’information que le compte d’un utilisateur ou compte de service est verrouillé ?

Consultation des objets

Dans un premier temps, j’ai pensé à scruter l’état de chaque objet utilisateur ou ordinateur de l’AD sur un intervalle définis dans le temps.

Le professeur rend les copies, et c’est un 4/20 qui tombe… L’idée peut paraitre bien, mais c’est mauvais. Oui je vais avoir l’information des comptes verrouillés, mais cela n’est pas du tout optimisé, cela va charger pour rien le serveur et générer des lenteurs et niveau proactivité c’est un zéro pointé. Imaginons si nous étions sur un SI avec genre 2k d’objets dans l’AD ?

Consultation des évènements déclenchés

La seconde approche consiste à définir une tache planifiée qui se déclenche sur un événement déclenché. Je l’ai fait il y a peu pour contourner un dysfonctionnement non patché de MS, donc c’est faisable. Mais je n’aime pas cette méthode car elle ouvre une vieille blessure intellectuelle… Ce traumatisme tout bête me dite vous ? Comment retourner et transmettre un paramètre de l’événement déclenché dans un script powershell…

Je peux vous dire qu’en 2015 je me suis torturé l’esprit à un point ou écouter du Evanescence en slip le soir de la Saint Valentin avec un kebab douteux et de l’alcool frelaté relève du plaisir (passe encore pour le kebab et l’alcool m’enfin).

Dix ans après, je rempile sur cette problématique et spoiler je trouve la solution. Comme quoi, un informaticien c’est comme un bon vin. Plus on le garde plus c’est bon. Enfin tout dépend de l’organisation. Oups pardon, je voulais dire la cave 🙂

Vous l’aurez compris ça sera la seconde méthode qui sera utilisé. Nous retournerons alors les attributs suivants :

• Le nom du compte qui lock
• Le nom de l’ordinateur, équipement source qui a cherché à s’authentifier
• Le nom de domaine

Là où j’ai merdé, ce que j’ai choisi de prendre en temps le temps de déclenchement du script et non le temps de lock de l’event. Ce qui du coup dans une configuration spécifique fausse complétement les informations. Donc il doit y avoir une adaptation de ma part sur la première version du code…

Sécurité

Nous sommes dans le domaine ? Nous allons réaliser une tâche planifiée ? Alors la réponse elle est vite répondu mon copaing ! Nous passerons par un compte de service managé, oui un gMSA¹⁴ comme d’habitude (et dire que je ne jugeais que par les comptes de services restreint avant…).

Les droits seront mis sur le script ainsi que l’ensemble des dépendances des utilisateurs externes. Sur le répertoire en somme ? Oui c’est ça…

Structure

S’agissant d’un petit projet, je me suis demandé si je devais ou non découper ce billet en différent sous article. Au final, je ne pense pas. Il y a eu plus indigeste que ça par le passé 🙂

Topographie – Applicative

Nous retrouvons donc l’architecture classique de mes projets précédents (Etonnant non ?) 🙂

A la racine du répertoire, nous retrouvons cette fois ci UN fichier exécutable (au lieu de DEUX) :

• SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1 : Fichier pensé pour fonctionner uniquement en mode service. Il ne peut être exécuté si et seulement si un event 4740 est levé. A voir si je fais un mode debug ou pas.

La suite se déroule en 3 répertoires distincts.

• Modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de deux dissociant la partie Windows Système et HTML.
• Log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa cave de corriger les bugs. Le fichier ne prend pas de place et est réinitialisé à chaque lancement.
• Config : Répertoire contenant le fichier de configuration powershell. Je reviendrai plus en détail sur le contenu de ce fichier dans la partie Pratique. Contrairement aux projets DreamNebula et GreenRay, je n’ai pas développé la fonction de reconstruction, régénération du fichier de configuration. Inutile car il n’y a pas de mode manuel et il n’y a pas grand-chose dans le fichier de conf…

Topographie – Logiciel

Je me passe par fénéantise la topographie du logiciel. Il n’est pas complexe du tout… Pour faire simple, cela se résume au cycle de vie suivant :

• 0 : Entrez dans le journal d’événement de sécurité d’un événement 4740.
• 1 : Déclenchement de la tâche planifiée sur l’événement. Récupération des informations liées au verrouillage du compte utilisateur, le poste source et le domaine d’application. Ces valeurs de type strings sont passés en argument du script powershell qui est exécuté SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1.
• 2 : Le script lit la configuration, puis charge les modules. Une fois les modules chargés, le corps du mail est construit et ce dernier est envoyé par mail. Naturellement et selon les options activées, le mode debug redirigeras l’ensemble des transactions powershell dans le fichier de log dans le répertoire du même nom.

Et le code ? Il est sur GitHub. Je ne souhaite pas le présenter. Toutefois, je partagerai volontiers ces derniers avec celui qui viendra m’en exprimer le souhait. Ca sera l’occasion de papoter un peu 🙂

Pratique

Configuration

Avant de lancer le script, il est nécessaire de faire un tour vers le fichier de configuration contenu dans le répertoire config à la racine du projet. Je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie et 1 sous-partie.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie concernant l’envoie de notification SMTP15, futur feature/bug (rayer la mention inutile) à venir

Avec la compréhension du fichier de configuration, je pense que nous pouvons passer à la suite, soit déployer l’application sur le serveur.

Installation

Je passe alégrement la partie gMSA il y a un certain nombre d’article sur le net (comme déjà dit dans des billets précédents) qui traite déjà du sujet. Pour le reste, j’ai comme d’habitude renforcé la sécurité et implémenté mes propres mécanismes (la preuve en est, j’ai passé deux put**n d’heures à trouver pourquoi ma tâche ne se lançait pas…).

Là où ça se corse, c’est au niveau de la tache planifiée. Si vous êtes sur un environnement possédant l’expérience utilisateur, vous êtes sauvés. En revanche, dans mon cas sur mes serveurs CORE, je l’ai mais alors bien profond dans la cucurbitacée… Voyez vous comme quoi une chose tout insignifiante soit il peut devenir un vrai casse-tête.

Mais alors qu’elle est cette petite chose insignifiante ?

The ScheduledTask

A première vue, vous vous demandez pourquoi je parle de la tache planifiée… Il s’avère que dans la version WINDOWS Core, nous ne pouvons pas créer de tache planifiée sur un déclenchement d’événement.

En réalité, nous pouvons constater également le dysfonctionnement sur un environnement WINDOWS avec expérience utilisateur. Il suffit d’utiliser la console powershell (il suffit de revenir aux bases du RTFM¹⁶).

Donc comment faire une tache planifiée, si :

• Nous n’avons pas d’interface graphique
• Les commandes powershell ne fonctionne pas
• Les moyens de contournement comme WAC¹⁷ ne fonctionne pas (normale co**ard c’est du powershell derrière)
• La console mmc.exe en remote pas plus de chance

J’ai essayé l’exécutable schtasks mais je ne suis pas arrivé à mes fins. Vous vous voulez la vérité ? J’ai lu qu’il fallait faire une fichier XML et ajouté les champs blablablabla… Je me suis dit « No Way » je vais encore me foirer dans une balise ou je vais avoir un problème d’encodage sur des caractères à la mord moi le noeud…

J’ai donc pensé à un autre moyen (tu as surtout épluché le net et les divers forum technet oui…). Pourquoi ne pas créer la tache sur mon poste avec des paramètres que je modifierai une fois importé ? Et bien ça voyez vous, ça fonctionne.

La création de la tâche ne pose pas de problème. Je joins toutefois la petite capture pour la configuration des critères de déclenchement de l’évent.

Une fois la tache créée, exportons là et ouvrons cette dernière dans un éditeur de texte.

Oh mais dit donc, ça ne serait pas ? Hé si le voilà notre fichier XML que l’on devait construire via la commande svctasks. Et dire qu’une tache planifiée ça ressemble à ça. Vous noterez que j’ai occulté deux parties. La première partie permet de récupérer les valeurs de l’événement. Il sera nécessaire de modifier manuellement le fichier XML. Mais je reviendrai plus en détails sur ce point dans la sous partie à venir (c’est ça ma frustration décennale !). La seconde partie permet de passer les variables que contiennent les valeurs récupérées ci haut en paramètre de notre script.

Bien. Maintenant importons la tâche 🙂

> $myTask = Get-Content "PATH_WHERE_XML_FILE\myTask.xml" | Out-String
> Register-ScheduledTask -XML $myTask -TaskName "PROD_EVENT_4740" -TaskPath "\_ronelab"

Récupérer les valeurs

Comme écrit plus haut, ce point va mettre fin à une frustration longue de 10 ans. Comment retourner les valeurs levées dans un event depuis l’exécution d’une tâche planifiée…

Là j’ai lu un nombre important de documentation pour comprendre comment cela fonctionne et comment mettre en œuvre la chose surtout. Toujours dans la démarche des 3S¹⁸.

Dans les approches :

• Quel est la structure, schéma du fichier XML d’une tache planifié : Lien
• Quel est la structure la plus adapté pour un eventTrigger de type complexe : Lien
• Un exemple d’implémentation : Lien

Avec la plus grande sincérité du monde, je n’avais pas il y a 10 ans de cela la maturité intellectuelle pour assimiler cette notion. Aujourd’hui je rougis de l’imbécile que je suis et de la simplicité et évidence de son mécanisme.

Maintenant que j’ai compris (mais que je n’ai pas expliqué 🙂 Il faut bien que vous vous investissiez aussi non ? Passons à la compréhension d’un événement. Il faudra sélectionner un évent 4740 et se rendre dans la vue Detail en Friendly, mais nous pouvons aussi se la jouer XML.

Nous notons deux catégories que nous pouvons déployer :

• System : Va contenir l’ensemble des balises et valeurs propres au déclenchement de la tâche avec les propriétés de l’évent. Comme dit plus tôt, l’un des attributs qui pourrait nous intéresser est le temps où l’évent a été inscrit dans le journal. Je prenais le temps de lancement du script, mais ce dernier n’est pas la bonne source de temps. Bref, il convient alors de noter le chemin de l’attribut qui nous intéresse :
  • Event/System/TimeCreated/@SystemTime

Il est important de noter que tout part de notre événement d’où le Event en début de path. Puis le chemin /System/TimeCreated/ jusqu’à la variable qui contient notre valeur spécifiée par le @ devant SystemTime

• EventData : Va contenir l’ensemble des balises et valeurs propres à l’évènement de sécurité déclenché. Ce qui nous intéresse ce sont les attributs TargetUserName qui contient le login utilisé et verrouillé, TargetDomainName qui contient le nom de poste cible où la connexion a tenté d’être initier et le SubjectDomainName qui contient le nom de domaine cible du compte verrouillé. Soit alors les les chemins suivants :
  • Event/EventData/Data/@[Name= »TargetDomainName »]
  • Event/EventData/Data/@[Name= »SubjectDomainName »]
  • Event/EventData/Data/@[Name= »TargetUserName »]

Alors comment intégrer proprement dans notre fichier XML correspondant à notre tache planifier nos 4 paths pour récupérer les valeurs ?

Normalement, nous avons eu toutes les informations ci-haut pour réaliser l’opération 🙂

Nous avons défini nos variables qui contiennent nos données. Il suffit alors de passer nos variables en arguments de notre script. Je passe une nouvelle fois mon tour. Le passage de variable en arguments d’un script powershell c’est un basique. La modification peut être réalisé en graphique dans le TaskScheduler ou directement dans le fichier XML.

Maintenant, il ne reste plus qu’à réimporter la tache de nouveau puis de réaliser un test.

Reporting

Pour le test, rien de plus facile… J’ai choisie d’initier une connexion à l’une des ressources des domaines à partir d’un compte pour lequel la FGPP est active : * RONEALB\erwan.guillemard Depuis une instance de bureau à distance, je décide de mettre en application ma plus belle couche 8 en saisissant 5 fois mon mot de passe de manière erroné. Windows m’informe que mon compte a été verrouillé à la suite de plusieurs tentatives d’authentifications infructueuses. Quelques minutes après, je reçois le mail ci-contre.

En regardant en détail, j’ai bien les informations qui m’informe que le compte erwan.guillemard a été verrouillé à la suite d’une plusieurs tentatives de connexions depuis la machine EGWKS-RDB01 le 26/09/2025 à 20:31:40 sur le domaine RONELAB.

Toutefois et si je regarde avec précision le déclenchement de la tâche, j’ai 7 minutes de retard dans le temps affiché dans mon mail et la date d’entrée dans le journal de sécurité. Ce retard s’explique par une mauvaise prise en compte de la valeur DateTime. Je pensais que la valeur Datetime du script serait définis lors du lancement du script à la détection de l’événement. Cependant, mon SI étant très ancien, la tache met une bonne dizaine de minutes (en grossissant le trait) à se lancer. Ainsi je génère un delta ce qui n’est pas super en termes de sécurité. Il faudrait donc que je récupère la valeur DateTime présente dans l’événement.

Conclusion

Je suis content d’avoir réinventé mon propre système de notification sur le verrouillage d’un compte utilisateur dans un domaine à partir de la problématique qu’avait il y a maintenant plusieurs années un ancien collègue. Ainsi, j’ai pu combler une problématique vieille de 10 ans en relation avec les événements et les taches planifiées (dans mon projet de mémoire sur la supervision Shinken).

J’ai également constaté que les modules développés dans les projets précédents m’ont fait gagner un temps monstrueux. Cela me permet donc de me dire et de m’auto-confirmer que premièrement je ne fais pas que de la merde, secondement qu’à partir de maintenant je vais prendre un chemin différent quant à l’ensemble des problématiques qui nécessite un dev en powershell.

Le plus difficile restera je le pense de toujours garder une vision claire et qui réponde au 3S.

Si je devais être efficient, je reprendrais mes bouts de code existant concernant la création de ticket dans la solution ITSM de COMBODO (ITOP) pour générer un ticket en criticité haute pour le verrouillage d’un compte. De cette manière, le centre de service ou les équipes locales (internalisées ou externalisées) pourraient être proactives quant à tous comportements succès en relation avec l’authentification et l’accès à des ressources. Ce qui pourrait alors se résumer selon notre bon vieux William Shakespear par « Le plaisir d’un travail en guérit la peine ».

J’ai encore une fois repris une idée. Je pense qu’il serait temps que je reprenne un peu de temps pour innover. Certes, comprendre et mettre en pratique les idées de mes paires et une bonne chose mais je pense qu’il est souhaitable de vivre pleinement une nouvelle fois cette satisfaction personnelle. Mon ultime rature se limitera à « Est ce que cela valait ce billet ?« .

Je vous laisse jugez de tout ça et prendre contact si vous voulez le bout de code 🙂

Le mot de la fin :

Vous êtes surqualifié pour le poste ? Que neni, j’aime les salsifis et je sens vaguement le chou. Je vous embauche et Toper Harley reste dans la boucle. Merci, j’ai les films de programmateurs.

Erwan GUILLEMARD

Sources

• ANSSI : Guide d’authentification multi facteur et mots de passe
• WINDOWS : Authentification & Identification
• WINDOWS : Evénements à surveiller
• WINDOWS : Type Complexe EventType
• WINDOWS : KERBEROS
• WINDOWS : Svctasks
• WINDOWS : New-ScheduledTask
• WINDOWS : Register-ScheduledTask
• WINDOWS : Event & Queries

1. AD : Active Directory ↩︎
2. PSSI : Politique de Sécurité des Systèmes d’Informations ↩︎
3. OSI : Open Systems Interconnection ↩︎
4. SI : Système d’Informations ↩︎
5. DNS : Domain Name Service ↩︎
6. DC : Domain Controller ↩︎
7. NTLM : NT Lan Manager ↩︎
8. TGT : Ticket Granting Ticket ↩︎
9. KDC : Key Distribution Center ↩︎
10. TGS : Ticket Granting Server ↩︎
11. GPO : Group Policy Object ↩︎
12. ANSSI : Agence Nationale de Sécurité des Systèmes Informatiques ↩︎
13. FGPP : Fine Grained Password Policy ↩︎
14. gMSA : Group Managed Service Account ↩︎
15. SMTP : Simple Mail Transfert Protocol ↩︎
16. RTFM : Read The F*cking Manual ↩︎
17. WAC : Windows Admin Center ↩︎
18. 3S : Simple, Standard, Sécurisé ↩︎

Comme dit précédemment pour GreenRay, il s’agit là d’un Readme dans un format différent du traditionnel fichier txt et du wiki.

Prérequis

Dernier point avant de taper dans le fond du sujet, le déploiement ne se fait que dans un environnement WINDOWS (Workstation ou Server) ayant au minimum la version Powershell 5 d’installer et qui prend en charge les communication TLS¹ en version 1.2 minimum.

Bien que pas j’ai automatisé un bon nombre d’installation de dépendances certaines restent tout de même à déployer manuellement. Toutefois, les outils à déployer manuellement concernent la partie exploitation de la donnée qui peuvent et doivent être dissocier de la partie serveur.

Naturellement et bien que cela coule de source, LES PRIVILEGES ADMINISTRATEURS sont nécessaire au premier usage pour l’installation des dépendances (logique non ?).

Back End

Les prérequis sont les suivants :

• Module powershell PSSQLite : Ce dernier est déployé automatiquement par l’application. Toutefois, il est possible d’installer cette dernière manuellement.
• Module powershell PowerCLI VMWare : J’ai à ce jour une version alpha du déploiement automatique du module. Toutefois ce dernier n’est pas intégré dans le projet Dream Nebula, mais dans un projet à part SS_042_VMWareInstalled-PowerCLI. Il sera donc nécessaire de déployer ce dernier manuellement.

> Get-InstalledModule | Where-Object {$_.Name -eq "PSSQLite" -or $_.Name -like "VMWare.*"}

> Find-Module -Name "VMWare.PowerCLI"
> Install-Module -Name "VMWare.PowerCLI"

Front End

Sur le serveur ou poste qui servira à exploiter les données il sera nécessaire d’installer les dépendances suivantes :

• Drivers ODBC² for SQLite3
• Microsoft PowerBI (si powerBI utilisé)
• DB³ Browser for SQLite (en option mais pratique pour débugger ou altérer des données dans les tables)

L’installation des divers composants ne représente aucun point bloquant. J’ajoute en fin de ce billet les sources pour télécharger les différents composants. Pour vraiment prendre la main de chacun le processus d’installation est disponible ci-dessous.

Configuration

Avant de lancer le script, il est nécessaire de faire un tour vers le fichier de configuration contenu dans le répertoire config à la racine du projet. Je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie et 5 sous-parties.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie dédiée à la VCSA4 permettant d’établir la connexion à l’API5. * Une sous-partie dédiée à l’export des données au format CSV, reliquat de la version 1 LEGACY * Une sous-partie concernant l’envoie de notification SMTP6, futur feature/bug (rayer la mention inutile) à venir * Une sous-partie dédiée à la base de données SQLite. Faut bien stocker les données quelques parts * Une sous-partie concernant le paramétrage du mode service en tant que tâche planifiée

Après cette longue énumération rébarbative, regardons en détail chacune des parties et sous-parties. Bandant n’est il pas ? J’avoue que je ne fais pas ch**r du tout car mes deux applications ont le même tronc, socle, base… Vous voyez quoi ? 🙂

J’ai ajouté dans la solution la possibilité d’éditer le fichier directement depuis l’interface console. Par sécurité, j’ai ajouté une fonctionnalité de régénération automatique du fichier en cas de suppression ou de corruption. Hé oui, j’en ai eu marre de me repalucher le fichier de configuration plusieurs fois à la mano…

Avec la compréhension du fichier de configuration, je pense que nous pouvons passer à la suite, soit déployer l’application sur le serveur.

Installation

Comme toujours, je dédie une disque et volume pour mon application, 5Go suffit amplement.

Les raisons sont toujours les mêmes et cela reste un point immuable de mon caractère professionnel. Il est impératif de dissocier le système d’exploitation des applications ou data pour se prémunir de toutes anomalies du système et d’un dépassement d’espace de stockage. Nous générons des logs et nous avons une base de données foutre bleu ! (Pourquoi bleu… Personne n’a jamais su m’expliquer…).

l suffit de déposer le répertoire à la racine du lecteur D:\ ou d’ailleurs puis de définir les paramètres du fichier de configuration. Et puis c’est tout. 🙂

Lancer le script SS_43_1.0.0_VMWare-PowerCLI.ps1 pour réaliser les opérations d’initialisation et vérification des dépendances. On me chuchote dans l’oreillette qu’il faut faire un clic droit Exécuter avec Powershell (en tant Administrateur).

Attention : Seule la première initialisation nécessite les droits d’administrations.

Lors de la première initialisation EN MODE MANUEL (MAIN), les credentials de connexion vous seront demandés dans le contexte de votre machine et de VOTRE session pour générer le fichier CLIXML.

Dans la première image, nous constatons la présence de 4 menu.

• [01] Edit Configuration : Permet d’ouvrir le fichier de configuration et de modifier ce dernier.
• [02] Restore Default Settings : Permet de lancer un rappel max ou le sort de magie blanche Vie Max / Vie 2 sur le fichier de configuration pour ressusciter, régénérer celui-ci face au spell UTLIMA que vous avez lancé sur ce pauvre fichier !
• [03] Reload Configuration : Permet de recharger le fichier de configuration et l’ensemble des variables de l’application.
• [04] VCSA Establish Session : Permet d’ouvrir la connexion à l’appliance VMWare à partir des éléments transmis plus tôt.

Si la connexion aboutie, vous devriez voir apparaitre ce même menu avec d’autres options complémentaires.

• [05] VCSA Close Session : Permet de terminer la session en cours.
• [06] Add VCSA Role (CSV File) : Permet de créer le rôle VMWAre avec les bonnes permissions pour l’appliance. Entre nous, je l’ai fait une fois et l’automatiser et bien… c’est chiant… C’est pourquoi, je dois revoir le fonctionnement. Aujourd’hui il est plus simple de le faire manuellement. M’enfin c’est comme ça.
• [07] Single Node Summary : Permet de faire l’inventaire et l’affichage des ressources d’une single node VMWare dans la console. Je reviendrai sur ce point plus tard. 🙂 Un peu de suspense pardi.
• [08] Cluster Node Summary : La même chose que précédemment mais pour une cluster VMWare avec plusieurs nodes 🙂
• [09] VMWare Inventory : Génère les rapports au format HTML. Je présenterai rapidement la chose, mais de mon point de vue, remplacer par les rapports PowerBI.
• [10] Send Bill Report : Envoi les données par mail pour une potentielle refacturation.

Naturellement, si le mode DEBUG est activé et que la redirection des sorties dans un fichier de log également, nous devons avoir en amont les entrées ci-dessous.

Concernant le mode Service, le fonctionnement et partiellement le même sans les fonctionnalités manuelles. En gros et pour faire simple, cela suit simplement le cycle de vie :

• Je vérifie les prérequis pour l’application
• Je m’authentifie à l’appliance
• J’exécute mes requetes
• Je récupère les données et les stocks dans la BDD
• Je me casse Whiskas

Donc normalement notre tache planifiée est là. Je passe encore une fois mon tour sur l’usage et la création du compte gMSA.

A ce stade, nous avons donc installé l’ensemble des modules (VMware et PSSQLite), déployé la tache planifiée avec le mode service, généré notre BDD et réalisé notre première extraction.

Comme pour GreenRay dans le cas de possible erreur, je rédigerai une quatrième partie KB.

Et maintenant si nous regardions le rendu ?

Exploitation des données, Reporting

Je pense aborder cette partie en 3 axes. Une vue de la console CLI, la vue HTML bien que j’hésite encore sur son sort (Vivre ou laisser mourrir ?) et pour terminer la partie Microsoft PowerBI.

Mais avant toutes choses, ayant passé un peu moins de 300 heures sur le projet, je vous fournit le modèle de liaison de données (MLD) de ma BDD lié à PBI.

Je ne suis pas satisfait de ma BDD. Il manque un élément crucial. Bien qu’implémenté dans le projet GreenRay, je ne l’ai pas fait ici. Oui, il n’y a pas de log. Ca, voyez vous c’est moche… Aussi moche que Robert HUE au congrès du MEDEF…

Après bien que ce soit SS_043, il est la première graine, la première application vis à vis de SS_034. D’où je crois cet oubli, absence, négligence ou fénéantise de ma part sur la BDD. Pardon SS_043…

CLI View

Comme vu ci-haut, j’ai voulu permettre d’un simple petit coup de powershell d’afficher la synthèse VMware d’un node. Sans pour avoir à jongler d’un onglet à l’autre dans l’interface web ESXi ou VCSA.

C’est juste du one shot. Toutefois, je ne pourrais pas montrer de vu CLI d’un cluster. Je vous garantit toutefois qu’il est fonctionnel. Néanmoins, je ne peux partager les données.

Bref, si nous appuyons sur [07] Single Node Summary nous afficherions dans notre console une synthèse de notre hote, l’usage CPU, RAM ainsi que l’ensemble de la consommation du stockage de chaque datastore. Par amusement, j’ai même refait l’association des VMNic avec les vSwitchs et les groupes de ports… (Drôle de loisir…). A la base, je voulais savoir si lors d’ajout de ressource je pouvais ou non ajouter une ressource virtuelle sans tomber dans le piège de surallocation.

La différence avec la vue cluster ? J’affiche les informations et configurations de HA et DRS. Toutefois, je dois revoir la configuration réseau. L’affichage ne prends pas en compte pour l’instant les DVS¹¹.

HTLM Report

Je partais dans l’idée, dans une entreprise de faire dans un petit serveur web un push des données pour que toutes personnes puissent consulter les données. Voilà pourquoi j’ai généré des fichiers HTML simple qui reprend les informations CLI vu plus haut en ajoutant une vue par bulle/client.

Pour cela il faudra se rendre dans le sous répertorie export :

Cela ouvrira de facto lors de l’ouverture du fichier main.html votre navigateur par défaut. L’ensemble du site est navigable (oui je me suis fait iech avec les liens hypertextes. En plus ils sont dynamiques selon les données recueillis par l’application. J’ai fait un effort !).

Nous retrouvons donc la partie infrastructure avec les informations d’inventaire du système puis selon l’infrastructure matérielle une synthèse d’une infrastructure mononode ou en cluster. Ensuite et par bulle, nous avons une synthèse dans l’état actuel des ressources consommés. Pour la suite, je serai malheureusement contraint d’anonymiser certaines données.

Attention : J’ai fait chacune des pages web à la main en mode Notepad++ et ISE. Alors s’il vous plait soyez indulgent.

Il reste encore du boulot, j’ai trouvé ça fun et rigolo à développer. M’enfin c’est juste ma spécialité (le gars modeste…). Ma spécialité c’est de réinventer la roue 🙂

PowerBI Report

Là, contrairement aux deux modèles de reporting ci-haut vise un tout autre dimension. Car là nous allons pouvoir élargir notre vision dans le temps en affichant et travaillant sur un historique des ressources.

En des mots plus simple, l’évolution sur 13 mois glissant des ressources. 🙂

Ouvrer le fichier présent dans le répertoire Report.

Une fois ouvert, changer la source de données. Sinon vous allez avoir une erreur ODBC. Naturellement les drivers ODBC pour SQLite ont été installé préalablement sinon c’est la mort assurée…

Paramétrage de la source

Depuis l’application PowerBI, Fichier > Options et paramètres > Paramètres de la source de données.

Changer la source existence

S’affiche à vous la configuration où charger les données. Il y a de forte chance que vous vous retrouviez avec l’un de mes Paths. Changer alors le chemin pour pointer vers votre BDD.

Dans la nouvelle fenêtre qui apparait, en premier lieu sélectionner en source de données SQLite3 Datasource. Modifier le chemin afin que celui soit de la forme database=<path>.

En guise de clause de réduction de ligne, choisissez LIMIT, puis confirmer la modification.

Chargement des données

Il ne reste alors qu’à charger, actualiser les données dans le rapport existant.

Normalement et il y a peu de chance que ce ne soit pas le cas, vous devriez avoir une multitude de coche vert en face de chaque table vous annonçant que les données ont été chargé avec succès.

Une fois les données actualisées, vous devriez avoir le rendu ci-dessous par défaut. Il vous faudra alors jouer avec les différents filtres et objets de contrôles sur les pages pour coller à vos données.

Rappelons nous notre problématique initiale. Je dis nous, mais au final c’est bien à moi de me rappeler ma problématique. Je pense que cette dernière est répondue avec un peu plus de fonctionnalité que prévu.

Ainsi, nous avons une visibilité totale sur l’ensemble du SI et des éléments virtuels qui le composent. Nous pouvons également donner la tendance et l’évolution dans le temps justifiant à la demande interne ou externe d’un potentiel sur ou sous facturation. Elle permet également dans l’application de la bonne licence Microsoft O365 de publier le modèle et donc de partager l’information à d’autres collaborateurs en temps réel.

Certains filtres restent toutefois à adapter selon ce que nous souhaitons afficher ou interpréter. Pour le reste, je vous laisse regarder les différents chevaux de mon carrousel ci-haut.

Comme pour l’article précédent, je pense faire une vidéo de démonstration (que je n’ai pas fait pour l’instant d’ailleurs. Non pas par fénéantise. Mais par épuisement moral. Il faut que je pense à Rosetta, à ressources humaines… Bref, je suis content de ce que j’ai rendu et accouché. Toutefois, il reste encore un peu d’ajustement. Dommage que cela ne puisse être utilisé au quotidien dans ma profession et ce pour des sujets de droit à la propriété intellectuelle.

A ce moment précis de mon second break, il se passe huit mois entre le début des première ligne de code et la fin de rédaction de cet article. Il me fallait terminer ce projet qui je le pense ne doit pas finir aux oubliettes. J’aimerai qu’il puisse à terme rendre service à d’autres SysAdmins et s’adapter à d’autres systèmes, socles de virtualisation.

Sources

• Microsoft PowerBI
• SQLite ODBC Driver
• DB Browser SQLite
• VMWare PowerCLI

1. TLS : Transport Layer Security ↩︎
2. ODBC : Open Database Connectivity ↩︎
3. DB : Database ↩︎
4. VCSA : VMware System Appliance ↩︎
5. API : Application Programming Interface ↩︎
6. SMTP : Simple Mail Transport Protocol ↩︎
7. LD : Liste Distribuée ↩︎
8. BAL : Boite aux lettres ↩︎
9. FQDN : Fully Qualified Domain Name ↩︎
10. gMSA : Group Managed Service Accounts ↩︎
11. DVS : Distributed Virtuals Switchs ↩︎

Des outils qui permettent de réaliser un suivie de la charge d’une infrastructure il en existe un certain nombre. J’ai donc ce besoin de suivre mon SI¹ et de définir de manière simple pour l’instant un planning de capacité de mon environnement VMWare qu’il soit basé sur une architecture standalone ou distribuée.

Toutefois, ce qui est emmerdant encore et toujours c’est le cout lié à ces solutions. Logique, car cela demande un certain recul et analyse et d’être flexible aux diverses solutions des éditeurs de virtualisation. Coucou VEEAMOne 🙂 Il existe aussi des solutions gratuites mais cela nécessite de manipuler ensuite les données retournées. Oui je pense à toi mon bon vieux RVTools.

De mon expérience d’administrateur système et réseau, j’ai constaté (comme je me suis fait avoir d’ailleurs) un manque crucial des équipes à tenir comptes des ressources matériels de leurs infrastructures. Que ce soient des jeunes loups qui viennent d’entrer sur le marché du travail ou de certains vieux loups charlot qui opère encore dans le milieu… C’est ainsi que les problématiques de surallocation des ressources voient le jour :

• Memory Balloning
• Storage Overprovisionned
• Storage Latency
• CPU Exhausted
• etc

Dans la grande majorité des cas, un suivi fin de l’exploitation permet d’éviter ce genre de cas de figure et dans d’autres cas de prévenir sa direction ou son client d’une évolution d’infrastructure à budgéter. L’une de mes bonnes pratiques (surtout celle que mes mentors m’ont transmises) et de prendre le SI de production et de prendre 20% de plus pour se prémunir des potentiels changements à venir et garder de l’évolutivité.

L’extraction des indicateurs de performance du SI permettra ainsi sur le plan technique de s’assurer de la charge et allocation de chacune des ressources matérielles et de définir l’allocation des ressources par services au plus bas niveau. Sur le plan financier et administratif cela permet de prévoir les investissements du SI tout comme il permet de refacturer en interne différents services. Derniers points qui peut-être marque d’espièglerie, la DSI² ou Direction peut se rendre compte des conseils et des compétences du RSI³.

Dans le contexte d’un petit fournisseur de service (je ne parle pas des OVH, AWS et autres mastodontes), il est difficile de facturer les ressources aux clients de la manière la plus juste possible sans tomber dans le cas de surfacturation ou sou facturation. Ces indicateurs permettent donc de justifier le cout et l’évolution des ressources mis à leurs dispositions sur leurs demandes.

Il est donc nécessaire de trouver une solution qui permet d’assurer un suivie de l’infrastructure sur une durée défini qui puisse être orienté MSP⁴ comme pour un client final. D’assurer une visibilité macroscopique jusqu’au plus bas niveau des ressources. Tout comme pour l’article précédent GreenRay, il est important de décorréler la partie métrique et son rendu. Le service qualité doit pouvoir exploiter et présenter les métriques dans la plus grande transparence et honnêteté qu’il soit. (Surtout c’est le boulot de la qualité de rendre sexy un truc qui de base ne l’est pas trop, sauf pour les AdminSys dans mon genre 🙂 ).

Cahier des Charges

Ok, on voit où l’on veut aller. Pensons maintenant à partir de ce qui est établi comment mettre en œuvre tout ça sans tomber dans l’éternelle piège de la dispersion et donc de ne voir aboutir ce projet. Encore une fois, mon esprit aura fait des siennes et le projet au final va comporter des fonctionnalités encore en cours de développement… Oui je suis comme ça et je ne compte pas changer dans le cadre de mes loisirs.

Nous resterons dans un premier temps sur le socle de virtualisation VMware (et ce même si BROADCOM est passé par là avec son chéquier) et les produits vSphere de base (comprendre VCSA et ESXi) et donc son API⁵. (Donnez moi le moyen de faire cela pour les socles de virtualisation PROXMOX, AHV et HyperV, JE VOUS SUIS !).

Je souhaite également utiliser la solution VEEAMOne pour bénéficier de la gestion des TAGS de manière automatique dans l’environnement VMware. L’aillant déjà déployé et configuré (cf le billet en question), autant en profité. Ce point est optionnel et nous pouvons nous passer de ce dernier. Il est tout à fait possible d’administrer les TAGS directement dans l’environnement vCenter.

Pourquoi tu parles de TAGS ?

Les TAGS ou marqueurs vont me permettre d’identifier les ressources virtuelles. Par exemple d’identifier les ressources virtuelles propres au bon fonctionnement de l’infrastructure et les ressources virtuelles propres à la production et donc au bon fonctionnement de l’organisation. Cela permet d’avoir un ratio Production/Infrastructure.

Il en va ainsi de même pour les services IaaS⁶, SaaS⁷ et pourquoi pas par environnement de service, réseau ou clients (dans le cas d’un MSP).

Les TAGs permettront d’apporter une finesse dans l’analytique.

Si nous faisons une petite synthèse, la solution doit pouvoir se connecter à l’API VCSA⁸ by VMware. De nouveau la question, quel langage utilisé ? JE TE CHOISIS ! Framework .Net avec powershell afin d’établir un mode manuel et un mode service. Certes pas esthétique mais avons-nous réellement besoin d’une interface GUI⁹ pour l’instant ? Naturellement, il est obligatoire que la solution laisse une trace de son exécution dans un fichier et ce à des fins de debug et de contrôle.

L’outil comportant un mode service, ce dernier doit être planifié de manière journalière pour traiter le point de suivi des métriques sur une durée donnée.

Les données seront stockées dans une base de données flexible et légère qui puisse être utilisé en dehors de la production et s’interfacer rapidement avec tous types de systèmes. Je propose d’utiliser SQLite3.

Concernant la partie exploitation et génération des métriques, j’ai pris parti d’utiliser PowerPI pour des raisons de praticité et de gain de temps. J’avais par le passé compiler les informations dans un fichier excel mais force est de constater que la solution n’est pas viable dans le temps en termes de gestion. L’avantage d’une BDD¹⁰ comme source de données et qu’elle reste interfaçable avec tous types de solutions (Web, Application lourde ou encore et toujours le terrible tableur Excel).

Pour la partie sécurité, nous resterons concernant la consultation des données VMware sur un compte restreint en lecture seul (pas besoin de plus et encore on peut affiner les droits de manière drastique). Quant à l’exécution de la tâche planifiée dédiée au mode service un compte gMSA¹¹ répondra à toutes les problématiques (dans le cas d’un poste joint à un domaine), sinon cela un compte local restreint. J’oubliais également que les informations d’identification seront chiffrées nativement par le SE¹² Windows dans le contexte d’exécution du poste et de la session.

En conclusion de notre liste de course, notre application utilisera :

• Connecteur API à l’Appliance VCSA VMware
  • Orienté MSP et SI finaux
  • Couvrir les architectures standalone et distribuée
  • Suivre les ressources virtualisées
  • Suivre les ressources matérielles
• Langage de développement & Fonctionnalités
  • .NET Framwork à travers Powershell (v5 ou plus)
  • Journalisation de l’exécution du code
  • Export des données en CSV et HTLM
  • Mode manuel et mode service
  • Fichier de configuration
  • Aide au déploiement
  • Visualisation en mode CLI
• SGBD
  • SQLite3
• Reporting
  • Microsoft PowerBI
• Securité
  • Si poste au domaine, création et utilisation d’un compte de service gMSA dédiéSi hors domaine, création d’un compte restreint au poste
  • Chiffrement des données d’authentification par les algorithmes natives Windows
  • Token API en lecture seule sur la VCSA

Il est temps de passer à la construction et définissions de nos différents niveaux de topographie d’architecture, applicative et logiciel.

Topographie – Infrastructure

La topographie a été pensé pour être la plus simple et standard (pour faciliter la gestion et l’évolution de l’application). J’ai fait le choix de tout embarqué dans l’application, mais il est toutefois possible de mettre en place une architecture 2 ou 3 tiers en dissociant les parties Engine, Reporting et BDD.

En d’autres termes, il est seulement nécessaire dans le cadre d’une architecture 1 tiers d’autoriser la communication des flux https/tcp entre l’appliance vCenter et notre application.

Topographie – Applicative

Depuis mon dernier gros projet, je suis désolé de vous apprendre que je ne suis toujours pas architecte applicatif. Renseignez vous, à l’agence des amants de Madame Müller, j’ai des restes !

A la racine du répertoire, nous retrouvons les deux fichiers exécutables :

• SS_43_1.0.0_VMWare-PowerCLI_Main.ps1 : Qui est le fichier d’instanciation de la solution est qui permet également de réaliser toutes les actions en mode manuel.
• SS_43_1.0.0_VMWAre-PowerCLI_Services.ps1 : Presque le même fichier que le fichier Main mais dédié au mode service avec un code adapté. Il ne peut être exécuté si et seulement si l’instanciation et initialisation à eu lieu.

La suite se déroule en 6 répertoires distincts.

• Modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de quatre dissociant la partie BDD, Windows, HTML et VMware.
• Database : Répertoire contenant la BDD qui va stocker les données. La SGBD étant sous SQLite il n’y a pas besoin de moteur SQLite. Seul le module SQLite pour powershell est nécessaire en termes de dépendance. La base de données est automatiquement générée si cette dernière n’est pas présente ou si cette dernière à un nom qui diffère du fichier de configuration. Uniquement lors de l’exécution du script en mode manuel.
• Config : Répertoire contenant le fichier de configuration powershell. Effectivement depuis des années je faisais ça directement dans le code… Je mourrai moins con ce soir comme dirait quelqu’un que je connais bien 🙂 Je reviendrai plus en détail sur la partie 2 sur le contenu de ce fichier. Afin de palier à toute suppression malencontreuse du fichier de configuration, j’ai développé une fonction pour regénérer ce dernier. Oui je suis adepte du Alt+Maj+Del et j’ai dû recommencer mon fichier. Maintenant plus de problème avec mon combo favori <3
• Report : Là où je stocke les fichiers Microsoft PowerBI. Je reviendrais sur ce point dans la partie 2.
• Log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa baignoire de corriger les bugs. Le fichier ne prend pas de place et est réinitialiser à chaque lancement.
• Export : Répertoire qui va contenir les données extraites selon les tags dans des rapports HTMLs. Les rapports ont été pensé pour être navigable et donc faciliter la consultation des rapports dans un navigateur internet. Cette fonctionnalité a été abandonnée pour l’instant car retranscrit dans PBI¹³. Mais cette fonctionnalité à le droit d’être finalisé et elle le sera. 🙂
• Import : Répertoire qui va contenir les sources CSV avec les permissions à définir le plus finement possible sur l’environnement VMware.

Il est important de noter que le script manuel et le script de service peuvent être dissocier. Ce qui se traduit dans un sens par je peux utiliser un serveur en mode type console avec l’outil manuel et garder l’automatisation sur un serveur avec uniquement le strict nécessaire.

Topographie – Logiciel

Comme toujours le code peut être optimisé, factorisé. Néanmoins, je considère cette version béta comme stable. Bien que par moment quelques ajustements restent nécessaire et quelques fonctionnalités ont besoin d’être finalisées. De plus, je pense sincèrement que d’autres cerveaux et d’autres idées permettraient de pousser plus loin certaines fonctionnalités existantes et de voir d’autres fonctionnalités naitre.

Oh ! La flemme du type qui ne veut pas se palucher un visio et montrer qu’il bosse encore à l’ancienne genre papier/crayon !

Dans son fonctionnement, nous pourrions voir le fonctionnement suivant :

• 0 : Contrôle et vérification des prérequis. Pour simplifier la chose, lecture du fichier de configuration vérification de la BDD et tout le toutim. Et dans une certaine mesure, création de la tâche planifiée
• 1 : Appel API vers l’appliance VMWare afin d’établir la connexion à l’appliance et réaliser les opérations de lecture nécessaire
• 2 : Traitement des données retournée par l’API VMWare afin de stocker ces dernières dans la SGBD, naturellement si l’option est activée l’ensemble des sorties consoles sont redirigées dans un fichier de log
• 3 : Laisser la possibilité d’exploitation des données
  • 3.1 : PS Output (cli) pour un affichage rapide des données dans la console powershell avec un affichage user friendly des performances et ressources VMWare (sinon tu as quasi la même chose dans la partie Dashboard de VMWare tu sais ?)
  • 3.2 : HTML Output pour générer une synthèse navigable par bulles et environnements virtuels
• 4 : Envoi d’une notification mail via le protocole SMTP pour informer du bon succès de la tâche.
• 5 : Possibilité d’exploitation dans Microsoft PowerBI.
  • Une fois le modèle en place de reporting (PowerBI) configuré (comprendre faire les jointures dans l’application), rafraichir les données. Modification des filtres dans un objectif d’exploitation

Comme d’accoutumé, je ne présente pas pour l’instant les différents bouts de code. Les raisons ? Toujours les mêmes. Première ça serait indigeste ici (bien que pour ça il y a GitHub), la seconde étant que je ne souhaite pas que mes travaux s’évaporent dans la nature. Et j’ajoute une troisième raison. Vous savez ce que vous pouvez « potentiellement recruter » dans votre équipe interne. (Oui, j’ai toujours en travers mon dernier entretien professionnel où je n’étais pas assez technique… Mais ce de bonne guerre #coeuraveclesmains). Je me pose toutefois la question et laisse part à la réflexion de rendre mon projet communautaire.

Sécurité

A ce moment de la rédaction, je ne vois qu’un point négatif sur l’ensemble du projet qui nécessite d’être amélioré. Ce point concerne la partie SGBD.

SGBD

Comme pour le projet GreenRay, la problématique est la même. Tout reste à faire… Bien que la BDD ne contienne pas de données sensibles pouvant nuire à la sécurité du SI cette BDD reste conforme à la législation en vigueur avec la RGPD¹⁴.

Toutefois, le choix de SQLite et de son caractère singulier cross plateforme nécessite de sécuriser son contenu et intégrité. Hors, de ce côté là, pas de chiffrement de la BDD ni de côte d’accès. Alors comme dans le projet précédent il faudrait envisager de développer d’autres plugins pour d’autres SGBDs relationnels.

Une sécurité de base, serait de paramétrer les ACLs afin que le fichier de BDD ne soit accessible que du compte de service et des comptes utilisateurs habilités à lancer l’application en manuel.

Concernant le MCD… Toujours le même dilemme…

Toujours pareil ! Boum boum dans les oreilles ! Le MCD¹⁵ a été pensé sur papier puis construit sur les bases d’un modèle existant… Partager le MCD revient à publier mon code finalement. Avec un peu d’huile de coude et de reverse engineering vous me remiserez au placard.

Pis bon, je vois venir les SysDBAs¹⁶ me dire que c’est pas MERISE nanani nanana… La structure de la BDD n’était pas d’une complexité folle, cette dernière n’était composée que de 13 tables.

VMware

Concernant VMWare, j’ai pensé à deux approches. Une approche d’authentification à travers une jonction à un domaine et à l’authentification locale.

Dans les deux cas, j’ai choisi de limiter l’accès en lecture seul. L’objectif du projet étant rappelons le de suivre et d’interpréter dans le temps l’évolution des infrastructures et non d’interagir par une méthode tierce. Ce qui renforce la sécurité. Toutefois, il sera nécessaire d’attribuer les droits manuellement bien que cela pourrait s’automatiser.

Naturellement, le couple d’authentification ne doit pas apparaitre en clair. Si je permets la saisie manuelle des credentials, dans le cadre de l’automatisation de la tâche le mot de passe doit être chiffré.

Comme d’hab (j’ai envie de dire), je préfère utiliser les fonctionnalités natives du système pour chiffrer le mot de passe avec les WAPI¹⁷ dans un fichier XML. Encore et toujours ce bon vieux CLIXML. Ainsi, l’accès à l’appliance est sécurisé et l’impact est maitrisé.

Taches Planifiées

Là, toujours le même dilemme. Le serveur ou poste qui va exécuter le script est il au domaine ou non ?

Dans le cadre d’un environnement hors domaine, il conviendra de créer un compte utilisateur dédié avec les droits nécessaire pour assurer la sécurité. Néanmoins et lors de la création de la tâche, il conviendra de préciser le mot de passe ainsi que le compte local. Ce qui n’est pas ouf en termes de MCO. Mais c’est aujourd’hui l’une des méthodes que j’affectionne si le serveur est hors domaine.

A l’inverse, si l’environnement est lié à un domaine, l’approche est différente et j’ai pour le coup changer mon fusil d’épaule (va t’il passer l’arme à gauche ?). Je suis devenu un convaincu des groupes de compte de services administrés (gMSA) dans une certaine mesure. Après réflexion sur mon infrastructure ainsi que les 43 types de scripts développés, je me suis dit qu’il n’était pas déconnant de définir un serveur de script dédiée à des tâches planifiées.

De ce fait, je n’installe pas sur tous les serveurs les RSATs¹⁸ ActiveDirectory et la rotation de mes mots de passe est périodique sans avoir à repasser, modifier les taches à chaque fois. C’est cool non ?

Il subsiste toutefois une petite pirouette si nous venions à utiliser les fonctions de chiffrement windows pour encoder et décoder une information. La création de la tâche nécessitera une configuration manuelle pour assurer le chiffrement.

Dépendances

Oui, je m’appuie sur des dépendances tierces. Il me semble important de parler de ces derniers avant toutes choses. Premièrement pour rendre à Caesar ce qui appartient à Caesar et deuxièmement pour comprendre comment le projet est construit.

• Connecteur .Net VMware – VMWare PowerCLI : Pour communiquer directement avec l’appliance VMware, il suffit d’installer et d’utiliser le plugin VMware.PowerCLI depuis le repo de base powershell (PSGallery). Ainsi, nous disposons de l’interface de commande compatible pour interagir avec les produits vSphere, vSAN, NSX, VMware Cloud on AWS etc.
• Interface .Net Powershell – SQLite : Pour communiquer avec une base de données SQLite, j’ai installé le plugin powershell PSSQLite depuis le repo officiel.
• Connecteur MS PowerBI et SQLite : Il me manquait les drivers ODBC¹⁹, j’ai donc dû télécharger et installer ces derniers afin d’assurer la connexion entre l’application PowerBI et la BDD SQLite (lien).

Et c’est tout. Rien de plus, rien de moins.

Avec toute la théorie, je pense que nous pouvons maintenant aborder la seconde partie pratique qui n’est rien d’autre que le guide d’installation et de configuration de l’application développée.

1. SI : Système d’Information ↩︎
2. DSI : Directeur des Systèmes d’Informations ↩︎
3. RSI : Responsable des Systèmes d’Informations ↩︎
4. MSP : Managed Services Provider ↩︎
5. API : Application Programing Interface ↩︎
6. IaaS : Interface as a Service ↩︎
7. SaaS : Software as a Service ↩︎
8. VCSA : VMware System Appliance ↩︎
9. GUI : Graphic User Interface ↩︎
10. BDD : Base de données ↩︎
11. gMSA : Groupe Managed Service Account ↩︎
12. SE : Système d’Exploitation ↩︎
13. PBI : Microsoft Power BI ↩︎
14. RGPD : Règlement Général sur la Protection des Données ↩︎
15. MCD : Modèle Conceptuel de Données ↩︎
16. SysDBAs : Administrateur des systèmes de base de données ↩︎
17. WAPI : Windows Application Programing Interface ↩︎
18. RSATs : Remote System Administration Tools ↩︎
19. ODBC : Open Database Connectivity ↩︎

Après 3 mois d’absence et de retrait vis à vis du dernier article, j’ai pris la décision de faire une pause. Des contextes complexes m’ont menés à devenir un homme fatigué, à deux doigts du break. Mais ne nous attardons pas sur ce point si petit soit il mais sans le négliger non plus.

Bref, en parallèle du projet précédent Green Ray, dans ma fièvre créative j’ai conçu sur la même période une autre application. J’ai toujours à l’esprit cette même pudeur de présenter mes travaux, vis à vis des solutions déjà présente sur le marché ou des regards critiques de mes pairs.

J’ai rêvé depuis des nombreuses années d’une solution qui permettrai de suivre dans le temps l’évolution d’un SI en terme de ressource dans un environnement virtualisé VMWare. Je sais encore une fois que ce rêve n’est que la prolongation de la vision de mon prédécesseur. Ce dernier avait pensé et développé un tableau de bord dans un tableur pour définir le seuil de consommation d’un environnement clustérisé VMWare et de définir la charge critique des ressources dans un fonctionnement normal et dégradé. Il avait également poussé le curseur jusqu’à dissocier les grandes familles des ressources virtuelles.

La vie d’une entreprise vous connaissez ? Ca s’en va et ca revient (ou pas…). Vous comprenez qu’il a quitté l’entreprise, emportant avec lui la solution qu’il avait développé sur son temps personnel.

Je me suis donc inspiré de ces réflexions et ai poussé plus loin le curseur jusqu’aux serveurs virtuelles, datastores etc. De ce contexte est né SS_043 ou Dream Nebula, concrétisant l’accomplissement d’un projet de 3 ans. Mon application vient répondre à la problématique.

Comment garantir le capacity planning d’un système d’information virtualisé sous VMWare dans son fonctionnement normal et dégradé dans le temps tout en garantissant une vision la plus précise de chaque type d’environnement ainsi qu’une synthèse des bulles métiers ou clients à des fins de facilitation de refacturation interne ou externe des ressources consommées.

Encore une bien vaste problématique qui pourrait faire le sujet d’une fin de cycle de cinquième année. 🙂

Les premières versions pour répondre aux attentes se basait sur les RVTools et les données qui en étaient retournées. Ainsi il m’était donc facile de marcher dans les pas de mon prédécesseurs et d’integrer et manipuler les données dans un tableau xlsxm.

XLSXM tien donc ?

Oui. Je rappel que je souhaite avoir une traçabilité dans le temps. Donc pas besoin de sortir de Saint-Cyr pour savoir que cela va se traiter par le biais de MACRO en VB. (Normalement avec juste les termes tableurs, MACRO et VB nous SACHONS que cela ne fonctionnera pas dans le temps en terme de maintient de la solution). Et bien spoiler, la première solution aura tenue un an et demi. A la fin cela ne ressemblait plus à grand chose et beaucoup d’options automatisées étaient faites manuellement.

Pourquoi ?

Il y a bien des raisons et je vais les expliquer :

• La mise à jour des composants VMWares (vSphere et vCenter) ajoute ou modifie l’ordre des colonnes. Donc il est nécessaire de réadapter l’ensemble des formules dans le tableur
• Les mises à jour du framework .NET et Windows rendent obsolètes certaines fonctionnalités au sein d’excel. Retour case développement dans les MACRO
• Certaines lignes sautent et donc cela décalent toutes les autres lignes

C’est à partir des points précédents que Dream Nebula ou SS_043 est né 🙂

Mon projet se base sur une technologie, VMWare et son usage des tags. Toutefois et à des fins d’efficience, je me base sur VEEAMOne pour l’attribution des tags VMWares. Je vous laisse si nécessaire vous référer à l’article déjà présent sur le sujet. J’insiste, l’usage de VEEAMOne est optionnel.

Avant-Propos

Attention, bis repetita en approche…

Il est important de comprendre que ce billet ne rentrera pas dans le détail technique et ce pour des raisons évidentes de savoir faire et de protection intellectuelle. Le code source est disponible sur GitHub mais ne sera pas en libre accès. Ah ouai et pourquoi donc ?

Comme j’ai pu le mentionner dans un article précédent je suis satisfait de ce que j’ai réussi à livrer et à créer. J’ai passé un bon nombre d’heure de recherche et de développement à concevoir la solution ainsi que la lecture des différentes documentations. Contrairement à d’autres projets je suis satisfait de la qualité du code produit et de l’architecture de ce dernier.

Ce qui m’amène au point, dois je commercialiser ce dernier ou le laisser à la disposition de tous ? Mon cœur peine à se décider… Je souhaite valoriser mon travail de recherche…

Bref, si votre curiosité est toujours suscitée je pense que le reste de l’article devrait être satisfaite. Dans le cas contraire, je vous laisse exécuter la combinaison Ctrl+F4.

Prérequis

• SE : Windows Server 2k19 et version ultérieures ou Windows 11
• Apps : VCSA version 7 ou plus
• Autres :
  • PowerShell version 5 et superieur
  • PowerBI (optionnel)
  • ODBC drivers (SQLite3)
  • VEEAMOne version 12 ou plus (optionnel)

Guide

• Partie 1 : Théorie
  • Définir l’expression du besoin et aborder le cahier des charges attendu. Ce qui implique l’architecture de l’application, du code. Les solutions retenues ainsi que les notions de sécurité
• Partie 2 : Pratique
  • Guide de déploiement de la solution et paramétrage de cette dernière.
  • Oups, un mot de passe ? On échange avant ? #bisous
• Partie 3 : Démonstration
  • Faire une présentation de la solution dans les différents modes qui ont été développés.

Conclusion

Le mot de la fin

Moi j’ai la lèvre humide et je sais la science, de perdre au fond d’un terminal ISE l’antique conscience. Je sèche tous les pleurs sur mes KPIs triomphants, et fais rire les DSIs du rire du DEVOps

Erwan GUILLEMARD refondu de Charles BAUDELAIRE

Sources

• VMWare – PowerCLI

A quoi bon me direz vous si je ne donne pas accès à l’outil ? Ce à quoi je répondrai et si je décide de donner accès à ce dernier ? Il y a un petit effet UNO/CONTRE UNO <3

Au-delà de l’aspect, il s’agit surtout d’établir un mode opératoire différent du bon vieux README.txt, ou du moins faire en sorte d’avoir un MO¹ qui a de la gueule.

Prérequis

Dernier point avant de taper dans le fond du sujet, le déploiement ne se fait que dans un environnement WINDOWS (Workstation ou Server) ayant au minimum la version Powershell 5 d’installer et qui prend en charge les communication TLS² en version 1.2 minimum.

Bien que pas j’ai automatisé un bon nombre d’installation de dépendances certaines restent tout de même à déployer manuellement. Toutefois, les outils à déployer manuellement concernent la partie exploitation de la donnée qui peuvent et doivent être dissocier de la partie serveur.

Naturellement et bien que cela coule de source, LES PRIVILEGES ADMINISTRATEURS sont nécessaire au premier usage pour l’installation des dépendances (logique non ?).

Back End

Les prérequis sont les suivants :

• Module powershell PSSQLite : Ce dernier est déployé automatiquement par l’application. Toutefois, il est possible d’installer cette dernière manuellement.

Vérifier la présence du module

La commande des plus classique, Get-InstalledModule pour lister les modules présents sur le système.

> Get-InstalledModule -Name PSSQLite

Installer le module

Toujours vérifier en amont la disponibilité du module dans la liste des repos et lancer l’installation. Il est possible de filtrer et d’installer une version spécifique.

> Find-Module -Name PSSQLite
> Install-Module -Name PSSQLite

Front End

Sur le serveur ou poste qui servira à exploiter les données il sera nécessaire d’installer les dépendances suivantes :

• Drivers ODBC³ for SQLite3
• Microsoft PowerBI (si powerBI utilisé)
• DB⁴ Browser for SQLite (en option mais pratique pour débugger ou altérer des données dans les tables)

L’installation des divers composants ne représente aucun point bloquant. J’ajoute en fin de ce billet les sources pour télécharger les différents composants. Pour vraiment prendre la main de chacun le processus d’installation est disponible ci-dessous.

Driver ODBC

L’un des points problématiques à mon sens se porte sur l’origine du site qui n’est pas en HTTPS. Mon expérience de jadis sur la technologie SQLite fait que j’ai dû utiliser ce site. Je n’ai jamais eu de problème.

Oui, j’ai du chercher dans les mémoires que j’avais rédigé à l’époque…

PowerBI

Pas de difficulté en soi. Il est toutefois opportun de posséder un compte Microsoft…

DB Browser for SQLite

Toujours en mode enfonçage de porte…

Configuration

Avant de lancer le script, il est nécessaire de faire un tour vers le fichier de configuration contenu dans le répertoire config à la racine du projet. Je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie et 6 sous-parties.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie dédiée à la VSPC5 permettant d’établir la connexion à l’API6. * Une sous-partie dédiée à l’export des données au format CSV, reliquat de la version 1 LEGACY * Une sous-partie concernant l’envoie de notification SMTP7, futur feature/bug (rayer la mention inutile) à venir * Une sous-partie dédiée à la base de données SQLite. Faut bien stocker les données quelques parts * Une sous-partie concernant le paramétrage du mode service en tant que tâche planifiée

Après cette longue énumération rébarbative, je pense que nous pouvons regarder en détail chacune des parties et sous-parties.

J’ai ajouté dans la solution la possibilité d’éditer le fichier directement depuis l’interface console. Par sécurité, j’ai ajouté une fonctionnalité de régénération automatique du fichier en cas de suppression ou de corruption. Hé oui, j’en ai eu marre de me repalucher le fichier de configuration plusieurs fois à la mano…

Avec la compréhension du fichier de configuration, je pense que nous pouvons passer à la suite, soit déployer l’application sur le serveur.

Installation

Dans l’idéal, j’aime à dédier un disque de 5Go pour l’application.

Pourquoi ? Encore cette traditionnelle question que nous enfant de 3 ans avons posés sans cesse à nos ainés et que nous subirons à notre tour plus tard que nous soyons ou non parent… J’en veux pour preuve séance tenante 🙂

Pour la bonne et simple raison que cela permet de dissocier de la partie système de l’application et également de se prémunir d’un dépassement de stockage comme nous avons une base de données.

Il suffit de déposer le répertoire à la racine du lecteur D:\ ou d’ailleurs puis de définir les paramètres du fichier de configuration. Et puis c’est tout. 🙂

Lancer le script SS_34_2.0.0_VEEAM-Backup-Reporting_Main.ps1 pour réaliser les opérations d’initialisation et vérification des dépendances. On me chuchote dans l’oreillette qu’il faut faire un clic droit Exécuter avec Powershell (en tant Administrateur).

Si le mode DEBUG est activé et que la redirection des sorties dans un fichier de log également, nous devons avoir en amont les entrées ci-dessous (oui il y a des améliorations Hé Nanani Hé Nanana…).

Ce qui est cool avec la partie rédaction c’est qu’à ce moment je me rends compte que je n’ai pas réalisé la mise à jour de l’interface CLI¹³… L’option pour lancer l’application se fait en appuyant sur la touche 7. Oui promis, je corrige l’interface prochainement 🙂

Là je suis honnête, il y a quelque chose que je ne comprends pas bien et je pense que cela est dû à un problème de contexte. Je m’explique.

En exécutant le code directement dans une console, ce dernier retourne le résultat attendu sur le plan applicatif mais je n’ai pas de trace de débogage. A l’inverse, si j’exécute le même code dans la console ISE14 (après avoir saisie l’option 7 du menu contextuel, j’obtiens les sorties ci-contre. Rien de méchant en soit mais bon c’est moche…

Nous avons donc lancer notre script pour la première fois, nous pouvons clôturer l’application en appuyant sur la touche 0.

Normalement et si l’ensemble des prérequis ont été réalisés, nous avons :

• Installé le module PSSQLite
• Déployé la tache planifiée avec le mode service
• Réalisé la première extraction de notre environnement VSPC et générer notre BDD

Il est possible que des erreurs remontent. Cela peut être dû à plusieurs possibilités qui nécessite un diagnostic. Toutefois, il est possible de corriger certains points. A l’avenir une Partie 4 KB serait intéressant à développer.

Bref, si la tâche planifiée branle de la cafetière vous pouvez modifier cette dernière ou bien la supprimer. Dans tous les cas et si les paramètres sont corrects dans le fichier de configuration, lors de la prochaine exécution manuelle du script la tâche sera recréée.

Il est possible lors de la connexion à la VSPC en API que le script retourne une erreur. Cette erreur est dû au certificat autosigné. Ce point est abordé dans l’article VSPC.

Exploitation des données, Reporting

Comme abordé dans la partie précédente, il est tout à fait possible de définir votre propre modèle de reporting en venant interroger la BDD SQLite.

• Excel
• Homade Web Apps
• PowerBI
• etc

Je vous jure que pour une fois, je me suis dit que j’allais me mettre au WEB pour requêter ma BDD. Puis finalement, ayant opté pour une BDD SQLite, j’ai vite constaté que mon seul petit être ne suffirait pas à tout gérer dans un temps raisonnable (plus de 400 heures sur le projet tout de même) c’est pourquoi je me suis tourné vers l’outil Microsoft PowerBI.

Je fournis un modèle déjà tout fait avec les liaisons inter-table (MLD¹⁵ si je ne dis pas de bêtise).

• En Bleu la partie dédiée à la gestion des Licences des produits VEEAM
• En Vert la partie dédiée à VEEAM Backup et Réplication
• En Orange la partie dédiée à VEEAM Backup For Microsoft O365

D’après l’un de mes proches amis dans le monde l’IT je suis un grand malade d’avoir poussé jusque-là. M’enfin, comme pour les cons, nous sommes tous le malade/con d’un autre. 🙂

Ouvrer le fichier présent dans le répertoire Report.

Une fois ouvert, changer la source de données. Sinon vous allez avoir une erreur ODBC. Naturellement les drivers ODBC pour SQLite ont été installé préalablement sinon c’est la mort assurée…

Paramétrage de la source

Depuis l’application PowerBI, Fichier > Options et paramètres > Paramètres de la source de données.

Changer la source existence

S’affiche à vous la configuration où charger les données. Il y a de forte chance que vous vous retrouviez avec l’un de mes Paths. Changer alors le chemin pour pointer vers votre BDD.

Dans la nouvelle fenêtre qui apparait, en premier lieu sélectionner en source de données SQLite3 Datasource. Modifier le chemin afin que celui soit de la forme database=<path>.

En guise de clause de réduction de ligne, choisissez LIMIT, puis confirmer la modification.

Chargement des données

Il ne reste alors qu’à charger, actualiser les données dans le rapport existant.

Normalement et il y a peu de chance que ce ne soit pas le cas, vous devriez avoir une multitude de coche vert en face de chaque table vous annonçant que les données ont été chargé avec succès.

Une fois les données actualisées, vous devriez avoir le rendu ci-dessous par défaut. Il vous faudra alors jouer avec les différents filtres et objets de contrôles sur les pages pour coller à vos données.

Si nous revenons à la problématique initiale, l’ensemble des points ont été traité. Au delà de l’aspect graphique qui permet rapidement d’avoir une visibilité de la compliance ou non des jobs de protection sur une période donnée, il sera nécessaire de jouer avec les filtres sur les pages afin de choisir :

• Le nom de l’organisation
• Le job ou l’ensemble des jobs concernés

Les graphiques ou charts pour nos amis anglophones c’est un fait. Mais je préfère cette vue.

Nous avons ainsi une visibilité mensuelle pour l’ensemble des jobs de protection pour une organisation. Comme évoqué précédemment, il est possible de jouer avec les filtres pour définir une organisation ou un job spécifique.

J’ai volontairement ajouté en parallèle les messages pour les états or Success facilitant ainsi le reporting ainsi que les actions à engager.

Concrètement, mon SI à la maison est loin des 98% de disponibilités que je me suis fixé. (Dois je envisager de former et d’embaucher mes enfants à réaliser le MCO de l’infra maison ? Une tablette de chocolat Lindt 85% /semaine exonérée de taxe ça devrait le faire 🙂 )

Dans la partie 3, je vais simplement résumer en une vidéo, la partie installation ainsi que la partie exploitation. Toutefois, je pense que cette dernière partie arrivera plus tard.

Pour le coup, il me faut un break, il me faut un kit kat. J’ai pas mal charbonné pour ne pas dire souffert pour accoucher de cet article. J’ai surestimé mes capacités et d’une fièvre créative, j’ai mené deux projets de grosse envergure qui m’ont bien fatigué. A ce moment précis, il se passe un mois et demi entre la version béta et la rédaction du billet. Mais voyez vous, je crois que je tiens quelque chose qui pourrait plaire à beaucoup de SysAdmin et je serai heureux de faire vivre cette petite application…

Sources

• Microsoft PowerBI
• SQLite ODBC Driver
• DB Browser SQLite

1. MO : Mode Opératoire ↩︎
2. TLS : Transport Layer Security ↩︎
3. ODBC : Open Database Connectivity ↩︎
4. DB : Database ↩︎
5. VSPC : VEEAM Service Provider Console ↩︎
6. API : Application Programming Interface ↩︎
7. SMTP : Simple Mail Transport Protocol ↩︎
8. URL : Uniform Resource Locator ↩︎
9. LD : Liste Distribuée ↩︎
10. BAL : Boite aux lettres ↩︎
11. FQDN : Fully Qualified Domain Name ↩︎
12. gMSA : Group Managed Service Accounts ↩︎
13. CLI : Command Line ↩︎
14. ISE : Integrated Scripting Environnement ↩︎
15. MLD : Modèle Logique des Données ↩︎