Exchange your Mind

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

Archive for the ‘Publication-2010’ Category

Exchange 2010 SP1 : Répartition de charge 1/2

Posted by Teruin laurent le octobre 30, 2011


Introduction

La venue de Microsoft Exchange 2010 a fortement nécessité l’acquisition ainsi que la mise en place de répartiteur de charge matériel. Bien sûr me direz-vous, la répartition Windows est toujours là, mais est-ce vraiment jouable ? Comment répartir correctement la charge réseau dans un environnement exchange 2010 avec ce type de procédé. C’est ce que je vous propose de regarder.

En premier lieu, et par déontologie, je vous propose un petit retour sur les solutions possibles que vous pourriez mettre en place. A ce jour 3 choix sont envisageables.

  • Répartition de charge NLB
  • Répartition de charge Round Robin
  • Répartition de charge matérielle
  1. Répartition de charge Windows NLB ou WNLB.

Cette répartition de charge est présente dans n’importe quels serveurs Windows, qu’il soit en version standard ou en version Entreprise. Comme dans quasi-totalité des cas, vos serveurs de transport HUB ou vos serveurs d’accès clients s’exécutent sur des serveurs possédant la licence Standard, Cette solution est activable nativement.

Seulement, si elle fait partie de la licence serveur, la couche NLB n’as pas grand rapport avec l’environnement Exchange. Cette couche logicielle ne va pas par exemple, vérifier si les services publiés derrière l’adresse IP NLB sont en ordre de marche. Ainsi, si pour une raison quelconque un serveur IIS s’arrête, le NLB continuera à distribuer ce serveur comme destination aux clients de messagerie. En fait, tant que votre serveur répond via TCPIP alors le service NLB considère qu’il est valide, et ce même si tous les services Exchange sont arrêtés. D’autre part la mise en place de l’environnement NLB s’avère également complexe dans des environnements géographiquement étendus comme le sont de plus en plus les environnements Exchange.

La couche WNLB est également limitée par plusieurs facteurs comme le nombre de nœud quelle peut supporter, 8 au maximum. De plus, elle est incompatible avec des serveurs Exchange qui exécutent la couche Windows Failover clustering. Dans les environnements possédant un nombre de boites aux lettres important, elle va poser problème en raison du nombre de port limité à 65 000 depuis une seule et unique adresse IP. Mais nous allons expliciter cela. Pour finir, l’ajout ou la suppression d’un nœud au sein d’un cluster IP va provoquer la déconnexion des utilisateurs. Ce qui va de facto limiter son usage dans le cas des opérations de maintenance. Voici donc résumé les limitations de cette répartition de charge, qui vous l’aurez compris ne retient que peu mon attention dans la construction d’architecture Exchange redondantes. Son principal avantage ?… il est d’être gratuit.

  1. Répartition de charge Round Robin.

La répartition de charge Round Robin distribue le flux grâce aux fonctionnements DNS. Le principe est simple. Créez deux enregistrements DNS portant le même nom de domaine (nom de votre Client Access Array) et attribuez-lui deux adresses IP différentes. Activez le mode RoundRobin dans le server DNS (Par défaut dans Windows Server) et le tour est joué. Un coup sur deux, le DNS va renvoyer l’adresse 1 ou l’adresse 2. Enfantin, pas cher, simple, sauf que … c’est nettement insuffisant pour l’environnement Exchange 2010.

Comme WNLB, le round Robin n’a aucune idée de l’état des services Windows et même si le serveur est arrêté, il continuera à renvoyer au client l’adresse IP en question. Quant aux chances de connexion du client, sur un serveur hors service…… elles seront faibles.

En réalité ces deux modes de répartition de charge, sont relativement obsolètes et non pas évolués au fur et à mesure de l’évolution de l’environnement Windows. Conçus pour de la répartition de charge TSE ou de simple connexion IP, ils s’avèrent totalement dépassés dans l’environnement Exchange.

