Démystifier l’objet CAS Array - Partie 1

Article d’origine publié le samedi 24 mars 2012

Depuis sa sortie en 2009, l’intérêt pour Exchange 2010 a été fantastique. Tout en travaillant avec les clients pour les former et les préparer à passer à Exchange 2010, nous avons découvert certains malentendus courants. Une tendance relève d’idées fausses sur l’objet tableau de serveur d’accès client (objet CAS Array, pour faire court). Rédacteur technique et blogueur fréquent, Scott Schnoll m’a suggéré de prendre ma plume… heu… mon clavier alors que je commentais cette tendance sur un groupe de distribution interne de Microsoft, d’où la raison ce billet.

Je ne vais pas aborder tous les aspects techniques d’un objet CAS Array dans ce billet. Cela a déjà été merveilleusement traité par Nagesh Magadev dans un billet antérieur : Exploration du service d’accès client RPC d’Exchange 2010.

La liste suivante est une série de vérités que beaucoup de clients ne connaissent pas sur l’objet CAS Array que je vais essayer de démystifier. La partie 1 aborde les trois premiers éléments et la partie 2 couvrira les trois derniers.

1. Un objet CAS Array n’équilibre pas la charge de votre trafic
2. Un objet CAS Array ne prend pas en charge Autodiscover, OWA, ECP, EWS, IMAP, POP ni SMTP
3. Le nom de domaine complet (FQDN) d’un objet CAS Array n’a pas besoin de figurer sur votre certificat SSL
4. Un objet CAS Array ne doit pas être résolvable via DNS par des clients externes
5. Un objet CAS Array ne doit pas être configuré ou modifié après la création des bases de données de boîtes aux lettres Exchange 2010 et le déplacement de boîtes aux lettres dans ces bases
6. Un objet CAS Array doit être configuré même si vous n’avez qu’un seul CAS ou un seul serveur polyvalent.

Tout le monde est confus ? Bien, nous allons essayer de fixer cela du mieux que nous pouvons en examinant chacune de ces idées. Vous verrez quelques noms de serveur tout au long de cet article, alors pourquoi ne pas vous montrer d’abord ce avec quoi je travaille dans mon labo ?

OK, nous allons approfondir maintenant !

1. Un objet CAS Array n’équilibre pas la charge de votre trafic

Un objet CAS Array n’effectue aucun équilibrage de charge. C’est un objet Active Directory utilisé pour automatiser certaines fonctions au sein d’Exchange, et c’est tout. La documentation Exchange 2010 affirme partout qu’il est recommandé d’utiliser des équilibreurs de charge (LB) pour équilibrer la charge de trafic CAS. Alors, que signifie « l’objet CAS Array n’effectue aucun équilibrage de charge » ?

En réalité, un équilibreur de charge équilibre le trafic sur un pool de CAS ou peut-être on pourrait appeler cela un tableau (array) de CAS - mais pas l’objet CAS Array. La différence est subtile mais distincte ; peut-être avons-nous donné au départ des noms trop ambigus pour éviter la confusion.

La principale raison, et peut-être la seule, d’existence de l’objet CAS Array est de remplir automatiquement l’attribut RpcClientAccessServer de toute nouvelle base de données de boîtes aux lettres Exchange 2010 créée dans le même site Active Directory (que l’objet CAS Array).

L’attribut RpcClientAccessServer est utilisé pour indiquer aux clients Outlook, au cours du processus de création de profil, ce que doit être le nom du serveur dans le profil. C’est à peu près tout, il n’y a aucune magie à part cela, et une fois que vous avez créé votre objet CAS Array, c’est tout simplement un objet dans Active Directory et il n’y a aucun équilibrage de charge à ce stade.

Le reste dépend de vous, à ce stade. Vous pouvez :

