다음을 통해 공유

DirectAccess : mythes & réalité - partie 4 : Détermination du réseau et utilisation ou pas de DirectAccess

  • 아티클

Note : cet article fait partie d'un ensemble d'articles sur DirectAccess, les 3 premiers sont visibles aux adresses suivantes :

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 l'activation ou non de la connectivité DirectAccess :

- Quand le client DirectAccess démarre la connexion DirectAccess ?
- Comment le poste client DirectAccess détermine le type de réseau sur lequel il est connecté ?
- Que veut dire NLS et à quoi ça sert ?
- Comment fonctionne la détection de l'Intranet ?
- Peut-on faire du DirectAccess alors qu'on a une connexion VPN montée sur le réseau de l'entreprise?

L'objectif de ce post est de démystifier certaines idées reçues ou interrogations sur la détermination du réseau et l’utilisation ou pas de DirectAccess

Quand le client DirectAccess démarre la connexion DirectAccess ?

Quand un poste Windows 7 client DirectAccess se connecte à un réseau, il cherche en priorité à déterminer si ce réseau fait partie du réseau interne (Intranet) de l'entreprise ou si, au contraire, c'est un réseau externe à l'entreprise (ex: Internet, Hotspot wifi public, réseau domestique, réseau d'un partenaire, fournisseur...) auquel cas, il va utiliser les connexions DirectAccess.

Comment le poste client DirectAccess détermine le type de réseau sur lequel il est connecté ?

Windows 7 comme Windows Vista pourrait s'appuyer sur les mécanismes existants de détection de réseaux (cf. article Technet suivant : https://technet.microsoft.com/en-us/library/cc766017.aspx) mais cela ne permet pas de déterminer si un réseau local est celui de son entreprise ou pas.

Le mécanisme de détection utilisé dans Windows 7 pour DirectAccess est donc un mécanisme permettant au poste de savoir s'il est connecté ou non à l'Intranet de son entreprise.

Pour déterminer s'il est connecté sur l'Intranet de l'entreprise ou pas, le poste client DirectAccess va rechercher et interroger un serveur NLS.

 

Que veut dire NLS et à quoi ça sert ?

Un serveur de localisation (NLS : Network Location Server) est un serveur sur le réseau local de l'entreprise qui héberge une URL de localisation accessible via HTTPS. Ce serveur Web va héberger une simple page Web qui ne sera accessible en HTTPS que depuis l'Intranet. Du fait de la simplicité technique de ce rôle, il est clair qu'il n'est pas nécessaire de lui dédier un serveur. Le NLS peut être installé sur une machine ayant d'autres fonctions, ou d'autres services Web.

Pour assurer une haute disponibilité du service NLS (qui, je le rappelle, est nécessaire et obligatoire aux clients Windows 7 pour se connecter en DirectAccess), il faut avoir au moins 2 serveurs hébergeant cette ressource (avec un mécanisme de répartition de charge type DNS RoundRobin, NLB ou autre équipement d'équilibrage de charge réseau)

Attention : il faut que ce(s) serveur(s) de localisation soient accessible(s) depuis l'ensemble des réseaux internes de l'entreprise, y compris les réseaux d'agences donc attention où vous le positionnez.

Il est également recommandé d'installer, si c'est possible, le serveur NLS sur une autre machine que le serveur DirectAccess

 

Comment fonctionne la détection de l'Intranet ?

Quand un client Windows 7 DirectAccess démarre ou détecte un changement au niveau réseau (nouvelle adresse IP, nouveau status de l'interface réseau...), il considère qu'il n'est plus sur l'Intranet et utilise alors les entrées de la NRPT (cf. l'article sur la résolution de noms DNS écrit précédemment) pour déterminer où envoyer les requêtes de résolution de nom DNS.

Le client va alors essayer de résoudre le FQDN (Full Domain Qualified Name) de l'URL de localisation (page accessible en HTTPS sur le serveur NLS, généralement nls.nomdededomaineintranet). Comme la NRPT est active (car le poste Windows 7 ne se considère plus sur l'Intranet), le FQDN de l'URL doit correspondre à une exception de la NRPT obligeant ainsi le client à transférer la résolution de nom au serveur DNS renseigné dans les propriétés TCP/IP de l'interface réseau.

Si le client est connecté sur le réseau de l'Intranet, il va donc interroger les DNS de l'Intranet qui vont lui renvoyer la réponse (@IP du serveur Web NLS). Si le poste est connecté sur un autre réseau que l'Intranet, il n'obtiendra pas de réponse (car ce nom ne doit pas exister dans les DNS publics) donc fin de l'histoire : le poste n'est pas sur l'Intranet, il monte donc ses connexions DirectAccess.

Si le poste est bien sur l'Intranet et que les serveurs DNS Intranet ont répondu à sa requête, alors il tente d'établir une connexion en HTTPS sur le serveur NLS (en anonyme ou authentification NTLM) et vérifie également le certificat SSL présenté par le serveur Web (vérification du nom ou adresse IPv4 du serveur dans le certificat, vérification si le certificat n'a pas été révoqué).

Si la vérification du certificat et la connexion en HTTPS sont réussies, alors le poste Windows 7 considère qu'il est connecté à l'Intranet, il désactive les entrées NRPT de sa table de résolution et fait désormais les demandes de résolution de noms directement auprès des DNS configurés sur l'interface réseau (généralement les DNS de l’Active Directory).

Note : la vérification du status de révocation du certificat implique la disponibilité sur l'Intranet d'une (ou plusieurs) liste(s) de révocation de certificats (CRL : Certification Revocation List). Les FQDNs utilisés pour accéder aux CRLs doivent également être déclarés comme exceptions dans la NRPT.

Peut-on faire du DirectAccess alors qu'on a une connexion VPN montée sur le réseau de l'entreprise ?

Normalement non. Car dans ce cas le client est virtuellement connecté à l'Intranet et utilise donc les DNS Intranet et devrait pouvoir se connecter au(x) serveur(s) NLS (généralement, les entreprises ne filtrent pas les ressources internes accessibles via les connexions VPN nomades).

Et voilà vous savez presque tout sur la détermination du réseau et l’activation ou pas de DirectAccess sur les postes Windows 7 (versions Entrerprise ou Ultimate)

A bientôt pour la suite des mythes & réalité autour de DirectAccess.

Informations complémentaires  :

Determination of On-Intranet or Off-Intranet
https://technet.microsoft.com/en-us/library/dd637781(WS.10).aspx

Tags: NLS, Network+Location+Server