Stanislas Quastana's blog on TechNet

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 :

IPsec :
http://blogs.technet.com/stanislas/archive/2009/06/29/directaccess-mythes-r-alit-partie-2-ipsec.aspx

IPv6 :
http://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 \\monserveur\share)

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
http://technet.microsoft.com/en-us/library/dd637798(WS.10).aspx

DirectAccess & Teredo : le cas des flux sortants du LAN Entreprise vers les clients DirectAccess

Si vous avez essayé de monter une plateforme DirectAccess (en suivant le guide pas à pas), vous avez peut-être constaté un problème de connectivité depuis une machine du réseau de l'entreprise (par exemple un DC) à destination d'un client DirectAccess connecté via Teredo (c'est à dire derrière un équipement réseau faisant du NAT).

Ce problème ayant été remonté par un client, j'ai cherché une solution à ce problème bien limité au client DirectAccess connecté en Teredo (en 6to4 ou IP-HTTPS, pas de soucis). Je remercie au passage mon collègue Arnaud Lheureux qui m'a très très bien aiguillé !!

Voyons dans un schéma (très) basique, l'architecture en place :

Ici le but est de pouvoir, dans un premier temps, faire du ping et du Bureau à distance depuis le réseau de l'entreprise (ici le DC par exemple) vers le client Windows 7 en DirectAccess.

Si on teste la configuration après avoir suivi le guide pas à pas (qui est une version encore en brouillon donc soyons indulgents :-)), tout ne fonctionne pas :

Le ping depuis le client DirectAccess vers le DC, ça marche :

L'inverse, le ping depuis le DC vers le client DirectAccess en Teredo ne fonctionne pas

Le problème vient en fait de la présence d'un NAT et du pare-feu de Windows 7. Si on regarde la configuration de celui-ci sur la règle autorisant en entrée ICMPv6, on remarque une option avancée :

Sans rentrer dans le détail de cette option (je vous invite à lire suivre les liens indiqués en fin de ce billet), disons qu'elle permet à des applications d'être accessibles depuis l'extérieur (Internet) malgré la présence d'un NAT.

Donc il va falloir changer ce paramètre dans la GPO configurant le pare-feu Windows des clients DirectAccess

Une fois que le poste aura récupéré sa GPO et appliqué cette modification, cela devrait fonctionner beaucoup mieux pour le ping depuis le DC !

Maintenant, il ne vous reste plus qu'à rajouter dans la GPO, les règles de pare-feu entrantes pour les applications/flux que vous souhaitez autoriser (ex: le bureau à distance...). ça y est comme ça DirectAccess commence vraiment à devenir sexy ;-)

Informations complémentaires sur le paramètre Edge Traversal & Teredo :

Implementing the Teredo Security Model
http://msdn.microsoft.com/en-us/library/bb190942%28VS.85%29.aspx

Receiving Unsolicited Traffic Over Teredo
http://msdn.microsoft.com/en-us/library/aa965911%28VS.85%29.aspx

Adding an Application Rule to Allow Dynamic Edge Traversal
http://msdn.microsoft.com/en-us/library/dd607244%28VS.85%29.aspx

Teredo owerview
http://technet.microsoft.com/en-us/library/bb457011.aspx

Connexion à 2 fournisseurs d'accès Internet dans Forefront TMG (beta 3) : guide pas à pas

Une des nouveautés de Forefront TMG est (enfin) la possibilité d'avoir plus d'une seule connexion vers un fournisseur d'accès à Internet. Tout le monde sera d'accord, Internet devenant un outil de travail à part entière (spécialement quand on utilise des services hébergés), il devient inconcevable de perdre ce lien de connexion vers le réseau des réseaux.

Forefront TMG permet donc la configuration de 2 connexions à des fournisseurs d'accès internet différents avec deux mode de configuration :

• Tolérance de panne avec l'utilisation d'une des 2 connexions comme lien primaire, la seconde assurant le rôle de ligne de secours en cas de perdre de la première connexion FAI. Dans ce scénario, la seconde ligne sera probablement une ligne avec un débit plus réduit mais néanmoins suffisant pour continuer de travailler le temps de dépanner la première.
• Equilibrage de charge avec l'utilisation en permanence des 2 lignes, l'équilibrage des flux se faisant en attribuant un pourcentage d'usage d'une ligne par rapport à l'autre.

 Voyons maintenant en images la mise en oeuvre de la tolérance de panne :

Dans ma configuration, mon serveur dispose de 3 interfaces réseaux : une pour le réseau  local, les 2 autres pour les connexions aux FAIs.

Pour configurer 2 connexions vers Internet, sélectionner Networking dans l’arborescence à gauche.

Cliquer sur Configure ISP Redundancy dans le panneau de tâches en haut à droite

On choisit ici le mode à utiliser : ici j’ai choisi la tolérance de panne avec un lien primaire et un lien de secours

