PI Services

Certains serveurs SMTP réalisent une vérification de l’entête d’un message électronique

et particulièrement du champ Message-Id généré par le serveur source de l’expéditeur.

Si ce champ est  incorrect ou vide une erreur 553 5.0.0 Bogus “Message-Id:” header

est retournée. Le message est donc rejeté.

L’erreur suivante est reçue par l’expéditeur:

Impossible de contacter le(s) destinataire(s) suivant(s) :

yyy@zzz.com le 05/05/2010 10:43

Le système de messagerie n'a pas pu remettre ce message mais n'a pas signalé de raison particulière. Vérifiez l'adresse du destinataire et réessayez d'envoyer le message. Dans le cas d'un nouvel échec, contactez votre administrateur système.< aaa.bbb.com #5.0.0 SMTP; 553 5.0.0 Bogus "Message-Id:" header>

Dans ce cas, le champ Message-ID à la valeur null qui n’est pas conforme pour certains

serveurs SMTP.

Message-ID: null

Un champ conforme est de ce type:

Message-ID: <BC0DD8437D918340AC4AF8FD8F367240072EE3BB@Fxxx.fyyy.fr>

Quelle est la cause d’une valeur non conforme dans ce champ?

La raison est simplement l’excès de zèle de certains administrateurs de messagerie

sur la sécurité.

Une sécurité excessive peut donc pénaliser les échanges classiques voir pénaliser les 

affaires commerciales.

Microsoft est en train d’analyser l’existence d’une vulnérabilité dans SharePoint Services et SharePoint Server qui permet l’exécution de scripts arbitraires permettant d’effectuer une élévation des privilèges au niveau des sites SharePoint.

Les versions affectées par cette vulnérabilité sont :

• Microsoft Office SharePoint Server 2007 SP1 et SP2
• Microsoft Windows SharePoint Services 3.0 SP1 et SP2

Les deux architectures x86 et x64 sont affectées.

Pour plus de détail cliquer ici

Pré-requis et architecture

Parmis les pré-requis à la mise en place de DirectAccess, un serveur Web répondant en HTTPS est nécessaire. Ce serveur, nommé NLS pour Network Location Server, ne doit pas être joignable depuis l'extérieur. En effet, sa seule et unique fonction est de permettre aux postes clients sous Windows Seven de détecter correctement leur emplacement réseau :

