MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. VPN RRAS Windows Server 2022 : résoudre l’impossibilité de rejoindre Active Directory

VPN RRAS Windows Server 2022 : résoudre l’impossibilité de rejoindre Active Directory

Windows Server

Lorsque le tunnel VPN s’établit mais qu’il reste impossible de joindre Active Directory, l’utilisateur se retrouve bloqué : impossible de faire rejoindre la machine au domaine, de lancer une session figée sur un compte de domaine ou tout simplement de résoudre un nom interne. Le scénario est fréquent avec les installations RRAS fraîchement déployées sous Windows Server 2022 – souvent parce qu’un détail réseau a été négligé lors de la configuration initiale. Ce guide exhaustif décrit chaque point de contrôle, du DNS aux routes de retour, afin de restaurer une jonction de domaine fluide et durable.

Sommaire

Impossibilité pour un client VPN (RRAS) de joindre le domaine Active Directory

Vue d’ensemble du problème

  • Environnement :
    • Serveur RRAS Windows Server 2022 configuré avec un pool statique d’adresses IPv4 (ex. 10.10.50.0/24).
    • Client VPN Windows 10 Pro 22H2 utilisant le protocole PPP avec authentification NPS/Radius.
  • Symptôme : la connexion VPN aboutit, mais la tentative de jonction affiche :
    « An Active Directory Domain Controller (AD DC) for the domain xyz.com could not be contacted. »
  • Constats clés côté client :
    • L’adaptateur PPP reçoit bien l’IP du contrôleur de domaine (DC) comme serveur DNS.
    • Masque /32 (255.255.255.255) affecté par RRAS.
    • nslookup retourne « Non-existent domain » pour tout FQDN interne.
    • Aucune route statique configurée dans RRAS.
    • Les ports standards AD/DNS paraissent autorisés dans les pare‑feu.

Causes probables

CatégorieExplication
DNS non joignableLe client connaît l’adresse DNS interne mais les paquets ne parviennent pas jusqu’au DC : filtrage, absence de route retour ou NAT mal implanté.
Routage asymétriqueLe réseau LAN ignore le sous‑réseau dédié aux VPN : le DC voit partir les requêtes mais renvoie la réponse vers sa passerelle par défaut… pas vers RRAS.
Attribution IP/DNS incomplèteRRAS communique un serveur DNS secondaire public ou omet l’option DNS. Les requêtes se mélangent et échouent.
Ports ou stratégies ADUDP/TCP 53, 88, 389, 445, 135 ou 464 sont bloqués ; le compte utilisé n’a pas le droit Add workstations to domain.

Plan de résolution synthétique

  1. S’assurer que le DNS interne est bien fourni et joignable
    • Dans RRAS → Propriétés du serveur → IPv4, renseigner uniquement l’adresse IPv4 du contrôleur de domaine (10.10.10.11 par exemple).
    • Redémarrer le service RRAS puis exécuter ipconfig /all sur le poste client pour confirmer qu’aucun DNS public n’est conservé.
  2. Mettre en place les routes manquantes
    • Si le pool VPN (10.10.50.0/24) est hors du LAN du DC (10.10.10.0/24), ajouter :
      destination 10.10.50.0/24 via 10.10.10.5 # adresse LAN de RRAS sur le routeur ou le pare‑feu principal.
    • Alternative plus rapide : activer le NAT côté RRAS (« IPv4 → NAT → nouvelle interface ») afin que les requêtes sortent du VPN avec l’adresse LAN du serveur RRAS. Idéal pour une POC, moins pour la production.
  3. Vérifier la configuration IP attribuée au client
    • Le masque /32 n’est pas bloquant pour PPP mais certaines règles GPO ou logiciels de sécurité peuvent le rejeter.
    • Pour un masque « classique » :
      • Basculer RRAS en DHCP relay vers le serveur DHCP interne.
      • Ou élargir le pool statique et définir 255.255.255.0. Dans ce cas, prévoir les routes de retour comme au point 2.
  4. Contrôler le pare‑feu et les services AD
    • Profils Domaine, Privé et Public : autoriser explicitement TCP/UDP 53, 88, 135, 389, 445 et 464.
    • Côté contrôleur : ouvrir Server Manager → AD DS → Services : vérifier que Netlogon, Kerberos KDC, DNS Server et Active Directory Web Services sont en écoute.
    • Inspecter l’Observateur d’évènements : JournalID critiqueSignification RRAS20271, 20276Échec d’auth PPP, problème d’IP ou de certificats System422, 423Filtrage ICMP ou MTU trop réduit Directory‑Services5719, 1058Impossible de localiser un DC ou accès GPO défaillant
  5. Tests rapides après corrections nslookup dc1.xyz.com nltest /dsgetdc:xyz.com ping dc1.xyz.com -4 ipconfig /flushdns && ipconfig /displaydns Les quatre commandes doivent résoudre l’adresse interne du DC (10.10.10.11) puis répondre sans perte.

