PI Services

L’utilitaire “Logging Task” sous TMG 2010 est souvent nécessaire pour rechercher

des informations, pour dépanner, etc…

Ayant rencontré de fréquents problèmes lors de recherches “passées”, j’ai travaillé

avec Microsoft pendant plusieurs mois sur ce problème. Les multiples analyses

ont amené Microsoft à écrire un correctif privé (Unofficial RU).

Ce correctif devrait pris en compte par le prochain RU (RU4 ?).

Ayant observé des échecs de mise à jour du moteur VirusBuster, j’ai donc effectué

quelques recherches.

Microsoft ne travaille plus avec cet éditeur. Il est donc fortement recommandé de désactiver

la mise à jour et l’utilisation de ce moteur.

Voici ce que l’on peut lire sur le site de VirusBuster.

Désactivons cet antivirus:

Quitter la console en sauvegardant.

Un peu plus tard….

Voilà, tout est au vert.

Introduction

Dans le cadre d’un POC (proof of concept) ou bien tout simplement dans le cadre d’un rapprochement entre deux sociétés (fusion / acquisition), il peut être nécessaire de déployer Lync Server 2010 dans une forêt distante.

S’il s’agit d’un POC, l’intérêt de monter une forêt dédiée à Lync 2010 est généralement de ne pas impacter l’environnement de production (Lync nécessitant une extension du schéma Active Directory) et donc de permettre un retrait / une désinstallation facile de Lync dans l’hypothèse où le produit ne serait pas retenu à l’issue de la phase de test.

S’il s’agit d’une fusion entre deux sociétés ou tout simplement d’une société disposant de plusieurs forêts (reliées entre elles par le biais de relations d’approbation) on déploie généralement Lync dans une seule forêt (la forêt “principale” ou bien la forêt de ressources le cas échéant) pour éviter de multiplier les serveurs.

Quel que soit le cas de figure, à un moment donné l’administrateur se retrouve contraint de donner un accès à des serveurs Lync dans une forêt B sur ses utilisateurs de la forêt A.

Ce billet a pour but de lister l’ensemble des contraintes et actions à prendre en compte dans un tel scénario.

Points à prendre en compte

Les points à prendre en considération (par rapport à un déploiement de Lync en environnement mono-forêt et mono-domaine) sont les suivants :

• Une relation d’approbation (de type inter forêt) doit exister entre les deux forêts
• Les comptes utilisateurs de la forêt A doivent être provisionnés dans la forêt B par le biais d’un outil tél qu’ADMT (si la population est réduite) ou bien via un outil de synchronisation de compte tel que FIM (si l’environnement est de plus grande taille)
• L’outil de provisionnement des comptes doit migrer l'attribut SID du compte source dans l’attribut SIDHistory des comptes cible. Il est conseillé de désactiver les comptes présents dans la forêt cible pour des raisons de sécurité (de la même manière que pour une boîte aux lettres Exchange 2010 de type “linked”)
• Un script doit ensuite être développé pour copier le SID source dans l’attribut msRTCSIP-OriginatorSid du compte utilisateur
• Les certificats utilisés sur les serveurs frontaux et Edge Lync 2010 devront être émis par une infrastructure PKI reconnue comme de confiance par les clients des deux forêts

L’intégration du composant Lync au Webmail Exchange 2010 est possible quelle que soit la forêt dans laquelle est déployée Exchange. Si la messagerie Exchange 2010 est déployée dans une forêt distincte de celle de Lync alors les adresses SIP devront être ajoutées manuellement (ou pas script) sur les boîtes aux lettres.

N.B. : Le déploiement de Lync 2010 dans une forêt distante n’a pas d’impact particulier sur le déploiement des services de Mobilité Lync 2010.

TMG et support de l'IPv6

A l'instar de son prédécesseur, TMG 2010 ne supporte pas le trafic IPv6. Ainsi lors de l'installation, certaines fonctionnalités IPv6 intégrées à Windows Server 2008 / Windows Server 2008 R2 sont désactivées. De plus un serveur TMG rejette par défaut l'intégralité du trafic IPv6 qu'il reçoit.

Ce comportement est intrinsèque au produit et est documenté sur Microsoft Technet dans la page unsupported configuration. Voici un extrait de l'article :

Forefront TMG does not support IPv6 traffic
Issue: IPv6 traffic is not supported by Forefront TMG (except for DirectAccess).

