Archives mensuelles : juin 2011

DirectAccess : Un jeu de légo?

C’est mon point de vue. DirectAccess n’est que l’assemblage de briques existantes des systèmes d’exploitation de Microsoft. ce n’est donc pas de la magie noire. Au contraire, une fois chaque brique clairement expliquée, DirectAccess apparait immédiatement plus clair. Pour vous en convraincre, voila une série d’articles que j’ai écrit sur Technet sur le sujet :

 

Alors oui, c’est peut être un peu long, mais tout y est expliqué. Par contre, j’avoue, le Network Location Server entièrement en Core, c’est juste pour le plaisir, c’est pas simple du tout, je sais.

 

Bonne lecture.

 

Benoits – Simple and Secure by Design but Business compliant.

DirectAccess in NLB Multicast

According to Technet documentation, the only way to setup a high available DirectAccess infrastructure is to use Microsoft Forefront Unified Access Gateway 2010. No problem until you read the following technet article describing how to setup the Network Load Balancing feature : Only Unicast is supported.

 

NLB in Unicast may be painful especially if you deploy your UAG array on a VMWARE platform. Multicast would be great in this situation.

 

After doing some research, it is technically possible to setup a UAG DirectAccess array with Network Load Balancing in Multicast. This is one of the features included in UAG 2010 SP1. In the UAG Management console, you can select the MultiCast option in the Network Load Balancing Interface

 

MULTICAST0

 

On the Web Monitor console, everything is operational too.

MULTICAST1

 

Until now, it seems that the Technet documentation is outdated. Multicast support is one of the new features of UAG 2010 SP1.

 

Benoits – Simple and Secure by Design but Business compliant.

DirectAccess en NLB Multicast

A ce jour, seul UAG permet de déployer DirectAccess en haute disponibilité, offrant à la fois le Scale In et le Scale out. Selon les bonnes pratiques en la matière, NLB n’est supporté qu’en Unicast “Forefront UAG DirectAccess supports NLB only in Unicast mode; multicast modes are not supported.”.

 

Le Network Load Balancing de Microsoft pose quand même un certain nombre de problèmes lorsqu’on utilise des solutions de virtualisation tel que VMWARE pour héberger une ferme de serveurs UAG. L’utilisation du Multicast serait un vrai plus.

 

Après quelques recherches, il est techniquement possible de mettre en œuvre un ferme de serveur UAG en Multicast pour du DirectAccess avec UAG 2010 SP1. Dans l’interface de configuration, rien n’interdit de choisir Multicast dans le mode de déploiement.

 

MULTICAST0

 

Cote Web Monitor, tout fonctionne aussi.

MULTICAST1

 

A ce jour, il semble que la documentation Technet ne soit pas à jour puisque le support du multicast est une nouveauté du SP1 d’UAG 2010.

 

Prochain chalenge DirectAccess : La haute disponibilité matérielle!

 

Benoits – Simple and Secure by Design but Business compliant.

Capture de traces réseau sous Core

C’est le chalenge que j’ai eu chez un client cette semaine. Comment faire une capture de trace sur un serveur Windows 2008 R2 installé sous Core. Mon premier réflexe a été de dire Facile : NETSH TRACE START CAPTURE=YES TRACEFILE=c:\CAPTURE.ETL. C’est simple et en plus cette méthode permet de collecter un grand nombre d’informations complémentaires qui peuvent nous aider à comprendre ce qui se passe au niveau du système d’exploitation. Manque de bol, sous Core, c’est pas implémenté!

0

 

Bon ben on va installer le Network Monitor sous Core. Une fois installé, on constatera qu’il est possible de réaliser la capture à l’aide de l’outil NMCAP.EXE

1

 

Avec un peu de recherche, on verra qu’il est possible de mettre en place un filtre pour capturer uniquement le trafic recherché.

2

 

La grande surprise, c’est qu’il est réellement possible d’utiliser le Network Monitor dans une installation de Windows Server 2008 R2 Core. Il semble donc qu’il subsiste en beaucoup de composants de l’interface graphique sous Core. C’est toujours bon à savoir.

3

 

Par contre autre chalenge, comment désinstaller le Network Monitor. Microsoft livre un exécutable et non un package Windows Installer. Avec un peu de recherche, on découvre qu’il est possible de décompresser l’exécutable pour retrouver les packages Windows Installer. Reste plus qu’à désinstaller avec la commande “MSIEXEC.EXE /X”.

4

 

A noter qu’il y a deux packages Windows Installer à désinstaller.

5

 

Chalenge relevé

 

Benoits – Simple and Secure by Design but Business compliant.

SQL Server en Core!

Le mode d’installation “Core” est une avancée importante pour les systèmes d’exploitation de Microsoft puisqu’en n’installant pas certains composants, il n’est plus nécessaire d’installer les correctifs qui vont avec. Le problème, c’était que jusqu’à maintenant, aucune application phare de Microsoft ne s’était penché sur la question (exception faite d’Hyper-V).

 

