Automatisation d’une infrastructure hybride et gestion de parc

Projet en bref

Contexte

Ce projet répondait au besoin d’une petite entreprise devant faire évoluer un parc informatique hybride composé de postes Windows et Linux. L’objectif était de disposer d’une plateforme de test capable de reproduire les principales opérations d’exploitation avant leur application à un environnement réel.

La solution devait centraliser les comptes et les autorisations, automatiser les tâches récurrentes, inventorier les équipements et faciliter le déploiement des mises à jour et des logiciels. Le laboratoire a été conçu pour rester isolé du réseau de production et pouvoir être reconstruit avec Vagrant et Ansible.

Objectifs techniques

• Déployer une infrastructure de test Windows/Linux reproductible ;
• centraliser l’authentification et appliquer des droits adaptés aux fonctions ;
• automatiser la création des comptes, groupes, partages et configurations ;
• gérer les mises à jour, les logiciels et le montage des ressources réseau ;
• consolider l’inventaire du parc dans une solution de gestion dédiée.

Architecture retenue

flowchart LR
    Host["Poste hôte<br/>Vagrant + VirtualBox"]

    subgraph Lab["Laboratoire isolé · 192.168.10.0/24"]
        Control["Serveur de gestion<br/>Ansible + GLPI"]
        DC["Contrôleur de domaine<br/>AD DS + DNS + SMB"]
        Win["Poste Windows"]
        Linux["Poste Ubuntu"]
    end

    Host -->|"Création des VM"| Control
    Host -->|"Création des VM"| DC
    Host -->|"Création des VM"| Win
    Host -->|"Création des VM"| Linux

    Control -->|"WinRM HTTPS<br/>Kerberos"| DC
    Control -->|"WinRM HTTPS"| Win
    Control -->|"SSH + GSSAPI"| Linux

    Win -->|"DNS · LDAP · Kerberos"| DC
    Linux -->|"DNS · LDAP · Kerberos"| DC
    Win -->|"SMB"| DC
    Linux -->|"SMB 3 + Kerberos"| DC

    Win -.->|"Agent d’inventaire"| Control
    Linux -.->|"Agent d’inventaire"| Control

    style Control fill:#fee2e2,stroke:#dc2626
    style DC fill:#dbeafe,stroke:#2563eb
    style Win fill:#eff6ff,stroke:#0284c7
    style Linux fill:#fff7ed,stroke:#ea580c

Le serveur Linux cumule les rôles de nœud de contrôle Ansible et de plateforme GLPI. Le contrôleur de domaine fournit l’annuaire, le DNS et cinq espaces de fichiers. Les postes clients utilisent les mêmes identités, mais conservent des mécanismes d’administration adaptés à leur système.

Travaux réalisés

Infrastructure

• Définition de quatre machines virtuelles avec Vagrant ;
• création d’un réseau privé avec adressage fixe ;
• ajout d’un disque de données dédié de 20 Go au serveur de fichiers ;
• installation automatisée du nœud de contrôle Ansible ;
• préparation d’un poste Ubuntu avec environnement graphique.

Identités et accès

• Installation d’Active Directory Domain Services et du service DNS ;
• création des unités d’organisation, de 38 comptes et des groupes de sécurité ;
• création de 9 groupes globaux et de 10 groupes locaux de domaine, avec des chaînes d’autorisation conformes au modèle AGDLP ;
• création d’un compte de service dédié à l’automatisation ;
• intégration des clients Windows et Linux au domaine ;
• configuration de SSSD et de la création automatique des répertoires personnels sous Linux.

Partages de fichiers

• Initialisation et formatage automatique du disque de données ;
• création de cinq partages correspondant à différents périmètres métier ;
• séparation des accès en lecture et en modification avec des ACL NTFS ;
• montage automatique des ressources à l’ouverture de session ;
• utilisation de Kerberos pour les montages SMB sous Linux ;
• journalisation et nettoyage des montages devenus invalides.

Automatisation et exploitation

• Organisation de 16 playbooks Ansible par phase de déploiement ;
• administration de Windows avec WinRM HTTPS et Kerberos ;
• administration de Linux avec SSH et GSSAPI ;
• installation des mises à jour critiques et de sécurité sous Windows ;
• mise à niveau des paquets et gestion des redémarrages sous Linux ;
• déploiement d’outils de vérification du contraste sur les deux systèmes.