• Si le serveur NLS est accessible, alors le poste client sait qu'il est connecté à l'intérieur du réseau de l'entreprise (dans ce cas, le poste ne tente pas de se connecter à l'aide des technologies DirectAccess)
• Si le serveur NLS est inaccessible, alors le poste client sait qu'il est connecté à l'extérieur (dans ce cas, le poste tente de se connecter à l'aide des technologies DirectAccess)

Le but du serveur NLS n’est pas d’afficher un site Web complexe mais juste de répondre à une simple requête HTTP encapsulé dans du SSL. En ce qui concerne le contenu de cette page, il n'y a pas de pré-requis particulier (une page HTML vide, ou bien la page par défaut de IIS 7.5 peut tout à fait être utilisée!). Pour héberger le "rôle" NLS, Microsoft conseille de respecter les préconisations suivantes :

• Utiliser un serveur dédié (même si il est tout à fait envisageable de réutiliser un serveur Web existant)
• Mettre en place un site Web hautement disponible

La mise en place de la haute disponibilité sur le rôle NLS est extrêmement importante ! En effet, si le serveur NLS tombe, tous les postes de travail situés en LAN pour lesquels DirectAccess est configuré, penseront qu'ils sont à l'extérieur de l'entreprise (car le NLS ne sera pas joignable) et tenteront alors de se connecter en IPv6 à la passerelle DirectAccess ce qui perturbera leur connexion au réseau de l'entreprise !

Si l'on respecte à la lettre les préconisations de Microsoft, la mise en oeuvre du rôle NLS implique donc l'utilisation de deux serveurs Web avec équilibrage de charge réseau (load balancer matériel ou NLB). Afin de minimiser les coûts en matériel, il est tout à fait possible de virtualiser les serveurs Web sous Microsoft Hyper-V R2 et d'activer le NLB entre les deux machines virtuelles pour fournir la haute disponibilité.

Dans la suite de ce billet, vous trouverez la procédure complète mettre en place cette configuration (ferme de machines virtuelles NLS en NLB). La petite subtilité étant l'usage d'une version Core de Windows Server 2008 R2 ce qui permet de réduire encore plus l'utilisation en ressources matérielles sur les serveurs Hyper-V tout en minimisant la maintenance.

Déploiement de 2008 R2 en version core

Une fois l'installation du système en version Core réalisée dans les deux machines virtuelles, et une fois le mot de passe du compte Administrator défini, une invite de commande telle que celle-ci s'affiche :

Une série de commande va permettre de mettre en place le serveur Web IIS 7.5.

Pour commencer la commande sconfig (nouveauté de 2008 R2), permet d'effectuer une configuration rapide (nom de la machine, jointure au domaine, configuration TCP/IP).

Je ne détaille pas cette partie qui ne devrait pas poser trop de soucis. En cas de doute vous pouvez vous référer à la documentation sur Technet ( http://technet.microsoft.com/en-us/library/ee441254(WS.10).aspx). Pour les amateurs de l'invite de commande, il est également possible d'exécuter ces différentes opérations à l'aide de netsh (cf. : http://technet.microsoft.com/en-us/library/ee441257(WS.10).aspx).

Une fois ces différentes opérations effectuées on peut envisager d’activer le bureau à distance pour avoir une administration plus souple.

Mise en place du rôle IIS 7.5 sur 2008 R2 en version core

Une fois le système correctement configuré, le rôle serveur Web doit être installé.

Remarque : Dans un premier temps, seuls les composants basiques de IIS sont déployés afin de pouvoir disposer d'un site (enfin une page ;-) ) complètement statique.

Une nouvelle commande est apparue dans 2008 R2 pour installer les rôles et fonctionnalités offerte par la version core :

dism /online /enable-feature /featurename:IIS-WebServerRole

Pour faciliter l’administration du site, il faut activer la prise de contrôle à distance au travers de la console d’administration Internet Information Service (IIS) Management et le WAS :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Attention cela ne suffit pas, il faut aussi autoriser l’administration à distance par MMC en ajoutant la clé de registre suivante :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

La dernière étape consiste à démarrer le service de management et à modifier son type de démarrage en automatique pour qu'il se lance à chaque démarrage de la machine :

sc config wmsvc start= auto

net start wmsvc

Une fois ces étapes réalisées, le site Web par défaut de IIS doit être visible en saisissant http://<IP-SERVEUR> et le rôle IIS du serveur Core peut être configuré à distance à la console MMC graphique !

Installation du certificat et passage en HTTPS

Pour avoir accès au site en HTTPS il reste deux choses à faire. La première consiste à installer le certificat contenant la clé privée en ligne de commande :

certutil –importPFX  “C:\certificat.pfx”

Lors de son exécution la commande certutil nécessite la saisie du mot de passe pour valider l’import du PFX.

Une fois le certificat importé dans le magasin de certificat de l'ordinateur, il faut configurer IIS de manière à ce qu'il le prenne en compte. Pour cela, vous pouvez utiliser la console IIS Management depuis un poste distant. Il faut cliquer sur le site Web par défaut, puis sur Bindings, et enfin sélectionner le certificat voulu dans la liste déroulante (dans cet exemple le certificat se nomme "PI Services Secure Access").

A l'issue de cette étape, le site Web par défaut doit être accessible en saisissant l'URL https://<IP-SERVEUR>.

Mise en place du NLB entre les deux machines virtuelles

Remarque : Avant d'entamer la configuration du NLB sur les deux machines virtuelles, vérifiez que l'option enable spoofing of MAC address est bien activée dans les propriétés de la carte réseau sur les deux machines virtuelles (cette option se configure avec la console MMC Hyper-V Manager). Cette option est apparue avec Hyper-V R2 et permet le bon fonctionnement du NLB au sein des machines virtuelles.

Pour mettre en place le Network Load balancing, il faut commencer par installer la fonctionnalité sur chacun des serveurs de la ferme. Pour cela, saisissez la commande suivante :

Dism /online /Enable-Feature /FeatureName:NetworkLoadBalancingHeadlessServer

Une fois la fonctionnalité installée, le plus simple est d'utiliser la console Network Load Balancing Manager depuis un poste client pour configurer le cluster (la console doit être exécutée avec les "crédentials" d'un compte possédant les droits administrateur sur les serveurs Web).

Pour créer un nouveau cluster, il faut effectuer un clic droit sur Network Load Balancing Clusters, sélectionner New, puis se laisser guider par l’assistant :

Il est possible d'affiner la configuration de la ferme NLB en précisant les ports TCP et UDP sur lesquels l'équilibrage de charge sera actif. Dans l'exemple ci-dessous, deux règles activent l'équilibrage de charge sur les ports 80 TCP et 443 TCP (seul l'équilibrage de charge sur le 443 est nécessaire à DirectAccess).

Pour ajouter un nouveau membre à la ferme NLB, il faut effectuer un clic-droit sur le cluster existant, sélectionner Add Host to Cluster, puis préciser l'adresse IP du deuxième serveur Web.

Une fois le second noeud ajouté et le cluster correctement convergé, il faut vérifier que le site Web est accessible en HTTPs via l'adresse IP virtuelle du cluster (saisir https://<adresse-IP-virtuelle> dans un navigateur).

La dernière étape consiste à créer une entrée dans le DNS pour pointer vers l'adresse IP virtuelle. Cette entrée DNS doit correspondre au FQDN du certificat précédemment importé (par exemple NLS.PISERVICES.FR).

Une fois l'entrée DNS créée, vérifiez que le site Web est accessible via l'URL https://nls.piservices.fr. Aucune erreur de certifiat ne doit s'afficher dans le navigateur !

Remarque : Il est possible de tester le cluster en mettant en pause l'une des deux machines virtuelles (via la console MMC Hyper-V Manager) !

A partir de cet instant la ferme de serveurs NLS est pleinement opérationnelle !

Mise en place d'une page Web dynamique sur la ferme NLS

Pour faciliter le dépannage lors de la mise en place de DirectAccess, il est souvent nécessaire de connaitre l'adresse IP utilisée par le poste de travail pour accéder au serveur NLS. Cela permet de déterminer quelle technologie de transition a été utilisée (6to4, Teredo, ISATAP, NAT64...).

Pour cela il suffit de modifier la configuration de la page par défaut des serveurs NLS afin d'afficher l’IP du client. Dans cet exemple, le langage ASP.net est utilisé.

Pour pouvoir héberger une page en ASP.net des composants supplémentaires doivent être installé sur les serveurs. Tout d’abord, il faut installer les Framework .NET 2 et 3 :

dism /online /enable-feature /featurename:NetFx2-ServerCore

dism /online /enable-feature /featurename:NetFx3-ServerCore

Les fonctionnalités ISAPI et ASP.NET doivent également être installées sur le rôle IIS :

dism /online /enable-feature /featurename:IIS-WebServerRole

dism /online /enable-feature /featurename:IIS-ISAPIFilter

dism /online /enable-feature /featurename:IIS-ISAPIExtensions

dism /online /enable-feature /featurename:IIS-NetFxExtensibility

dism /online /enable-feature /featurename:IIS-ASPNET

Enfin il faut installer le WAS et le service de gestion :

dism /online /enable-feature /featurename:IIS-ManagementService

dism /online /enable-feature /featurename:WAS-WindowsActivationService

dism /online /enable-feature /featurename:WAS-ConfigurationAPI

Pour démarrer le service de management, le rendre automatique et autoriser la gestion à distance, il faut exécuter les commandes suivantes :

Reg Add HKLM\Software\Microsoft\WebManagement\Server /V EnableRemoteManagement /T REG_DWORD /D 1

sc config wmsvc start= auto

net start wmsvc

A présent le serveur est capable d’interpréter du code ASP.net, il est donc possible de créer une page ASPX. Dans l'exemple ci-dessous, une page default.aspx a été créée et le site a été reconfiguré pour l'utiliser en document par défaut :

Voici le résultat obtenu avec les méthodes permettant de récupérer les adresses IP (seul le "body" de la page est affiché) :

<body>
    <form id="form1" runat="server">
    <div>
        Nom du serveur :    <%= Request.ServerVariables["SERVER_NAME"]%><br />
        Adresse IP du serveur :     <%= Request.ServerVariables["SERVER_ADDR"]%><br />
        Adresse IP du visiteur :     <%= Request.ServerVariables["REMOTE_ADDR"]%>
    </div>
    </form>
</body>

N'hésitez pas à laisser un commentaire sur cette procédure si vous avez des éléments à ajouter ou des précisions à demander.

Problème rencontré :

Dans le cadre d’une implémentation de SEP dans une entreprise, beaucoup de services informatiques ont la volonté d’intégrer le client SEP dans le “Master”. Pour intégrer le produit, l’idée première serait de créer un package d’installation avec la console SEPM et de lier le client SEP directement a la console. Ce package serait déployé sur le poste de référence et donc présent au sein du "master".

Cette idée d’optimisation serait idéale si le client SEP ne possédait pas un “SID” unique créé lors de l’intégration du client à l’architecture SEP. L’effet créé est que un seul poste remonte dans la console (même si le master contenant l'installation de SEP est déployé sur des centraines de postes), et change de nom, d’IP, … à chaque démarrage d’une machine issue de la même intégration.

Exemple, dans l’ajout d’un poste (PosteB) avec le même client SEP d’installé, la communication avec le serveur SEPM ne fait pas s’ajouter un client supplémentaire dans la console, mais change les “informations” d’un autre poste (PosteA)

Solution apportée :

Pour optimiser le déploiement, il est possible de pré-installer le client SEP dans un “Master”. Le client doit être impérativement installé en mode “Non-géré”. A la fin d’un déploiement, il suffit de “lier” le client SEP a la console de gestion grâce a l’outil “Sylinkdrop.exe” et d’un fichier de liaison “Sylink.xml”.

Symantec recommande d’installer l’antivirus après la “masterisation” du poste. Cela évite d’avoir à refaire les “Masters” à chaque évolution (MRx) du produit.

Si des masters ont déjà été créé, voici un lien de Symantec qui explique les modifications à apporter au client SEP installé:

http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/d84071c5137d6d318825738a00663b8d?OpenDocument

NOTE: La clé de registre HKLM \ SOFTWARE \ Symantec \ Symantec Endpoint Protection \ SMC \ SYLINK \ SyLink \ SySoftk peut également être supprimée si elle est présente.
Une fois l'image “Ghost” appliquée sur un nouveau système, le client va générer une valeur d'identification unique, se connecter avec son SEPM et s’enregistrer.  Lors de l'inscription sur le le serveur de gestion,  SEPM va enregistrer toutes les informations clientes nécessaires dans la base de données.

Problème rencontré

Certains postes peuvent rester indéfiniment avec la notification « besoin d’un redémarrage pour le Network Threat Protection » alors qu’ils ont déjà été redémarrés plusieurs fois depuis l’installation du client SEP et alors même que le composant Network Threat Protection (NTP) n’est pas installé.

Solution apportée

L’origine de cette panne est la DLL Teffer2.sys. Cette DLL n’arrive pas ou plus à se charger. Le problème est que cette DLL n’est utilisée que pour le composant NTP.

Cf. la Kb de Symantec :

• http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/1d710556d47fe468882575ef00652769?OpenDocument

Une réparation de l’installation ou une réinstallation du produit ne suffisent pas pour régler ce problème.

La solution est d’installer le composant NTP de SEP pour que le système enregistre la DLL, puis de re-désinstaller proprement le composant pour que Windows dé-valide le besoin de redémarrage et de chargement de cette DLL.

Rappel sur LUA et PostGreSQL

Dans le cadre d’un projet d’intégration de SEP, j’ai installé un serveur LiveUpdate en interne. LiveUpdate est la technologie utilisée par les produits Symantec pour se mettre à jour par Internet (c'est l'équivalent d'un serveur WSUS chez Microsoft).

Dans la suite de ce billet, Live Update désigne le service de mise à jour et Live Update Administrateur (LUA) désigne le serveur interne de distribution des mises à jour.

Le client Live Update utilise une technologie PULL pour se connecter en HTTP et en FTP. Par défaut le client Live Update est configuré pour pointer vers les serveurs publics de Symantec. Il est possible de modifier ce comportement de manière à ce qu'il se connecte au serveur LUA interne en lieu et place des serveurs publics.

Le serveur LiveUpdate Administrateur utilise le moteur de base de données PostgreSQL . La version de PostgreSQL fournie avec LUA 2.x est la version 8.1(cf. site officiel PostGreSQL).

Remarque : Le support technique de Symantec recommande fortement à ses clients l'application de toutes les mises à jour du serveur LUA de manière à bénéficier de toutes les améliorations disponibles (notamment des améliorations apportées par la version 8.1 de PostGreSQL).

Le moteur PostGreSQL est configurable via le fichier « postgresql.conf » situé a la racine du dossier d’installation de LiveUpdate Administrator.

Tuning des performances PostGreSQL

Voici les principaux paramètres ayant une grande influence sur les performances de la base ainsi que les valeurs recommandées :

1. shared_buffers

Le paramètre shared_buffers détermine la quantité de mémoire utilisée pour la mise en cache des données. Certaines sources recommandent une valeur correspondant à 25% de la mémoire vive du serveur.

Par défaut la valeur du paramètre shared_buffers est de 32Mo avec LUA 2.2. Une valeur de 512 Mo permet d'améliorer les performances. Certains gros clients ont augmenté cette valeur jusqu'à 1024 Mo et on ensuite pû observer de grandes améliorations.

2. temp_buffers

Le paramètre temp_buffers n'est utilisé que pour le maintient des tables temporaires en mémoire.

Comme LUA 2.x ne dépend pas fortement de ces tableaux, certains clients ont réduit cette valeur de 2 Mo dans le cadre de leur mise au point.

3. work_mem

work_mem fixe la quantité maximale de mémoire à utiliser pour l’exécution d’une requête.

Le réglage de work_mem à 256 Mo a conduit à une amélioration des performances pour certains clients.

4. max_fsm_pages

Cette valeur doit être réglée sur le nombre maximum de pages de données (affichage Web) que vous voulez modifier ou supprimer. Une valeur de 20 000 a bien fonctionné pour certains clients.

5. wal_buffers

Une valeur de 256Kb devrait être suffisamment grande. pour une bonne utilisation de LUA.

6. checkpoint_segments

Les valeurs recommandées vont de 16 à 128 en fonction de l’espace disque disponible.

Par défaut, la valeur est de 3. Certains gros clients ont augmenté cette valeur à 30 et vu de grandes améliorations.

7. effective_cache_size

Effective_cache_size définit la taille du cache disque par rapport à la quantité de mémoire RAM disponible pour la mise en cache des données,

Il est recommandé de configurer la valeur effective_cache_size à 50% de la RAM du système (cette préconisation est valide si et seulement si le serveur est dédié au rôle LUA).

Par défaut, LUA 2.2 a effective_cache_size a une valeur de 128Mo. Certains gros clients ont augmenté cette valeur jusqu'à 2048 Mo et vu de grandes améliorations.

SEP, Symantec Endpoint Protection est le dernier antivirus de Symantec. Chaque évolution de SEP est nommée MR (Major Release). Symantec corrige et améliore la solution SEP à chaque release. Il est donc important de toujours maintenir à jour la solution avec le dernier correctif.

Aujourd’hui, nous sommes à la version SEP MR6

Chaque MR apporte trois évolutions :

• Evolution du SEPM (cf post sur l’architecture SEP)
• Evolution de la base SEP (SQL ou Sybase)
• Evolution des clients

Ces évolutions ne sont ni une mise a jour du moteur antivirus, ni une mise à jours de la base virale du client SEP.Chaque montée de version fait donc l’objet d’un « upgrade » de l’architecture SEP.

Il existe plusieurs méthodologies pour faire cette montée de version. Voici celle que j’estime être la plus sure, et la plus rapide.

Les pré-requis sont :

• Un serveur de « spare »
• La nouvelle version (les sources, CD1)
• Du temps :-) (cette migration peut se faire sur deux à trois jours)

1) Rappel d’une architecture SEP (cf : Lien Solution SEP )

Une architecture SEP est constituée des composants suivants :

• SEPM (manager)
• Clients SEP (postes et serveurs client)
• GUP (client SEP, serveur ou poste de travail, relais pour la mise à disposition des mises à jour)
• Base de données (une par défaut, SQL ou Sybase) SEP

2) Montage d’un serveur de relais pour la migration

Un second serveur de relais sert à ne pas impacter les utilisateurs lors de la migration du serveur SEPM (montée de version du SEPM et de la base de données).

Donc, la première des actions est de monter un second serveur avec une seconde base (même version que le premier).

3) Synchroniser les deux serveurs