• Créer un enregistrement « A » dans DNS qui va permettre à l’ordinateur client de résoudre le nom d’hôte en adresse IP. Cette adresse IP sera probablement l’IP virtuelle (VIP) de l’équilibreur de charge (LB) accessible uniquement par les clients internes. Cette IP virtuelle (VIP) est l’adresse à laquelle Outlook ou toute autre application prenant en charge MAPI/RPC se connectera ensuite pour accéder aux ressources de boîtes aux lettres Exchange 2010.
• Configurer votre solution d’équilibrage de charge pour passer le trafic vers le pool de serveurs CAS via la VIP.

Les CAS eux-mêmes n’ont aucune idée si un équilibrage de la charge a lieu.

Vous pouvez également être embrouillé par ce qui apparaît après avoir créé un objet CAS Array en utilisant l’applet de commande New-ClientAccessArray ou en affichant un objet CAS Array préexistant à l’aide de l’applet de commande Get-ClientAccessArray.

Ici, je crée un nouvel objet CAS Array dans mon labo nommé CASArray-A, avec le nom de domaine complet (FQDN) outlook.lab.local, dans le site Active Directory nommé Site-A.

Figure 1 : Création d’un CAS Array

Tout d’abord, les champs FQDN (nom de domaine complet) et Name (Nom) ne correspondent pas car le Nom est un nom d’affichage (purement cosmétique). C’est le nom que vous voulez, qui évoque ce à quoi cet objet CAS Array servira. Le nom de domaine complet (FQDN) est l’enregistrement que vous devez ensuite créer dans DNS, sinon les clients ne pourront jamais le résoudre en adresse IP à laquelle se connecter. À ce stade, je vous rappelle qu’il ne peux y avoir qu’un seul objet CAS Array par site Active Directory.

Alors pourquoi la propriété Members (membres) est-elle remplie avec deux CAS immédiatement après la création ? Ne vous ai-je pas dit qu’il n’y a aucun équilibrage de charge à ce stade ? On dirait un peu que je vous ai menti n’est-ce-pas ?

Pour être honnête, la propriété Members est un peu trompeuse. Si vous n’avez pas étudié les étapes de création d’un objet CAS Array, vous pourriez penser en avoir terminé à ce stade. Vous avez créé votre objet CAS Array et vous pouvez voir que deux CAS ont rejoint automatiquement le tableau… Mais, vous songez peut-être à aller boire un verre de célébration ou chiper des cookies à ce mec. Pas tout de suite mon ami !

En raison du fait que nous avons associé l’objet CAS Array au site Active Directory Site-A, l’applet de commande y accède simplement et trouve tous les serveurs d’accès client enregistrés comme résidant dans le Site A et les répertorie ensuite dans la colonne des membres. J’aime dire aux clients de penser cette colonne comme celle des membres potentiels (Potential Members) ou comme mon collègue Kamal Abburi, un autre ingénieur principal de terrain (PFE) ici chez Microsoft, le suggère comme la colonne des membres CAS du site. Vous pouvez ajouter ces serveurs d’accès client comme des nœuds dans votre solution d’équilibrage de charge car ils résident tous dans le même site Active Directory. Mais tant que l’équilibreur de charge n’est pas configuré, nous n’avons aucun équilibrage de charge.

Comment les applets de commande savent dans quel site se trouvent les CAS ? Eh bien, je suis content que vous ayez posé la question parce que nous allons recourir au meilleur ami de tous, AdsiEdit.msc, et fouiller la partition Configuration d’Active Directory pour rechercher les composants magiques.

Figure 2 : L’attribut msExchServerSite d’un serveur Exchange 2010 contient le site Active Directory où réside le serveur

Chaque serveur Exchange possède un attribut msExchServerSite qui contient le site Active Directory dans lequel il réside actuellement. Au cas où vous vous poseriez la question, oui il est dynamiquement mis à jour si vous déplacez le serveur Exchange vers un nouveau site et que le service de topologie Active Directory de Microsoft Exchange a une chance de s’exécuter et de mettre à jour certaines choses. Mais l’attribut AutoDiscoverSiteScope (faisant partie de Get/Set-ClientAccessServer) ne sera pas actualisé dynamiquement et vous pouvez obtenir de drôles de résultats Autodiscover tant que cela n’est pas corrigé, selon la configuration de votre site, de votre serveur et de votre client.

