Friday, January 27, 2017

Exchange 2016 (7) : Outlook - MAPI/RPC/HTTP ou MAPI/HTTP ? - Première partie

English summary: we compare some Outlook connection protocols and evaluate various combinations on our new Exchange 2016 server with a Outlook 2010 client (on Windows 7). Most of this blog deals with aspects of Outlook Anywhere that were confusing at first glance. For example, Outlook Anywhere uses HTTP, and not HTTPS, when SSL Offloading is selected on the Exchange server. Because the text became rather long, I decided to dedicate a separate blog post to the use of MAPI/HTTP with Outlook 2010 (yes, it is possible with SP2 and two patches).


***

Dans le billet précédent, j'ai précisé qu'Outlook utilise désormais le protocole HTTP(S) pour accéder à la boîte aux lettres.

J'aurais pu ajouter : d'une façon ou d'une autre.

Autrefois, avec Exchange 2003, 2007 et 2010, les connexions Outlook "locales" se faisaient avec le concours du protocole RPC.

Je précise : c'est bel et bien le protocole MAPI qui permettait l'interaction entre Outlook et la boîte aux lettres. Mais il fallait un autre protocole pour les communications sur le réseau, entre client et serveur. La solution consistait à encapsuler MAPI dans RPC. 

Cela fonctionnait assez bien en interne mais pour les connexions qui passaient par l'Internet il fallait recourir à un autre protocole encore : HTTP. Cette nouvelle solution consistait à encapsuler MAPI dans RPC et RPC dans HTTP. MAPI faisait donc l'objet d'une double encapsulation. On aurait pu écrire : "MAPI/RPC/HTTP". En réalité, on écrit "RPC/HTTP" ou "Outlook Anywhere". De plus, même si la connexion est chiffrée la plupart du temps (voir plus bas), on ne précise pas "HTTPS" en général.

De nos jours, pour les versions d'Exchange et d'Outlook encore prises en charge (2010, 2013, 2016), nous nous trouvons devant plusieurs scénarios possibles. 

Pour communiquer avec Exchange 2013 ou 2016, Outlook 2010 utilise RPC/HTTP. RPC "tout seul" n'est donc plus une option, même derrière le pare-feu dans le réseau local.

A un moment, RPC/HTTP était aussi l'option par défaut pour Outlook 2013 mais depuis Outlook 2013 SP1 (et Exchange 2013 SP1) nous avons une option plus simple et plus efficace : MAPI/HTTP. Il s'agit d'encapsuler MAPI directement dans HTTP. Quant à RPC, il ne joue plus aucun rôle dans la connexion.


(You Had Me At EHLO… The Microsoft Exchange Team Blog)

Comme on pourrait s'y attendre, Outlook 2016 est capable d'utiliser MAPI/HTTP aussi.

A retenir :
  • MAPI/HTTP n'est pas activé par défaut dans Exchange 2013.
  • MAPI/HTTP est activé par défaut dans Exchange 2016 mais nous devons configurer les Urls pour le répertoire virtuel MAPI (ce que nous avons fait dans un autre billet de blogue). Toutefois, la documentation laisse penser que MAPI/HTTP ne serait pas activé par défaut dans un environnement mixte (Exchange 2010 et 2016 par exemple).

Note : document non encore traduit en français au moment de la composition de ce texte. Quant au blogue de l'Equipe Exchange (Exchange Team Blog), il n'existe, bien entendu, qu'en version anglaise.


***

Lors de mes premiers essais "accès client" (voir le billet de bloque précédent), j'ai remarqué qu'Outlook 2010 SP2 est capable d'accéder à une boîte à lettres stockée sur Exchange 2016 directement après l'installation de celui-ci. Aucune autre configuration n'est requise.

Il faut donc conclure qu'Outlook Anywhere est activé et deux simples cmdlets nous permettent de confirmer que c'est le cas, non seulement pour Outlook Anywhere, mais aussi pour MAPI/HTTP :



En ce qui concerne MAPI/HTTP, les Urls sont bien en place :



Par contre, je ne me souviens pas d'avoir configuré d'Url pour Outlook Anywhere (?).

En fait, pour Outlook Anywhere, il n'y a pas d'Url mais plutôt un "nom d'hôte", interne et externe :



Observez bien cette capture d'écran. Remarquez-vous quelque chose de bizarre ?

Réfléchissons...

