⚠️ Disclaimer
La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.
Introduction
J’ai construit une infrastructure IT fonctionnelle pour une entreprise fictive appelée Vertex Studio, un studio de développement de jeux vidéo. Ce projet m’a demandé de concevoir et déployer un environnement complet avec Active Directory, GLPI pour la gestion de parc, et Ansible pour l’automatisation. Je vais te partager comment j’ai abordé les défis techniques, notamment les pièges de l’authentification Kerberos, et ce que j’en ai tiré sur le plan professionnel.
Contexte : de la théorie à la pratique
Vertex Studio simule une entreprise réelle avec 40+ collaborateurs répartis en plusieurs départements : Direction, Développement, Graphisme, Audio, Testing, et IT. Le scénario pédagogique m’a confié la responsabilité de concevoir une infrastructure qui répond à leurs besoins tout en respectant les bonnes pratiques de sécurité. À l’issue du projet, j’aurais dû pouvoir la présenter devant un jury technique et défendre mes choix.
Les objectifs étaient clairs : maîtriser l’administration d’environnements d’entreprise, comprendre les mécanismes d’authentification distribués, notamment Kerberos, et automatiser les tâches répétitives plutôt que de les gérer manuellement. Sur le plan portfolio, il s’agissait de démontrer ma capacité à gérer un projet IT de A à Z.
Tout cela s’est déroulé sur mon infrastructure Proxmox personnelle (3 mini-PC avec 96 Go de RAM). J’ai créé 4 machines virtuelles dédiées : un contrôleur de domaine Windows Server 2022, un serveur Debian pour GLPI et Ansible, et deux clients pour les tests d’intégration.
Architecture : trois piliers, une vision
L’infrastructure repose sur trois piliers. D’abord, Active Directory pour la gestion centralisée des utilisateurs, groupes et stratégies de groupe. Ensuite, GLPI : un logiciel open-source pour l’inventaire et la gestion du parc matériel et logiciel. Enfin, Ansible pour automatiser les configurations et les déploiements sur tous les postes de travail.
J’ai choisi Windows Server 2022 pour AD, DNS et DHCP, qui constituent le standard industriel avec une documentation abondante. GLPI offrait une synchronisation LDAP native avec Active Directory, ce qui facilitait l’intégration. Pour l’automatisation, j’ai préféré Ansible à PowerShell DSC. La syntaxe YAML d’Ansible me semblait plus accessible, et surtout, Ansible permet de gérer Windows et Linux dans un même outil, une compétence très demandée en entreprise.
J’ai appliqué la méthodologie AGDLP (Accounts, Global groups, Domain Local groups, Permissions), qui sépare clairement « qui sont les utilisateurs » de « à quoi ont-ils accès ». Les comptes utilisateurs sont organisés par département, les groupes globaux représentent les rôles métier, et les groupes locaux de domaine contrôlent l’accès aux ressources. Cette hiérarchie permet de scaler sans devenir fou.
Mise en place : étape par étape
Active Directory et l’infrastructure réseau
J’ai commencé par installer Windows Server 2022 sur Proxmox et le promouvoir en contrôleur de domaine. J’ai créé le domaine vertex.local avec les rôles AD DS, DNS et DHCP.
La structure organisationnelle a suivi les départements. J’ai créé les OUs (Organizational Units) correspondantes, généré 40+ comptes utilisateurs via PowerShell, puis configuré les stratégies de groupe pour les bases de sécurité. Assez basique, mais efficace.
Le premier piège que j’ai rencontré concerne les délais de réplication AD. Lors des tests, certains changements mettaient du temps à se propager. J’ai appris à forcer la réplication avec repadmin /syncall pour accélérer le cycle de développement.
GLPI et synchronisation LDAP
J’ai installé GLPI sur Debian avec Apache, MariaDB et PHP. L’objectif était d’avoir un inventaire automatisé du parc matériel et logiciel, centralisé et à jour.
La partie critique a été la configuration de l’authentification LDAP dans GLPI. Une fois en place, les utilisateurs importés automatiquement depuis Active Directory pouvaient se connecter directement, un seul compte AD pour toutes les ressources. C’est un gros gain en maintenance.
La difficulté ici venait des permissions sur les OUs. GLPI ne voyait pas certains utilisateurs parce que le compte de service que j’avais créé ne disposait pas des permissions de lecture suffisantes sur l’annuaire. J’ai dû affiner les permissions LDAP dans AD pour que le compte de service puisse parcourir l’arborescence correctement.
Ansible et les playbooks
C’est la partie la plus technique et la plus gratifiante. J’ai créé plusieurs playbooks pour automatiser le montage des partages réseau, le déploiement d’outils d’accessibilité, et la gestion des mises à jour.
Le montage automatique des partages réseau semblait simple en théorie. Chaque département reçoit son propre lecteur réseau (P: pour les Projets, D: pour le Département, etc.). Mais en pratique, cela a mené droit aux problèmes d’authentification Kerberos : la plus grosse difficulté du projet.
L’authentification Kerberos : le combat
J’ai passé énormément de temps sur ce problème. Le montage automatique des partages nécessitait que les clients établissent une authentification Kerberos avec Active Directory. Voici ce qui s’est mal passé.
D’abord, j’ai reçu une erreur récurrente : « Server not found in Kerberos database ». Cela signifiait que le SPN (Service Principal Name) n’était pas correctement enregistré dans AD. Les SPNs sont des identifiants qui permettent à Kerberos d’associer un service à un compte AD. J’ai dû les enregistrer manuellement avec setspn.
Ensuite, les tickets Kerberos expiraient. Les clients perdaient leur authentification après quelques heures, ce qui cassait les montages réseau. J’ai dû configurer le renouvellement automatique des tickets via kinit et cron.
Mais le vrai piège que j’ai commis était d’exécuter les scripts de montage en contexte SYSTEM (via une tâche planifiée Windows standard). Le contexte SYSTEM n’a pas d’identité de domaine, il ne peut pas passer le ticket Kerberos. Les montages échouaient silencieusement. J’ai dû configurer la tâche planifiée avec le type de connexion interactive_token pour que les scripts s’exécutent en tant qu’utilisateur réel.
La solution finale a combiné plusieurs éléments. Les tâches planifiées tournent maintenant en interactive_token logon type. Les scripts PowerShell vérifient d’abord l’appartenance de l’utilisateur aux groupes AD avant de monter les lecteurs. Ils gèrent aussi les conflits de lettres de lecteur (si quelqu’un branche une clé USB). Et j’ai ajouté des logs détaillés pour faciliter le debugging en production.
Intégration dans le homelab
Ce projet s’est intégré naturellement dans mon infrastructure Proxmox existante. J’ai pu tester la cohabitation avec mon pfSense et mon NAS Synology. Pour l’instant, tout est sur le même réseau, mais je prévois une segmentation VLAN, DMZ pour GLPI, VLAN de management, VLAN utilisateurs. Les VMs critiques (AD, GLPI) sont sauvegardées quotidiennement sur le NAS.
Résultat opérationnel
À la fin, j’avais une infrastructure fonctionnelle permettant la gestion centralisée de 40+ utilisateurs, un inventaire automatisé du parc, et un déploiement automatisé d’outils et de patchs. Concrètement :
- 6 départements structurés dans AD avec leurs OUs et groupes
- 3 playbooks Ansible opérationnels (montage réseau, accessibilité, patch management)
- 100% d’automatisation sur les tâches récurrentes
Les cas d’usage réels décrivent bien ce qu’une infrastructure peut faire. Un nouveau développeur arrive, son compte AD est créé, il reçoit automatiquement accès au partage Développement et aux outils requis. Une mise à jour de sécurité critique sort, elle se déploie en une seule commande Ansible sur tout le parc. Un poste tombe en panne, GLPI permet d’identifier rapidement le matériel de remplacement disponible.
Ce qu’il faut retenir
Sur le plan technique, j’ai découvert que Active Directory n’est pas juste une base d’utilisateurs. C’est un écosystème complexe avec DNS, Kerberos, réplication, stratégies de groupe. Comprendre les SPNs, les tickets Kerberos et leur cycle de vie m’a forcé à monter en compétences réelles, pas juste de surface.
L’importance du contexte d’exécution m’a frappé fort. Une tâche planifiée en SYSTEM ne peut pas accéder aux ressources réseau authentifiées. Ça semble évident une fois qu’on le sait, mais ça m’a coûté plusieurs heures de débogage avant de saisir l’évidence. J’ai aussi découvert la puissance d’Ansible sur Windows, WinRM, les modules Windows spécifiques, et surtout l’idempotence qui permet de relancer un playbook 10 fois sans casser l’état.
Le principe AGDLP n’est pas qu’une best practice théorique. C’est ce qui permet de rester sain d’esprit quand on gère 50+ utilisateurs et 10+ ressources partagées.
Sur le plan méthodologique, documenter au fur et à mesure a changé la donne. J’ai pris des notes Obsidian après chaque étape clé. Quand j’ai dû préparer la présentation technique, tout était déjà structuré. À l’opposé, utiliser Claude pour comprendre Kerberos m’a confronté à une certaine culpabilité, douter de ma légitimité en utilisant un assistant IA pour mon apprentissage. Mais en expliquant à l’oral ce que j’avais assimilé, j’ai vraiment intégré les concepts. L’IA a juste accéléré le chemin.
Tester petit et souvent plutôt que de déployer un énorme playbook d’un coup m’a sauvé d’innombrables rollbacks. Et ne pas ignorer les logs, j’ai découvert Event Viewer Windows très tard, alors que les messages d’erreur Kerberos y sont ultra-détaillés.
Les erreurs à éviter : copier-coller des scripts sans les comprendre jusqu’au bout, négliger les tests sur un utilisateur avant de scaler à 40+, et croire que les tests unitaires ne sont pas importants pour du code d’automatisation.
Pour aller plus loin
Les scripts et la documentation complète sont sur GitHub. Si tu fais un projet similaire, n’hésite pas à creuser la documentation Microsoft sur Active Directory, les guides Ansible pour Windows, et les ressources du MIT sur Kerberos.