Le but de la synchronisation est de s’assurer que les deux bases aient le même niveau d’information.

• Politique
• Client
• Package de déploiement
• …

4) Faire basculer les postes clients sur le second serveur

Cette bascule s’effectue via la configuration de la liste de serveur SEPM.

Il faut créer une liste (via la copie de la liste par défaut est un bon moyen).

Créer une nouvelle priorité de serveur, et ajouter le second serveur à la liste.

Attention, il faut bien vérifier que le nouveau serveur est en priorité1

5) Casser la synchronisation

Lors de la migration d’un serveur SEPM, la base est migrée. Si la synchronisation est active, elle risque de casser les tables de la seconde base.

6) Migrer le premier serveur

Lancer simplement le setup. Exe du CD 1 dans le dossier SEPM

7) Vérifier le bon fonctionnement du SEPM, de la base

Redémarrer le serveur et la base.

Vérifier que les informations de la base sont accessibles via la console de gestion SEP…

8) Basculer un lot de postes clients SEP et vérifier le bon fonctionnement de ceux-ci

Tester que le client est bien connecté au serveur SEPM

Le bouclier informe de l’état de la solution SEP client et informe du lien avec le SEPM (pastille et couleur).

• Vert OK
• Jaune lié mais léger problème SEP ou définitions non a jour
• Rouge antivirus désactivé ou non fonctionnel
• -Non présent SEP en mode « Autonome – Hors Ligne »

