Infrastructure virtualisée : hyperviseur Proxmox, Active Directory et serveur de fichiers

Le contexte

Je voulais disposer d'un environnement représentatif d'un système d'information de PME, sur lequel je puisse installer, casser, diagnostiquer et reconstruire sans dépendre de personne. Un lab d'entraînement, mais construit avec les exigences de la production : nommage cohérent, adressage maîtrisé, droits d'accès justifiables, et chaque choix technique défendable en une phrase.

L'ensemble tourne sur une machine unique — un mini-PC GMKtec M5 Ultra, Ryzen 7, 32 Go de RAM — qui héberge une dizaine de machines virtuelles.

L'objectif

Monter de zéro une infrastructure Windows complète et centralisée :

• un hyperviseur capable de porter durablement l'ensemble des services ;
• un annuaire unique gérant l'authentification, la résolution de noms et la configuration des postes ;
• un serveur de fichiers dont les droits reposent sur un modèle documenté plutôt que sur des permissions posées au cas par cas.

L'architecture

Le réseau est resté plat (192.168.1.0/24), avec un bloc .200 – .219 réservé au lab et retiré de la plage DHCP de la box — le lab devait cohabiter avec un réseau domestique actif, sans conflit d'adresse et sans dépendre de la box pour les services critiques. Le plan d'adressage complet et son articulation avec la box opérateur font l'objet d'une page dédiée.

Adresse	Machine	Rôle
192.168.1.200	pve	Hyperviseur Proxmox VE
192.168.1.201	SRV-AD-01	Contrôleur de domaine, DNS, GPO
192.168.1.202	PC-CLIENT-01	Poste client Windows 11
192.168.1.203	PC-CLIENT-02	Poste client Windows 11
192.168.1.206	SRV-FICHIER-01	Serveur de fichiers, FSRM

Une convention simple structure l'ensemble : l'identifiant de la VM correspond au dernier octet de son adresse IP. La VM 106 porte le .206. Sur une infrastructure d'une dizaine de machines, cette règle supprime toute ambiguïté lors des interventions.

Chaque VM est créée sur un socle homogène — machine q35, firmware UEFI OVMF, contrôleur VirtIO SCSI single, agent QEMU, type de processeur host — de façon à ce que les comportements soient reproductibles d'une machine à l'autre.

Ce que j'ai réalisé

L'hyperviseur

Installation de Proxmox VE 9, bascule sur les dépôts sans souscription, organisation du stockage entre un SSD de 240 Go pour le système et les images ISO, et un NVMe de 1 To en LVM-thin pour les disques des machines virtuelles. Le provisionnement fin permet d'allouer plus d'espace que le disque n'en contient réellement, les disques ne consommant que ce qu'ils utilisent — utile sur un lab où l'on crée et détruit des machines en permanence.

Le contrôleur de domaine

Avant toute promotion, le serveur a été durci : renommage du compte Administrateur d'origine, création d'un compte d'administration nominatif, politique de mot de passe à 14 caractères avec historique et verrouillage après cinq échecs, authentification NTLMv2 uniquement, signature SMB et bannière légale de connexion.

La forêt lab.julien.local a ensuite été créée en niveau fonctionnel Windows Server 2016, avec une structure d'unités d'organisation volontairement minimale — Utilisateurs et Ordinateur — et l'application de redircmp pour que tout nouveau poste joint au domaine atterrisse directement dans la bonne UO au lieu du conteneur Computers par défaut, sur lequel aucune stratégie de groupe ne peut être liée.

Les stratégies de groupe

Quatre GPO couvrant des besoins distincts :

• GPO-Fond-Ecran — fond d'écran d'entreprise distribué via le partage NETLOGON ;
• GPO-RDP-AutoAcces — ajout d'un groupe de sécurité au groupe local Bureau à distance, par les préférences de stratégie de groupe côté ordinateur ;
• GPO-Zabbix-Agent — script de démarrage installant l'agent de supervision, accompagné d'une règle de pare-feu ouvrant le port 10050 à la seule adresse du serveur de supervision ;
• GPO-Lecteurs-Reseau — connexion automatique d'un lecteur P: commun à tous, et d'un lecteur S: de service dont l'affectation repose sur un ciblage au niveau de l'élément selon le groupe de sécurité de l'utilisateur. Une seule stratégie sert ainsi trois services différents.