Certes, l’absence du Framework Dot.Net était un point de blocage important, mais Windows 2008 R2 avait résolu le problème. La prochaine version de SQL Server dite “Denali” fonctionnera sous Core.

 

Pour ceux qui veulent en savoir plus, une seule adresse : http://www.microsoft.com/sqlserver/en/us/product-info/future-editions.aspx

 

Benoits – Simple and Secure by Design but Business compliant.

TMG 2010 et MS11-40

En parcourant la liste des failles de sécurités couvertes en ce mois de Juin par Microsoft, le bulletin MS11-40 a attiré mon attention. Il fait référence à une faille de sécurité dans le client de pare-feu de TMG/ISA Server.

 

Certes ce n’est pas un composant qu’on utilise pas tous les jours mais si on utilise la fonctionnalité d’inspection de trafic HTTPS de TMG, alors il est nécessairement installé, rien que pour notifier l’utilisateur de l’opération d’analyse du flux HTTPS.

 

Grand merci à Richard Hick’s pour son billet sur le sujet.

 

Benoits – Simple and Secure by Design but Business compliant.

DirectAccess : bloquer l’accès à un serveur donné

Dans le billet DirectAccess : Désactiver NAT64/DNS64, j’avais évoqué le fait que désactiver cette fonctionnalité permettait indirectement de filtrer quels sont les systèmes accessibles en DirectAccess.  C’est vrai, cela fonctionne.

 

Après réflexion, il existe peut être une méthode plus simple. Et effectivement, il y a plus simple. DirectAccess intègre cette solution nativement en plus.

 

Si je regarde le contenu de la Name Resolution Policy Table sur mon poste client, je constate deux entrées. La première concerne mon domaine Active Directory et indique d’utiliser le serveur UAG pour la résolution DNS des noms dans cette zone. La seconde, c’est mon Network Location Server. C’est une exception. C’est exactement ce dont j’ai besoin pour bloquer l’accès à un serveur donné. S’il n’est pas possible de résoudre son nom, il n’est pas possible d’y accéder.

0

 

Dans la console UAG, la section Infrastructure servers permet de configurer le contenu de la NRPT. Il faut juste ajouter une entrée.

1

 

Celle-ci va concerner un hôte donné pour lequel on va indiquer qu’il n’y aura pas de serveur DNS associé.

2

 

Une fois le paramétrage mis en place, le contenu de ma NRPT est le suivant. Pour qu’il soit pris en compte, il est nécessaire de re-générer les stratégies de groupe. Par contre, il n’est pas nécessaire de réactiver la configuration d’UAG.

3

 

Coté client, on retrouvera bien la nouvelle entrée lors de la prochaine application des stratégies de groupe.

4

 

Finalement, c’est bien plus simple non?

 

Benoits – Simple and Secure by Design but Business compliant.

DirectAccess et Symantec Endpoint Protection

La suite Symantec Endpoint Protection inclus un pare-feu nommé “Proactive Threat Protection”. Avec DirectAccess, les choses se compliquent car en remplaçant le pare-feu de Windows par un autre, il faut reproduire le même paramétrage. Pour l’essentiel des informations, tout est résumé ici : http://technet.microsoft.com/en-us/library/ee382257(WS.10).aspx.

 

Le premier point, c’est que SEP s’interface bien avec la WIndows Filtering Platform en prenant soin de ne pas remplacer le module ConSecRuleRuleCategory. C’est en effet celui-ci qui est chargé des tunnels IPsec nécessaires à DirectAccess.

SEP0

 

Une fois SEP installé et actif, DirectAccess fonctionne mais pas exactement comme on l’attend. Lorsque le client dispose d’une connectivité Internet directe, c’est le protocole 6to4 qui doit être utilisé. Dans le cas d’une connectivité Internet au travers d’un mécanisme de translation d’adresses, c’est le protocole Teredo qui doit être utilisé. IPHTTPS ne devant être utilisé qu’en dernier recours. Pourtant, quelque soit le type de connectivité réseau, c’est toujours le protocole IPHTTPS qui est utilisé par le client DirectAccess.

 

Après un peu de recherches, ce comportement est normal car la configuration pare-défaut de FEP bloque l’utilisation des protocoles de transition vers IPv6.

SEP1

 

En désactivant ces deux règles, les protocoles de transition 6to4 et Teredo sont de nouveau opérationnel.

 

Benoits – Simple and Secure by Design but Business compliant.

Forefront UAG DirectAccess – "A timeout occurred. The Teredo network interface cannot be enabled."

During a DirectAccess PoC, i was lucky to have the following error : “A timeout occurred. The Teredo network interface cannot be activated”. First reflex, Bing. And Bing, yes, an excellent wiki article : http://social.technet.microsoft.com/wiki/contents/articles/forefront-uag-directaccess-troubleshooting-10026-quot-a-timeout-occurred-the-teredo-network-interface-cannot-be-enabled-quot.aspx.

 

