ATA

Advanced Threat Analytics (ATA) est une plateforme OnPremise qui permet d’analyser l’ensemble des actions effectuées (accès à des ressources, verrouillage de compte, déplacement latéral…) avec des comptes Active Directory.

ATA fonctionne avec un serveur central qui récupère l’ensemble des logs des contrôleurs de domaines.

Ces logs peuvent être récupérés de deux façons :

• Via un agent installé sur les DC (nommé Lightweight Gateway)
• Via du port mirroring (nommé Full Gateway)

Ce billet s’intéressera uniquement à la configuration d’ATA avec des Lightweight Gateway.

Mise en place

Prérequis pour les Lightweight Gateway

Pour qu’ATA soit efficace il est impératif d’installer l’agent sur l’ensemble des DC du domaine Active Directory.

Pour la mise en place il faut

• l’ouverture du port TCP 443 entre les DC et le serveur ATA
• un compte de service (sans droit d’administration) présent dans l’AD
• un certificat SSL (optionnel, il est possible d’utiliser un certificat auto-signé pour la console d’administration)

Installation du serveur ATA

L’installation du serveur d’administration est très simple et se fait via l’assistant d’installation.

Il est possible de paramétrer le chemin d’installation, le chemin des logs et le certificat qui sera utiliser pour la console web.

