Active Directory sur VPN : ce qui casse en premier (DNS, heure, ports) et comment le réparer

novembre 20, 2025 • février 3, 2026 • Lecture : 31 min • Views: 9

Cet article vous a aidé ?

Le VPN se connecte. Les pings fonctionnent. Quelqu’un proclame la victoire. Puis les utilisateurs ne peuvent plus se connecter, les stratégies de groupe prennent un temps géologique, et « trust relationship failed »
commence à apparaître comme des toasts dans une cuisine de bureau partagée.

Active Directory ne tombe pas proprement sur un VPN. Il échoue de façons spécifiques et reproductibles : le DNS devient étrange, l’heure dérive, les ports sont « serrés », et
la latence transforme des protocoles conçus pour des LAN rapides en quelque chose qui patauge dans la boue. Voici le guide de terrain pour ce qui casse en premier — et les corrections qui survivent en production.

Ce qui casse en premier : l’ordre habituel de la douleur

Si vous migrez ou étendez Active Directory via un VPN — site‑à‑site IPsec, WireGuard, OpenVPN, peu importe — les modes de défaillance sont remarquablement
cohérents. L’ordre ci‑dessous n’est pas théorique. C’est ce qui déclenche les pages d’astreinte à 2 h du matin.

1) Le DNS casse en premier (ou était toujours cassé et vous venez de le remarquer)

AD est un annuaire, mais il se comporte comme une application DNS avec des fonctions d’identité. Les contrôleurs de domaine sont découverts via des enregistrements SRV.
Les clients trouvent LDAP, Kerberos et GC via le DNS. Si votre VPN change le serveur DNS qu’utilise un client, si le DNS split est mal configuré,
ou si des forwarders conditionnels pointent vers une adresse morte, le domaine disparaît pratiquement.

2) L’heure casse en second (Kerberos refuse de négocier avec des menteurs)

Kerberos utilise l’heure pour empêcher les attaques par rejeu. Si l’horloge client dévie au‑delà du décalage autorisé (souvent 5 minutes), l’authentification échoue.
Sur un LAN, les incohérences NTP sont souvent masquées par le « assez proche ». Sur VPN, vous ajoutez de nouvelles sources de temps, des comportements veille/reprise sur les portables,
et parfois des dispositifs NAT qui perturbent le comportement NTP/UDP.

3) Les ports cassent ensuite (les firewalls font pleurer les adultes)

Quelqu’un proposera « n’autorisez que le 88 et le 389 ». Quelqu’un d’autre insistera « c’est tout en 443 maintenant ». Aucune n’est vraie pour le fonctionnement classique d’AD.
Vous avez besoin d’un ensemble de ports connus et d’une stratégie pour les ports RPC dynamiques. Sur VPN, la posture « deny par défaut » est bonne pour la sécurité,
mais c’est aussi comment vous créez des domaines mystérieux et à moitié fonctionnels.

4) Latence et perte de paquets dégradent l’expérience utilisateur (même si rien n’est « down »)

AD peut être techniquement fonctionnel tandis que les connexions prennent 90 secondes, que les GPO expirent, ou que le backlog DFSR gonfle comme une plante d’horreur.
Sur VPN, le RTT et la gigue comptent. Les protocoles bavards d’AD — surtout pendant l’ouverture de session et le traitement des stratégies — punissent les allers‑retours longs.

Blague n°1 : Active Directory sur un VPN, c’est comme une relation à distance : ça marche tant que quelqu’un communique de manière fiable, et le DNS est généralement « quelqu’un ».

Faits intéressants et contexte historique (pour que l’étrange ait du sens)

Fait 1 : La découverte de services d’AD repose fortement sur les enregistrements SRV DNS (RFC 2782). Voilà pourquoi « le DNS est OK » est rarement suffisant.
Fait 2 : Le décalage horaire maximum par défaut de Kerberos dans les domaines Windows est typiquement 5 minutes — suffisamment petit pour que la veille d’un portable ruine votre journée.
Fait 3 : La réplication AD utilise RPC, qui impliquait historiquement des plages de ports dynamiques. Windows moderne peut restreindre la plage, mais il faut le faire volontairement.
Fait 4 : La réplication de SYSVOL est passée de FRS à DFSR parce que FRS était fragile à grande échelle et mauvais en gestion de conflits.
Fait 5 : « Sites and Services » existe parce qu’AD supposait des liens rapides et fiables à l’intérieur d’un site et des liens plus lents entre sites — en gros, une conception WAN‑aware avant que le « cloud » soit à la mode.
Fait 6 : Le Global Catalog (GC) utilise le port 3268/3269 parce que Microsoft avait besoin d’un moyen de requêter l’ensemble de la forêt sans suivre des referrals partout.
Fait 7 : Le signing LDAP et le channel binding ont été renforcés au fil des années parce que LDAP était trop permissif pour les modèles de menace modernes ; les VPN ne rendent pas LDAP ancien plus sûr.
Fait 8 : L’ajout au domaine Windows dépend encore d’un mélange de protocoles anciens (SMB, RPC, Netlogon) parce que la compatibilité descendante en entreprise est un mode de vie, pas une phase.

Mode opératoire de diagnostic rapide (vérifiez dans cet ordre)