Il n'y a pas de nom d'hôte externe, soit. Mais le nom d'hôte interne comporte encore le nom du serveur (ex16-3) et là, je ne comprends plus...

S'il s'agit, en fin de compte, d'une connexion en HTTP, comment se fait-il qu'Outlook s'ouvre sans afficher un message d'erreur à propos du certificat que nous avons installé pour valider les connexions en HTTP? En principe, les Urls que nous utilisons doivent correspondre aux noms qui figurent sur le certificat. Dans notre cas, ce serait, pour l'essentiel...
  • mail.machlinkit.biz
  • autodiscover.machlinkit.biz
Le nom du serveur ne figure pas parmi ces noms. Et pourtant, quand j'ouvre Outlook, utilisant a priori le protocole HTTP, rien ne semble gêné par l'absence du nom de serveur sur le certificat.

Deux questions se posent alors :
  • Est-ce bien en mode RPC/HTTP que la connexion se fait ?
  • A en juger par les paramètres "ExternalClientsRequireSsl" et "InternalClientsRequireSsl", je me demande si Outlook Anywhere fonctionne sans SSL ?

Qu'en est-il donc ?

D'abord, sachez qu'Outlook Anywhere utilise le répertoire virtuel : /rpc

De plus, comme nous avons cru remarquer plus haut, SSL n'est pas exigé (confirmation dans la console de gestion IIS) :



Et pourquoi pas ?

Parce que, par défaut, le "déchargement SSL" est coché (sous les noms d'hôte et la méthode d'authentification) :




Décharger SSL signifie qu'un autre dispositif (un répartiteur de charge par exemple) déchiffre le flux SSL avant le serveur Exchange. Le flux de données entre le répartiteur de charge et le serveur n'est pas chiffré. C'est ce qu'on observe dans notre cas.

Note : il est possible de (re)chiffrer les flux de données entre le répartiteur et le serveur si nous le souhaitons.

Selon les sources que j'ai consultées, c'est bien cette propriété qui gouverne l'obligation de recourir (ou non) à SSL : si elle est cochée (pour le déchargement) SSL n'est pas exigé et la correspondance entre les Urls et les noms sur le certificat n'entre même pas en jeu. Au contraire, si elle est décochée (aucun déchargement), SSL est exigé.

Puisque je n'ai pas l'intention d'utiliser un répartiteur de charge (pour le moment), allons désactiver le déchargement SSL et voyons si ce changement modifie les paramètres SSL.

Voici le statu quo :



Je tente de désactiver le déchargement avec cette cmdlet :


Mais ce message s'affiche en rouge :

La fonctionnalité Outlook Anywhere doit être configurée avec SSLOffloading défini sur true si des clients internes ou externes ne requièrent pas SSL. Si SSLOffloading est défini sur $false, RPC/HTTP vDir acceptera uniquement les connexions SSL.

Je fais attention alors à modifier les trois paramètres en même temps :


J'observe que la valeur ne change pas pour l'externe (ce qui s'explique, peut-être, par l'absence d'un nom d'hôte dans le champ correspondant ?).

En tout cas, ce changement se constate aussitôt dans la console de gestion IIS aussi (nul besoin de faire redémarrer tel ou tel service) :




Alors... qu'est-ce qui va se passer quand un de nos utilisateurs ouvre Outlook, maintenant que SSL est exigé ?

Attention ! C'est exprès que je n'ai pas (encore) changé les noms d'hôte afin de voir, justement, ce qui se passe.

Quand l'utilisateur "Mark Patel" essaie d'ouvrir Outlook, l'application lui demande son nom et mot de passe. Quand Mark les saisit et appuie sur OK, l'application les lui redemande et ainsi de suite. C'est un cycle sans fin : 



Bien que cela ne ressemble pas tellement à une erreur de certificat, je me dis qu'il est peut-être temps de mettre les noms d'hôte qui conviennent, c'est-à-dire des noms qui correspondent à l'un des noms de domaine figurant sur notre certificat SSL.

C'est ce que j'ai fait avec les cmdlets suivantes :



Note : vous pouvez cliquer sur les images pour les agrandir.

Mark ouvre une nouvelle session et cette fois-ci, un autre message d'erreur s'affiche :



C'est à ce genre de message que je me serais attendu parce qu'il désigne le nom du serveur comme source du problème. Cependant, je viens de changer les noms d'hôte, tant interne qu'externe. Que puis-je faire de plus ?