Mais est-ce vraiment si compliqué que cela de faire de la répartition de charge Exchange correctement. ? Et bien … cela dépend ! Comme un jour m’a dit un jour une personne de Microsoft, Exchange 2007 vous a fait découvrir les coulisses des certificats, Exchange 2010 vous fera découvrir les sous-sols de la répartition de charge matérielle. Alors c’est parti !

  1. Répartiteur de charge matériel (HLB ou ADC).

En opposition avec les deux protocoles que je vous ai présenté, les répartiteurs de charges matériels offrent beaucoup plus de possibilité et notamment la répartition de charge selon plusieurs critères. Car une des questions à se poser c’est sur quels critères votre répartiteur de charge va se baser pour répartir le flux clients vers les serveurs Exchange

La première possibilité est l’adresse IP du client. Lorsque le répartiteur de charge matériel identifie un client avec son adresse Ip (ex : 192.168.1.1) , il le connecte sur le serveur Exchange Numéro 1. Pour une autre adresse IP (ex : 192.168.1.2) , il le positionnera sur le numéro 2 , etc etc . L’avantage de cette répartition est de garantir que pour une session IP, le client à l’adresse 192.168.1.1, sera toujours affecté au serveur Exchange 1.

Pour quelle raison ? Pour tout simplement garantir par exemple dans OWA que l’utilisateur n’ait pas à se reconnecter lorsqu’il demande à voir le message suivant. C’est effectivement ce qui se passerait si pour une même session IP Owa, le répartiteur de charge acheminait le client vers un autre serveur d’accès client. Tout cela pour maintenir la persistance de session. Deux termes qu’il nous faut définir.

  1. Session et persistance

Les problèmes de persistance de sessions viennent entre du fait que par nature, le protocole HTTP n’a pas été conçu pour à l’origine pour être de type applicatif mais plutôt orienté lecture et récupération de document. De ce fait, le protocole HTTP ne maintient pas de connexion (Stateless) en permanence avec les serveurs Web qu’il consulte. Parallèlement, l’usage de ce protocole à évolué, et il est utilisé aujourd’hui pour comme un frontal applicatif (Exchange OWA par exemple, Site d’achat en ligne etc..) usage qui demande nécessairement la persistance de session (Statefull).

Une des solutions et qui fonctionne correctement pour mettre en place une notion de session entre le client et le serveur est l’usage de Cookie qui, stocké sur le poste client permet à l’applicatif de retrouver les éléments des sessions (SessionID). C’est par ailleurs grâce à ce mécanisme que nous arrivons à maintenir les sessions Outlook Web Access.

L’exemple ci-dessous donne une idée de ce que l’on peut trouver dans un Coolie de session et notamment la notion d’Id de session.

Cookie: JSESSIONID=9879876473431
Cache-Control: no-cache
Host: 127.0.0.1:8080
Connection: Keep-Alive

 Une fois la session créée par le biais de Session ID et de cookie, les répartiteurs de charges ou plutôt les ADC (Application Delivery Controller) vont se charger de récupérer cette session ID de chaque client de façon à orienter les requêtes d’un client toujours sur le même serveur. On parle alors de persistance. Plusieurs solutions sont possibles. La première est de se baser sur L’ID SSL d’une session HTTPS (généré par le serveur dans la phase de négociation) par exemple. La seconde est simplement d’utiliser un cookie de session transféré dans l’entête HTTP et généré par le serveur Web.

Autre solution alternative consiste pour garantir la notion de session, à ce baser sur l’adresse IP du client. Ce baser sur l’adresse IP c’est bien, mais à condition que vos clients en possèdent une toutes différentes ! Je m’explique. Si vos clients viennent d’un sous réseau naté de votre entreprise ou si ils utilisent un serveur proxy d’agence, ils posséderont virtuellement la même adresse IP et votre répartiteur de charge sera bien incapable de répartir la charge. Résultat vous vous retrouverez, avec tous les clients connectés sur le même serveur Exchange.

