ASRS Projet 5 : Déploiement d'une infrastructure Active Directory multi-sites

⚠️ 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.

Contexte et objectifs

Une mission pour une banque qui s’étendait. Lyon en tant que siège, Marseille comme nouveau site distant. Active Directory pour gérer tout ça de manière centralisée.

Ce qui était attendu : un tunnel VPN sécurisé entre les deux sites, un contrôleur de domaine en lecture seule à Marseille (RODC), et que les utilisateurs puissent se connecter même si le VPN tombait en panne. Des politiques de sécurité via les Group Policy Objects. Et bien sûr, respecter RGPD, PCI-DSS et l’ACPR qui surveille le secteur bancaire.

Contraintes matérielles : Proxmox avec du VXLAN pour la virtualisation, Windows Server 2019 (Desktop au siège, Core à distance), chiffrement AES-256 minimum sur le VPN, moindre privilège partout.

Architecture

Pourquoi Windows Server Core à Marseille et pas Desktop ? Surface d’attaque réduite. Pas d’interface graphique, moins de services, moins de possibilités pour quelqu’un qui aurait mal intentionné. Et puis ça consomme moins de RAM, moins de patchs à appliquer.

Phase 1 : le tunnel VPN IPsec

Le VPN site-à-site en IPsec IKEv2 était la base de tout. Site-à-site plutôt que client-serveur, car il fallait que les utilisateurs à Marseille accèdent à Active Directory de façon transparente, sans même savoir qu’il y a un tunnel, le trafic passe automatiquement par pfSense.

Et puis Active Directory, c’est compliqué. Kerberos, LDAP, DNS, SMB, RPC, tous ces protocoles ont besoin d’une vraie connexion réseau bidirectionnelle. Un VPN SSL basique n’aurait pas suffi. IPsec opère à la couche 3 (réseau), donc il chiffre tout le trafic IP, pas juste les requêtes web.

La configuration IPsec en deux phases. Phase 1 (IKE) établit un canal de négociation sécurisé. J’ai choisi IKEv2 plutôt que IKEv1 parce que c’est plus efficace (4 messages au lieu de 6), et ça résiste mieux aux attaques DoS. Pre-Shared Key pour l’authentification (idéalement des certificats PKI en production, mais PSK c’était plus simple). Chiffrement : AES-256-CBC, intégrité avec SHA-256, Diffie-Hellman Group 14 (2048 bits).

Phase 2 (ESP) protège les données réelles. Mode tunnel qui encapsule complètement les paquets IP originaux. AES-256-CBC aussi. Et Perfect Forward Secrecy, les clés se régénèrent toutes les heures, donc même si quelqu’un casse une clé, il ne peut pas déchiffrer les vieilles sessions.

Dead Peer Detection détecte une panne en 50 secondes max via des keepalive réguliers. Si le tunnel s’effondre, pfSense le remonte automatiquement sans intervention. Et si Internet revient après une coupure, le tunnel se rétablit seul, la réplication AD reprend toute seule.

Tests de validation :

1
2
3
4
5
6

# Connectivité de base
ping 172.16.20.2

# Compteurs IPsec — Bytes-In/Out doivent augmenter
# Test de latence
traceroute 172.16.20.2

Résultats : latence due au chiffrement moins de 3 ms, zéro perte de paquets sur 1000 ICMP.

Phase 2 : RODC à Marseille

Un contrôleur de domaine en lecture seule plutôt qu’un DC classique. Trois raisons. Sécurité : en lecture seule, le RODC ne peut pas faire remonter de modifications malveillantes vers le reste du domaine. Si Marseille se fait compromettre, le dégât reste localisé. Continuité : le RODC met en cache les identifiants d’authentification localement, donc même sans VPN, les utilisateurs de Marseille peuvent se connecter. Conformité : les banques ne font pas confiance à un site distant avec un DC en écriture, audit et traçabilité.

Réplication unidirectionnelle : Lyon vers Marseille, pas l’inverse. Les partitions répliquées : Schema, Configuration, Domain, ApplicationPartitions. Par défaut toutes les 15 minutes. RPC over IP via le tunnel VPN sur les ports 135 et dynamiques. Les objets AD (utilisateurs, ordinateurs, GPO) arrivent en lecture seule. Le RODC ne peut jamais initier de modifications lui-même.

Ensuite, la Password Replication Policy, quel contrôle des mots de passe peut être stocké localement sur le RODC ? Par défaut, zéro. Aucun mot de passe. Faut explicitement les autoriser :

1
2