Vous voulez de la vitesse. Pas une checklist de 40 étapes qui ressemble à un audit de conformité. Voici la séquence « trouver le goulot en 10 minutes ».

Étape 1 : Confirmez que le client utilise les bons serveurs DNS (pas « ce que le Wi‑Fi de l’hôtel suggère »)

Si le client ne peut pas résoudre _ldap._tcp.dc._msdcs pour le domaine, stop. Réparez le DNS d’abord.
Si la résolution DNS fonctionne mais renvoie des IPs de DC injoignables, corrigez le routage/le split‑tunneling/les sous‑réseaux du VPN.

Étape 2 : Vérifiez le décalage horaire sur le client et sur le DC qu’il tente d’utiliser

Si le décalage horaire est > 300 secondes, corrigez la hiérarchie NTP et la source de temps du client. Ne « augmentez pas simplement le décalage Kerberos ».

Étape 3 : Validez les ports AD de base depuis le réseau problématique vers un DC spécifique

Testez TCP 88, 389/636, 445, 135, 53, 464, et un port RPC élevé représentatif (ou votre plage restreinte).
Si 445 échoue : attendez‑vous à des problèmes SYSVOL/GPO, de jonction de domaine, et de « trust relationship ».

Étape 4 : Identifiez quel DC le client a choisi, et s’il est dans le bon site

Si un site distant utilise un DC à travers le tunnel alors qu’un DC plus proche existe, corrigez Sites/Subnets et le comportement du localisateur de DC.

Étape 5 : Si tout « marche » mais que c’est lent, mesurez RTT et perte et cherchez des problèmes MTU/MSS

RTT élevé + perte de paquets + SMB + RPC = logons lents et expirations GPO.
Les trous noirs MTU provoquent des échecs intermittents maddening qui ressemblent à « problèmes d’auth aléatoires ». Ce n’est pas aléatoire.

DNS : le saboteur silencieux

Le DNS n’est pas un acteur secondaire dans AD. Le DNS est co‑tête d’affiche. Le mécanisme entier de découverte d’AD est « demandez au DNS qui sont les contrôleurs de domaine »
et « demandez au DNS quel DC est le plus proche ». Quand les clients VPN ou les sites distants ne peuvent pas utiliser de manière fiable le DNS intégré à AD, vous obtenez des échecs partiels :
invites de connexion, jonctions de domaine lentes, erreurs GPO, et applications incapables de trouver LDAP.

Split DNS et clients VPN : choisissez une conception et tenez‑vous y

Vous avez essentiellement deux options sensées :

Forcer le DNS interne lorsque connecté au VPN (full tunnel ou split tunnel avec DNS forcé). C’est la plus simple pour la correction AD.
Utiliser le forwarding conditionnel / DNS à horizon fractionné où les zones AD internes sont résolues par le DNS interne même si d’autres requêtes vont à l’extérieur.

L’option insensée est « laisser le client utiliser n’importe quel serveur DNS reçu via DHCP ou Wi‑Fi et espérer ». L’espoir n’est pas une stratégie ; c’est une panne avec un poster motivationnel.

Enregistrements SRV : ce que les clients recherchent réellement

Quand un client Windows a besoin d’un DC, il interroge des enregistrements comme :
_ldap._tcp.dc._msdcs.<domain> et _kerberos._tcp.<domain>.
Si ceux‑ci ne se résolvent pas, le client n’est pas « un peu confus ». Il est aveugle.

Pourquoi le DNS AD casse spécifiquement sur VPN

Mauvais serveur DNS poussé par le VPN : vous avez poussé du DNS public « pour la vitesse », et maintenant les enregistrements AD n’existent pas.
Split tunneling sans route vers le serveur DNS : le client est configuré pour utiliser le DNS interne mais ne peut pas l’atteindre à cause de la politique de routage.
Les forwarders conditionnels pointent à travers le tunnel : quand le tunnel clignote, la résolution DNS se bloque (et la connexion aussi).
Problèmes EDNS/fragmentation : les réponses DNS avec SRV peuvent être plus volumineuses ; les problèmes MTU peuvent rendre le DNS instable.

Heure : Kerberos est pointilleux et garde des preuves

Kerberos repose sur des « tickets » qui expirent et sont liés au temps. Si vos horloges ne s’accordent pas, le protocole suppose que quelqu’un ment — ou rejoue.
Sur VPN, les problèmes de temps sont amplifiés parce que les portables se déplacent, se mettent en veille, reprennent, et choisissent différentes sources NTP selon le réseau.

À quoi ressemble la « dérive horaire » en production

L’utilisateur se voit redemander ses identifiants en boucle.
La jonction de domaine échoue avec des erreurs génériques qui ne mentionnent pas l’heure.
Le bind LDAP fonctionne (parfois), mais le SSO Kerberos ne fonctionne pas.
Les journaux d’événements montrent des erreurs Kerberos (comme des échecs de pré‑auth) qui sont mal diagnostiquées comme « mauvais mot de passe ».

Faites la chose ennuyeuse : une hiérarchie de temps faisant autorité

Dans un domaine Windows, vous voulez :

Le PDC Emulator dans le domaine racine de la forêt synchronisé sur des sources de temps externes fiables.
Tous les autres DC synchronisés depuis la hiérarchie de domaine.
Tous les membres synchronisés depuis la hiérarchie de domaine.