La fin de l’installation s’effectue depuis l’interface d’administration web (https://localhost depuis le serveur ATA).

Le compte de service est nécessaire à ce moment pour lire l’AD.

L’étape suivante consiste à télécharger le setup pour les DC.

Installation des Lightweight gateways

L’installation de l’agent sur les DC se fait à travers l’assistant d’installation. Il est possible de paramétrer le chemin d’installation.

Une fois l’agent installé, celui-ci démarre automatiquement et le DC est visible dans l’interface d’administration.

Il est nécessaire de modifier la configuration d’un des DC dans l’interface d’administration pour le désigner comme Domain synchronizer candidate.

Tout DC défini comme Domain synchronizer candidat peut être responsable de la synchronisation entre ATA et le domaine Active Directory.

Analyse

Depuis l’interface d’administration les différentes alertes remontent automatiquement. Celles-ci sont classées par niveau de criticité : High, Medium et Low.

Il est possible de configurer des alertes mail et/ou d’envoyer l’ensemble de ces logs dans un SIEM.

Privileged Identity Management

Privileged Identiy Mangement (PIM) une une fonctionnalité de Microsoft Azure qui permet de déléguer des droits et des ressources dans Azure, Office 365 et Intune.

Mise en place

Prérequis

Pour mettre en place PIM il est indispensable d’avoir sur les comptes qui l'utiliseront :

• Une license Enterprise Mobility + Security (EMS) E5 ou à minima une license Azure AD Premium P2
• Le MFA activé

Par défaut, PIM n’est pas actif dans Azure. Pour l’activer, il faut se rendre sur le portail Azure (https://portal.azure.com) avec des droits d'"administrateur global" et rechercher Privileged Identity Management.

Une page nous invite à vérifier notre identité via le MFA.

Une fois la vérification d’identité effectuée il est possible d’activer la fonctionnalité.

Quelques instants après le service est disponible.

Il est ensuite nécessaire de se déconnecter / reconnecter du portail Azure.

Configuration des rôles

Depuis PIM, dans la section Manage puis Roles, il existe par défaut une quarantaine de rôle que l’on peut modifier.

Dans cet article, je vais modifier le rôle Exchange Administrator pour qu’il soit actif durant 3H et qu'il nécessite une validation (par défaut le rôle est en auto-validation pour une durée d’une heure). Les utilisateurs Adminstrator et Megan auront le pouvoir d’accepter ou non la demande d’accès au rôle.

Pour ça, dans PIM, dans la section Manage puis Settings, je sélectionne Roles.

Je sélectionne le rôle Exchange Administrator et je change les paramètres.

Je peux ensuite depuis PIM, dans la section Manage puis Roles ajouter un utilisateur à mon rôle.

Obtention du rôle

Une fois le rôle ajouté sur l’utilisateur, celui-ci reçoit un mail pour le prévenir.

Depuis le lien présent dans le mail il est alors possible de faire la demande pour activer le rôle.

Une vérification d’identité via MFA est nécessaire à cette étape également.

Une fois l’identité confirmée, il est possible de demander l’activation du rôle.

Je peux réduire le temps d’activation du droit (de 30 minutes à 3h) et je dois indiquer un message pour obtenir les droits.

Une fois la demande effectuée, il ne reste plus qu’à attendre la validation par un administrateur.

Les administrateurs reçoivent un mail indiquant qu’une demande d’activation de rôle est en attente.

Depuis le lien présent dans le mail, il est possible d’accepter ou de refuser la demande.

Un message est obligatoire pour approuvé la demande.

L’utilisateur reçoit alors un mail lui indiquant qu’il dispose des droits d’administration.

Depuis le portail PIM l’utilisateur peut voir ses droits en cours et passés.

Il a également accès à la tuile Admin et bien évidement à la page d’administration d’Exchange dans notre cas.

Log

L’ensemble des droits demandées, validées et refusées est loggé dans PIM, section Activity puis Directory roles audit history.

Les administrateurs ont également le mail prouvant la validation au rôle.

Voila qui conclut ce billet sur PIM !

Dans les nouveautés de Windows Server 2012 l’interface graphique de gestion granulaire de mot de passe vient simplifier le travail de l’Administrateur en lui évitant de passer par les GPO et ADSIEdit.

La gestion granulaire des mots de passe est déjà disponible depuis Windows Server 2008, un niveau fonctionnel de 2008 suffit donc pour bénéficier de l’interface graphique sur un serveur 2012.

Avant de commencer : il est très probable que dès la mise en place de la stratégie vos utilisateurs aient à changer de mot de passe, or certaines applications ne peuvent le gérer, je vous conseille donc d’appliquer la stratégie une fois vos utilisateurs délogué.

Dans le Server Manager, lancer le tool “Active Directory Administrative Center” :

Une fois lancé, basculer en vue arborescente (Tree View), puis dans le dossier System, double-cliquer sur le dossier “Password Settings Container”

Pour créer une nouvelle politique de mot de passe, sélectionner dans l’onglet de droite : New –> Password Setting

Nous arrivons alors sur cette fenêtre et l’on remarque que Windows Server 2012 se veut intuitif :

Les textbox précédés d’un astérisque rouge sont des éléments requis pour la création de la stratégie.

Parmi ces éléments, il y a le champ “Precedence”, qui permet – dans le cas déconseillé ou plusieurs stratégies s’appliquerait aux mêmes utilisateurs ou groupes – de gérer quelle stratégie s’applique en priorité.

Une fois le paramétrage terminé, cliquer sur “Add” et la stratégie est immédiatement exécutée pour les utilisateurs concernés.

La problématique

Lors du déploiement d'une Appliance Symantec Brightmail Gateway un certificat numérique auto-signé est automatiquement généré et assigné à l'interface Web du rôle Control Center.

La principale conséquence de cette configuration est l'apparition systématique d'une fenêtre d'avertissement lors de la connexion à l'interface Web d'administration (cf. capture d'écran ci-dessous).

De plus l'URL du navigateur apparaît en rouge pour rappeler que le certificat SSL utilisé pour chiffrer les données est invalide.

Cela n'est pas gênant lorsque seule une population d'administrateur se connecte à l'interface Web. Cependant, lorsque l'accès utilisateur à la quarantaine est activée, il devient nécessaire de corriger ce comportement.

Cette configuration doit être effectuée en plusieurs étapes :

1) Configuration de l'URL d'accès à la quarantaine
2) Import de l'autorité de certification interne dans l'Appliance
3) Génération d'une requête de certificat (CSR)
4) Validation de la requête auprès de l'autorité de certification interne (ou externe)
5) Import du certificat signé par l'autorité dans l'Appliance
6) Positionnement du certificat sur l'interface Web

Procédure à suivre

1) Configuration de l'URL d'accès à la quarantaine

La première étape consiste à définir, puis à configurer l'URL d'accès à la quarantaine utilisateur. Pour cela il faut se connecter à l'interface Web d'administration en tant qu'administrateur, cliquer sur l'onglet Spam, puis sur le lien Quarantine Settings dans le menu de gauche.

On peut ensuite spécifier l'URL d'accès à la quarantaine dans le champ Spam Quarantine Login URL. Dans l'exemple ci-dessous l'URL retenue est la suivante :

• https://sbg.piservices.fr:41443/brightmail

Remarque : L'accès utilisateur à la quarantaine nécessite également que l'option Administrator-only Quarantine soit décochée et donc que l'accès à un annuaire soit configuré (pour l'authentification LDAP). De plus une entrée DNS doit également être créée pour effectuer la correspondance entre le FQDN de l'interface Web (exemple : sbg.piservices.fr) et l'adresse IP du control center.

2) Import de l'autorité de certification interne dans l'Appliance

Dans l'hypothèse où l'on souhaite utiliser un certificat émis par une autorité de certification interne, il faut impérativement insérer le certificat de l'autorité de certification racine dans le magasin Certificate Authority de l'Appliance.