En réalité tout dépend de la façon dont vous allez implémenter votre répartiteur de charge matériel et comment se dernier agira sur les flux clients vis-à-vis de votre infrastructure Exchange d’accès client.

Snat / Dnat

La mise en place d’un répartiteur de charge ou ADC va en partie conditionner la façon dont ce dernier doit agir avec vos serveurs Exchange. La première possibilité est de placer votre Répartiteur de charge en coupure de vos infrastructures Parefeux


 

La seconde est de le placer sur le réseau de l’entreprise.


Dans le cas où le répartiteur de charge est en coupure, il est évident que le flux entrant et sortant (réponse des serveurs d’accès client) passera par le répartiteur de charge. Dans Le cas contraire, ou le répartiteur de charge est sur le réseau local, il est possible que le flux entrant passe alors par le répartiteur de charge mais que le serveur réponde directement aux clients.

En fait tout dépend d dont la translation d’adresse est faite et dont le réseau est organisé. Un petit tour vers les notions de Snat et Dnat s’impose donc.

  1. SNAT ou Source NAT

Le Source NAT (translation d’adresse source) correspond à la modification de l’adresse source dans un paquet translaté. Dans ce cas, votre répartiteur de charge va changer l’adresse source du paquet client par une adresse IP positionnée sur votre répartiteur que vous aurez désignée. Le but de cette opération est par conséquent de s’assurer que votre serveur CAS, renvoi la réponse de facto à votre répartiteur de charge au lieu de le renvoyer directement au client originel. Vous noterez que dans ce cas précis, le répartiteur de charge n’a même pas besoin d’être en coupure physique. Pour effectuer cette opération vous aurez plusieurs choix et notamment le choix de faire une simple translation d’adresse vers un adresse ip unique ou alors, vers un pool d’adresse IP positionné sur votre répartiteur. Dans le premier cas on parlera de SNAT Standard dans le second de SNAT pool.

 


Ce mode de translation peut être utile car d’un point de vue firewall seul le Répartiteur de charge est concerné. Par contre dans Exchange les choses se compliquent un peu.

 