2. Un objet CAS Array ne prend pas en charge OWA, ECP, EWS, Autodiscover, IMAP, SMTP ni POP

Revenons un moment à ce que fait un objet CAS Array effectivement. Il remplit l’attribut RpcClientAccessServer d’une base de données de boîtes aux lettres Exchange 2010, qui est ensuite utilisé pour indiquer à Outlook où il doit se connecter lors de l’utilisation de RPC (via TCP). Pour les clients Outlook Anywhere (HTTPS), il indique où le trafic qui quitte le proxy RPC-via-HTTP doit se connecter au nom du client afin de parvenir à sa boîte aux lettres.

Donc à quels services le client Outlook tente-t-il de se connecter lors de l’utilisation de RPC (via TCP) ?

Premièrement, Outlook se connecte à l’objet CAS Array sur TCP/135 pour communiquer avec le mappeur de point de terminaison RPC afin de découvrir les ports TCP desquels les deux services suivants sont à l’écoute.

1. Accès client RPC de Microsoft Exchange (alias MSExchangeRPC)
2. Carnet d’adresses Microsoft Exchange (alias MSExchangeAB)

C’est tout pour le mode RPC (via TCP) !

Les clients Outlook Anywhere (alias RPC via HTTP) se connectent au composant proxy RPC-via-HTTP sur TCP/443 sur un CAS en résolvant le nom d’hôte externe Outlook Anywhere, ou ce que le profil Outlook appelle le serveur proxy.

Remarque intéressante pour tout geek intéressé : Outlook ajoute magiquement et tranquillement /rpc/rpcproxy.dll au nom de serveur spécifié, car c’est vraiment ce qu’il faut pour s’y connecter, mais si nous avions demandé aux gens de taper ça, comme au temps d’Outlook 2003, vous pouvez imaginer combien l’auraient oublié ou tapé de travers !

Figure 3 : Spécifier l’URL du proxy RPC dans Outlook 2003

Le trafic est routé du proxy RPC-via-HTTP vers le point de terminaison MAPI/RPC approprié à l’aide d’une liste de ports TCP codés en dur plutôt qu’assignés dynamiquement, soit TCP 6001, TCP 6002 et TCP 6004. Le nom d’hôte externe Outlook Anywhere n’est délibérément pas le même que le nom de domaine complet (FQDN) de l’objet CAS Array ; j’expliquerai pourquoi plus tard.

Un client peut aussi établir des connexions HTTPS aux services tels que Autodiscover, téléchargements OAB, EWS, POP ou IMAP, mais ces services sont définis par des méthodes entièrement différentes telles que les URL de répertoire virtuel ou la valeur AutoDiscoverServiceInternalUri. Aucun de ces services supplémentaires n’est pris en charge par l’objet CAS Array car aucun d’entre eux n’utilise RPC, bien qu’il s’agisse probablement du même serveur que celui auquel ils se connectent. Le nom de domaine complet de l’objet CAS Array peut partager la même IP virtuelle que les URL des autres services, mais nous recommandons fortement que le nom de domaine complet de l’objet CAS Array soit différent des URL des autres services si DNS divisé est utilisé. Je détaillerai sur cette dernière recommandation plus tard.

3. Le nom de domaine complet d’un objet CAS Array n’a pas besoin de figurer dans la liste des noms de votre certificat SSL

C’est une idée fausse très répandue, fondée généralement sur l’élément directement au-dessus. Les certificats SSL dans le domaine de cet article sont uniquement utilisés lorsque nous voulons par exemple établir une session HTTP protégée par SSL. Comme RPC (via TCP) n’est pas une session HTTP, il ne sera pas protégé avec SSL et, par conséquent, il est inutile que le nom de domaine complet de l’objet CAS Array soit inclus dans la liste des noms d’objet du certificat SSL. Jetons-y un œil.