Pour cela l'administrateur doit se connecter à l'interface Web d'administration, cliquer sur l'onglet Administration, puis sur le lien Certificates dans le menu de gauche. Il faut ensuite sélectionner l'onglet Certificate Authority, puis cliquer sur le bouton Update.

L'assistant propose alors d'injecter un certificat présent localement sur le poste de l'administrateur. Ce certificat doit respecter le format PEM (CER encodé en base64).

Remarque : Dans le cas où l'autorité de certification interne est issue du monde Microsoft (serveurs sous Windows Server 2003, 2003 R2, 2008 ou 2008 R2), les formats généralement utilisés sont les formats CER ou CRT. Pour les convertir au format PEM un utilitaire de conversion comme Crypto4PKI peut être utilisé.

3) Génération d'une requête de certificat (CSR)

L'étape suivante consiste à créer une requête de demande de certificat dans l'interface Web d'administration. Pour cela il faut aller dans l'onglet TLS & HTTPs Certificates, puis cliquer sur le bouton Add.

Dans l'assistant de création de la requête il faut sélectionner Certification Authority Signed dans le type de certificat, renseigner le nom commun qui doit correspondre à l'URL d'accès à la quarantaine (ici "sbg.piservices.fr") ainsi que tous les champs descriptifs demandés.

Le bouton Request permet ensuite de générer la demande de certificat ou CSR (Certificate Signing Request).

La requête obtenue doit ensuite être conservée en mémoire (cf. capture d'écran ci-dessous).

Suite à cette manipulation le certificat apparaît comme étant Requested dans l'interface Web.

4) Validation de la requête auprès de l'autorité de certification interne

La requête de certificat doit ensuite être validée et signée numériquement par l'autorité de certification interne. Si il s'agit d'une autorité de certification Microsoft, l'une des méthodes consiste à se connecter à l'interface Web d'administration (l'URL est généralement du type https://server/certsrv).

Pour commencer l'administrateur doit sélectionner le lien Request a certificate, puis advanced certificate request et enfin Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

Dans la page Submit a Certificate Request or Renewal Request il faut insérer la requête précédemment générée, sélectionner le modèle de certificat Web Server et enfin cliquer sur le bouton Submit.

Si l'autorité de certification est de type "entreprise" et si le compte utilisateur possède les bonnes autorisations alors un certificat signé numériquement au format CER est immédiatement émis par l'autorité de certification (dans le cas d'une autorité de certification "autonome", l'émission du certificat doit être validée manuellement dans la console MMC Autorité de certification).

Remarque : Le certificat émis étant au format CER, il doit être converti au format PEM pour pouvoir être utilisé au sein de l'interface Web Brightmail.

5) Import du certificat signé par l'autorité dans l'Appliance

Pour importer le certificat au format PEM dans l'interface Web Brightmail, il faut cliquer sur l'onglet Administration, puis sur le lien Certificates et enfin sur le bouton Import.

Suite à l'opération d'import un message indique que le certificat a été correctement importé et le certificat apparaît comme étant disponible (available).

6) Positionnement du certificat sur l'interface Web

La dernière étape consiste à positionner le certificat sur l'interface Web d'administration du control center. Pour cela il faut cliquer sur l'onglet Administration, puis sur le lien Control Center.

Dans la page Control Center Settings, il faut ensuite cliquer sur l'onglet Certificates, puis sélectionner le nouveau certificat dans la liste déroulante User interface HTTPs certificate.

Une fois cette dernière modification opérée, aucun message d'erreur n'est généré dans les navigateurs lors de l'accès à l'interface Web et l'URL du site ne s'affiche plus sur fond rouge mais sur un fond blanc ou vert (en fonction du type de certificat utilisé).

L’installation de SAV 10 demande des pré-requis d’installation.

Avant d'installer tous les paquets, vous devez installer Sun JRE version 1.4.2 ou supérieur avec la version illimitée de JCE. Par défaut, JRE est livré avec la version de cryptographie forte de JCE, mais LiveUpdate nécessite la version illimitée. Si vous voulez utiliser l'interface graphique, vous devez également installer un environnement X11.

Il y a des pré-requis supplémentaires pour certains noyaux Linux (Fedora et Debian). Red Hat étant nativement supporté, nous ne détaillerons pas ces pré-requis.

Ils sont disponibles sur le site de Symantec à l’addresse : http://service1.symantec.com/support/ent-security.nsf/docid/2010062217010148.

L'installation des packages sous Linux doit respecter un ordre précis :

1. SAV

2. savap (ou savap-x64 pour la version 64-bit)