Problem, i had to find the root cause of the problem. During the activation process, i noticed with the “NETSH.EXE INTERFACE TEREDO SHOW STATE” that once, the teredo interface started but immediately stopped. That what i found in the event log with this curious message  :

TeredoBug

 

What a strange message. Because it was the second installation of this UAG server and it worked perfectly once, i figured that there might have one or more difference between the first installation and this second one, and i found it. My UAG server had three network interface. The third one is dedicated to remote administration. During the first installation, i took care to the binding orders of the network card and place this one at last. This was not the case in my second installation. After changing the binding order of the network interfaces and rebooted my UAG box, the activation process completed without error.

 

Now i have a happy customer experiencing DirectAccess, thanks to the Technet Wiki pages on UAG DirectAccess.

 

Benoits – Simple and Secure by Design but Business compliant.

DirectAccess : Désactiver NAT64/DNS64

Pourquoi désactiver cette fabuleuse fonctionnalité d’UAG. Elle est fort utile pour DirectAcccess pour permettre aux clients nomades d’accéder à des systèmes qui ne supportent pas IPv6. Pour ceux qui veulent en savoir plus sur ce sujet, je conseille la lecture des deux billets qu’à consacré Stanislas QUASTANA sur son blog :

 

Pourquoi désactiver DNS64/NAT64

Désactiver cette fonctionnalité peut présenter un intérêt pour limiter les ressources qui seront accessibles depuis l’extérieur en DirectAccess. De cette manière, seuls les systèmes qui sont capables de faire de l’IPv6 seront accessibles par les clients nomades. Si en plus, on a volontairement oublié de créer l’enregistrement DNS ISATAP, on est certain que l’interface ISATAP ne sera opérationnelle que sur les systèmes sur lesquels on aura configuré l’interface ISATAP manuellement (netsh.exe interface isatap set router adresse IPv4 enabled 1440). Globalement, on est à peu près assuré que des serveurs de la génération Windows 2003 ne seront pas accessibles en DirectAccess.

 

Comment Désactiver

Facile, un petit coup de Bing et on trouvera cette page sur le Technet de Microsoft. C’est vrai, cela va désactiver le service correspondant. Par contre, la page Technet ne dit pas tout. Dans la NRPT du client, il sera toujours référencé la première adresse 6to4 de notre serveur UAG. Or maintenant, le service ne répond plus. Si on va jeter un œil dans la console UAG, il est toujours référencé qu’il faille utiliser DNS64 pour résoudre les noms du domaine DNS *.DirectAccess.Lan.

DISABLEDNS640

 

Problème, c’est que dans l’interface, il n’est plus possible de référencer une serveur DNS IPv6. La console ne veut que des adresses IPv4. Pour contourner cette problématique, il va valoir ruser. La première étape c’est d’exporter la configuration. Le script PowerShell obtenu a pour objectif de créer nos stratégies de groupes. La solution se trouve dans le script.

DISABLEDNS641

 

En parcourant un peu le script, on va localiser une fonction nommée “ApplyClientRegistrySettings”. C’est elle qui va coder le contenu de la Name Resolution Policy Table entre autre chose.

DISABLEDNS642

 

En parcourant la fonction, on constate qu’elle code bien mes deux entrées de la NRPT et que pour la première, elle référence “en dur” dans le script l’adresse la première adresse 6to4 de mon serveur UAG.

DISABLEDNS643

 

Le truc, c’est tout simplement de remplacer cette adresse par l’adresse ISATAP de notre contrôleur de domaine.

DISABLEDNS644

 

Attention, si plusieurs serveurs DNS sont référencés, bien veiller à conserver le caractère séparateur, sinon la NRPT sera corrompue une fois arrivée sur le client.

 

Une fois le script sauvegardé, on va tout simplement l’exécuter. Pour cela, attention à bien autoriser l’exécution des scripts non signés.

DISABLEDNS645

 

Puis lancer le script comme le fait UAG dans la console d’administration.

DISABLEDNS646

 

Suite à une actualisation des stratégies de groupe sur mon client, on constate que celui-ci référence bien l’adresse ISATAP. 

DISABLEDNS647

 

Avec cette reconfiguration, on vient juste de rétablir le mode de fonctionnement de la résolution DNS dans une infrastructure DirectAccess basée sur Windows Server 2008 R2. C’est dommage que ce soit devenu si compliqué de désactiver DNS64/NAT64. Dans UAG 2010 RTM, c’était deux simples cases à cocher, …

 

Limitation

A chaque fois qu’une nouvelle configuration sera appliquée dans la console UAG, il faudra bien faire attention à corriger le script, sinon l’adresse 6to4 du serveur UAG reviendra prendre sa place.

 

Benoits – Simple and Secure by Design but Business compliant.