Ne laissez pas les clients VPN utiliser des serveurs NTP publics aléatoires tout en tentant d’utiliser Kerberos avec vos DC. C’est ainsi que vous obtenez « ça marche à la maison, ça échoue à l’hôtel ».

Ports : quand « on a juste ouvert le 443 » rencontre la réalité

AD n’est pas un protocole unique. C’est une suite. Sur un VPN, vous n’avez peut‑être pas « un firewall » au sens traditionnel, mais vous avez des groupes de sécurité,
des ACL, du routage basé sur la politique, des règles NAT, et des gens avec de fortes convictions. Les ports comptent toujours.

Ports essentiels généralement nécessaires (pas exhaustif, mais réel)

DNS : TCP/UDP 53
Kerberos : TCP/UDP 88
Changement de mot de passe Kerberos : TCP/UDP 464
LDAP : TCP/UDP 389 (UDP utilisé pour quelques anciens scénarios ; la plupart des binds sont TCP)
LDAPS : TCP 636 (si utilisé)
Global Catalog : TCP 3268 / 3269
SMB (SYSVOL, NETLOGON) : TCP 445
RPC endpoint mapper : TCP 135
Ports RPC dynamiques : TCP ports élevés (plage dépendant de l’OS/config)

Le problème des ports RPC dynamiques (et la solution adulte)

La réplication AD et de nombreuses opérations de gestion Windows utilisent RPC. RPC utilise TCP 135 pour trouver un service, puis passe la main à un port élevé dynamique.
Si la politique de votre « firewall VPN » n’autorise qu’un petit nombre de ports, la réplication casse de façons étranges.

L’approche correcte est : restreindre la plage RPC dynamique sur les contrôleurs de domaine (et tout serveur concerné) à une petite plage définie, puis autoriser cette plage à travers le VPN.
Ce n’est pas glamour. C’est stable.

Blague n°2 : Bloquer les ports RPC dynamiques au nom de la « sécurité » revient à retirer toutes les poignées de porte pour prévenir les cambriolages — félicitations, vous vivez maintenant dehors.

Latence et perte de paquets : mourir d’un millier d’allers‑retours

Vous pouvez avoir un DNS parfait, une heure parfaite et des ports ouverts, et quand même passer une mauvaise journée. Cette journée s’appelle « le VPN a 120 ms de RTT et 1 % de perte ».
Les logons AD et le traitement GPO impliquent de multiples opérations réseau : requêtes LDAP, échanges Kerberos, lectures SMB des stratégies, parfois vérifications de certificats.
Chacune ajoute des allers‑retours. On multiplie. Puis on ajoute la perte de paquets, qui déclenche retransmissions et timeouts.

MTU/MSS : le gremlin derrière « ça marche pour les petites choses »

Les VPN réduisent souvent le MTU effectif. Si vous ne clampiez pas le MSS ou ne régliez pas le MTU correctement, vous pouvez obtenir des trous noirs de fragmentation :
les petits paquets réussissent, les plus gros disparaissent. Le DNS avec réponses volumineuses, les tickets Kerberos et le trafic SMB peuvent mal se comporter.
Le symptôme est des échecs intermittents qui ne corrèlent pas à la charge. Les gens accuseront « AD qui est AD ». Ce n’est pas AD. C’est votre chemin de paquets.

Quand « optimiser » signifie « empirer »

La compression, le DPI agressif et les dispositifs d’« optimisation WAN » peuvent abîmer le trafic AD, surtout SMB et RPC.
Certains appareils sont corrects. D’autres non. Si vous introduisez une boîte qui réordonne des paquets ou a des timeouts étranges, AD vous punira avec une misère imprévisible.

Sites, sous‑réseaux et réplication : faites correspondre la topologie AD au réseau

Si vous exécutez AD sur VPN et que vous ne configurez pas correctement Sites and Services, vous laissez votre destin aux heuristiques du localisateur de DC.
Parfois vous aurez de la chance. Parfois un bureau de branche à Singapour authentifiera contre un DC en Virginie parce que le client pense que c’est « le plus proche ».
C’est à la fois hilarant et coûteux.

Faites ces trois choses ou n’y pensez pas

Créez un site AD pour chaque emplacement connecté par VPN ayant des différences notables de latence/bande passante.
Mappez les sous‑réseaux IP au site correct pour que les clients choisissent des DC locaux et que la topologie de réplication ait du sens.
Configurez les liens de site et les calendriers de réplication si le lien VPN est contraint ou mesuré.

Réplication sur VPN : la stabilité vaut mieux que la vitesse

La réplication n’est pas juste « ouvrir les ports ». Il s’agit aussi d’éviter le flapping. Si votre VPN est instable, la réplication se mettra en file.
Vous prenez le risque d’objets persistants, backlog DFSR et bizarreries qui n’apparaissent pas immédiatement.

La priorité opérationnelle : garder le tunnel stable, maintenir le temps, assurer un DNS cohérent, et limiter volontairement la réplication si nécessaire.
« Lâcher tout » est la façon de saturer un lien puis d’accuser AD des conséquences.

SYSVOL, DFSR et GPO sur VPN

