DirectAccess : installation d'une plateforme avec Forefront UAG, pas d'IPv6 dans l'Intranet et des DC & DNS en Windows Server 2003 - partie 3 : tests, bilan et perspectives

  • Article

L'objectif de cette nouvelle série de billets consacrés à DirectAccess et Forefront UAG 2010 est de voir les apports de Forefront Unified Access Gateway dans une architecture DirectAccess un peu particulière : un Intranet entièrement en IPv4 et avec des contrôleurs de domaines et des DNS internes en Windows Server 2003. L'idée étant de tester si dans ce type d'environnement, il serait possible de faire du DirectAccess avec des postes Windows 7 (Entreprise ou Intégrale). Et si tel est le cas, de lister les limitations inhérentes à cette plateforme.

Si vous avez loupé les 2 premières parties de cette série, vite vite cliquez sur le lien suivant : https://blogs.technet.com/stanislas/archive/2009/11/27/directaccess-installation-d-une-plateforme-avec-forefront-uag-pas-d-ipv6-dans-l-intranet-et-des-dc-dns-en-windows-server-2003-partie-2-configuration.aspx

Cette troisième partie va être consacrée aux tests de fonctionnement, au bilan (ce qui marche, ce qui ne fonctionne pas) et aux perspectives.

Tout d’abord, on peut vérifier que le script de configuration DirectAccess a bien créer 2 stratégies de groupe au niveau du domaine : une pour configurer les postes clients, l’autre pour configurer le(s) serveur(s) Forefront UAG

Note : je ne recommande pas d’éditer ces GPO directement depuis les outils en standard de Windows Server 2003. Il vaut mieux utiliser la GPMC sur le serveur Forefront UAG ou mieux depuis un poste Windows 7 avec les RSAT (Remote Server Administration Tools. cf. ici).

Maintenant si on ouvre la console d’administration du DNS et qu’on se positionne sur la zone DNS de l’Active Directory, on constate la présence de 2 enregistrements avec des adresses IPv6 (et ce malgré le fait que le serveur DNS Windows Server 2003) n’ait pas d’adresse IPv6. On remarque l’adresse IPv4 du client Windows 7 (WINDACLIENT) qui est connecté pour l’instant sur le LAN.

L’adresse IPv6 enregistrée pour le nom UAG2 correspond à son adresse IPv4 publique (la première des 2 : 131/107.0.2) transformée via le mécanisme de transition 6to4

l’adresse UAGDirectAccess-corpConnectivityHost correspond à l’adresse loopack (en version IPv6)

On va maintenant mettre à jour la configuration du poste client Windows 7.

Puis on désactive son interface sur le LAN et on active l’interface WAN (Internet) ==> ici on simule un poste qui quitte le réseau de l’entreprise et qui obtient par la suite une connectivité à Internet.

Ensuite on teste la connectivité au système d’information via par exemple un PING vers le contrôleur de domaine (qui je le rappelle n’est qu’en IPv4). La connectivité fonctionne et on remarque que la connexion est en IPv6 (normal c’est du DirectAccess), la transition du monde IPv6 vers IPv4 (Client DirectAccess —IPv6 —> Forefront UAG —IPv4 —> DC01) étant assuré par le NAT64/DNS64 de Forefront UAG.

Au delà un ping qui est traité via une exception (ICMP dans les règles de pare-feu), on vérifie la connectivité à des services tels que le partage de fichier sur le DC01 et le serveur de fichier FILE01

Si on retourne sur le serveur DNS, on constate la présence d’enregistrement IPv6 dynamique pour le client DirectAccess (Ces enregistrements dynamiques sont en fait réalisés par le DNS64 de Forefront UAG. A ma connaissance le DNS 2003 ne sait pas accepter l’enregistrement dynamique d’un client Windows en IPv6)

Là c’est un peu différent d’avec un serveur DA uniquement Windows Server 2008 R2 et avec un DNS 2008 / 2008 R2 où il ne devrait y avoir qu’une seule adresse IPv6 enregistrée directement et dynamiquement par le client Windows 7 (qui a l’adresse IPv4 131.107.0.110 sur “Internet”)

