Guide de dépannage DirectAccess pour les administrateurs Windows
Vérification d’une plateforme DirectAccess : guide de dépannage à l’usage des administrateurs Windows
Bon voilà, vous venez de passer quelques heures à monter une plateforme DirectAccess et à l'instant fatidique du test fonctionnel ça ne marche pas (si ça fonctionnait du 1er coup ce ne serait pas marrant).
Alors effet Murphy ou erreur de configuration ?
Nous allons voir dans ce post quelques pistes pour le dépannage d'une plateforme DirectAccess. Dépannage basé sur ma propre expérience suite à la réinstallation de ma plateforme DirectAccess avec des versions RTM de Windows Server 2008 R2 et Windows 7 édition Entreprise.
Ce guide de dépannage est une première version, il n'est pas exhaustif et sera enrichi par la suite en fonction de mon expérience (ou de la votre si vous voulez me faire part de vos propres expériences via la page mail)
Ma plateforme de test est la suivante :
Pour plus d'informations sur le détail des différentes machines virtuelles, cf. l'article suivant :
https://blogs.technet.com/stanislas/archive/2009/06/01/ma-plateforme-windows-server-2008-r2-windows-7-avec-directaccess-des-informations-utiles.aspx
Etape 1 : revérifier les prérequis nécessaires à DirectAccess
La liste est disponible depuis la page de garde de la console d'administration de DirectAccess :
Il faut donc :
- vérifier la présence d'au moins un contrôleur de domaine Active Direction en Windows Server 2008 (ou version ultérieure)
- vérifier la présence d'une autorité de certification interne
- vérifier la présence d'une stratégie de groupe pour l'autoenrollment des certificats. Cette GPO doit s'appliquer aux postes clients DirectAccess ainsi qu'au(x) serveur(s) DirectAccess
- vérifier la présence de poste client Windows 7 Entreprise ou Ultimate qui soient membres du domaine
- que ces postes clients doivent recevoir la GPO autoenrollment
- que ces postes doivent faire parti d'un groupe de sécurité dans AD
- que vous avez autorisé les équipements réseaux filtrant entre Internet et votre serveur DirectAccess à laisser passer les flux nécessaires (Teredo sur UDP 3544, TCP 443 pour IP-HTTPS, le protocole 41 pour 6to4....)
- configurer le pare-feu Windows du serveur DirectAccess pour autoriser en entrée les flux Teredo (UDP 3544) et IP-HTTPS
- s’assurer de la présence d'au moins un serveur NLS (Network Location Server) accessible en https depuis le LAN avec l'URL https://nls.nomdedomaineintranet
- que pour tous les serveurs DNS internes, le nom ISATAP a été retiré de la liste Global Query Block
Etape 2 : vérifications sur le serveur DirectAccess (LH03R2 dans mon exemple)
Dans la console d'administration de DirectAccess, sélectionner Monitoring
important :
- quand une icône est en orange, cela signifie que le service fonctionne mais n'est pas en cours d'utilisation
- quand une icône est en vert, cela signifie un trafic réseau via l'interface/service concerné
- quand l'icône est rouge, alors il y a un problème et c'est là qu'on attaque le débugage avec quelques lignes de commandes
Vérification de la configuration IP du serveur. Celui-ci doit avoir 2 adresses IPv4 publiques consécutives sur l'interface Internet (nécessaires pour Teredo)
sur l'interface réseau interne, le serveur DA doit avoir une adresse IPv6 ISATAP pour le tunnel adapter isatap.w2K8R2-demo.net. L'adresse IPv4 visible à la fin de cette adresse IPv6 doit correspondre à l'enregistrement A ISATAP défini dans le DNS interne pour la zone DNS du domaine.
Vérification du status ISATAP
Vérification que le serveur DA est bien un routeur ISATAP
Vérification que le serveur DA est bien un routeur 6to4 : Netsh interface ipv6 show interface “6to4 adapter”
Vérification que le serveur DA est bien un serveur Teredo :
Vérification du serveur IP-HTTPS
Vérification que le serveur DA dispose bien de tous ses certificats, il en faut :
- 1 pour IPsec (distribué via GPO la plupart du temps)
- 1 pour le serveur IP-HTTPS
Etape 3 : vérification des serveurs DNS
Vérifier sur le(s) serveur(s) DNS externe(s) que les noms suivants sont bien résolus avec des IP externes :
- le nom du serveur web hébergeant la CRL (ex: crl.macompagnie.fr)
- le nom du serveur IP-HTTPS (ex: da.macompagnie.fr) qui doit résoudre la première adresse IP externe du serveur DA
Vérifier sur le(s) serveur(s) DNS internes que les noms suivants sont bien résolus :
- l'enregistrement A nls.nomdedomaineinterne doit pointer sur l'adresse IP du serveur web NLS (ou sur la VIP dans le cas d'une ferme de serveurs)
- l'enregistrement A isatap.nomdedomaineinterne doit pointer sur l'adresse IP interne du serveur DirectAccess
Etape 4 : vérification sur le poste client Windows 7
1- Quand le poste est connecté sur le LAN
Vérifier qu'il peut se connecter sur le serveur NLS avec l'URL https://nls.nomdedomaineinterne.
vérifier que le poste a bien un certificat machine (récupéré via la GPO d'autoenrollment)
Vérifier que la NRPT est bien désactivée quand le poste est sur le LAN :
Ouvrir la console avancée du pare-feu Windows et vérifier la présence de règles IPsec
2- quand le poste est connecté à l'extérieur du réseau d'entreprise
Afficher la NRPT qui cette fois-ci doit ressembler à la capture suivante :
Ceci est la configuration de la NRPT qui a été appliquée via GPO, maintenant pour voir ce qui est réellement actif :
Tenter un ping -t avec le nom court du serveur contrôleur de domaine. Normalement, on doit avoir la résolution et un ping en IPv6.
Se connecter sur un partage (ou un autre service, histoire de tester autre chose que le ping en ICMP) sur un DC par exemple :
Si ça fonctionne, à priori tout se passe bien, on peut vérifier la présence d'association de sécurité dans la console avancée du pare-feu Windows
3- Quand le poste est connecté à l'extérieur de l'entreprise, derrière un équipement faisant du NAT
Le comportement par défaut est d'utiliser Teredo comme méthode de transition IPv4 vers IPv6
Vérification du fonctionnement du client en Teredo : affichage de la configuration IP
Si Teredo a été désactivé, il est possible de le réactiver avec la commande suivante :
4- Quand le poste est connecté à l'extérieur de l'entreprise, derrière un équipement filtrant mais laissant passer HTTPS
Le comportement par défaut est d'utiliser IP-HTTPS comme méthode de transition IPv4 vers IPv6.
Note : il est possible de désactiver Teredo pour forcer l'utilisation de IP-HTTPS derrière un NAT
Vérifier que le poste peut se connecter au serveur hébergeant les listes de révocation de certificat (CRL)
Note : si la CRL est sur un serveur IIS 7.0 (Windows Server 2008) ou IIS 7.5 (Windows Server 2008 R2), il faut penser à autoriser le Double Escaping pour permettre aux clients de télécharger les fichiers de CRL et DeltaCRL. Plus d'informations sur :
Double escaping with IIS7 is a known issue with delta CRLs.
https://blogs.technet.com/pki/archive/2008/02/25/how-to-avoid-delta-crl-download-errors-on-windows-server-2008-with-iis7.aspxVérification du fonctionnement du client en IP-HTTPS: affichage de la configuration IP :
Voilà, j’espère que cette première version de mon guide de dépannage de DirectAccess vous sera utile et vous fera gagner quelques heures ;-)
Tags: dépannage, troubleshooting, troubleshooting+guide, guide+de+survie