La stratégie de groupe est l’endroit où « AD est en ligne » rencontre « les utilisateurs sont en colère ». Le traitement des GPO dépend de :
LDAP pour les métadonnées et le filtrage de sécurité, et l’accès SMB à SYSVOL pour les fichiers de stratégie réels.
Sur VPN, la santé de SMB (445) et de la réplication DFSR devient critique.

Schémas de douleur courants pour GPO sur VPN

Ouverture de session lente : le client attend des lectures SYSVOL sur des liens à haute latence.
GPO échoue de manière intermittente : timeouts SMB dus à la perte de paquets ou aux problèmes MTU.
Nouvelles stratégies non appliquées : backlog DFSR ou échecs de réplication rendent SYSVOL incohérent entre les DC.

Conseils d’opinion

Pour les utilisateurs distants sur VPN instable, privilégiez des stratégies qui n’exigent pas de lourdes lectures SYSVOL au moment du logon.
Gardez SYSVOL propre. Ne le traitez pas comme un partage pour des « scripts pratiques ».
Si vous avez besoin de gros paquets, utilisez une distribution de logiciel appropriée, pas SYSVOL comme CDN officieux.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les commandes à lancer quand tout brûle. Chaque tâche inclut : commande, sortie représentative, ce que cela signifie, et la décision à prendre.
Mélange Windows et Linux intentionnel — de nombreuses passerelles VPN et hôtes de monitoring sont Linux, et vous devez tester depuis le chemin qui échoue.

Tâche 1 : Vérifier quels serveurs DNS un client Windows utilise

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {10.20.0.10, 10.20.0.11}
Wi-Fi          {8.8.8.8}

Signification : Le Wi‑Fi utilise un DNS public. Si le client VPN n’écrase pas le DNS sur l’interface active, les recherches AD peuvent aller sur du public et échouer.
Décision : Forcer le DNS interne quand le VPN est connecté, ou implémenter NRPT/forwarders conditionnels pour que les zones AD se résolvent en interne.

Tâche 2 : Vérifier la résolution des enregistrements SRV pour les contrôleurs de domaine

cr0x@server:~$ nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com 10.20.0.10
Server:  dns01.corp.example.com
Address: 10.20.0.10

_ldap._tcp.dc._msdcs.corp.example.com  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc01.corp.example.com
_ldap._tcp.dc._msdcs.corp.example.com  SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = dc02.corp.example.com

Signification : Le DNS peut trouver les DC via les enregistrements SRV. Si cela échoue, la découverte AD échoue.
Décision : Si NXDOMAIN/timeout, corrigez la reachabilité DNS ou la réplication de zone ; ne touchez pas Kerberos pour l’instant.

Tâche 3 : Confirmer que le DC résolu est joignable via le VPN

cr0x@server:~$ ping -c 3 dc01.corp.example.com
PING dc01.corp.example.com (10.20.0.21) 56(84) bytes of data.
64 bytes from 10.20.0.21: icmp_seq=1 ttl=127 time=42.1 ms
64 bytes from 10.20.0.21: icmp_seq=2 ttl=127 time=41.8 ms
64 bytes from 10.20.0.21: icmp_seq=3 ttl=127 time=42.4 ms

--- dc01.corp.example.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 41.8/42.1/42.4/0.2 ms

Signification : La reachabilité basique existe et le RTT est ~42 ms. C’est acceptable.
Décision : Si le ping échoue, vérifiez le routage VPN, les ACL, et si l’ICMP est bloqué (testez aussi les ports TCP).

Tâche 4 : Tester les ports critiques vers un DC depuis un jump host Linux

cr0x@server:~$ nc -vz dc01.corp.example.com 53 88 135 389 445 464 3268
Connection to dc01.corp.example.com (10.20.0.21) 53 port [tcp/domain] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 88 port [tcp/kerberos] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 135 port [tcp/msrpc] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 389 port [tcp/ldap] succeeded!
nc: connect to dc01.corp.example.com (10.20.0.21) port 445 (tcp) failed: Operation timed out
Connection to dc01.corp.example.com (10.20.0.21) 464 port [tcp/kpasswd] succeeded!
Connection to dc01.corp.example.com (10.20.0.21) 3268 port [tcp/globalcatLDAP] succeeded!

Signification : SMB (445) est bloqué ou cassé. Attendez‑vous à des problèmes GPO/SYSVOL et de jonction de domaine.
Décision : Réparer le chemin 445 à travers le VPN, ou concevoir explicitement autour de ce blocage (rarement faisable si on veut un comportement Windows normal).

Tâche 5 : Vérifier la santé du canal sécurisé Windows

cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Verbose"
VERBOSE: Performing the operation "Test-ComputerSecureChannel" on target "WIN11-042".
True

Signification : Le trust machine‑to‑domain est intact.
Décision : Si False, vous devrez peut‑être réparer le canal sécurisé (après avoir corrigé DNS/heure/ports).

Tâche 6 : Réparer un canal sécurisé cassé (après vérification de la connectivité)

cr0x@server:~$ powershell -NoProfile -Command "Test-ComputerSecureChannel -Repair -Credential (Get-Credential)"
PowerShell credential request
Enter your credentials.
User: CORP\adminuser
Password for user CORP\adminuser: ********

True

Signification : Le mot de passe du compte machine a été réinitialisé et le trust restauré.
Décision : Si la réparation échoue, revérifiez le décalage horaire et l’accès RPC/SMB ; ne continuez pas les tentatives jusqu’à verrouiller les identifiants admin.

