Archives mensuelles : février 2010

5000 serveurs tout équipés gratuits jusqu’au 30 Juin 2010

Microsoft organise une opération visant à promouvoir sa plateforme web. Pour cela, 5000 serveurs sont mis à disposition (jusqu’au 30 Juin 2010) pour démontrer les multiples atouts de la plateforme de Microsoft.

 

Tout a été fait pour simplifier la prise en main de son serveur web depuis sa mise en œuvre dans des environnements représentatifs (Joomla, DotnetNuke, Drupal ou WordPress).

 

L’initiative est plus qu’intéressante, mais attention, seulement 5000 serveurs.

100212_480x325 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Réflexions sur DirectAccess

Pas de billet ultra technique (mon seul neurone doit être en grève) mais un billet de réflexion.

Toute personne qui a déjà travaillé avec la gamme de produit ISA Server et consorts connait l’excellentissime Thomas W. Shinder et son célèbre http://www.isaserver.org.

Thomas vient de publier un excellent billet sur DirectAccess. Il insiste sur la révolution que cette technologie représente pour l’utilisateur final, surtout quand celui-ci est toujours sur la route, jamais dans les locaux de son entreprise. Cette réflexion en amenant une autre, …

Et si on appliquait DirectAccess sur le réseau interne de l’entreprise?

La question peut paraître saugrenue mais pourquoi appliquer une stratégie d’accès distant à mon réseau LAN.

Ma première réponse : Pour mieux le sécuriser.

  • Considérons le cas des réseaux de type Branch Office avec les succursales. Chacune d’entre elle doit disposer de son propre réseau LAN, de son accès au réseau de l’entreprise et d’un ensemble de ressources locales. Tout cela a un coût de gestion, de maintenance. L’utilisation de DirectAccess pour les réseaux Branch Office permettrait d’en simplifier grandement le déploiement et l’exploitation : Une simple box Internet (avec un peu de GTR cela va de soi!).
  • Considérons maintenant les réseaux LAN. Ici, la mise en œuvre de DirectAccess permettra aussi de mieux le sécuriser car seuls les postes de l’entreprise présentant un niveau de conformité (qui a dit NAP?) satisfaisant pourront accéder au Datacenter.

Note : Un serveur Windows Server 2008 R2 membre de domaine peut tout à fait être considéré comme un client DirectAccess.

Ma seconde réponse : Pour préparer la transition vers IPV6.

  • IPV6 frappe à la porte. Coté Internet, le Number Resource Organization a annoncé récemment qu’il reste moins de 10% d’adresses IPV4 disponibles. Le développement de l’Internet mobile va rapidement épuiser les adresses restantes.
  • Dès lors qu’il n’y aura plus d’adresses IPV4 ou que celles-ci seront devenues hors de prix, il faudra bien basculer vers IPV6. Le sujet étant complexe, il est important de s’y préparer au plus tôt, d’où DirectAccess.

Voila la réflexion du jour sur DirectAccess

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Supervision de DirectAccess/UAG en PowerShell

Après un premier billet sur la supervision de DirectAccess, passons au stade supérieur, la supervision des clients DirectAccess connectés via ForeFront Unified Access Gateway  2010. Techniquement tout est livré par UAG mais tout reste à configurer.

 

La solution implémentée par l’équipe ForeFront UAG 2010 consiste à exploiter les initialisations et les fermetures des différents tunnels IPSEC utilisés par le client. Pour ceux qui désirent en savoir plus à ce sujet, se reporter à mon premier billet sur le sujet.

 

Mise en place de l’audit avancé

Pour commencer, nous avons besoin d’activer des fonctionnalités d’audit avancées (une fonctionnalité propre à Windows Server 2008 R2). Pour cela, nous allons créer une stratégie de groupe qui ne devra s’appliquer qu’à notre serveur UAG (ou nos serveurs en cas de ferme).

MonitoringDA4

Nous avons besoin de collecter les informations d’audit concernant la négociation associations de sécurité principales des tunnels IPSEC

image

Mais aussi les informations supplémentaires.

image

Mise en œuvre du Snap-In PowerShell

Comme indiqué en début de billet, tout reste à configurer et en premier lieu l’installation du Snap-In PowerShell de supervision. Le composant est disponible dans le répertoire d’installation d’UAG, plus précisément dans le sous-répertoire “bin\da\monitoring”.Ce composant doit être installé au moyen de l’utilitaire “Installer Tool du Framework Dot.Net” tel qu’illustré ci-dessous :

 