Le serveur de fichiers et le modèle AGDLP

C'est la partie qui m'a demandé le plus de rigueur. Le serveur dispose de deux disques distincts — système et données — et porte les rôles Serveur de fichiers et Gestionnaire de ressources (FSRM), sans aucun sous-composant superflu : moins de services installés, moins de surface exposée.

L'arborescence sépare les partages métier (Direction, Comptabilite, Technique, Commun) des répertoires techniques destinés aux profils et à la redirection de dossiers.

Les droits suivent strictement le modèle AGDLP : un utilisateur est membre d'un groupe global correspondant à son service, ce groupe global est membre d'un groupe de domaine local portant un niveau d'accès sur une ressource, et c'est ce dernier — et lui seul — qui apparaît dans les ACL NTFS.

Pourquoi ce modèle ? Parce que l'appartenance d'une personne et le droit sur une ressource sont deux informations différentes. Quand un collaborateur change de service, on modifie une seule appartenance de groupe : aucun droit n'est touché sur le serveur de fichiers.

Une exception documentée : les utilisateurs du domaine sont imbriqués directement dans le groupe local du partage commun, plutôt que de créer un groupe global redondant qui aurait dupliqué un groupe existant sans rien apporter.

Côté NTFS, l'héritage a été converti avant d'être rompu — ce qui préserve les entrées existantes et évite de repartir d'une ACL vide —, le groupe local Utilisateurs a été retiré, et un droit de traversée seule a été posé à la racine pour permettre l'accès aux sous-dossiers sans exposer leur contenu. Les quatre partages SMB ont l'énumération basée sur l'accès activée : un utilisateur ne voit pas les dossiers auxquels il n'a pas droit, ce qui évite les demandes d'accès à des ressources qui ne le concernent pas.

L'isolation a été validée dans les deux sens avec trois comptes de test appartenant à trois services distincts.

L'automatisation

Un script PowerShell idempotent crée les comptes utilisateurs en masse à partir d'un fichier CSV : lecture du référentiel, création des comptes dans la bonne UO, affectation aux groupes globaux correspondants, journalisation horodatée de chaque opération et gestion des erreurs. Relancé deux fois, il ne produit aucun doublon et signale simplement les comptes déjà présents.

Deux incidents diagnostiqués

Une horloge en roue libre. Le contrôleur de domaine s'annonçait en strate 1 tout en fonctionnant sur son horloge interne, sans aucune source de synchronisation en amont. Il diffusait donc une heure fausse à l'ensemble du domaine avec l'autorité maximale, et les clients Linux la rejetaient. Correction par reconfiguration du service de temps vers un pool NTP public, avec le drapeau de synchronisation manuelle et le marqueur de source fiable.

Une zone DNS inverse absente. La résolution directe fonctionnait, la résolution inverse non — la zone 1.168.192.in-addr.arpa n'avait jamais été créée. Sans elle, un outil de supervision ou de diagnostic qui interroge une adresse IP pour obtenir un nom ne renvoie rien.

Ces deux incidents ont un point commun qui vaut d'être souligné : ni l'un ni l'autre ne provoque d'erreur visible. Ils se manifestent plus tard, ailleurs, sous une forme qui ne pointe pas vers leur cause.

Le résultat

Une infrastructure Windows opérationnelle et documentée : un domaine avec ses stratégies, un serveur de fichiers dont chaque droit est justifiable en remontant la chaîne AGDLP, et un socle sur lequel se sont greffés ensuite la supervision, la sauvegarde et le déploiement de postes.

Ce que j'en retiens

Le modèle AGDLP paraît lourd sur trois services ; il devient évident à trente. Le construire correctement une fois, sur une maquette, c'est comprendre pourquoi on ne pose jamais un droit directement sur un compte.

Et surtout : une infrastructure qui fonctionne n'est pas nécessairement une infrastructure saine. Les deux incidents ci-dessus tournaient depuis des semaines sans rien casser de visible.