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 :
http://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.
http://blogs.technet.com/pki/archive/2008/02/25/how-to-avoid-delta-crl-download-errors-on-windows-server-2008-with-iis7.aspx

Vé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 ;-)