Tâche 7 : Vérifier l’état de synchronisation temporelle sur Windows

cr0x@server:~$ w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Last Successful Sync Time: 12/28/2025 11:22:10 AM
Source: dc01.corp.example.com
Poll Interval: 6 (64s)

Signification : Le client se synchronise depuis le domaine (bon).
Décision : Si la source est « Local CMOS Clock » ou un NTP public while on VPN, corrigez la configuration du service temps et le DNS/routage VPN.

Tâche 8 : Mesurer le décalage temporel depuis un hôte Linux (vérif rapide)

cr0x@server:~$ chronyc tracking
Reference ID    : 0A140015 (dc01.corp.example.com)
Stratum         : 4
Ref time (UTC)  : Sun Dec 28 11:22:15 2025
System time     : 0.000412345 seconds fast of NTP time
Last offset     : -0.000120113 seconds
RMS offset      : 0.000231009 seconds
Frequency       : 12.345 ppm fast
Residual freq   : -0.120 ppm
Skew            : 0.210 ppm
Root delay      : 0.042123456 seconds
Root dispersion : 0.001234567 seconds

Signification : Le décalage est inférieur à la milliseconde. Le temps n’est pas le problème.
Décision : Si le décalage est de secondes/minutes, corrigez le chemin NTP avant de toucher Kerberos/GPO.

Tâche 9 : Voir quel DC un client Windows a réellement choisi

cr0x@server:~$ nltest /dsgetdc:corp.example.com
           DC: \\dc02.corp.example.com
      Address: \\10.20.0.22
     Dom Guid: 3d1d5d8a-1111-2222-3333-aaaaaaaaaaaa
     Dom Name: corp.example.com
  Forest Name: corp.example.com
 Dc Site Name: HQ
Our Site Name: BRANCH01
        Flags: GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE

Signification : Le site client est BRANCH01 mais il a choisi un DC dans HQ ; « CLOSE_SITE » suggère qu’il n’a pas trouvé de DC local ou que le mapping du sous‑réseau est incorrect.
Décision : Corrigez le mapping Sites/Subnets ou assurez‑vous d’un DC/RODC dans BRANCH01 si c’est l’intention.

Tâche 10 : Vérifier le résumé de santé du contrôleur de domaine

cr0x@server:~$ dcdiag /s:dc01 /q
cr0x@server:~$ echo $?
0

Signification : Le code de sortie 0 implique aucune anomalie majeure lors de l’exécution silencieuse.
Décision : Si des erreurs apparaissent (échecs test DNS, échecs d’advertising), corrigez la santé du DC avant d’accuser le VPN.

Tâche 11 : Vérifier l’état de réplication AD entre DC

cr0x@server:~$ repadmin /replsummary
Replication Summary Start Time: 2025-12-28 11:24:31

Beginning data collection for replication summary, this may take awhile:
  ......

Source DSA          largest delta    fails/total %%   error
 dc01                    00:05:12    0 / 20    0
 dc02                    00:06:01    2 / 20   10    (1722) The RPC server is unavailable.

Destination DSA     largest delta    fails/total %%   error
 dc01                    00:06:01    0 / 20    0
 dc02                    03:42:19    2 / 20   10    (1722) The RPC server is unavailable.

Signification : La réplication vers/depuis dc02 échoue avec RPC unavailable. C’est presque toujours des ports, règles firewall, ou routage.
Décision : Validez TCP 135 et la plage RPC dynamique entre DC à travers le VPN ; restreignez la plage si nécessaire et autorisez‑la.

Tâche 12 : Inspecter la plage de ports RPC dynamique sur Windows

cr0x@server:~$ netsh int ipv4 show dynamicport tcp
Protocol tcp Dynamic Port Range
---------------------------------
Start Port      : 49152
Number of Ports : 16384

Signification : La plage dynamique moderne par défaut est 49152–65535. Si la politique VPN n’autorise pas cela, les opérations basées RPC peuvent échouer.
Décision : Envisagez de restreindre la plage sur les DC à un bloc plus petit et de le permettre à travers le VPN.

Tâche 13 : Tester l’accès SMB à SYSVOL depuis un client Windows

cr0x@server:~$ powershell -NoProfile -Command "dir \\corp.example.com\SYSVOL | Select-Object -First 3"
    Directory: \\corp.example.com\SYSVOL

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d----          12/12/2025  10:10 AM                corp.example.com
d----          12/12/2025  10:10 AM                staging
d----          12/12/2025  10:10 AM                sysvol

Signification : SYSVOL est accessible et consultable. L’accès aux fichiers GPO devrait fonctionner.
Décision : Si cela bloque ou renvoie une erreur, corrigez TCP 445, les problèmes MTU/MSS, ou la résolution de nom vers le DC hébergeant les referrals SYSVOL.

Tâche 14 : Forcer le rafraîchissement des stratégies et lire le résultat

cr0x@server:~$ gpupdate /force
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.

Signification : Au moins un passage a réussi. Si c’est lent, vous avez peut‑être toujours des douleurs liées à la latence/SMB.
Décision : Si gpupdate échoue avec « cannot read gpt.ini », concentrez‑vous sur SYSVOL/SMB et la santé DFSR.