Gestion de parc

• Intégration d’une plateforme GLPI au laboratoire ;
• préparation des agents d’inventaire Windows et Linux ;
• production de huit exports CSV couvrant les utilisateurs, groupes, ordinateurs, périphériques et équipements réseau ;
• constitution d’un référentiel exploitable pour suivre le matériel et préparer son renouvellement.

Difficultés et choix techniques

Fiabiliser Kerberos dans un environnement virtualisé

Problème — L’authentification dépend du DNS, de l’heure et du nom du service

Une connexion utilisant une adresse IP ou un nom différent du SPN attendu provoquait un échec Kerberos.

Solution et résultat : les inventaires utilisent les FQDN, le DNS du domaine est imposé aux clients, la synchronisation horaire est activée et les SPN HTTP, HOST et SSHD sont enregistrés. Les tickets peuvent ainsi être vérifiés avec kinit, klist et kvno.

Sécuriser l’administration distante de Windows

Problème — Administrer les machines sans autoriser WinRM en clair

Le nœud Ansible devait piloter le contrôleur de domaine et le poste Windows tout en limitant les méthodes d’authentification.

Solution et résultat : un listener WinRM HTTPS est créé avec un certificat autosigné, Kerberos et Negotiate sont activés, Basic est désactivé et les échanges non chiffrés sont refusés. Cette configuration convient au laboratoire, avec une autorité de certification à prévoir en production.

Adapter les partages aux deux systèmes clients

Problème — Windows et Linux ne montent pas les ressources de la même manière

Les utilisateurs devaient retrouver uniquement les espaces autorisés, avec le bon niveau d’accès, quel que soit leur poste.

Solution et résultat : un script PowerShell associe les groupes AD à des lettres de lecteur, tandis qu’un script Bash monte les partages sous /mnt avec SMB 3 et Kerberos. Les deux scripts vérifient les appartenances, corrigent les anciens montages et écrivent des journaux dédiés.

Autoriser les connexions Linux sans masquer les erreurs de GPO

Problème — Une erreur d’interprétation des GPO par SSSD pouvait bloquer les sessions

Le poste Linux devait rester accessible pendant la mise au point de l’intégration au domaine.

Solution et résultat : le contrôle GPO de SSSD a été placé en mode permissif dans le laboratoire. Les écarts restent visibles dans les journaux sans interrompre les tests de connexion.

Résultats

Le laboratoire permet de reconstruire l’infrastructure, de centraliser les identités et de rejouer les opérations d’administration. Les tâches répétitives sont décrites sous forme de code, ce qui facilite leur contrôle et leur reproduction.

Compétences démontrées

• Administration de Windows Server et d’Ubuntu ;
• déploiement d’Active Directory Domain Services et de DNS ;
• automatisation d’infrastructure avec Vagrant et Ansible ;
• administration distante avec WinRM, SSH et Kerberos ;
• intégration de clients Windows et Linux à un domaine ;
• conception de groupes et d’autorisations selon le modèle AGDLP ;
• configuration de partages SMB et d’ACL NTFS ;
• scripting PowerShell et Bash ;
• gestion des mises à jour et des redémarrages ;
• déploiement automatisé de logiciels ;
• inventaire et gestion de parc avec GLPI ;
• diagnostic de problèmes DNS, Kerberos, SPN et SSSD ;
• rédaction de procédures techniques.

Retour d’expérience

Ce projet m’a permis de mesurer à quel point Active Directory, DNS et Kerberos sont interdépendants. Une automatisation correcte ne suffit pas si la résolution de noms, les SPN ou la synchronisation horaire ne sont pas cohérents sur l’ensemble des machines.

Il m’a également appris à traiter un même besoin avec des mécanismes propres à chaque système. Le montage de partages illustre cette différence : PowerShell s’appuie sur le contexte utilisateur Windows, tandis que Linux combine SSSD, tickets Kerberos et montage CIFS.

Pour aller plus loin, je rendrais le provisionnement Vagrant entièrement portable, remplacerais les certificats autosignés par une autorité interne, passerais le contrôle GPO Linux en mode strict après validation et ajouterais des tests automatisés ainsi qu’une intégration continue.