Add-ADDomainControllerPasswordReplicationPolicy -Identity "RODC-NANTES" `
    -AllowedList "GG-Utilisateurs-Marseille"

Une fois autorisés, les mots de passe se mettent en cache à la première authentification réussie avec VPN actif. Les fois suivantes, c’est le cache local qui répond, même sans VPN.

Les Sites AD, c’est crucial pour l’optimisation. Les clients doivent savoir d’utiliser le RODC local plutôt que de traverser le VPN à chaque connexion :

1
2

New-ADReplicationSite -Name "Site-Marseille"
New-ADReplicationSubnet -Name "172.16.20.0/24" -Site "Site-Marseille"

Une fois ça configuré, les clients du réseau 172.16.20.0/24 découvrent automatiquement leur DC local via les enregistrements DNS SRV. Pas besoin de traverser le VPN à chaque fois.

Test critique : authentification hors ligne. D’abord un utilisateur Marseille se connecte avec VPN actif (mise en cache du mot de passe). Puis j’ai tué le tunnel IPsec. L’utilisateur a tenté de se reconnecter. Résultat : succès, authentification locale sur le RODC, sans accès au DC Lyon. La variable LOGONSERVER pointait bien sur RODC-NANTES.

Ensuite j’ai essayé avec un utilisateur Lyon. Échec attendu, son mot de passe n’est pas dans la PRP du RODC.

Phase 3 : Group Policy Objects

Restriction horaire pour les utilisateurs. Les gens ne peuvent se connecter qu’entre 8h et 18h du lundi au vendredi. C’est du Logon Hours dans les propriétés AD, appliqué via PowerShell sur tous les comptes. C’est une exigence ACPR, limiter la fenêtre où un attaquant pourrait exploiter une session ouberte.

Blocage des clés USB. Computer Configuration → Policies → Administrative Templates → System → Removable Storage Access → Deny all access.

Un piège : cette GPO s’applique en Computer Configuration, pas User. J’avais d’abord mis que des groupes d’utilisateurs dans le Security Filtering. Résultat : rien ne se passait. Faut que les objets Computer soient dans le filtrage pour que ça marche.

Déploiement logiciel via GPO : f.lux pour un utilisateur spécifique (Ana Garcia). User Configuration, Item-Level Targeting filtrée sur son SamAccountName, MSI dans un partage réseau. L’outil s’installe automatiquement à sa connexion. Ça montre la granularité qu’on peut avoir avec les GPO, une personne, un logiciel, sans toucher aux autres.

Les détours

MTU avec VXLAN. Perte de paquets aléatoire, timeouts sur les gros fichiers. VXLAN ajoute 50 octets d’overhead, IPsec en ajoute ~70, et l’Ethernet standard c’est 1500. Les paquets se retrouvaient fragmentés. J’ai réduit le MTU à 1400 sur les interfaces VM, les tunnels IPsec (MSS clamping à 1360), et la configuration VXLAN dans Proxmox. Problème réglé.

Promotion du RODC : erreur “Impossible de contacter le contrôleur de domaine”. DNS cassée. Le serveur Marseille ne résolvait pas le DC Lyon. J’ai mis le DNS primaire du RODC vers 172.16.10.2 (le DC Lyon) et vérifié les enregistrements SRV avec nslookup -type=SRV _ldap._tcp.dc._msdcs.company.local.

Et puis la GPO de blocage USB ne s’appliquait pas. J’avais mis que des groupes d’utilisateurs dans le Security Filtering. Faut les objets Computer. J’ai ajouté “Domain Computers” ou créé un groupe “GG-Ordinateurs-Marseille”.

Sécurité

Comptes utilisateurs en “Domain Users” seulement, pas d’admin. Les comptes privilegiés sont séparés et restrictifs.

Le RODC n’a aucun rôle FSMO (Flexible Single Master Operations). Tous les rôles FSMO restent à Lyon. Ça centralise le contrôle.

Journalisation avancée : événements d’authentification (ID 4624, 4625, 4776), modifications de GPO (ID 5136, 5137), réplication AD. Les logs remontent à un SIEM pour analyse.

Communications au-delà du VPN : Kerberos pour l’authentification chiffrée, LDAPS pour chiffrer les requêtes LDAP, SMB Signing pour les signatures, empêche le relay.

Concepts derrière tout ça

Multi-master vs single-master. Normalement tous les DC AD acceptent les modifications, se répliquent mutuellement. Risqué si le site distant est mal sécurisé. Le RODC change ça : seul Lyon peut écrire, Marseille ne lit que.

Réplication intra-site vs inter-site. Intra-site c’est immédiat et fréquent (notification de changement tout de suite). Inter-site c’est programmé (15 minutes par défaut) et compressé pour épargner la bande. Le Knowledge Consistency Checker calcule automatiquement la topologie de réplication et génère les connections nécessaires.

DNS et SRV records. Active Directory dépend du DNS. Chaque DC enregistre des trucs comme _ldap._tcp.Site-Marseille._sites.dc._msdcs.company.local → RODC-NANTES.company.local pour que les clients de Marseille découvrent leur DC local.

Tombstone Lifetime. Si le VPN reste down plus longtemps que la Tombstone Lifetime (180 jours par défaut), les objets supprimés à Lyon ne vont pas remonter à Marseille. C’est pour ça que même avec un RODC, faut un VPN stable.

À faire plus tard

Haute disponibilité du VPN : un second tunnel de backup sur une autre connexion Internet, basculement auto via BGP ou SD-WAN. Monitoring : Nagios ou Zabbix pour alerter sur l’état du tunnel, la réplication AD, les événements de sécurité. Certificats PKI pour remplacer la Pre-Shared Key, meilleure scalabilité, révocabilité. DNS purement read-only sur le RODC (actuellement il accepte des updates dynamiques vers Lyon). BitLocker sur les serveurs.

Ce qui n’a pas été fait

Script PowerShell de sauvegarde Google Drive, le cahier des charges en mentionnait un. J’ai préféré Google Drive Desktop en sync automatique. C’est natif, ça marche, pas besoin de développer du PowerShell compliqué avec OAuth et scheduling. En prod, la fiabilité prime sur la technicité.

Infrastructure as Code avec Terraform ou Ansible, déploiement manuel via l’interface pfSense et PowerShell. En vraie prod, je dirais que c’est quasi obligatoire pour la reproductibilité, la version control, les rollbacks simples. Mais pour un projet de formation, ça n’avait pas de sens.

Segmentation VLAN interne, les réseaux Lyon et Marseille sont séparés, mais pas de VLAN interne pour les serveurs, les postes clients, le management. Une vraie architecture incluerait une micro-segmentation avec pare-feu applicatif entre les zones.

Ce qui m’a marqué

Windows Server Core. D’abord c’était étrange, pas d’interface graphique du tout. Mais vite plus efficace. Moins de services, moins de vulnérabilités. 2 GB de RAM au lieu de 4. Moins de patchs parce que pas de composants graphiques. Et PowerShell à distance, finalement c’était plus rapide qu’un RDP graphique. La courbe d’apprentissage est raide, mais la productivité à long terme paie.

Le DNS. Tous les problèmes de réplication AD venaient du DNS. Règle essentielle : le DNS doit être parfait avant de promouvoir un DC. Résolution du DC source par FQDN. Les enregistrements SRV dans la zone AD. Résolution inverse (PTR). Pas de DNS publics (genre 8.8.8.8) en configuration.

MTU en environnement virtualisé. J’aurais dû calculer l’overhead avant de commencer. Ethernet 1500, moins VXLAN 50, moins IPsec ESP 70. Ça donne 1380 réelle. Configuration 1400 avec marge de sécurité. Leçon : toujours calculer avant avec du SDN.

User Configuration vs Computer Configuration sur les GPO. C’est fondamental. User Config s’applique au contexte utilisateur, faut des objets User dans le Security Filtering. Computer Config s’applique au démarrage, faut des objets Computer. Erreur classique : filtrer une GPO Computer avec que des groupes d’utilisateurs. Elle ne s’appliquera jamais.

Conformité

RGPD : comptes utilisateurs uniquement les données nécessaires, pas de champs superflus, chiffrement en transit (VPN) et au repos (EFS).

PCI-DSS (même si on ne traite pas directement des cartes) : AES-256 pour le VPN, moindre privilège, audit trail des authentifications.

ACPR pour la banque française : RODC assure la continuité si le VPN tombe, logs AD pour l’audit, séparation entre production (Lyon) et site distant (Marseille) avec réplication unidirectionnelle.

Conclusion

Au final, j’ai déployé une infrastructure AD multi-sites qui fonctionne. Le tunnel VPN IPsec avec AES-256, le RODC qui garantit la continuité d’authentification même sans VPN, les GPO avec restrictions horaires et blocage USB, la réplication AD qui marche, tout ça en place.

C’est devenu beaucoup plus clair en le faisant. IPsec, les phases de négociation, l’overhead réseau, les enregistrements SRV, la distinction entre intra-site et inter-site replication, ça s’abstraie quand tu lis des docs, mais tu comprends vraiment quand tu debugs un problème MTU ou une résolution DNS qui plante.

L’infrastructure est opérationnelle pour la formation. Les fondations sont là pour évoluer vers une vraie prod sécurisée et conforme aux standards bancaires.