Tâche 15 : Vérifier le MTU effectif sur le chemin (Linux)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.20.0.21
PING 10.20.0.21 (10.20.0.21) 1372(1400) bytes of data.
1380 bytes from 10.20.0.21: icmp_seq=1 ttl=127 time=42.5 ms
1380 bytes from 10.20.0.21: icmp_seq=2 ttl=127 time=42.0 ms
1380 bytes from 10.20.0.21: icmp_seq=3 ttl=127 time=42.2 ms

--- 10.20.0.21 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Signification : Le chemin supporte des paquets de 1400 octets sans fragmentation. C’est un bon signe pour de nombreux setups VPN.
Décision : Si « Frag needed » apparaît, clampiez le MSS sur les bords du VPN ou ajustez le MTU ; les problèmes AD intermittents disparaissent souvent après cela.

Tâche 16 : Valider la poignée de main LDAPS (si vous utilisez LDAPS)

cr0x@server:~$ openssl s_client -connect dc01.corp.example.com:636 -servername dc01.corp.example.com -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN=dc01.corp.example.com
Verification: OK

Signification : LDAPS est joignable et le certificat valide (depuis le trust store de cet hôte).
Décision : Si cela échoue, ouvrez le 636, corrigez le certificat du DC, ou cessez d’insister sur LDAPS pour les applications qui ne peuvent pas le joindre via VPN.

Trois mini‑histoires du monde de l’entreprise (ce qui arrive vraiment)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a acquis une plus petite firme et décidé de « connecter temporairement » les réseaux via un VPN site‑à‑site. L’hypothèse était simple :
« Si on peut pinger le contrôleur de domaine, la jonction au domaine fonctionnera. »

La première semaine semblait correcte parce que seuls quelques portables IT testaient — et ces portables avaient des identifiants en cache et utilisaient manuellement le DNS interne.
Puis ils ont déployé un lot de nouvelles machines. La jonction au domaine échouait de manière intermittente. Certaines machines rejoignaient, d’autres non, et celles qui rejoignaient mettaient une éternité à appliquer les stratégies.

Le postmortem fut brutalement simple. Le VPN ne poussait aucune configuration DNS. Les clients utilisaient n’importe quel DNS qu’ils avaient — généralement le routeur de la branche qui forwardait vers un résolveur ISP.
L’ISP, étonnamment, n’hébergeait pas _ldap._tcp.dc._msdcs pour leur zone AD privée. Le processus de jonction se rabattait donc sur une découverte lente et parfois erronée.

La correction n’a pas été héroïque. Ils ont forcé le DNS interne via le VPN et ajouté des forwarders conditionnels pour la zone AD dans le résolveur de la branche.
Tout s’est stabilisé immédiatement. La leçon : « ping marche » est un test d’ICMP, pas un test d’infrastructure d’identité.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une autre organisation avait un design AD solide : DC dans chaque site majeur, Sites and Services configurés, réplication planifiée. C’était ennuyeux.
Puis une équipe réseau a introduit une « optimisation de performance » sur le concentrateur VPN : gestion UDP agressive avec une nouvelle politique qui priorisait le « trafic important »
et dépriorisait le « trafic bulk ». Devinez dans quel seau SMB et certains flux RPC ont atterri.

Les symptômes étaient étranges. L’authentification fonctionnait généralement, mais les scripts de logon échouaient parfois. Le traitement GPO prenait aléatoirement des minutes.
Le backlog DFSR a commencé à croître, mais pas uniformément — seulement un lien de site montrait un retard persistant.

Ils l’ont poursuivi comme un « problème de réplication AD » trop longtemps. Quand quelqu’un a finalement tracé la perte de paquets sur le tunnel et l’a corrélée aux retries SMB,
le schéma était évident : l’optimiseur laissait tomber ou retardait des segments sous charge. Les clients Windows martelaient alors le lien avec des retransmissions,
renforçant la conviction de l’optimiseur qu’il s’agissait de « trafic bulk », et le punissant davantage. Une boucle de rétroaction, la meilleure.

La correction a été de supprimer la politique et d’implémenter un QoS simple protégeant le tunnel de la saturation au lieu d’essayer de surpasser TCP.
Les performances sont revenues, et la réplication AD a cessé de ressembler à une dépression saisonnière.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise globale avait des sites de production distants connectés par VPN sur des liaisons last‑mile peu fiables. Ils savaient que les liens allaient clignoter.
Ils ont donc fait trois choses ennuyeuses tôt : installer un RODC dans chaque site distant, mapper correctement les sous‑réseaux aux sites, et établir une hiérarchie horaire stricte
avec le PDC emulator comme source externe.

Des mois plus tard, une panne d’un ISP régional a coupé un ensemble de tunnels pendant une demi‑journée. Les gens attendaient un chaos d’authentification.
À la place, les utilisateurs des usines ont continué à se connecter. Les identifiants en cache ont aidé, mais le vrai héros a été l’authentification locale contre le RODC pour de nombreuses opérations,
plus une horloge cohérente empêchant Kerberos de partir en vrille quand la connectivité est revenue.

Quand les tunnels sont revenus, la réplication a rattrapé son retard de façon contrôlée parce que les liens de site et les calendriers étaient configurés pour une bande passante contrainte.
Pas d’interventions manuelles frénétiques. Pas de « on a rebooté le DC sans raison ». L’incident est resté principalement un problème réseau.

