DirectAccess : mythes & réalité - partie 3 : la résolution de noms DNS
Note : cet article fait partie d'un ensemble d'articles sur DirectAccess, les 2 premiers sont visibles aux adresses suivantes :
IPv6 :
https://blogs.technet.com/stanislas/archive/2009/06/08/directaccess-mythes-r-alit-partie-1-ipv6.aspx
Windows 7 couplé à Windows Server 2008 R2 offre une nouvelle fonctionnalité destinée aux professionnels baptisée DirectAccess.
DirectAccess permet à l'utilisateur de se connecter à distance au Système d'Information de l'entreprise de manière complètement transparente. Les personnes qui utilisent aujourd'hui Outlook 2003 ou 2007 couplé à Exchange Server 2003 ou 2007 avec la fonctionnalité RPC sur HTTPS connaissent déjà une première expérience de la transparence des accès distants : il suffit de démarrer le client de messagerie et celui-ci trouve tout seul le moyen de se connecter au serveur Exchange que le poste soit connecté sur Internet ou au sein du réseau local. Et bien DirectAccess, c'est la même expérience mais appliquée à l'ensemble des applications exécutées sur Windows 7.
Une architecte basique DirectAccess ressemble au schéma suivant :
Beaucoup de personnes se documentant (ou ayant vu mon schéma ci-dessus) sur DirectAccess se posent des questions concernant la résolution de noms DNS voire certaines idées reçues :
- Est ce qu'il faut un(des) serveur(s) DNS externes répliquant les DNS de l'intranet ?
- Est ce qu'il n'y a pas un risque à exposer les noms et adresses IP de l'Intranet sur des DNS publiques ?
- Est ce qu'il faut des serveurs DNS sous windows Server 2008 R2 ?
- Comment est ce que cela se passe si j'ai un nom utilisé en interne et en externe mais pas avec les mêmes adresses ?
- Est ce que DirectAccess fonctionne même avec des noms courts ?
- Comment cela fonctionne la résolution de noms pour un client DirectAccess ?...
L'objectif de ce post est de démystifier certaines idées reçues ou interrogations sur DirectAccess & la résolution de noms
Est ce qu'il faut un(des) serveur(s) DNS externes répliquant les DNS de l'intranet ?
Non, DirectAccess n'a pas besoin de serveurs DNS externes supplémentaires (installés dans une DMZ par exemple) contenant les informations des DNS de votre Intranet / Active Directory.
Est ce qu'il n'y a pas un risque à exposer les noms et adresses IP de l'Intranet sur des DNS publiques ?
DirectAccess ne nécessite pas d'exposer les noms et adresses IP de l'Intranet sur des DNS publiques. Les seules informations qui seront disponibles sur les DNS publiques sont :
- le nom et adresses publiques du serveur DirectAccess. Rien de bien différent par rapport à une passerelle VPN classique
- éventuellement le nom et adresse de la CRL si le certificat utilisé pour IP-HTTPs a été généré par une autorité de certification interne
Est ce qu'il faut des serveurs DNS sous windows Server 2008 R2 ?
Non, il faut un serveur DNS supportant IPv6. Donc si vous avez un(des) serveur(s) Active Directory sous Windows Server 2008 ça fonctionne (à vérifier avec d'autres implémentations DNS IPv6)
Comment est ce que cela se passe si j'ai un nom utilisé en interne et en externe mais pas avec les mêmes adresses (et donc déclarées sur un DNS externe et un DNS interne)?
Si le nom de domaine de cette ressource fait parti de ceux paramétrés via l'assistant de configuration de DirectAccess (cad : le nom de domaine AD) alors les clients DirectAccess résoudront le nom avec l'adresse IP interne. Il est possible de modifier ce comportement par défaut en créant une exception dans la NRPT (Name Resolution Policy Table).
Est ce que DirectAccess fonctionne même avec des noms courts ?
Oui, le client ajoute de lui-même le nom de domaine. il est donc possible au client de se connecter à des ressources avec des noms courts (ex: connexion à une ressources CIFS comme \monserveurshare)
Comment cela fonctionne la résolution de noms pour un client DirectAccess ?
C'est assez simple, on utilise une des nouveautés de windows 7 : la NRPT (Name Resolution Policy Table).
Cette table contient une liste d’espace de noms avec les adresses des serveurs DNS associés. Vous l'aurez compris, c'est une sorte de conditional forwarding côté poste client (le conditional forwarding est arrivé côté serveur avec Windows Server 2003)
exemple de table NRPT, telle qu'on la configure dans l'assistant de configuration de DirectAccess :
Si pour une requête, le nom correspond à une entrée de la NRPT, la requête est envoyée au serveur DNS spécifié dans la NRPT
Ce sont les adresses des DNS internes qui n’ont pas besoin d’être exposés dans une DMZ
Si le nom requêté ne correspond pas à une entrée de la table NRPT, la requête part vers le serveur DNS paramétré sur l’interface réseau
Nouvel ordre de résolution de nom dans Windows 7 :
1- Cache local
2- Fichier Host
3- NRPT
4- DNS Internet
Pour voir la configuration la table NRPT sur un poste Windows 7, vous avez au moins 2 options :
– La première est de visualiser la résultat de l’application des stratégies de groupes en utilisant gpresult ou rsop.msc :
– la seconde est d’utiliser la commande netsh name show policy
Et voilà vous savez presque tout sur la résolution de noms DNS dans DirectAccess.
A bientôt pour la suite des mythes & réalité autour de DirectAccess.
Informations complémentaires :
Appendix D – Scripted and Group Policy DirectAccess Client Installation Instructions
https://technet.microsoft.com/en-us/library/dd637798(WS.10).aspx
Tags: Résolution+de+noms, DNS, NRPT, Name+Resolution+Policy+Table
Comments
- Anonymous
October 09, 2014
DirectAccess : mythes & réalité - partie 3 : la résolution de noms DNS - Stanislas Quastana's blog on TechNet - Site Home - TechNet Blogs