On sélectionne ensuite l’interface réseau du premier fournisseur d’accès

On valide les paramètres IPv4 (il faut absolument une passerelle par défaut)

On sélectionne ensuite l’interface réseau du second fournisseur d’accès

On valide les paramètres IPv4 (il faut absolument une passerelle par défaut)

On choisit enfin qui sera le lien primaire (celui qui n’est pas sélectionné devient donc le lien de secours)

On valide l’assistant

On applique les changements

On donne une description des changements (même fonctionnalité que ISA Server 2006 SP1)

Et voilà c’est fini

La version avec l’équilibrage de charge dans un prochain post :-)

DirectAccess : mythes & réalité - partie 2 : IPsec

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.

A la différence d'une connexion VPN nomade (classique ou SSL), DirectAccess ne nécessite aucune intervention de l'utilisateur, il n'y a pas de connexion à établir au travers d'un gestionnaire de connexion.

Commençons par un schéma très basique d’une architecture DirectAccess :

Parmi les technologies nécessaires et utilisées par DirectAccess, on voit bien sur ce schéma qu’il y a IPv6 et IPsec

IPv6 a été traité dans un billet précédent : cf. DirectAccess : mythes & réalité - partie 1 : IPv6  (http://blogs.technet.com/stanislas/archive/2009/06/08/directaccess-mythes-r-alit-partie-1-ipv6.aspx)

Beaucoup de personnes se documentant (ou ayant vu mon schéma ci-dessus) sur DirectAccess voient IPsec dans la liste des pré-requis, ce qui génère beaucoup d'interrogations et d'idées reçues
- C'est quoi IPsec ?
- IPsec ce n'est que pour les tunnels VPN ?
- IPsec c'est pour chiffrer les communications ?
- IPsec est-il vraiment nécessaire pour DirectAccess ?
- ...

L'objectif de ce post est de démystifier certaines idées reçues ou interrogations sur DirectAccess & IPsec

Tout d'abord : qu'est ce que IPsec ? Est ce que c'est que pour les VPN (Virtual Private Network) ?

Comme son nom l’indique IPsec opère au niveau IP (couche 3 ou réseau du modèle théorique OSI de l’ISO) et permet d’établir un canal sécurisé pour échanger de manière protégée des données entre deux périphériques (machines, routeurs, …)

Deux modes de fonctionnement existent :

• Mode tunnel
•  Sécurisation du trafic entre 2 réseaux (de routeur à routeur, typiquement : entre 2 passerelles VPN)
•  Protection de l’entête et de la charge
• Mode transport
• Sécurisation du trafic entre 2 machines (de PC à PC en passant par des routeurs)
• Protection de la charge seulement
• Ce mode est utilisé typiquement sur des LANs pour sécuriser les communications IP entre 2 ordinateurs (un client et un serveur par exemple)

Mode tunnel et mode transport sont utilisés dans DirectAccess en fonction du scénario d'implémentation choisi :

1. Le mode tunnel (du client DirectAccess vers le serveur DirectAccess) pour le scénario Full intranet access (end-to-edge)
   
   
2. Le mode transport et le mode tunnel sont utilisés pour le scénario Selected server access (modified end- to-edge)
   
3. Le mode transport est utilisé pour scénario End-to-end
   

Information complémentaires sur ces scénarios : http://technet.microsoft.com/en-us/library/dd637836(WS.10).aspx

IPsec c'est pour chiffrer les communications ?

Oui et Non, IPsec peut être utilisé aussi pour authentifier les communications entre 2 machines.

2 modes sont utilisés dans IPsec : AH et ESP

• AH (IP Authentication Header) - RFC 2402
• Permet de faire de l'authentification mutuelle
• Assure l'intégrité des données transmises et de l’adresse IP (sans chiffrement)
• Ne traverse pas le NAT (Network Adress Translation)

Le trafic IPSec AH modifie les paquets IP de la manière suivante :

• ESP (IP Encapsulating Security Payload) - RFC 2406
• Permet aussi l'authentification mutuelle
• Assure l'intégrité et le chiffrement des données échangées
• Traverse le NAT

Le trafic IPSec ESP modifie les paquets IP de la manière suivante :

Il est possible de cumuler les 2 fonctions (Authentification et chiffrement des données) en utilisant ESP et AH.

Pour faire passer des flux IPSec au travers d’un pare-feu, il suffit d’autoriser les flux suivants :
• Protocole IP – 50 : Trafic IPSec Encapsulating Security Protocol (ESP)
• Protocole IP – 51 : Trafic IPSec Authentication Header (AH)
• UDP 500 pour le trafic de négociation Internet Key Exchange (IKE)

IPsec est-il vraiment nécessaire pour DirectAccess ?

Oui, vous l'aurez compris, dans DirectAccess, IPsec est nécessaire dans DirectAccess pour assurer :
- La confidentialité des données échangées (entre le client DirectAccess et le serveur DirectAccess ou entre le client et les serveurs internes)
- L'authentification lors des communications entre les postes DirectAccess et des serveurs (DirectAccess ou internes)

Liens utiles pour aller plus loin dans la découverte d’IPsec :

Le portail IPsec sur microsoft.com
http://www.microsoft.com/ipsec

[Microsoft TechDays 2009] - La sécurité de demain : Et si l’on repensait la notion de périmètre ?
par Bernard Ourghanlian
http://www.microsoft.com/france/vision/mstechdays09/Webcast.aspx?EID=a64edf40-0f8d-40e3-98dc-4cfad84443b5

[Microsoft TechDays 2007] - Windows Vista : améliorations du firewall et IPsec
par Arnaud Lheureux, Network Support Engineer, Microsoft France
http://www.microsoft.com/france/vision/WebcastTechNetTechDays.aspx?EID=8e8e7b7a-fe1a-4662-9111-74ccff0ab3c8

Introduction to Server and Domain Isolation
http://technet.microsoft.com/en-us/library/cc725770(WS.10).aspx

[JMS 2006] Isolation de domaine ou de serveur avec Ipsec
par Christophe Dubos
http://www.microsoft.com/france/vision/Technet-tv/Webcast.aspx?EID=519543bb-40e9-484a-bdd8-7a4504bf9856

Et si je Twittais ?

Aller pour le fun, je teste Twitter, l’occasion de commenter l’installation de mes plateformes ainsi que mes tests, notamment sur Forefront TMG, DirectAccess….

C’est par ici : http://twitter.com/squastana

AV-Test calls Microsoft Security Essentials "very good"

C’est pas moi qui le dit, c’est dans un article de ZdNet : http://blogs.zdnet.com/hardware/?p=4785

Filtrage d'URLs dans Forefront TMG (Beta 3) - partie 2 : côté administrateur et côté utilisateur

Ce post est la suite d’un billet précédent : Filtrage d'URLs dans Forefront TMG (Beta 3) - partie 1 : Vue d'ensembleFiltrage d'URLs dans Forefront TMG (Beta 3) - partie 1 : Vue d'ensemble

Voici maintenant quelques informations (en 5 points) sur l’utilisation de cette fonction de filtrage d’URLs dans Forefront TMG :

1– Si vous suivez l’assistant de configuration des accès Web (Web Access Wizard), il est possible très rapidement de créer une politique d’accès Web filtrant un ensemble de catégories de sites clairement inapropriés :

Ainsi, l’assistant va générer 2 règles : une bloquant l’accès Web (sur HTTP et HTTPS) pour les URLs faisant parties de ces catégories et une seconde autorisant l’accès à Internet sans limitation (rappel : les règles dans ISA Server 2004/2006 & Forefront TMG sont ordonnées et la première règle qui “matche” est celle qui est appliquée).

2– il est bien entendu possible de modifier ces règles pour faire des exceptions pour une règle d’accès

Par exemple si votre société fait des paris / jeux en ligne, c’est peut être pas une bonne idée d’avoir la catégorie Gambling ;-)