Astuce de contournement en environnement critique

Lorsque la machine est pressée de rejoindre le domaine pour un déploiement de masse, deux raccourcis sauvent la mise :

  • Brancher physiquement le poste sur le LAN la première fois, l’enregistrer dans le domaine, puis réutiliser la connexion VPN pour les sessions suivantes ; Kerberos tolère les changements d’IP tant que le nom DNS reste valide.
  • Créer à l’avance une réservation DHCP (ou un bail statique) couplée aux enregistrements A et PTR dans la zone DNS AD. Le client percevra alors un environnement crédible dès l’établissement du tunnel.

Comprendre l’option « Utiliser la passerelle par défaut sur le réseau distant »

Par défaut, le client Windows active cette case : tout son trafic (y compris Internet) transite donc par RRAS. L’avantage est de simplifier le dépannage DNS et routage puisque la table se réduit à :

0.0.0.0/0  → interface PPP
10.10.50.0/24  → interface PPP

Dès que la jonction fonctionne, vous pouvez passer en split‑tunneling : décochez l’option dans Panneau de configuration → Connexions réseau → Propriétés → TCP/IPv4 → Avancé et poussez des routes plus fines via PowerShell VPNv2 CSP ou un profil Intune.

Activer le DNS dynamique pour les IP VPN

Dans de nombreuses entreprises, la résolution inverse (PTR) ou les enregistrements A créés par RRAS sont absents. Sans ces entrées, certaines applications (SQL Server, Exchange, DFS) refuseront la connexion. Dans DHCP → Propriétés du serveur → DNS, cochez « Mettre à jour dynamiquement les enregistrements DNS » et validez que le compte dhcp possède l’ACL DNSUpdateProxy. Un redémarrage du service DHCP puis RRAS peut être nécessaire pour initialiser le handshake GSS‑TSIG entre les deux rôles.

Script PowerShell tout‑en‑un pour valider la configuration

# Variables à adapter
$VpnAdapter = "PPP-adapter"
$DcIp       = "10.10.10.11"
$VpnPool    = "10.10.50.0/24"

Write-Host "===== Vérification DNS ====="
Resolve-DnsName -Name "dc1.xyz.com" -Server $DcIp -ErrorAction SilentlyContinue |
    Select-Object Name,IPAddress

Write-Host "===== Routage ====="
Get-NetRoute -InterfaceAlias $VpnAdapter |
    Where-Object { $_.DestinationPrefix -eq $VpnPool }

Write-Host "===== Ports ouverts vers DC ====="
$ports = 53,88,135,389,445,464
foreach ($p in $ports) {
    Test-NetConnection -ComputerName $DcIp -Port $p -InformationLevel Quiet |
        ForEach-Object { "$p`t$($_)" }
}

Write-Host "===== Credentials ====="
nltest /sc_verify:xyz.com

Exécutez ce script avec des droits administrateur juste après la connexion VPN : vous disposez d’un état instantané des routes, de la résolution DNS et de l’accessibilité des services AD.

Synthèse et bonnes pratiques

  • Un DNS interne unique est la condition sine qua non : même un DNS public configuré en secours perturbera la découverte SRV _ldap._tcp.dc._msdcs.
  • Une route de retour doit exister dans le LAN ; sans elle, la réponse du DC meurt avant de rejoindre RRAS.
  • NAT ou DHCP peut simplifier la gestion des masques mais ajoute un point de traduction supplémentaire : surveillez les journaux en conséquence.
  • Journalisation : activez les logs Analytical et Debug dans Event Viewer → Applications and Services Logs → Microsoft → Windows → Ras pour décortiquer une négociation PPP complexe.
  • Sécurité : accorder temporairement le droit Add workstations to domain plutôt que d’utiliser Domain Admins pour une jonction ; pensez à le révoquer ensuite.

Conclusion

Dans la quasi‑totalité des cas, l’échec de jonction au domaine via RRAS se ramène à un trio : DNS mal diffusé, route de retour manquante ou filtrage de ports essentiels. En suivant l’itinéraire pas à pas (analyse du pool, contrôle des routes, test de chaque port Kerberos/LDAP, validation des enregistrements DNS), vous éliminez systématiquement chaque point de rupture. Une fois la jonction réussie, conservez un jeu de scripts PowerShell et de journaux Event Viewer comme base de référence. Vous disposerez ainsi d’une trousse de secours prête à l’emploi pour tout nouveau site RRAS ou tout changement d’infrastructure réseau.

En appliquant ces correctifs — DNS cohérent, routage symétrique et ports AD ouverts de bout en bout — le client VPN atteint enfin le contrôleur de domaine et rejoint Active Directory sans la moindre erreur.

Windows Server
DNS VPN RRAS Windows Server Active Directory
Sommaire