Explication : Dans le cas du SNAT, et vous l’aurez compris, vous perdez (coté Exchange) la notion d’adresse client, puisque toutes les adresses IP du client sont modifiées par l’adresse ou les adresses sélectionnées (Snat Pool) dans votre répartiteur de charge. De ce fait, et si vous faites cela pour l’environnement SMTP interne par exemple, vous perdez notamment la possibilité dans les connecteurs de réception de limiter le relai par adresses IP.
Pour rappel, voir set-receiveconnector et le paramètre RemoteIprange des connecteurs de réception. (http://technet.microsoft.com/fr-fr/library/bb125140.aspx)

Limitation du SNAT

.

Les fonctionnalités de SNAT sont intéressantes mais limitées, car le nombre de port ouverts maximum pour une seule adresse Ip est de 65,535 par destination. Ce qui peut être très vite atteint (environ 6000 utilisateurs). Dans ce cas il faudra privilégier l’utilisation des fonctions de SNAT pool pour dépasser cette limite.
Par contre, si vous projetez d’utiliser les fonctions de SNAT Pool et que vos serveurs d’accès client doivent recevoir des flux Mapi RPC (Je ne parle pas de Outlook anywhere ici mais de connexion MAPI Outlook) alors, il faudra que le répartiteur de charge adresse vers le serveur CAS toujours la même adresse source par connexion RPC. En gros si un client Mapi se connecte sur un HLB effectuant du SNAT pool, il faut que cette connexion garde toujours la même adresse IP de sortie vers le serveur Cas.

DNAT ou Destination NAT
Le Destination NAT correspond à la modification de l’adresse destination dans un paquet translaté. Il est utilisé pour la NAT statique, lorsqu’on veut accéder à un serveur sur un réseau local. Cette solution consiste à garder l’adresse IP du client mais cacher les adresses IP local du serveur d’accès client Exchange.

Bon vous voilà paré pour la seconde partie plus axée sur l’environnement Exchange 2010

Cordialement
Laurent Teruin

Posted in Cas-2010, Exchange 2010 Service Pack 1, Publication-2010 | 3 Comments »

Tmg, Répartiteur de charges, Exchange 200X : Problématiques de basculement

Posted by Teruin laurent le septembre 23, 2010


Dans un article précédent (http://unifiedit.wordpress.com/2010/08/18/exchange-2010-plaidoyer-pour-les-repartiteurs-de-charges-materiels/), j’avais préconisé l’usage de répartiteur matériel. Je vous rassure je n’ai pas changé d’avis. Mais je me permets de revenir vers vous vis-à-vis d’une problématique que vous allez rencontrer si vous envisager de mettre en place des HLB (Répartiteurs de charge matériels) vers des serveurs reverse proxy TMG, ISA ou autre. Dans le cas où vous envisagez de mettre un site de secours (DRP) comme le précise la figure suivante plusieurs règles seront à établir.


Dans un premier temps, il faudra définir votre site Actif et votre site passif et définir les règles de basculement. Dans la plupart des cas on paramétrera les HLB pour qu’ils vérifient la présence du service de publication Exchange via des ports classiques comme 80/TCP et 443/TCP sur les serveurs Reverse Proxy. Dans le cas où ces ports ne répondent pas, alors le HLB du site primaire devra basculer le flux vers le second serveur ISA/TMG du site distant. Si vous n’allez pas plus loin vous vous apercevrez rapidement que votre HLB ne basculera jamais les flux vers le site de secours pour la bonne et simple raison que même si les services CAS sont arrêtés les serveurs proxy continuent à écouter sur les ports 80/443 et par conséquent votre HLB ne détectera pas la panne. Il vous faudra donc allez plus loin et analyser le type de page retournée pour vérifier que celle-ci correspond bien à celle d’un OWA. Mais pour cela ….. il faudra vous connectez via le HLB avec un compte AD autorisé.
Par contre la bonne question à vous poser c’est quel type d’authentification votre HLB supporte-t-il ? Car comme vous l’aurez deviné l’authentification que va vous proposer votre ISA ou TMG Server est une authentification de type FBA (Authentification par formulaire) .Un beau formulaire de type html dans lequel votre HLB devra rentrer ces coordonnées pour vérifier si votre serveur CAS répond convenablement. Je sais que la crème des Load Balancer savent le faire (Ex : F5 BigIP), mais avant de vous lancer dans l’achat effréné d’une solution bon marché mieux vaut vérifier.
Une autre solution consiste à monitorer directement le serveur CAS via le HLB. Cela impliquera de mettre votre HLB dans plusieurs zones (DMZ/LanInterne) et de conditionner le basculement vers le serveur TMG/ISA/Reverseproxy de secours a la non réponse du serveur CAS du site primaire. Ça aussi il faudra vérifier que cela est possible dans la solution HLB envisagée.
Enfin il existe une troisième solution si votre Load Balancer ne sait pas faire ce genre d’exercices c’est de confier le basculement de vos services CAS à votre reverse proxy ISA/TMG en les déclarant via une ferme.

Conclusion : le choix d’un HLB doit se faire non pas uniquement sur le prix mais également vis-à-vis de ce vous escomptez lui faire faire.
Cordialement
Laurent Teruin
Questions / Réactions : unifiedit@hotmail.fr

Posted in 1-EXCHANGE 2010, Cas-2010, EXCHANGE 2007, Forefront TMG, Publication-2007, Publication-2010 | Leave a Comment »

Publication d’Exchange Server 2010

Posted by David PEKMEZ le juillet 21, 2010


Je vous recommande vivement la lecture de ce white paper sur la publication Exchange via UAG ou TMG !

http://www.microsoft.com/downloads/details.aspx?FamilyID=894bab3e-c910-4c97-ab22-59e91421e022&displaylang=en

Bonne lecture

David Pekmez

Posted in 1-EXCHANGE 2010, Publication-2010 | Leave a Comment »

Tmg 2010 : Publication des services POP3 IMAP4

Posted by Teruin laurent le mai 3, 2010


Bon vous allez me demander qui utilise encore de nos jours les services POP3 et IMAP4 alors que le RPC over HTTPS est si pratique. Je vous répondrais beaucoup de gens. Car bien souvent répartis dans le monde entier et sur des configurations parfois mal maitrisées par les entreprises. Une des difficultés est de protéger ce flux externe via des reverse Proxy. Si cela est possible avec Isa Server 2006 cela nécessitera que ce dernier possède deux interfaces réseau, ce qui n’est parfois pas possible voir difficile lorsque ce dernier est présent au sein d’un DMZ qu’il ne gère pas. La plupart des DMZ n’ont pas toutes, deux réseaux IP différents et là les choses vont se compliquer. En effet si vous tentez de publier en environnement Mono Carte des ressources Pop3 Imap4 via un serveur ISA 2006 voilà ce que vous obtiendrez .


 

J’ai voulu faire le test dans un environnement TMG 2010 toujours en monocarte positionnée au sein d’un Workgroup. La réponse est bien différente la preuve en image

Voici la configuration du serveur TMG 2010 Standard Edition


Création de règle









Je ne suis pas allé plus loin pour l’instant mais en tout cas pas de Warning . Plutôt une bonne nouvelle

Laurent Teruin

Posted in Forefront TMG, Publication-2010 | Leave a Comment »

Publication de Exchange 2010 a travers un serveur ISA 2006 SP1

Posted by Teruin laurent le décembre 23, 2009


Comme vous le savez peut-être, la publication d’un environnement Exchange 2010 est possible à travers un serveur ISA 2006 SP1. Cependant, ISA 2006 entretien des relations étroites avec l’environnement Exchange notamment en ce qui concerne l’environnement de publication OWA et l’authentification par Formulaire.. De plus, les serveurs Exchange 2010 CAS n’utilisent plus certains répertoires comme /exchweb et /unifiedmessaging. Les serveurs CAS utilisent également d’autres répertoires comme Exchange Control Panel. Les serveurs Exchange 2010 ne fournissent pas l’accès à l’environnement de boites aux lettres des plateformes anciennes et vont utiliser la technique de redirection.

Comme on peut donc le prévoir certaines disposition de publication… devront être réalisées pour permettre une publication correcte de l’environnement Exchange 2010 à travers un serveur ISA 2006 SP1.

Ross Smith vient de publier un article très complet à ce sujet. Un document complet et indispensable pour assurer la migration exchange 200x vers Exchange 2010 sans encombre.

A lire donc : http://msexchangeteam.com/archive/2009/12/17/453625.aspx

Cordialement

Posted in Publication-2010 | Leave a Comment »

Comment configurer une Autorité de certification pour accepter un attribut SAN d’une demande de certificat

Posted by David PEKMEZ le août 17, 2008


Par défaut une autorité de certification configurée sur un ordinateur Windows Server 2003 ou 2008 n’émet pas de certificats qui contiennent l’extension SAN. Si les entrées SAN sont incluses dans la demande de certificat, ces entrées sont omises

À partir du certificat émis. Pour vous modifier ce comportement, exécuter les commandes suivantes à une invite de commandes

Sur le serveur qui exécute le service Autorité de certification. Appuyez sur ENTRÉE après chaque ligne.

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

net stop certsvc

net start certsvc

Dans la demande de certificat, dans ATTRIBUTE entrez les différents noms de certificat sous cette forme

san:dns=dns.name[&dns=dns.name]

Exemple:

san:dns=intra.net&dns=mail.intra.net

ou par la cmdlets Exchange New-ExchangeCertificate avec le paramètre -DomainName

Posted in Certificat-2007, Certificat-2010, Publication-2007, Publication-2010, Sécurité-2007, Sécurité-2010 | Tagué: , , | Leave a Comment »

 
Suivre

Recevez les nouvelles publications par mail.

Rejoignez 222 autres abonnés