Voilà ce que fait une bonne infrastructure : elle échoue dans son propre rayon d’explosion. L’ennuyeux est une fonctionnalité.

Erreurs courantes : symptôme → cause racine → correction

1) Symptôme : La jonction de domaine échoue avec des messages d’erreur génériques

Cause racine : Le client ne peut pas résoudre les enregistrements SRV AD ou utilise un DNS public ; ou les ports SMB/RPC sont bloqués.

Correction : Forcer le DNS interne via le VPN ; vérifier les recherches SRV ; s’assurer que 445/135 et la plage RPC sont autorisés ; confirmer les routes client vers les sous‑réseaux DC.

2) Symptôme : « The trust relationship between this workstation and the primary domain failed »

Cause racine : Canal sécurisé rompu après un décalage de mot de passe machine, souvent déclenché par de longues périodes hors ligne et des reconnexions instables ; parfois dérive horaire.

Correction : Corriger DNS/heure d’abord ; puis Test-ComputerSecureChannel -Repair ou réintégrer le domaine si nécessaire ; vérifier la reachabilité DC et SMB/RPC.

3) Symptôme : Les utilisateurs se connectent, mais la stratégie de groupe est lente ou échoue

Cause racine : SMB (445) altéré ; SYSVOL inaccessible ; backlog DFSR ; latence élevée et perte de paquets.

Correction : Valider l’accès \\domain\SYSVOL ; réparer 445 et MTU/MSS ; vérifier la santé DFSR ; réduire le volume des GPO.

4) Symptôme : Les invites d’authentification se répètent, ou le SSO échoue alors que le mot de passe fonctionne

Cause racine : Dérive horaire Kerberos ; client utilisant le mauvais KDC à cause du DNS ou d’un mauvais mapping de sites.

Correction : Faire respecter la hiérarchie temporelle du domaine ; vérifier l’état w32tm ; corriger Sites/Subnets pour que les clients choisissent des DC locaux.

5) Symptôme : Erreurs de réplication comme « RPC server unavailable »

Cause racine : TCP 135 ou ports RPC dynamiques bloqués ; routage asymétrique via split tunnels ; interférence NAT.

Correction : Autoriser 135 et la plage dynamique ; ou restreindre la plage RPC sur les DC et autoriser cette plage. Valider avec repadmin et des tests de ports.

6) Symptôme : Tout fonctionne jusqu’aux heures de pointe, puis AD « fait le bazar »

Cause racine : Saturation du VPN, mise en file, perte de paquets ; parfois des dispositifs « d’optimisation » nuisibles au SMB/RPC.

Correction : Planifier la capacité du tunnel ; ajouter un QoS sensé ; éviter les optimiseurs WAN intrusifs ; mesurer RTT/pertes et corréler avec les temps d’auth/GPO.

7) Symptôme : Seuls certains sous‑réseaux/utilisateurs échouent

Cause racine : Sites/Subnets incomplets ; routes split tunneling manquantes ; forwarding conditionnel DNS appliqué seulement à certains clients.

Correction : Auditer les mappings de sous‑réseau ; standardiser les profils VPN ; s’assurer que les politiques DNS s’appliquent de façon cohérente selon les types de clients.

Listes de contrôle / plan pas à pas (construire pour que ça reste corrigé)

Étapes pas à pas : rendre AD sur VPN fiable

Inventoriez vos DC et rôles. Sachez où se trouve le PDC emulator et quels DC sont GC.
Choisissez une stratégie DNS pour les clients VPN. Forcer le DNS interne quand connecté, ou implémenter le split DNS correctement.
Validez la résolution des enregistrements SRV depuis chaque réseau distant. Faites‑en un contrôle de monitoring, pas un test ponctuel.
Renforcez la hiérarchie temporelle. Le PDC se synchronise sur des sources externes ; tout le monde se synchronise via le domaine. Vérifiez avec w32tm et du monitoring.
Définissez les ports requis et la stratégie RPC. Décidez d’autoriser la plage RPC dynamique par défaut ou de la restreindre. Documentez et appliquez.
Corrigez le MTU/MSS tôt. Configurez le clamping MSS sur les bords du VPN. Testez avec des pings « do not fragment » et de grandes réponses DNS.
Implémentez le mapping Sites/Subnets AD. Chaque sous‑réseau distant doit mapper à un site. Aucune exception. Les exceptions deviennent des pannes.
Décidez DC local vs RODC pour les sites distants. Si le site doit fonctionner pendant les pannes de tunnel, installez un RODC ou un DC local.
Planifiez les calendriers de réplication pour les liens contraints. Ne saturez pas le tunnel avec la réplication pendant les heures ouvrées.
Testez l’accès GPO et SYSVOL. Validez régulièrement la reachabilité SMB et la santé DFSR.
Créez un test synthétique de logon distant. Depuis un hôte sur le réseau distant, testez périodiquement SRV DNS, Kerberos, LDAP, SMB.
Rédigez le plan de rollback. Si un changement VPN casse AD, vous devez avoir une voie de retour rapide. « On analysera en production » n’est pas un plan.

Checklist opérationnelle : avant d’accuser AD