Ici, il est possible de rajouter une exception avec votre notre de domaine par exemple.

3– il est possible de déterminer à quelle catégorie appartient une URL :

On saisi ici l’URL à tester. Par exemple ce blog :

Le résultat renvoyé est ici que mon blog est dans la catégorie General Business.

4– il est possible de modifier la catégorie d’une URL :

Pour cela on clique sur Add…, on sélectionne la nouvelle catégorie et on met l’url (attention par de http://)

5– on peut personnaliser le message renvoyé aux utilisateurs finaux :

Résultat côté utilisateur :

Filtrage d'URLs dans Forefront TMG (Beta 3) - partie 1 : Vue d'ensemble

Une des grosses nouveautés fonctionnelles présente dans la beta 3 de Forefront TMG est le filtrage d'URL (les participants du programme TAP avaient pu évaluer cette fonctionnalité dans la beta 1 puis cela avait été retiré dans la beta 2 suite à des changements de la solution).

Le filtrage d'URL (URL Filtering) permet de contrôler les accès Web des utilisateurs finaux dans les organisations et donc par exemple d'interdire l'accès à des sites dont le contenu est jugé inapproprié ou pouvant contenir du code malveillant.

L'utilisation du filtrage d'URL permet ainsi :
- d'améliorer la sécurité en limitant les risques
- d'économiser de la bande passante
- d'éviter de perdre de la productivité (ce point reste discutable en fonction des entreprises)

Le filtrage d'URLs en tant que tel n'est pas vraiment une nouveauté sur le marché de la sécurité et la gestion de listes noire / listes blanche est une activité connue et régulière de nombreux administrateurs de proxies ou pare-feu depuis plusieurs années.

Reste que l'utilisation manuelle / semi-automatisée de ces listes n'est pas vraiment simple et le plus souvent, les listes disponibles gratuitement (c'est à dire maintenues par la Communauté) ne représentent qu'un faible échantillonnage de l'ensemble du Web (au mieux quelques millions d'entrées).

Quelques exemples de blacklists sont disponibles sur : http://www.squidguard.org/blacklists.html

Exemple d’utilisation des blacklists Squid avec ISA Server 2004 : http://www.microsoft.com/france/vision/Technet-tv/Webcast.aspx?EID=06965789-56de-4479-9a18-f4971113555d

Aussi, de nombreux éditeurs se sont spécialisés dans la création / maintenance et fourniture de solutions de filtrage d'URLs ou uniquement de base d'URLs. Certaines de ces solutions sont des partenaires historiques de Microsoft et proposent des plug-ins pour ISA Server (cf. http://www.microsoft.com/forefront/edgesecurity/isaserver/en/us/isa-solution-partners.aspx?SortField1=ISA&SortField2=URL%20Filtering) et autre proxies comme Squid par exemple.

Les avantages des solutions payantes packagées sont multiples :
- les bases d'URLs sont plus importantes (plusieurs dizaines de millions d'entrée, voire plus)
- les bases sont en général bien plus à jour
- la catégorisation est souvent plus granulaire
- certains fournisseurs sont très spécialisés (ex: identification de sites malicieux, Web 2.0...)

Mais revenons au sujet principal de ce billet qui est la fonction URL filtering dans Forefront TMG beta 3.

Forefront TMG va proposer sous la forme de service (et au travers d'un abonnement dont je n'ai pas encore de détails en terme de prix...) environ 80 catégories d'URLs comprenant notamment :
- des catégories permettant d'améliorer la sécurité des accès : Phishing, Malicious, Anonymizers...
- des catégories plutôt destinées à empêcher la perte de productivité : Games, Instant Messanging, Pornography...
- des catégories associées à des contenus illégaux : Criminal Activities, Child Pornography, Drugs...

A noter que ces catégories peuvent être regroupés dans des ensembles de catégories (Category Set) dans Forefront TMG.

Lors de la RSA Conference 2009 (cf. http://blogs.technet.com/stanislas/archive/2009/04/20/rsa-conference-les-annonces-de-microsoft-a-new-approach-to-enterprise-security.aspx), Microsoft a annoncé ses nouveaux services de réputation et son intention de fournir ces services dans ses nouveaux produits de sécurité (dont Forefront TMG avec le filtrage d'URLs).

De même, nous avons annoncé de nombreux partenariats avec différents acteurs dans le monde du filtrage d'URLs afin de les inclure dans notre offre Microsoft Reputation Service (MRS). Quelques exemples :

• Le partenariat avec  annoncé lors de la RSA Conference 2009 (cf. http://www.marshal8e6.com/i/Marshal8e6-to-Provide-Web-Security-Library-to-Microsoft-,news.960~.asp)
• Le partenariat avec : cf. http://www.brightcloud.com/release.asp?id=20090604

En s'associant à de nombreux partenaires, l'équipe MRS a voulu se confronter à un problème inhérent au solutions traditionnelles de filtrage d'URLs : il est très difficile (voire impossible) qu'un fournisseur unique soit capable de gérer et offrir une solution complète. Ainsi, il existe une miriade de sociétés avec pour chacune ses spécialités. Certaines sont spécialisées dans le référencement de sites avec du contenu malveillant ou des URLs utilisées dans les SPAM, d'autres sont plus spécialisées sur le Web 2.0.... De même, chaque société spécialisée utilise diverses méthodes pour le référencement et la catégorisation des URLs: automatisée ou/et via une interaction humaine.

L'idée de l'équipe MRS a donc été très simple : pourquoi ne pas utiliser et profiter de ces compétences / sources variées et complémentaires pour créer une base unifiée qui répondrait le mieux aux besoins actuels des clients en terme de filtrage & de sécurité ?

Notre équipe a donc mis en place une infrastructure capable de monter en charge et qui permet d'inclure des sources de données multiples au sein d'une même base. Ainsi, chaque société spécialisée / source de listes & de catégories d’URLs peut apporter sa plus value dans notre solution MRS.

MRS intégre aujourd'hui plusieurs sources et de nouvelles seront intégrées dans les prochains mois. Certaines sources sont internes à Microsoft, d'autres sont le résultat de la collaboration de Microsoft avec des sociétés tierces (j'en ai présenté deux un peu plus haut dans ce texte)

Forefront TMG va donc être le premier produit à utiliser Microsoft Reputation Service.

MRS est une solution dans le "Nuage/Cloud" de catégorisation d'objets qui est hébergée dans les centres de données de Microsoft. MRS maintient une base de données de plusieurs dizaines de millions d'objets uniques ainsi que leur catégorie respective.

Quand Forefront TMG va vouloir déterminer la catégorie associée à un URL demandée par un utilisateur, il va envoyer une requête au service en ligne MRS qui va lui répondre à quelle catégorie l'URL est associée.

Est-ce que cela signifie que chaque requête http émise par un client proxy web va être envoyée par Forefront TMG au service MRS via Internet ?
Non non Non !!! Pour optimiser la base passante et les performances, nous avons implémenté dans Forefront TMG un cache local qui contient les URLs récemment demandées et leur catégorie respective). Les entrées de ce cache ont toutes un TTL (Time To Live) permettant un rafraichissement périodique. Ce cache va donc servir à l'ensemble des requêtes et devrait limiter les échanges Forefront TMG --> Plateforme MRS.

A noter :
1- ce cache est persistent et ne nécessite pas un rafraichissement en cas de redémarrage du serveur.
2- les échanges entre le serveur Forefront TMG et les services MRS sont chiffrés (utilisation de tunnel SSL) --> cf. capture d'écran ci-dessus.

Suite dans le prochain billet avec plus de captures d’écran de Forefront TMG !

Forefront TMG beta 3 : l'assistant de configuration des accès Web en images

Suite de la découverte de la beta 3 de Forefront Threat Management Gateway (TMG) avec cette fois-ci l’utilisation de l’assistant de création des stratégies d’accès Web (Web Access Policy Wizard)

Celui-ci est d’ailleurs proposé une fois la configuration initiale effectuée (cf. post précédent : http://blogs.technet.com/stanislas/archive/2009/06/23/installation-de-forefront-tmg-beta-3-en-images.aspx)

OK, l’assistant est là pour vous aider à créer des règles basiques d’accès Web avec des fonctions d’inspection du contenu (antivirus HTTP), de filtrage de contenu (URL Filtering), de cache (ça c’est une fonction historique depuis Proxy Server) voire d’inspection des flux sortants HTTPS

L’assistant propose la création d’une règle de blocage des accès Web vers une liste de catégories de sites sans rapport direct avec la majorité des besoins d’accès Internet pour les employés des entreprises.

Dans les catégories proposées par défaut, on trouve des catégories assez classiques : haine raciale, drogue, pornographie…

L’assistant propose ensuite de faire l’analyse anti-virale du contenu téléchargé sur HTTP

Ensuite l’assistant permet de choisir si on autorise ou pas les utilisateurs de l’entreprise à accéder à Internet sur des sites sécurisés (HTTPS). En général c’est assez rare de bloquer complètement les accès en HTTPS. Aussi, il est possible (recommandé) d’autoriser ces accès mais avec une grosse nouveauté : la possibilité d’inspecter les flux sortants HTTPS

Ici, il faut choisir si on souhaite notifier ou pas les utilisateurs de l’inspection de leur connexions HTTPS. Attention pour cela, il faut que le poste client ait le client Firewall de Forefront TMG installé

Le serveur Forefront TMG va agir ici comme un “Man-in-the-Middle” et va générer à la volée des certificats pour les présenter aux postes clients. Il va donc agir comme une petite “autorité de certification” et nécessite donc d’être trusté par les postes clients. Dans cet exemple, j’ai choisi un certificat autogénéré par Forefront TMG qui doit être déployé sur les postes. Dans la vraie vie (= dans un environnement de production), je recommande très très fortement l’usage d’un certificat émis par une autorité de certification interne et trustée par l’ensemble des postes de l’entreprise.

Comme dans ISA Server 2004/2006, il est possible d’activer ou pas les fonctionnalités de cache. Dans ce cas, il faut définir la taille et l’emplacement des fichiers de cache sur la machine

Pour l’exemple j’ai créé ici un cache de 10 Mo (c’est vraiment pour l’exemple :-))

L’assistant est maintenant terminé, on clique sur Finish avant de confirmer l’application des règles générées par l’assistant

On clique sur Apply pour appliquer les nouvelles règles d’accès Web générées par l’assistant

Là c’est comme pour les versions antérieures (ISA 2004/2006), la modification des propriétés du cache implique un redémarrage du service Firewall

L

Voilà la configuration a été mise à jour dans le serveur ADAM local, reste à vérifier que le firewall est bien synchronisé avec cet annuaire LDAP

C’est vert donc tout va bien :-)

Les règles générées par l’assistant sont visibles dans la branche “Web Access Policy” mais aussi dans la branche “Firewall Policy” sous la forme de plusieurs règles regroupés dans un groupe de règles (ça c’est nouveau dans Forefront TMG).

A bientôt pour la suite :-)

Microsoft Security Essential (nom de code Morro) est disponible en version beta !

Microsoft Security Essential dont le nom de code était Morro est une solution de lutte anti logiciels malveillants (donc un anti-virus et un anti-spyware..) destiné aux PC personnel qui devrait être gratuit !!!

La beta est disponible en téléchargement et fonctionne sur Windows XP, Windows Vista ou Windows 7 beta.

Donc pourquoi sans priver, ne serait-ce que pour tester avec Windows 7 :-)