Cause: Filtering of IPv6 traffic is not supported, and all IPv6 traffic is blocked by default.

Solution: It is recommended that you disable IPv6 traffic on the Forefront TMG computer or array members. To disable the IPv6 stack on the Forefront TMG computer or array member, see Knowledge Base article KB929852 (http://go.microsoft.com/fwlink/?LinkId=179983).

Microsoft conseille donc de positionner la clé de registre DisabledComponents avec la valeur 0xFFFFFFFF afin de désactiver totalement la pile IPv6 dans le système d'exploitation.

Le seul scénario où l'utilisation de l'IPv6 avec TMG est supporté correspond à la mise en oeuvre de Direct Access. En effet Direct Access nécessite l'activation de la pile IPv6 ainsi que celle de plusieurs technologies de transition (ISATAP, Teredo...).

Dans ce cas bien précis une clé de registre spécifique doit être créée avant l'installation de TMG sur le serveur.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\ISACTRL]
"CTRL_SKIP_DISABLE_IPV6_PROTOCOLS"=dword:00000001

A titre informatif, la procédure exacte de configuration de Direct Access sur TMG est disponible sur le Blog Technet dédié à TMG.

Remarque : Même si il est possible d'implémenter Direct Access sur un serveur TMG, la plateforme à privilégier reste Forefront UAG (Unified Access Gateway). Pour en apprendre plus sur les avantages de Direct Access avec UAG, consultez ce lien.

Problématique rencontrée avec le service VPN / RRAS

Une fois la clé de registre DisabledComponents positionnée et le serveur TMG redémarré, toutes les fonctionnalités de TMG fonctionnent correctement hormis le service VPN (qui correspond en fait au service Routage et accès distant de Windows) qui refuse de démarrer.

Dans la console MMC de TMG, le service Remote Access Service est en état arrêté et l'erreur suivante se produit lorsque l'on tente de le démarrer manuellement :

The service could not be started

En parallèle, les erreurs suivantes sont générées dans le journal Système à chaque tentative de démarrage du service.

• Source : Service Control Manager
  Event ID : 7024
  Description : The Routing and Remote Access service terminated with service-specific error A device attached to the system is not functioning.
• Source : RemoteAccess
• Event ID : 20103
  Description : Unable to load C:\Windows\System32\iprtrmgr.dll.

Ce sujet est abordé dans certains forums (dont les forums MS Technet) et un moyen de contournement consisterait à supprimer la clé de registre suivante ainsi que tout son contenu :

HKEY_LOCAL_MACHINE \ System \ currentcontrolset \ services \ remoteaccess \ routermanagers \ IPV6

Effectuer cette opération permet en effet un lancement manuel du service RRAS mais à chaque redémarrage du serveur TMG, le service RRAS refuse de démarrer automatiquement et il faut impérativement le lancer manuellement ! Dans ce scénario l'erreur suivante est loguée dans le journal d'évènements Applications :

• Log Name : Application
  Source : Microsoft Forefront TMG Firewall
  Event ID : 21199
  Description: The Remote Access Service configuration for VPN could not be completed. As a result, the Remote Access Service may be stopped.

Cette solution (suppression de la clé de registre routermanagemers\IPV6) n'est donc pas une fin en soi mais un simple contournement permettant de démarrer (manuellement) le service RRAS. De plus dans ce scénario, le service RRAS accepte de démarrer mais la configuration positionnée dans TMG ne descend plus sur le service RRAS (TMG ne remplit donc plus son rôle qui consiste à "piloter" le service RRAS).

La solution : réactiver l'IPv6 !

Après de nombreux tests infructueux, j'ai finalement déterminé une solution au problème : il suffit de "réactiver l'IPv6" en supprimant la clé de registre DisabledComponents !

Comme quoi il faut parfois aller au delà des préconisations Microsoft.

Si vous souhaitez aller plus loin, cette problématique est également en discussion sur le forum Technet suivant :

http://social.technet.microsoft.com/Forums/en-US/ForefrontedgeVPN/thread/d033a9d1-aff6-4098-a002-e5e15ee1834c

Le Management Pack pour Forefront Theat Management Gateway (TMG) 2010 (successeur d’IAS 2006) est disponible en version 7.0.7695.100.

Ce Management Pack fournit des fonctions :

• Déploiement de la topologie

• De Création d’événements signalant des interruptions de service

• Des alertes signalant des problèmes de configuration et des modifications des sources de données connectées

• De Vérification de l’exécution de tous les services dépendants

• De synchronisation du stockage de configurations

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5bfce6be-b681-48bf-bda9-a93d005820dd

Le contexte :

A l'instar de son prédécesseur, Forefront Threat Management Gateway 2010 (TMG) intègre un assistant de publication pour Exchange 2007.

Cet assistant permet de publier les divers services Web intégrés à Exchange 2007 :

• Le Webmail Outlook Web Access
• Le push mail ActiveSync
• Le mode Outlook Anywhere (RPC over HTTP)
• Les services Web Outlook 2007 (OAB Web, Autodiscover...)

Cet assistant génère des règles "sécurisées" dans le sens où seuls les répertoires virtuels associés à ces services Web sont publiés (/OWA, /EWS, /Autodiscover...). Il vous est aussi possible de paramétrer une authentification au niveau du périmètre à l'aide du port d'écoute Web.

Il est possible d'augmenter encore plus le niveau de sécurité de la publication en utilisant le filtre HTTP intégré à ISA/ TMG. Cette fonctionnalité, méconnue ou du moins très peu mise en valeur au sein d'ISA/TMG, permet d'effectuer un filtrage plus fin sur les requêtes HTTP.

Fonctionnement du filtre HTTP

Le filtre HTTP permet d'agir à différents niveaux :

• Limitation de la longueur des URL, des en-têtes et du corps des requêtes HTTP
• Blocage de certaines méthodes HTTP / Webdav
• Blocage d'extensions de fichiers et de types MIME
• Blocage de certains en-têtes HTTP
• Modification à la volée de l'en-tête "Server" ou de l'en-tête "Via"
• Blocage de "signatures" (une signature correspond à une application cliente reconnue grâce au contenu de l'en-tête HTTP "User-Agent")
• Etc.

Le filtre HTTP se configure indépendamment au niveau de chaque règle d'accès ou de publication Web. Dans une règle de publication Web, il est possible de lancer l'interface de configuration via le bouton Filtering de l'onglet Traffic (cf. capture d'écran ci-dessous).

Sinon il est également possible d'effectuer un clic droit sur la règle, puis de cliquer sur Configure HTTP.

Règles de publication pour Exchange 2007

Les outils d'analyse des requêtes HTTP comme Fiddler ou HTTPWatch permettent de mettre en valeur les méthodes HTTP utilisées par chacun des services Web Exchange.

Ainsi le Webmail Outlook Web Access n'utilise que les méthodes GET et POST alors que le mode Outlook Anywhere d'Outlook 2003/2007 utilise les méthodes Webdav RPC_IN_DATA et RPC_OUT_DATA.

Pour autoriser de manière très fine les bonnes méthodes sur chacun des types d'accès Web, il suffit de créer plusieurs règles de publication Web.

Le tableau ci-dessous est un exemple dans lequel six règles sont définies (une règle par service Web). Pour chaque règle sont indiquées les méthodes HTTP et les répertoires virtuels à autoriser.

Remarque : La sécurisation de ces flux passant également par l'authentification des utilisateurs, il est également intéressant d'implémenter une authentification au niveau du serveur ISA / TMG avec une délégation des informations d'identification vers le serveur CAS.

Sauvegarde de la configuration

Attention, la configuration du filtre HTTP n'est pas sauvegardée lorsque l'on effectue un export ou une sauvegarde dans la console MMC !!!

Pour sauvegarder la configuration du filtre HTTP il faut utiliser le script HttpFilterConfig.vbs fournit dans le SDK du produit ! Ce script prend en paramètre l'action (backup ou restore) ainsi que le nom de la règle.

Cela signifie qu'il faudra exécuter le script six fois pour sauvegarder la configuration de six règles. Dans ces conditions la création d'un batch est appréciable ! (ce batch peut également sauvegarder le reste de la configuration à l'aide du script ImportExport.vbs lui aussi présent dans le SDK).

A titre informatif, les SDK d'ISA Server 2006 et de Forefront Threat Management Gateway 2010 Beta3 sont disponibles aux adresses suivantes :

• SDK ISA : http://www.microsoft.com/downloads/details.aspx?familyid=16682c4f-7645-4279-97e4-9a0c73c5162e&displaylang=en
• SDK TMG : http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dff77975-84bf-484f-a3bd-9d8dd800e220#filelist

N'hésitez pas à laisser vos commentaires sur cette procédure !