Le tunnel VPN est‑il stable ? Pas de flapping, pas de rekeys fréquents qui causent des coupures?
Le routage est‑il symétrique ? Pas de bizarreries split tunnel où les requêtes vont d’un côté et les réponses reviennent d’un autre?
Le DNS est‑il cohérent ? Les clients utilisent des résolveurs internes et peuvent résoudre les enregistrements SRV?
L’heure est‑elle stable ? Clients et DC dans les 5 minutes, idéalement dans les secondes?
Les ports sont‑ils vérifiés ? 53/88/389/445/135 + plage RPC atteignable?
La latence est‑elle acceptable ? Si le RTT > ~150 ms et la perte > ~0.5 %, attendez‑vous à des problèmes sans refonte.

FAQ (les questions qu’on pose juste après la panne)

1) Active Directory peut‑il fonctionner sur un VPN ?

Oui. Ça fonctionne tous les jours dans des entreprises réelles. Mais cela exige un DNS discipliné, une hiérarchie temporelle correcte, une politique de ports explicite (incluant la stratégie RPC),
et des Sites/Subnets AD qui reflètent la topologie VPN.

2) Qu’est‑ce qui casse en premier en pratique : DNS, heure ou ports ?

DNS. Presque toujours le DNS. L’heure vient deuxième. Les ports troisièmes. La latence est le problème à combustion lente qui vous fait croire qu’AD est instable quand c’est le lien.

3) Avons‑nous vraiment besoin de SMB (445) sur le VPN ?

Si vous voulez un comportement normal du domaine : oui. SYSVOL et beaucoup de flux de logon/GPO reposent sur SMB.
Vous pouvez réduire la dépendance (par ex. minimiser scripts et gros fichiers de stratégie), mais bloquer 445 se transforme généralement en dysfonctionnement d’identité auto‑infligé.

4) Peut‑on « juste utiliser LDAPS » et fermer LDAP 389 ?

Certains environnements peuvent le faire, mais ce n’est pas un remplacement universel. Les opérations de domaine, des apps legacy, et certains mécanismes de découverte peuvent encore utiliser 389.
Si vous imposez LDAPS, faites‑le comme un projet planifié avec inventaire applicatif et cycle de vie des certificats, pas comme un changement de firewall le vendredi soir.

5) Devons‑nous augmenter le décalage horaire Kerberos autorisé pour arrêter les échecs ?

Non. Corrigez la synchronisation du temps. Augmenter le décalage, c’est comme desserrer les écrous parce que la roue tremble.
Le compromis de sécurité est réel, et vous aurez toujours des bizarreries car d’autres parties du système supposent une cohérence temporelle.

6) Le split tunneling est‑il compatible avec AD ?

Ça peut l’être, mais ça augmente la difficulté. Vous devez vous assurer que les requêtes DNS pour les zones AD vont vers des résolveurs internes et que les routes vers les DC, SYSVOL et services requis existent.
Le split tunneling sans discipline DNS/routage est un moyen fiable de créer des tickets « ça marche parfois ».

7) Avons‑nous besoin d’un RODC dans chaque site distant ?

Si le site doit continuer à authentifier quand le tunnel tombe, oui — envisagez‑le fortement.
Si le site peut tolérer la dépendance au VPN et utilise des identifiants en cache, peut‑être pas. Mais soyez honnête sur les besoins métier, pas sur l’espoir.

8) Pourquoi la réplication AD se plaint‑elle de RPC alors que le DNS semble OK ?

Le DNS vous amène au DC. RPC nécessite TCP 135 puis des ports dynamiques. Si ces ports dynamiques ne sont pas autorisés, la réplication échoue avec « RPC server unavailable ».
Voilà pourquoi la politique de ports doit inclure une stratégie pour les RPC dynamiques.

9) Quelle est la façon la plus rapide de prouver que c’est lié au MTU ?

Utilisez des pings « do not fragment » avec une taille proche du MTU supposé du chemin et observez les échecs, puis comparez le comportement avec et sans clamping MSS.
Les problèmes MTU apparaissent souvent comme des bizarreries SMB et DNS intermittentes plutôt que des pannes nettes.

10) Comment monitorer pour ne pas l’apprendre par le PDG ?

Lancez des contrôles synthétiques depuis chaque réseau distant : lookup SRV, reachabilité Kerberos, bind LDAP (si applicable), listing SMB de SYSVOL, et un résumé de réplication sur les DC.
Alertez sur les échecs et sur les seuils de latence/perte. Le meilleur incident est celui que vous avez discrètement résolu avant qu’on ne le nomme.

Prochaines étapes (pratiques)

Si vous ne faites que trois choses cette semaine : forcez le DNS correct via le VPN, appliquez une hiérarchie de temps saine, et rendez explicite et testable votre politique de ports/RPC.
Ensuite faites le travail adulte : mappez Sites/Subnets correctement et décidez où vous avez besoin de DC locaux/RODC.

Une idée paraphrasée souvent attribuée à des voix de l’ingénierie de fiabilité comme John Allspaw : Les systèmes échouent de façons prévisibles ; votre travail est de rendre ces défaillances visibles et récupérables.
C’est tout le jeu ici. AD sur VPN n’est pas magique. C’est de la plomberie. Faites la plomberie correctement, et elle reste ennuyeuse.