Lien de téléchargement : http://go.microsoft.com/fwlink/?LinkID=153446

Installation de Forefront TMG Beta 3 en images !

Bon j’ai enfin pris le temps d’installer cette beta 3 de Forefront Threat Management Gateway 2010 (qui est le successeur d’ISA Server 2006) sortie publiquement il y presque 2 semaines (cf. le billet suivant : http://blogs.technet.com/stanislas/archive/2009/06/10/forefront-tmg-disponible-en-version-beta-3.aspx).

J’ai fait l’installation sur un Dell D820 avec 3.5 Go de RAM et 2 interfaces réseaux (pour l’instant) avec une Windows Server 2008 Entreprise 64 bit US Service Pack 2 (très important : se mettre bien à jour)

Voici le déroulé en image de l’installation:

Exécution de l’outil de préparation (qui sera de toute façon exécuté) :

On voit bien ici la vérification de pas mal de pré-requis

On coche la case pour accepter les contrats de licence des différents pré-requis

On choisit quelle préparation pour quel type d’installation (console d’administration de TMG ou le “pack complet”)

Les composants manquants sont installés automatiquement :

Un petit récapitulatif des tests et actions (installations) réalisés

Un fois le rédémarrage effectué, il est possible de relancer le test pour vérifier que tous les pré-requis logiciels sont là :

On peut ensuite passer à la phase sérieuse : l’installation de Forefront TMG :

On clique sur Next

[clé générée automatiquement sur la beta 3]

On défini ici le répertoire d’installation (au passage vous constaterez que c’est celui utilisé historiquement par ISA Server)

Pareil, c’est comme l’installation d’ISA Server 2004/2006 : on clique sur Add… pour spécifier les plages d’adresses IPv4 internes

Des informations sur les services qui vont être redémarrés ou désactivé (comme dans ISA Server 2004/2006)

Ensuite ça mouline plusieurs, plusieurs minutes

Là encore cette étape est assez longue et comprend notamment l’installation de SQL Server 2008 (une version réservée à Forefront TMG). [Vous pouvez aller boire un grand café et discuter de la suite avec vos collègues & amis]

C’est pas fini !! on attaque maintenant la 3ème phase du Setup

On clique que Configure Network Settings

Là j’ai choisi la première option (je rajouterai des interfaces réseau plus tard)

Ici on peut configurer les paramètres IPv4 de la carte réseau côté réseau local

Idem mais cette fois-ci avec la carte réseau côté Internet

On clique sur Finish pour passer à la seconde partie de cette 3ème phase

On clique sur Configure System Settings

On choisi ici si la machine est membre d’un domaine ou en workgroup (ça c’est une des  nouveautés de la beta 3 qui fonctionne en workgroup – le domaine était nécessaire en beta 2)

Aller on clique sur finish pour attaquer la 3ème partie

On clique sur Define Deployment Options

Forefront TMG utilise Microsoft Update pour les mises à jour des signatures anti-malware, on conserve donc l’option par défaut

On pense à cocher la case “Enable URL Filtering”

On définit ici la fréquence de la vérification et des installations des mises à jour

Voilà c’est terminé pour la partie installation.

Il ne reste plus qu’à configurer la bête ! La suite dans un prochain billet sur ce blog.

Forefront TMG disponible en version beta 3

Une bien bonne nouvelle : la sortie de la beta 3 de Forefront Threat Management Gateway (TMG) qui est comme vous le savez le successeur d'ISA Server 2006. Et cette beta 3 est téléchargeable par tous !

Quoi de neuf dans cette nouvelle beta ?

• Le produit est feature complete c’est à dire qu’il intègre (normalement) toutes les fonctions qui seront disponibles dans la version finale
• Il intègre le filtrage d'URL qui utilise MRS (Microsoft Reputation Service). Nous avons également annoncé des partenariats entre MRS et des tiers travaillant sur le filtrage URL comme BrightCloud (cf. http://www.prweb.com/releases/2009/06/prweb2500324.htm)
• Un nouvel assistant de préparation à l'installation qui permet l'installation des pré-requis à Forefront TMG
• Cette beta introduit également la notion de version Standard et de version Entreprise
• Le scénario Forefront TMG dans un workgroup (dans les betas précédentes, il fallait avoir le serveur Forefront TMG membre d'un domaine)
• La capacité à s'installer sur Windows Server 2008 R2, le support officiel de Windows Server 2008 et 2008 R2 sera fait avant la fin de l'année
• Amélioration du NIS (Network Inspection Sytem)
• Support du protocol VPN SSTP (Secure Socket Tunneling Protocol) qui est du VPN SSL (Fonction disponible à partir de Windows Vista SP1 côté poste client)
• La possibilité de regrouper des règles
• Des fonctions de recherches
• Protection des serveurs Exchange 2007 SP1 et Exchange 2010 (beta)
• Intégration de Powershell (pour l'instant en mode lecture seule)

Bref que du bon, je vais préparer du contenu sur le sujet cet été donc venez jeter un oeil sur ce blog pour plus d'informations ;-)

Télécharger Forefront Threat Management Gateway à l'adresse suivante :
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e05aecbc-d0eb-4e0f-a5db-8f236995bccd

Un super document sur TCP/IP incluant des informations sur IPv6 (utile donc pour DirectAccess)

En recherchant des informations sur IPv6, je viens de tomber sur une perle : une véritable bible sur TCP/IP incluant bien entendu plein d'informations sur IPv6 et donc forcément très utile en ces temps où se posent plein de questions sur le sujet ;-)

TCP/IP Fundamentals for Microsoft Windows
 
 Chapitre 1  : Introduction à TCP/IP
 Chapitre 2  : Vue d'ensemble de l'architecture de la suite de protocoles TCP/IP
 Chapitre 3  : L'adressage IP
 Chapitre 4  : Le sous-adressage, la segmentation
 Chapitre 5  : Le routage IP
 Chapitre 6  : DHCP
 Chapitre 7  : La résolution de noms d'hôtes
 Chapitre 8  : Vue d'ensemble du DNS
 Chapitre 9  : Le support de DNS dans Windows
 Chapitre 10 : TCP/IP de bout en bout
 Chapitre 11 : NetBIOS sur TCP/IP
 Chapitre 12 : Vue d'ensemble de WINS
 Chapitre 13 : IPsec et le filtrage de paquets
 Chapitre 14 : Les réseaux privés virtuels (VPN)
 Chapitre 15 : Technologies de transition IPv6
 Chapitre 16 : Dépannage TCP/IP

(en rouge les chapitres intéressants pour DirectAccess)

 
 Bref vous l'aurez compris, c'est un Must to have dans sa bibliothèque numérique d’autant que le document (je devrais dire le livre car c’est quand même 560 pages !)
  
 Télécharger le PDF TCP/IP Fundamentals for Microsoft Windows sur :
 http://www.microsoft.com/downloads/details.aspx?FamilyID=c76296fd-61c9-4079-a0bb-582bca4a846f&DisplayLang=en

DirectAccess : mythes & réalité - partie 1 : IPv6

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.

A la différence d'une connexion VPN nomade (classique ou SSL), DirectAccess ne nécessite aucune intervention de l'utilisateur, il n'y a pas de connexion à établir au travers d'un gestionnaire de connexion.

Parmi les technologies nécessaires et utilisées par DirectAccess, il y a IPv6, un protocole réseau qui remplacera à terme (disons dans plusieurs, plusieurs années) IPv4 qui le protocole réseau le plus utilisé sur Internet.

Beaucoup de personnes se documentant sur DirectAccess voient IPv6 dans la liste des pré-requis, ce qui génère beaucoup d'interrogations et d'idées reçues :
- Je n'ai pas d'IPv6 dans mon réseau d'entreprise donc je ne peux pas faire de DirectAccess
- Si je veux mettre en oeuvre DirectAccess dans mon entreprise, cela implique une refonte complète de mon infrastructure réseau (Firewall, routeur...)
- Il va falloir refaire les plans d'adressage IP de toute l'entreprise
- DirectAccess ne fonctionnera pas depuis mon réseau à la maison car je suis en IPv4
- Seul les FAI qui proposent de l'IPv6 permettent de faire du DirectAccess
- ....

Du coup, beaucoup pensent que DirectAccess n'est pas possible dans leurs environnements. L'objectif de ce post est de démystifier toutes ces idées reçues sur DirectAccess & IPv6

Tout d'abord, DirectAccess n'impose pas une utilisation en natif et de manière exclusive d'IPv6. ça c'est le premier point important à retenir.

Il existe un ensemble de technologies de transition IPv4 vers IPv6 parce qu’aujourd’hui on « vit » dans un monde principalement IPv4 et la migration globale vers IPv6 n’est pas pour demain.

Poursuivons avec une vue basique d'une architecture DirectAccess :

Comme on peut le constater, les communications DirectAccess s'appuient effectivement sur IPv6 et IPsec (IPsec : mythes et réalité fera l'objet d'un futur billet sur ce blog) mais heureusement pour tous, de nombreuses technologies présentes dans les systèmes d'exploitation vont permettent l'utilisation de DirectAccess dans un monde aujourd'hui principalement IPv4

Les technologies pour assurer la transition IPv4 vers IPv6 sont les suivantes :
- 6to4
- Teredo
- ISATAP
- IP HTTPS

Maintenant, nous allons voir quelle technologie est utilisée sur quel type de réseau.

Commmençons par les communications qui ont lieu sur Internet à destination du réseau de l'entreprise, ici 3 technologies sont utilisables en fonction des scénarios :

- 6to4 s'utilise sur Internet pour des machines qui ont une adresse IPv4 :

- Teredo s'utilise quand le client est sur un réseau en IPv4 situé derrière un (des) équipements faisant du NAT :

- IP-HTTPS quand le client est sur un réseau situé derrière un (des) équipements filtrant mais laissant passer https :

Windows 7 qui est le système client requis pour faire du DirectAccess a nativement une couche réseau incluant l'ensemble des mécanismes pour assurer de manière transparente ces transitions

Le serveur DirectAccess qui est une machine Windows Server 2008 R2 intègre l'ensemble des composants côté pour assurer la transition du trafic IPv4 :
- 6to4
- Teredo
- IP-HTTPS

Maintenant, regardons la partie infrastructure du réseau de l'entreprise qui veut faire du DirectAccess.

Aujourd'hui, la majorité des réseaux internes sont en IPv4 donc du coup, doit-on tout casser et rebatir entièrement un adressage en IPv6 et remplacer certains équipements réseaux ? la réponse est clairement NON !!!

Il faut savoir que depuis Windows Vista et Windows Server 2008, le système dispose d'une pile réseau intégrant IPv4 ET IPv6. Si vous installez Windows avec les options par défaut, IPv6 est installé et actif.

Concernant le plan d'adressage, il est possible de laisser le système se débrouiller et dans ce cas, il va s'autoconfigurer avec la technologie de transition ISATAP. L'adresse IPv6 va être construite à partir de l'adresse IPv4.

Exemple :

Le serveur DirectAccess sait également dialoguer en en ISATAP (Tunnel IPv6 dans des paquets IPv4) avec les serveurs en interne :

Conclusion :

Vous pouvez faire du DirectAccess dès aujourd'hui sans avoir à refaire votre réseau Interne en IPv6 natif ni avoir une connectivité Internet en IPv6 car :

1– Le serveur DirectAccess intègre les technologies de transition suivantes :
- 6to4
- Teredo
- IP-HTTPs
- ISATAP

2– sur le réseau interne, utilisez ISATAP dans votre réseau d’entreprise 
 —> il suffit de conserver la case IPv6 cochée par défaut dans le paramétrage réseau

Suite au prochain billet… ;-)

DirectAccess : l'installation pas à pas d'une plateforme de test par Benoit Sautiere

Benoit Sautière [Exakis] vient de se lancer dans un marathon DirectAccess et il nous fait profiter de cette aventure.
Le montage de sa plateforme est inspirée du guide pas à pas d'installation de DirectAccess [cf. http://blogs.technet.com/stanislas/archive/2009/05/25/guide-pas-pas-pour-tester-directaccess.aspx) mais dans une version adaptée façon Benoit, c'est à dire avec du PowerShell... :-)]