La première adresse IPv6 : 2001:0000:836b:0002:14e1:36b0:7c94:ff91 correspond à une adresse Teredo (on remarque dans la version “formatée pour être lisible” l’adresse du relais Teredo qui est la première IPv4 de Forefront UAG côté Internet et l’adresse IPv4 du client )

La seconde adresse IPv6 : 2002:836b:006e:0000:0000:0000:836b:006e est une adresse 6to4 (ce qui est la méthode normalement retenue vu l’adressage IPv4)

Si on déplace maintenant le client Windows 7 DirectAccess derrière un NAT, il bascule en Teredo

et DirectAccess fonctionne bien là encore

Là encore l’enregistrement au niveau DNS est mis à jour

Cette adresse décomposée montre bien l’adresse publique du routeur NAT (131.107.0.200)

Du coup quand on a vu tout cela, on peut se dire c’est génial tout marche !!!

Oui côté utilisateur, cela ne fait effectivement aucune différence (je n’en ai pas noté pour l’instant)

Par contre côté administrateur, avec l’usage d’IPv4 uniquement sur le LAN (donc pas d’IPv6 natif ou transité avec ISATAP) et la généralisation de l’utilisation de NAT64/DNS64, on pert pas mal de choses :

1– il n’est pas possible d’émettre une connexion sortante du réseau de l’entreprise vers le poste client sur Internet car les clients DA sont je le rappelle uniquement connectés via IPv6. Donc non seulement la résolution ne va pas fonctionner car il n’y a pas d’adresse IPv4 exploitable. La connectivité n’est pas non plus assurée car le NAT64/DNS64 ne va pas faire la conversion d’un dialogue initié en IPv4 vers de IPv6 (c’est l’inverse qu’il permet : IPv6 —> IPv4).

  • Donc toutes les opérations telles que la connexion à distance via Remote Desktop ou autre solution de prise de contrôle ne vont pas fonctionner —> ça c’est assez dommage car c’est extremement utiliser par les supports interne pour aider les utilisateurs en difficulté (en plus si c’est des VIPs, c’est encore plus critique si ils sont géographiquement éloignés)
  • Idem si vous avez des outils type scanner de sécurité pour analyser à distance des machines
  • Idem si vous avez des outils d’inventaires
  • Idem si vous exécutez des scripts
  • Idem pour toute solution initialisée depuis le réseau en IPv4 à destination des stations de travail
  • connexion en SMB/CIFS sur la machine cliente distante
  • …

2– Le NAT64 comme tout bon NAT implique une rupture des flux réseaux ce qui limite les possibilités en terme de modèle d’accès aux serveurs d’applications. Si vous voulez assurer de l’authentification de bout en bout ou pour des groupes de serveurs d’applications (cf. ici pour plus de détails), alors il va falloir revoir la copie et disposer d’un peu d’IPv6 (natif ou transité avec ISATAP) et de serveurs 2008 / 2008 R2 dans votre réseau.

Reste cependant des applications de types management qui vont bien fonctionner : toutes celles dont les opérations sont initiées par les postes clients comme par exemple :

  • Recherche et téléchargement des mises à jour depuis un serveur WSUS ou SCCM
  • Application des stratégies de groupes
  • Téléchargement de fichiers de signatures Antivirale

Perspectives : pour moi, commencer à faire du DirectAccess devient finalement assez aisé avec l’usage de Forefront UAG 2010, car certaines barrières technologiques (voire psychologiques :-)) telles que la présence d’IPv6 sur le réseau Interne sont levées. Donc pourquoi ne pas commencer rapidement à tester DirectAcces et faire évoluer ensuite l’architecture (ajout d’IPv6 en natif ou transité sur le LAN, authentification mutuelle avec des groupes de serveurs d’applications…) afin de disposer et profiter de l’ensemble du potentiel de DirectAccess.

Voilà c’est terminé pour cette mini-série de billet sur la mise en oeuvre de DirectAccess avec des DC 2003 en IPv4 uniquement, un Intranet IPv4 uniquement et du Forefront UAG 2010.

Tags: Windows+Server+2003