9) Basculer le reste des clients

Les clients doivent être rebasculés dans l’intégralité avant de passer à l’étape d’après.

10) Couper le serveur relais

Le serveur relais n’a pas besoin d’être migré.

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

La solution SEP est la dernière solution antivirale avancée de Symantec. Elle regroupe plusieurs fonctionnalités.

• Protection antivirale
• Protection réseau
• Contrôle des périphériques
• Protection contre les intrusions
• Protection contre les « malwares »

Le client (agent SEP), la console (SEPM) de gestion et une base de données (Sybase, SQL), le moteur de mise à jour (LiveUpdate LU) sont les composants principaux.

1) LiveUpdate - LU

LiveUpdate est la technologie utilisée par les produits Symantec pour se mettre à jour par Internet. Il utilise une technologie PULL pour se connecter en http, puis (et/ou) ftp. En combinaison avec un serveur LiveUpdate Administrateur il est possible de modifier son comportement pour qu’il utilise un site interne au réseau d’entreprise pour ses connexions.

 2) Serveur SEPM

La gestion centralisée de la solution Symantec Endpoint Protection (SEP) se fait par l’intermédiaire d’un serveur SEP Manager (SEPM). Ce serveur s’appuie sur une base de données pour stocker toutes les informations générées par les activités de la solution configurations, politiques, logs, packages d’installation, mises à jour logicielles ou de signatures, etc. Ce serveur est géré par une console qui peut être locale ou déportée.