image

Note : Pour des raisons de commodités, j’ai volontairement copié le composant dans le répertoire “%WINDIR%\System32”.

 

Monitoring des clients

venons-en à la partie la plus intéressante, à savoir la supervision des clients connectés. Tout se passe dans une console Powershell à laquelle on aura pensé à déclarer le snap-in UAGDAUsersMonitoring tel qu’illustré ci-dessous :

image

Histoire de faire le tour du propriétaire, un Get-Help nous indique qu’il n’y a qu’une seule commande disponible : Get-DirectAccessUsers.

image

Commençons simple, avec la liste des sessions actives, en précisant la source de données que nous allons utiliser, à savoir le journal de sécurité de notre serveur UAG :

image

On reconnait tout de suite le formalisme des évènements de sécurité des tunnels IPSEC. La commande PowerShell ne faisant que nous proposer un moyen d’exploiter le journal de sécurité de notre serveur UAG.

 

Maintenant, creusons un peu plus en appliquant un filtre sur le compte utilisateur connecté :

image

Il est même possible de ne retenir que les sessions relatives à un poste DirectAccess donné connecté à partir d’une date donnée.

image

Subtilité de la collecte

le Snap-in PowerShell ne fait qu’exploiter le contenu du journal de sécurité de notre UAG. En creusant un peu plus le sujet, on s’aperçoit qu’il est possible de spécifier le nom du journal à utiliser (paramètre Logname), voire même le système d’exploitation (paramètre CollectorMachineName). Cela signifie qu’il est possible de déporter les journaux de sécurité du ou des serveurs UAG (dans le cas d’un ferme) pour les centraliser un un point unique et les exploiter. Pour cela rien de plus simple que la mise en place d’un processus de collecte/souscription. Ce processus devra assurer la collecte et la centralisation des évènements de sécurité dont l’ID est compris entre 4981 et 4655.

 

Conclusion

On a enfin un moyen de superviser les sessions actives du point de vue DirectAccess. Maintenant, il ne manques plus qu’un habillage graphique et c’est parfait.

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure).

DirectAccess Connectivity Assistant suite

Après un premier billet, allons un peu plus loin dans le DAC. Ce n’est pas par ce qu’on l’installe qu’il fonctionne. Il faut en premier lieu le configurer. Toute la configuration repose sur des paramètres de stratégies de groupes (encore faut-il avoir positionné les fichiers DirectAccess Connectivity Assistant GP.adml et DirectAccess Connectivity.admx). Tout se passe dans dans les “Administratives Templates” des stratégies de groupe :

DAC

Le DAC valide le bon fonctionnement de DirectAccess en vérifiant la connectivité avec le serveur “DirectAccess/UAG”. On référence donc les deux adresses IPV6 6to4 (cela fonctionne quelque soit le type de connectivité) dans le paramètre DTE. La recommandation est de référencer les adresses IPV6 et non les noms DNS.

DAC4

Le DAC valide aussi qu’il est bien capable de joindre des ressources internes. Ici, la recommandation n’est pas de référencer des adresses IPV6 mais des noms DNS ou même mieux, des ressources UNC. Si elles sont accessibles, c’est que le tunnel IPSEC “Utilisateur” est bien opérationnel.

DAC5

le paramètre “PortalName” permet de référencer le nom du portail qui sera présenté à l’utilisateur lorsque le DAC détectera une problématique de connectivité.

DAC1

Le paramètre “Support Email” permet de référencer l’adresse mail à laquelle les journaux de débogage générés par le DAC seront envoyés pour aider au dépannage.

DAC2

Le paramètre “Corporate Portal Site” permet de spécifier l’URL à laquelle l’utilisateur pourra se connecter pour accéder à un support ou un accès VPN/SSL (ForeFront UAG 2010) si la connectivité DirectAccess devait être inutilisable.

DAC3 

Voila pour la configuration, passons à l’interface coté client. Le DAC est un composant qui s’intègre dans la barre de notification.

image

Lorsque tout va bien, on le sait. C’est déjà un bon point.

image

Lorsque la connectivité Internet est en cause, on le sait aussi. l’utilisateur est même invité à déclencher la génération des rapports sur son poste de travail.

image

Un mode “Advanced” est même disponible pour permettre à l’utilisateur de déclencher l’envoie du package contenant les éléments de diagnostics à l’administrateur.

image 

