
🌐 Aussi en: English · Deutsch · Español
🖥️ Encore une étape franchie dans le projet « du homelab au mini-datacenter » : Active Directory est vivant, mon PC de bureau a juré allégeance à un domaine, et Pi-hole blanchit désormais ses requêtes DNS via un authentique Windows Server, comme s’il avait soudain une mallette et un badge d’entreprise autour du cou. C’est parti. 🎩 Dans les épisodes précédents : j’ai monté le cluster Proxmox et je l’ai déployé avec Terraform – rattrapez votre retard ici si vous l’avez manqué.🏰 Un domaine est né : muench.home.arpa
Active Directory est maintenant en production, installé sur HP1-dc01 et HP2-dc02 dans une vraie configuration multi-DC (parce qu’un seul contrôleur de domaine, ce n’est qu’un point de défaillance unique avec un nom chic). Le domaine lui-même s’appelle muench.home.arpa – un choix de nom signé ChatGPT, qui a fait remarquer à juste titre que .home.arpa est le seul TLD réservé spécialement pour « ceci ne sera jamais, au grand jamais, routé sur le vrai Internet, promis ». Aucun risque de collision accidentelle avec la vraie zone DNS publique de quelqu’un. Geek, correct et vaguement administratif à l’oreille. 10/10, je délèguerais à nouveau mes choix de noms à un LLM. 🤖 Mon PC de bureau (un Asus NUC qui fait de son mieux pour imiter un poste de travail d’entreprise) a rejoint le domaine. Un de fait, il en reste quelques-uns à faire – deux autres PC et un portable attendent leur tour pour devenir citoyens du domaine. 💻➕🕸️ La chaîne DNS à l’élégance discutable
C’est là que ça devient amusant. La chaîne de résolution DNS ressemble désormais à ceci :FritzBox (router)
│ DNS server = DC01
▼
DC01 (Windows Server, AD-integrated DNS)
│ DNS server = Pi-hole VM
▼
Pi-hole
│ upstream DNS = FritzBox
▼
FritzBox → the actual internetOui, ça revient à la FritzBox à la fin – c’est tout l’intérêt. Chaque client interroge le contrôleur de domaine, le contrôleur de domaine transmet à Pi-hole, Pi-hole fait sa magie anti-pubs et anti-traqueurs, et ce n’est qu’ensuite que quoi que ce soit atteint la FritzBox pour la vraie résolution. Résultat : le blocage des pubs au niveau DNS se fait désormais de façon transparente pour chaque machine du domaine, sans aucune configuration par client, blanchi par une infrastructure qui, accessoirement, distribue aussi des tickets Kerberos. Du blocage de pubs de niveau entreprise. Personne n’a demandé un tel degré de sur-ingénierie, et pourtant nous y voilà. 🙃🗺️ La saga du lecteur Z: continue…
J’ai aussi fait écrire un script PowerShell qui crée de manière idempotente un objet de stratégie de groupe mappant le lecteurZ: sur un partage Samba, hébergé sur une VM Linux dédiée façon NAS, pour chaque utilisateur du domaine à l’ouverture de session. GPO créé ✅, lié au domaine ✅, affiche Enabled = True dans chaque vérification RSOP que je lui ai fait subir jusqu’ici ✅. Est-ce que Z: apparaît enfin dans l’Explorateur Windows ? Non. Pas encore. 😅 C’est le genre de bug qui vous fait douter de la réplication SYSVOL, des canaux sécurisés, du DNS, des journaux d’événements et, pour finir, de votre propre santé mentale, dans cet ordre précis. Considérez ceci comme un fil ouvert : quand j’aurai enfin attrapé le gremlin responsable, il aura droit à son propre article, parce qu’à ce stade il l’a bien mérité.📦 Stockage de fichiers : une VM Samba séparée, pas le contrôleur de domaine
Petite décision d’architecture qui mérite d’être soulignée : j’aurais pu simplement utiliserDC01 lui-même comme serveur de fichiers – AD et services de fichiers partagent la même machine depuis à peu près l’aube de Windows NT. À la place, j’ai déplacé le stockage de fichiers sur sa propre VM Linux/Samba dédiée. Pourquoi ? Surtout pour la flexibilité – je préfère pouvoir redimensionner, snapshotter, reconstruire ou un jour clusteriser le stockage indépendamment de « la machine qui, accessoirement, fait tourner toute l’authentification de mon domaine ». Lier le cycle de vie de votre serveur de fichiers à celui de votre contrôleur de domaine, c’est le genre de décision qui semble parfaite… jusqu’au moment où elle ne l’est plus du tout. 🔥🗄️🧰 Le workflow du poste de travail : VS Code comme client SSH très chic
Ça mérite d’être mentionné, car cela explique une bonne partie de la logique du setup : toute la gestion côté Linux –git, Ansible, kubectl – vit sur une VM Seed dédiée, pas sur mon PC de bureau. Mon vrai poste de travail, double écran compris, n’exécute pratiquement rien en local pour tout ça : il n’y a que VS Code, connecté en SSH directement à la VM Seed, où il ouvre un dossier et un terminal. À ce stade, le bureau Windows n’est en gros qu’un émulateur de terminal très joli et très cher, avec un menu Démarrer. 😄✅ État des lieux
- Domaine AD
muench.home.arpa– en production sur deux DC - PC de bureau joint au domaine – 1 machine cliente sur 4
- Chaîne DNS avec blocage des pubs par Pi-hole via le domaine – fonctionne
- Mappage du lecteur
Z:par GPO – configuré, pas encore visible côté client (enquête en cours) - VM Samba dédiée au stockage de fichiers – décidée et en service
- Travaux restants sur les VM – la suite dans de prochains articles




