Interconnexion sécurisée de deux sites avec Active Directory

Projet en bref

Contexte

Ce projet consistait à intégrer un nouveau site géographique au système d’information d’une organisation. Les collaborateurs distants devaient bénéficier de l’annuaire et des politiques de sécurité du site central, tout en conservant un service d’authentification local adapté à un site disposant de moins de moyens d’administration.

L’infrastructure devait également faciliter l’exploitation quotidienne : création structurée des comptes, application de stratégies de groupe et copie externalisée des données importantes. Une maquette virtuelle a permis de préparer et de valider la conception avant un éventuel déploiement.

Objectifs techniques

• Étendre un domaine Active Directory à un second site ;
• assurer une authentification locale au moyen d’un RODC ;
• structurer les utilisateurs et appliquer des politiques adaptées ;
• automatiser les opérations d’administration reproductibles ;
• externaliser les données du serveur principal avec journalisation.

Architecture retenue

flowchart LR
    subgraph Central["Site central — 10.0.1.0/24"]
        DC["Contrôleur de domaine principal<br/>AD DS, DNS et données"]
        Policies["OU, groupes et GPO"]
        DC --- Policies
    end

    Tunnel["Liaison intersite sécurisée"]

    subgraph Remote["Site distant — 10.0.2.0/24"]
        RODC["Contrôleur de domaine<br/>en lecture seule"]
        Workstation["Poste utilisateur<br/>membre du domaine"]
        Workstation -->|"DNS et authentification"| RODC
    end

    Backup["Stockage externalisé<br/>Google Drive"]

    DC <-->|"Réplication AD et DNS"| Tunnel
    Tunnel <--> RODC
    DC -->|"Synchronisation rclone"| Backup

    style DC fill:#e8f4ff,stroke:#2563eb
    style RODC fill:#ecfdf5,stroke:#059669
    style Workstation fill:#f8fafc,stroke:#475569
    style Tunnel fill:#fff7ed,stroke:#ea580c
    style Backup fill:#f5f3ff,stroke:#7c3aed

Le site central héberge le contrôleur de domaine inscriptible et les données. Le site distant dispose d’un RODC : une compromission locale présente ainsi moins de risques qu’avec un contrôleur inscriptible, sous réserve d’une politique de réplication des mots de passe correctement définie.

Les sous-réseaux sont déclarés dans Active Directory afin d’associer chaque machine à son site. Le poste distant interroge son serveur local pour le DNS et l’authentification, tandis que les modifications de l’annuaire restent centralisées.

Travaux réalisés

Infrastructure Windows

• Configuration des adresses statiques et du nommage des serveurs ;
• installation d’AD DS et création d’une forêt ;
• déclaration de deux sites et de leurs sous-réseaux ;
• promotion du serveur distant en RODC ;
• mise en place d’une zone DNS secondaire ;
• intégration d’un poste Windows au domaine.

Administration de l’annuaire

• Création d’unités d’organisation correspondant aux services ;
• import de 10 comptes depuis un fichier CSV ;
• génération normalisée des identifiants ;
• création de groupes de sécurité et affectation de leurs membres ;
• préparation de restrictions horaires à partir d’un compte modèle.

Stratégies et sécurité

• Initialisation d’une GPO destinée aux restrictions sur les supports amovibles ;
• préparation du déploiement ciblé d’une application par stratégie de groupe ;
• séparation des rôles entre contrôleur principal et contrôleur en lecture seule ;
• utilisation de comptes et groupes pour limiter le périmètre d’application.

Sauvegarde et exploitation

• Initialisation et formatage d’un volume NTFS dédié ;
• synchronisation des données vers Google Drive avec rclone ;
• exclusion des données système ;
• création automatique de journaux horodatés pour faciliter le suivi.

Difficultés et choix techniques

Faire fonctionner l’annuaire à travers deux sous-réseaux

Problème — Dépendances entre routage, DNS et Active Directory

Un serveur distant peut être joignable par son adresse IP sans que la promotion, la réplication ou l’authentification du domaine fonctionne correctement.

Analyse : Active Directory dépend fortement du DNS et de nombreux flux réseau. Les deux sous-réseaux devaient être routés, le serveur distant devait résoudre le nom complet du contrôleur principal et chaque réseau devait être associé au bon site AD.

Solution et résultat : les adresses DNS ont été configurées explicitement, les sites et sous-réseaux ont été déclarés et des contrôles avec Resolve-DnsName, dcdiag et repadmin ont été intégrés à la procédure de validation.

Adapter le rôle du contrôleur au niveau de confiance du site

Problème — Héberger l’authentification sur un site moins administré

Installer un contrôleur de domaine inscriptible sur le site distant aurait augmenté l’impact potentiel d’une compromission physique.

Solution et résultat : le serveur distant a été conçu comme un RODC. Les écritures restent centralisées et le cache local des secrets peut être limité par une stratégie de réplication des mots de passe (Password Replication Policy).

Automatiser sans masquer les opérations sensibles

Problème — Trouver l’équilibre entre rapidité et contrôle

La configuration réseau, la promotion d’un contrôleur de domaine et l’application des GPO ont des effets importants et nécessitent souvent des redémarrages.

Solution et résultat : les tâches ont été séparées en scripts thématiques, exécutables dans un ordre documenté. Les étapes nécessitant une authentification élevée ou une validation manuelle restent visibles dans la procédure.

Résultats

La maquette fournit les composants nécessaires à une administration centralisée du site distant. Les scripts réduisent les opérations répétitives et rendent la configuration plus facile à relire, à démontrer et à reproduire.

Le VPN n’étant pas inclus dans la version actuelle du dépôt, la validation complète de bout en bout nécessite l’ajout préalable d’une liaison intersite routée et sécurisée.

Compétences démontrées

• Installation et administration de Windows Server ;
• conception d’un annuaire Active Directory multisite ;
• déploiement et sécurisation d’un RODC ;
• configuration de DNS dans un environnement de domaine ;
• organisation des OU, comptes et groupes de sécurité ;
• création et ciblage de stratégies de groupe ;
• automatisation de tâches d’administration avec PowerShell ;
• gestion d’adresses, de routes et de flux intersites ;
• sauvegarde externalisée et journalisation avec rclone ;
• diagnostic de la réplication, du DNS et de l’application des GPO ;
• documentation d’une procédure technique reproductible.

Retour d’expérience

Ce projet m’a permis de mesurer à quel point Active Directory repose sur la cohérence du réseau, du DNS et de la topologie des sites. La création d’un RODC n’est pas une étape isolée : elle demande une connectivité fiable, une résolution de noms correcte et une stratégie explicite de réplication des mots de passe.

Il m’a également montré qu’une automatisation utile doit rester contrôlable. Découper la configuration en étapes, produire des journaux et documenter les validations facilite le diagnostic et évite de transformer un script en boîte noire.

Avec davantage de temps, je remplacerais les secrets codés en dur par un coffre-fort, rendrais tous les scripts idempotents et ajouterais des tests automatisés de réplication, d’application des GPO et de restauration des sauvegardes.