3) Console SEPM locale ou déportée

Cette console, écrite en JAVA, se connecte à un serveur SEPM, soit localement, ou à distance. Son installation est automatique pendant l’installation du serveur SEPM, mais par une simple connexion au site SEPM il est possible de l’installer à distance sur un ou plusieurs poste(s) administrateur.

4) Group Update Provider (GUP) - optionnel

Le Group Update Provider, ou GUP (en français : Fournisseur de Mise à jour Groupée), est un PC ou un serveur sur un site, qui a été identifié par la console comme un « proxy » pour la mise à disposition des mises à jour de signatures. Il utilise un protocole http(s) modifié, et donc simule un serveur.

Une vulnérabilité dans la sécurité d'Excel Services pour Microsoft Office SharePoint Server 2007 peut permettre à un code arbitraire de s'exécuter lors de l'ouverture sur le serveur d'un fichier qui a été modifié à des fins malintentionnées.

Une mise à jour de sécurité vient d’être publié le 05 mars 2010 afin de remédier à cette vulnérabilité.

La mise à jour est disponible en téléchargement en version 32 Bit et 64 Bit et elle concerne seulement les serveurs SharePoint 2007 sur les quels Excel Services est installé.

Pour de plus amples détail consulter le Bulletin de Sécurité MS10-017.