Voila pour le DirectAccess Connectivity Assistant. Une bonne idée qui vient compléter la solution DirectAccess. Sa transparence pouvant perturber les utilisateurs.

 

Benoîts – Simple and Secure by Design (J’insiste sur le Secure)

Tip troubleshooting DirectAccess et IPV6

Dans des configurations un peu complexes de DirectAccess, il peut qu’on soit amené à ne pencher plus avant sur IPV6 et plus particulièrement sur le routage IPV6. Lorsque le client DirectAccess ne peut accéder au réseau interne, cela peut avoir plusieurs causes :

  • Routage IPV6 défaillant
  • Résolution de noms DNS défaillante
  • Name Resolution Policy Table incomplète

 

Si on suspecte une problématique de résolution de noms DNS au travers de la Name Resolution Policy Table, le meilleur moyen reste d’accéder à votre serveur DNS IPV6. Normalement, une invite de commande avec “\\” suivi de l’adresse IPV6 devrait suffire?

image

Perdu! il faut utiliser sa forme “littérale” et cela fonctionne tout de suite mieux :

image

Pour transformer une adresse IPV6 en adresse littérale, il faut :

  1. Positionnant la séquence de caractères « \\ » comme préfixe (c’est un chemin UNC après tout!)
  2. Remplaçant les caractères « : » par « -»
  3. Puis suffixer le tout avec « .ipv6-literal.net »

 

 

Qu’est ce que cela prouve?

  1. Que le routage IPV6 n’est pas en cause
  2. Qu’il est bien possible d’accéder à notre réseau interne en IPV6
  3. Que le tunnel IPSEC “Utilisateur” est bien opérationnel

 

Conclusion : Mon problème est purement DNS. Causes probables :

  • Le serveur DNS est inaccessible
  • Le serveur DNS n’écoute pas sur son interface IPV6
  • La ressource à laquelle j’essaie d’accéder n’a pas d’enregistrement AAAA dans le DNS interne

 Note : Si on veut tester la connectivité depuis Internet Explorer, ce n’est pas la même notation. Il suffit simplement d’encadrer l’adresse IPV6 par des crochets pour que cela fonctionne.

Benoîts – Simple and Secure by Design (j’insiste sur le Secure)

DirectAccess Connectivity Assistant

Pour ceux qui ont assisté à notre session aux Techdays avec Stanislas Quastana, DirectAccess, c’est avant tout la transparence pour l’utilisateur final.

 

De mon point de vue peut être un peu trop transparente. Comment l’utilisateur sait que cela fonctionne ou non? Avec les solutions VPN et VPN/SSL, il dispose d’une interface graphique lui indiquant que cela fonctionne ou non. Et bien pas avec DirectAccess, tout du moins nativement. On peut tenter de lui demander de réaliser la capture de son problème tel que le documentait mon billet “Tip de dépannage de DirectAccess coté client” mais j’ai quelques doutes, …

 

Avec un peu de recul, Microsoft vient de publier un assistant à mettre à disposition des utilisateurs de DirectAccess. le “DirectAccess Connectivity Assistant” prend la forme d’un assistant qui est présent dans la barre des tâches. Il peut indiquer à l’utilisateur que tout fonctionne normalement :

image

Que la connectivité Internet n’est pas opérationnelle et l’inciter à tenter de déterminer pourquoi?

image

Que le problème est plus complexe et qu’il nécessite de contacter un administrateur :

image

Bref, un outil essentiel à la mise en œuvre de DirectAccess. Un prochain billet lui sera consacré pour présenter sa mise en œuvre. Il faut saluer l’initiative. prochaine étape la supervision de la solution au travers d’UAG.

 

Benoîts – Simple and Secure by design (j’insiste sur le Secure)

UAG Design and planning guides pour configuration en load balancing

Microsoft Forefront Unified Access Gateway 2010 est un sujet qui m’occupe beaucoup ces temps-ci, surtout en ce qui concerne la haute disponibilité et l’équilibrage de charge, DirectAccess oblige. le sujet est plus complexe qu’il ne peut y paraitre, surtout lorsqu’on se tourne vers les solutions matérielles.

 

Pour ceux qui veulent se lancer dans cette aventure, je leur conseille la lecture des guides de Design et de déploiement qui sont disponibles sous formes électroniques. Ce sont de bonnes bases de travail, pour commencer.

 

BenoîtS – Simple and Secure by Design (j’insiste sur le Secure)