Voici Outlook 2010 en mode MAPI/RPC connecté à un objet CAS Array Exchange 2010.

Figure 4 : Connexions Outlook 2010 RPC (via TCP) au CAS Exchange 2010

Nous pouvons voir qu’il a établi des connexions à deux messageries et un répertoire. Dans la sortie netstat (superposée au-dessus de la capture d’écran), nous voyons que la machine a établi une connexion du mappeur de point de terminaison (TCP 135) à l’objet CAS Array ainsi que des connexions à TCP 59531 et TCP 59532 qui représentent les ports TCP assignés statiquement aux services MSExchangRPC et MSExchangeAB respectivement, dans ce labo.

Du côté serveur, que nous pouvons voir les services à l’écoute à l’aide de la commande netstat –n –b.

Figure 5 : Services auxquels Outlook doit se connecter lors de l’utilisation de RPC (via TCP)

Comme prévu, cela montre que les services ne sont pas contactés via HTTP (vers TCP 443). C’est pourquoi il est inutile que le nom de domaine complet de l’objet CAS Array figure sur le certificat SSL.

L’idée que vous avez besoin du nom de domaine complet de l’objet CAS Array sur le certificat SSL peut parfois être issue de la façon dont Outlook affiche les connexions en mode HTTPS, comme ci-dessous.

Figure 6 : Connexions Outlook Anywhere

Cette fois nous voyons qu’Outlook 2010 a établi deux connexions de messagerie et une connexion de dossier public (lorsque la capture d’écran a été faite) et nous voyons aussi que nous utilisons HTTPS. Depuis Outlook, il semble que nous sommes connectés à outlook.lab.local et E2K10-MLT-01.lab.local, ce qui est le cas en quelque sorte, mais en utilisant netstat encore une fois nous voyons que nous sommes en fait connectés au proxy RPC-via-HTTP situé à webmail.lab.local sur TCP/443 (HTTPS). Outlook affichera toujours le serveur auquel il s’est finalement connecté pour les données lui-même ou par l’intermédiaire du proxy RPC-via-HTTP. Si vous vous demandez pourquoi nous voyons 6 connexions via netstat au lieu de 3, c’est parce que HTTP est un protocole semi-duplex et que nous établissons donc un canal RPC_DATA_IN et un RPC_DATA_OUT pour chaque connexion vue à l’intérieur de Outlook.

Vous pensez peut-être, « Attendez ! Outlook 2007 ou 2010 chiffre par défaut les sessions RPC ! Il nous faut le nom sur le certificat ! » ; non mes amis parce que le paramètre de cryptage que vous voyez ci-dessous utilise le cryptage RPC et n’a rien à voir avec SSL. La communication se passe encore via RPC et non via HTTPS.

Figure 7 : Lors de la connexion à l’aide de RPC (via TCP), Outlook utilise le cryptage RPC

Simple n’est-ce pas ! Si un objet CAS Array rencontrait une autorité de certification qui lui dit : « Eh vous avez vraiment besoin de moi ! Je peux vous vendre un certificat générique classe pas cher ! », l’objet CAS Array lui répondrait simplement « Lâche-moi ! » et utiliserait probablement celle-ci pour faire une cocotte en papier. Cela bien sûr si vous avez suivi notre recommandation d’utiliser pour l’objet CAS Array un nom de domaine complet différent de celui des autres services. Je vais expliquer pourquoi…

J’espère que la partie 1 de cet article vous a été utile pour éclaircir certaines confusions à propos des objets CAS Array et souhaite que vous resterez à l’écoute pour la partie 2 ultérieurement, dans laquelle nous couvrirons les trois autres idées fausses courantes sur ces objets.

Brian Day
Ingénieur principal de terrain, Messagerie

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible ici Demystifying the CAS Array Object - Part 1