Nous fermons Outlook et mettons fin à la session Windows. Entre-temps, je fais redémarrer le serveur Exchange. J'allais me contenter de iisreset /noforce mais le service refusait de s'arrêter. Il fallait que je recoure aux grands moyens.

Ensuite, Mark Patel ouvre une nouvelle sessions sous Windows et ouvre Outlook. A ma surprise, la même erreur se manifeste de nouveau.

J'ouvre une autre session sous le nom de "Karen Roberts". Le premier message d'erreur s'affiche mais quand Karen ferme et rouvre Outlook le message n'apparaît plus.

Je crois que ces erreurs ont un rapport avec le profil Outlook de l'utilisateur. Que se passe-t-il si j'ouvre une session (et puis Outlook) sous le nom de Paul York, c'est-à-dire quelqu'un qui n'a pas encore ouvert une session sur le poste client ? Outlook ouvre sans peine et aucun message d'erreur s'affiche : rien au sujet des données de connexion, rien au sujet de notre certificat.

Mieux encore, quand j'essaie d'ouvrir une session sous le nom de Mark Patel à nouveau, les messages d'erreur ne s'affichent plus du tout. Je conclus que le profil avait gardé en cache des paramètres de connexion précédents et que Autodiscover les aurait mis à jour après un certain délai. Est-ce que je vois juste ? Je ne suis pas sûr mais je sais que nos utilisateurs peuvent désormais ouvrir Outlook sans accroc.


***


Et maintenant, tentons de répondre aux questions que nous nous sommes posé plus haut.

D'abord, la valeur pour la propriété "ExternalClientsRequireSsl" est "True" maintenant que le champ "ExternalHostname" est peuplé, sans que je puisse affirmer avec certitude que ceci explique cela : 



Les connexions se sont faites d'abord en mode RPC/HTTP et en RPC/HTTPS après que j'ai désactivé le déchargement SSL.

Nous pouvons observer cette évolution dans des captures d'écran successives de l'outil Outlook "Etat de la connexion" ou "Connection Status" en version originale.


Comment accéder à cet outil ? Il faut ouvrir Outlook d'abord et puis, tout en appuyant sur la touche Ctrl (sans relâcher), faire un clic-droite sur l'icône Outlook dans la barre des tâches et cliquer sur "Etat de la connexion" (ou "Connection Status") dans le menu :




A titre de comparaison, commençons par voir à quoi ressemble une simple connexion Outlook par opposition à une connexion Outlook Anywhere :



Le protocole est "RPC/TCP".

Quand nous avons ouvert Outlook 2010 SP2 avec le déchargement SSL activé sur notre serveur Exchange 2016 (CU3), l'état de la connexion ressemblait plutôt à ceci :





D'abord, la clarté de la présentation souffre de ce qui semble être des incohérences dans le nommage des colonnes. Nous n'avons plus de "Protocol" mais pour "Conn", le protocole affiché est "HTTP". Le "S" manque à la fin, sans qu'on puisse savoir si cela tient au déchargement SSL (encore activé à ce moment-là) ou à un simple choix de nommage. Dans la colonne "Encrypt", la valeur "None" (c'est-à-dire "aucun") tend à confirmer que la connexion ne bénéficie pas de protection par le chiffrement.

Dès que nous désactivons le déchargement SSL et imposons le chiffrement, la colonne "Conn" change de valeur : HTTPS (avec "S" donc) :



Pour combler l'incohérence, la colonne "Encrypt" montre "SSL" mais, entre crochets, la négation "No". Cela veut-il dire que malgré la valeur de la colonne "Conn", il n'y a toujours aucun chiffrement ?

En fait, ce serait un bogue :



***

Nous avons donc résolu quelques mystères entourant Outlook Anywhere dans un environnement d'essai qui comprend un serveur Exchange 2016 (CU3) et un client Outlook 2010 (SP2). Mais l'explication a allongé le texte au point que je vais remettre l'utilisation de MAPI/HTTP au billet de blogue suivant. Nous installerons les mises à jour nécessaires et verrons ce qu'il faut faire pour passer de "MAPI/RPC/HTTP(S)" à "MAPI/HTTP(S)". Nous verrons aussi à quoi ressemble ce genre de connexion dans l'outil "Etat de la connexion".

No comments:

Post a Comment