3. savjlu

4. savui

En premier, le noyau de SAV : SAV

Il contient le noyeau : « savap »

Il utilise une fonctionalité de recherche d’OS et de composants dont il a besoin.

Attention, au moment du démarrage du système, SAV pour Linux détecte la distribution Linux exécutée et assemble une liste des modules du noyau.

« Using a "fuzzy match" algorithm, it will go through the list of candidates, one at a time, until it finds one that can be loaded by the Linux OS. »

L’utilisation d'un algoritme à adéquation partielle ("fuzzy match") permet de lister les composants un à un, jusqu'à ce qu'il trouve celui qui peut être chargé par le système d'exploitation Linux.

Si aucun des systèmes linux n’est détecté comme compatible et ne peut être chargé dans le noyau, SAV pour Linux va écrire un message d'erreur dans la console et enregistrer l'erreur dans le journal des messages du système (/var/log/messages ou /var/log/syslog).

Les deux autres paquets contiennent Java et les fichiers LiveUpdate GUI.

Une fois l'installation terminée, vérifiez que les démons suivants sont en cours d'exécution:

1. rtvscand

2. symcfgd

Si ces processus ne sont pas en cours d'exécution, vous pouvez les démarrer comme suit:

1. # / Etc / init.d / start rtvscand

2. # / Etc / init.d / start symcfgd

Pour rappel :

Doc Sav 10 linux : Lien FTP

Pour préconfigurer le package de SAV 10 for Linux, il faut utiliser « ConfigEd.exe ».

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007100513224548?Open&seg=ent

Cette application demande la présence d’un SAV sur le poste qui l’exécute.

Note : il est possible de passer des commandes d’exclusion de Scan, directement sur le serveur une fois celui ci installé :

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2009072917021448?Open&seg=ent

Pour info :

un script et un fichier texte commençant par #!/bin/sh

Exemple de script pour faire une exclusion :

#!/bin/sh

symcfg add -k '\Symantec Endpoint Protection\AV\Storages\FileSystem\RealTimeScan' -v HaveExceptionDirs -d 1 -t REG_DWORD

symcfg add -k '\Symantec Endpoint Protection\AV\Storages\FileSystem\RealTimeScan\NoScanDir' -v /my/path/to/folder1 -d 1 -t REG_DWORD

/my/path/to/folder1 étant le chemin du dossier à exclure.

(Lu depuis http://www.tuteurs.ens.fr/unix/shell/script.html )

ensuite il faut le rendre exécutable chmod u+x lenomdufichier et pour le lancer soit : ./lenomdufichier ou sh lenomdufichier

Cette grosse faille de sécurité a été publiée par Microsoft le 16 juillet dernier ( CVE-2010-2568 ). Elle exploite le mode de fonctionnement des raccourcis ( ".LNK" ) sur tous les OS Windows. Bien sûr la mise à disposition du patch correspondant sera annoncée dans le bulletin de sécurité :http://www.microsoft.com/technet/security/advisory/2286198.mspx.

L’exploitation de cette faille se traduit par le fait, qu’un malware puisse s’exécuter par le biais du détournement du mécanisme d’affichage d’icône.

Cette vulnérabilité est exploitable localement par disque amovible ou via des partages réseaux et WebDAV

Il n'existe pas de correctif à ce jour. Mais en attendant des solutions de contournement recommandées par Microsoft peuvent-être mises en place.

La désactivation de l'affichage d'icône pour les raccourcis peu ainsi limiter les risques d’exploitation de cette faille. Cette solution affiche les icônes en blanc par défaut. Pour se faire il est nécessaire depuis l’éditeur de registre, de rechercher dans la ruche HKEY_CLASS_ROOT, IconHandler afin de modifier sa valeur par défaut par 0 après l’avoir exporté pour revenir à la valeur précédente dès la sortie d’une mise à jour.

Autre solution de contournement la désactivation du service WebClient se fait en passant par le gestionnaire de l’ordinateur ou en exécutant services.msc

Enfin troisième solution le blocage du téléchargement des fichiers LNK et PIF depuis Internet est recommandé. 

La liste des systèmes Windows concernés et supportés s'étend de Windows XP SP3 à Windows Serveur 2008R2.

Notez que des éditeurs d’antivirus (Sophos, Eset) ont déjà répertorié Stuxnet depuis mi-juillet exploitant cette vulnérabilité.

MAJ: Le 3 Aout Microsoft apporte une réponse par la mise en ligne de l'update KB2286198 annoncé dans le bulletin de sécurité suivant http://www.microsoft.com/technet/security/bulletin/MS10-046.mspx

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 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 !