Voici la liste de ces posts qui sont encore mieux à lire que le guide ci-dessus [qui reste cependant un "Must to Read", ne faites pas l'impasse dessus ;-)]

épisode n°1
Présentation de la plateforme DirectAccess de Benoit
http://blogcastrepository.com/blogs/benoits/archive/2009/05/31/directaccess-233-pisode-n-176-1.aspx

épisode n°2
Ce billet résume la configuration initiale de chaque système d'exploitation impliqué. Le plus important, c’est la configuration réseau de chaque système
http://blogcastrepository.com/blogs/benoits/archive/2009/06/01/directaccess-233-pisode-n-176-2.aspx

épisode n°3
Installation du contrôleur de domaine. Il va héberger les rôles AD, DNS, DHCP.
http://blogcastrepository.com/blogs/benoits/archive/2009/06/01/directaccess-233-pisode-3.aspx

épisode n°4
Qui dit DirectAccess, dit IPV6, dit IPSEC donc certificats, ce qui a pour conséquence qu'il est nécessaire de mettre en œuvre une infrastructure de clés publiques.
http://blogcastrepository.com/blogs/benoits/archive/2009/06/02/directaccess-233-pisode-n-176-4.aspx

épisode n°5
Coniguration du Network Location Server et aussi d'un serveur d'application
http://blogcastrepository.com/blogs/benoits/archive/2009/06/03/directaccess-233-pisode-n-176-5.aspx

épisode n°6
Configuration d'un serveur Web et DNS publique
http://blogcastrepository.com/blogs/benoits/archive/2009/06/03/directaccess-233-pisode-n-176-6.aspx

épisode n°7
Installation du serveur DirectAccess
http://blogcastrepository.com/blogs/benoits/archive/2009/06/04/directaccess-233-pisode-n-176-7.aspx

Les prochains épisodes seront donc l’assistant de mise en œuvre de DirectAccess va faire de la magie noire avec le serveur, le DNS, la PKI et TCP/IP pour obtenir DirectAccess.
Voilà donc à suivre :-)