Share via

Redirection intersite automatique OWA dans Exchange 2010 SP2

  • Article

Article d’origine publié le mardi 13 décembre 2011

À ce jour, nombre d’entre vous ont lu les articles sur les stratégies de carnet d’adresses, les modifications du mode /hosting et l’Assistant Configuration hybride, mais, au fond, je sais que vous attendez tous que soit abordée la fonctionnalité la plus désirée que nous avons décidé d’inclure dans Exchange 2010 SP2.

Que dites-vous ?  Oui, je sais, Tony a déclaré qu’« il était peu probable que les nouvelles fonctionnalités du SP2 engendrent beaucoup de remue-ménage » et qu’il n’y avait pas tant de nouveautés que cela dans son article sur l’annonce SP2, sur Windows IT Pro.

Bien. Sachez qu’il existe une fonctionnalité à grand succès dans Exchange 2010 SP2, qui n’est pas souvent mentionnée. Par conséquent, il est temps de présenter la redirection intersite automatique pour Outlook Web App !

Définitions

D’abord, quelques définitions pour nous assurer que nous sommes sur la même longueur d’ondes.

  • Site Active Directory avec accès via Internet : site Active Directory qui contient le serveur d’accès client ayant un ExternalURL complété pour le service associé (comme OWA (Outlook Web App)). Généralement, il s’agir du centre de données/site principal où Exchange 2010 est déployé.
  • Site Active Directory régional avec accès via Internet : site Active Directory qui contient le serveur d’accès client ayant un ExternalURLrempli pour le service associé (comme OWA).
  • Site Active Directory régional sans accès via Internet : site Active Directory qui contient le serveur d’accès client n’ayant pas un ExternalURLrempli pour le service associé.
  • Connexion directe : processus par lequel le serveur d’accès client établit un appel de procédure distante (RPC)avec le serveur de boîtes aux lettres hébergeant les données de boîtes aux lettres.
  • Proxy: processus par lequel le serveur d’accès client d’un site Active Directory avec accès via Internet achemine par proxy les demandes entrantes vers le serveur d’accès client d’un site Active Directory sans accès via Internet (situé sur le même site que le serveur de boîtes aux lettres auquel il est accédé).
  • Redirection: processus par lequel le serveur d’accès client avec accès via Internet d’un site Active Directory redirige l’utilisateur final vers un autre serveur d’accès client avec accès via Internet qui réside sur le même site que le serveur de boîtes aux lettres auquel il est accédé.
  • Redirection automatique: processus par lequel le serveur d’accès client émet une redirection automatique à l’attention du navigateur de l’utilisateur, en lui demandant d’établir une connexion à une URL spécifiée.
  • Redirection à authentification unique : processus par lequel le serveur d’accès client émet une redirection automatique à l’attention du navigateur de l’utilisateur, en lui demandant d’envoyer les informations d’identification de la demande et de l’authentification à un serveur d’accès client cible, de telle sorte que la connexion semble transparente.

Processus de connexion OWA

Afin de comprendre les différents scénarios de proxy et de redirection, il importe de bien connaître les mécanismes sous-jacents à ce qui se passe quand un utilisateur s’authentifie auprès d’un serveur d’accès client pour accéder à OWA comme cela se produit aujourd’hui avec la version Exchange 2010 pré-SP2 :

  1. L’utilisateur accède à l’URL OWA avec un navigateur Web.
  2. L’utilisateur entre les informations d’identification.
  3. Le serveur d’accès client authentifie l’utilisateur et extrait les informations suivantes via la demande du service de découverte :
    1. Version de la boîte aux lettres de l’utilisateur
    2. Emplacement de la boîte aux lettres de l’utilisateur (site Active Directory), s’il est connu
  4. Le serveur d’accès client collecte des informations supplémentaires basées sur celles de la boîte aux lettres de façon à pouvoir effectuer l’opération correcte :
    1. S’il s’agit d’une boîte aux lettres Exchange 2010 locale, le serveur d’accès client effectue une connexion directe.
    2. S’il s’agit d’une boîte aux lettres Exchange 2007 locale, le serveur d’accès client extrait l’ExternalURL d’un serveur d’accès client Exchange 2007 (si aucun n’est défini, il utilise l’InternalURL) et procède à une redirection automatique.
    3. S’il s’agit d’une boîte aux lettres Exchange 2003, le serveur d’accès client extrait l’Exchange2003URLet procède à une redirection automatique.
    4. S’il ne s’agit pas d’une boîte aux lettres locale, le serveur d’accès client extrait l’ExternalURL (s’il est défini) et procède à une redirection ou achemine par proxy si aucun ExternalURL OWA n’est défini sur le site Active Directory cible.

Types de redirection OWA SP1

Dans Exchange 2010 SP1, nous avons légèrement modifié certaines choses qui se traduisaient par trois types de redirection pour OWA dans le produit sur site :

  • Redirection manuelle
  • Redirection manuelle temporaire
  • Redirection automatique héritée

Redirection manuelle

La redirection manuelle permet aux clients de ne pas avoir à acheminer par proxy tout le trafic en provenance d’un emplacement centralisé quand il existe un serveur d’accès client plus proche de la boîte aux lettres de l’utilisateur.

Les redirections manuelles ont lieu quand le serveur d’accès client doit rediriger une demande OWA vers une infrastructure d’accès client Exchange 2007 ou Exchange 2010 située sur un autre site Active Directory. Comme mentionné précédemment, pour qu’une redirection manuelle ait lieu, le répertoire virtuel OWA cible doit avoir un ExternalURL. Vos utilisateurs verront le message de redirection manuelle suivant et l’ExternalURL du serveur d’accès client du site Active Directory :

1 
Figure1 : redirection manuelle lorsque la boîte aux lettres se trouve sur un autre site Active Directory

 

Redirection manuelle temporaire

Dans SP1, nous avons ajouté un autre type de redirection pour OWA, appelé redirection manuelle temporaire. Il existe deux scénarios où la redirection manuelle temporaire entre en scène :

  1. Lors d’un événement de type retour de l’activation du centre de données, la possibilité existe que le navigateur Web de l’utilisateur ait une entrée DNS incorrecte dans le cache et qu’il pointe ainsi vers l’infrastructure du serveur d’accès client du site Active Directory qui n’héberge plus la boîte aux lettres. En conséquence, le serveur d’accès client déclenchera une redirection manuelle vers le site Active Directory approprié, mais la redirection s’effectue vers la même URL que l’URL courante de l’utilisateur. Pour empêcher un effet de ping-pong où l’utilisateur ne peut pas accéder à ses messages, le serveur d’accès client détecte si le même cookie de session est retourné et si tel est le cas, vérifiera que le serveur d’accès client possède une valeur FailbackURL pour le répertoire virtuel OWA. S’il est spécifié une valeurFailbackURL, le serveur d’accès client déclenche une page de redirection manuelle temporaire qui fournit le lien FailbackURL. Si aucune valeur FailbackURL n’est spécifié, le serveur d’accès client affiche une page d’erreur qui demande à l’utilisateur de fermer toutes les sessions de navigateur et de réessayer.

    3
    Figure 2 : redirection manuelle temporaire lors d’un retour de l’activation temporaire

  2. Le second scénario est celui où le serveur d’accès client affiche la page de redirection manuelle temporaire quand il détecte que le site du serveur d’accès client local correspond à celui de la valeur RpcClientAccessServer des bases de données de boîtes aux lettres, mais que la base de données est montée sur un autre site Active Directory ; le serveur d’accès client effectue alors une redirection temporaire avec l’ExternalURL du serveur d’accès distant du site hébergeant la base de données montée.

    2
    Figure 3 : redirection manuelle temporaire quand la boîte aux lettres est montée sur un autre site Active Directory

Redirection automatique héritée

Pour Outlook Web Access, le serveur d’accès client Exchange 2010 ne prend pas en charge l’affichage des données de boîte aux lettres des versions héritées d’Exchange. Il effectue l’un des quatre scénarios selon la version de la boîte aux lettres cible et/ou de l’emplacement :

  • Si la boîte aux lettres Exchange 2007 se trouve dans le même site Active Directory que le serveur d’accès client 2010, celui-ci redirige automatiquement la session vers le serveur d’accès Exchange 2007.
  • Si la boîte aux lettres Exchange 2007 se trouve dans un autre site Active Directory avec accès via Internet, le serveur d’accès client 2010 redirigera manuellement l’utilisateur vers le serveur d’accès client 2007.
  • Si la boîte aux lettres Exchange 2007 se trouve dans un site Active Directory sans accès via Internet, le serveur d’accès client 2010 acheminera par proxy la connexion au serveur d’accès client Exchange 2007.
  • Si la boîte aux lettres se trouve sur un serveur Exchange 2003, le serveur d’accès client 2010 redirige automatiquement la session vers une URL prédéfinie.

Comme mentionné ci-dessus, la redirection automatique héritée n’est utilisée que pour les événements de redirection d’un même site entre un serveur d’accès client Exchange 2010 et l’infrastructure héritée. Lors de l’exécution de la redirection automatique héritée, le serveur d’accès client 2010 déclenche une redirection automatique sur le navigateur de l’utilisateur et demande au navigateur d’établir une connexion à l’infrastructure héritée du serveur d’accès client 2007/FE 2003. Afin de rediriger avec succès vers l’infrastructure existante, les éléments suivants doivent être configurés :

  • Pour rediriger les boîtes aux lettres Exchange 2003, la valeur Exchange2003URLdu répertoire virtuel OWA Exchange 2010 doit être renseignée.
  • Pour rediriger vers un serveur d’accès Exchange 2007, le répertoire virtuel OWA Exchange 2007 cible doit avoir la valeur ExternalURL.

La redirection automatique héritée peut aussi fournir une authentification unique quand l’authentification basée sur les formulaires est utilisée sur les répertoires virtuels OWA source et cible en renvoyant au navigateur Web un formulaire d’authentification basée sur les formulaires avec les champs renseignés. Ce formulaire masqué contient les mêmes informations que celles envoyées à l’origine par l’utilisateur à la page de l’authentification basée sur les formulaires du serveur d’accès client 2010 (nom d’utilisateur, mot de passe, sélecteur public/privé) ainsi qu’une redirection vers le chemin Exchange cible et une chaîne de requête. Une fois que le formulaire a été chargé, il est immédiatement envoyé à l’URL cible. Il en résulte que l’utilisateur est automatiquement authentifié et qu’il peut accéder aux données de la boîte aux lettres.

La redirection manuelle présente-t-elle un inconvénient ?

À première vue, vous pourriez penser que la redirection manuelle est une excellente chose et, dans une certaine mesure, vous n’avez pas tort. Elle permet en effet de contrôler à quel emplacement les utilisateurs accèdent à leurs données (ce qui contraint ainsi les utilisateurs à employer les liaisons réseau appropriés). Cependant, en réalité, l’expérience n’est pas optimale pour l’utilisateur final.Dans le scénario où l’utilisateur n’emploie pas l’URL OWA correcte, l’utilisateur effectue les actions suivantes :

  1. L’utilisateur n’entre pas dans le navigateur Web l’URL correcte.
  2. L’utilisateur entre les informations d’identification et s’authentifie auprès du serveur d’accès client (site incorrect).
  3. Le serveur d’accès client (site incorrect) exécute la découverte de service et détermine qu’il peut rediriger l’utilisateur vers le serveur d’accès client approprié.
  4. Le serveur d’accès client (site incorrect) fournit à l’utilisateur une page qui contient un lien vers le serveur d’accès client (site correct).
  5. L’utilisateur clique sur un lien pour accéder à OWA depuis le site correct.
  6. L’utilisateur entre les informations d’identification et s’authentifie auprès du serveur d’accès client (site correct).

C’est cette situation où l’utilisateur apprend qu’il n’a pas utilisé la bonne URL et celle où il doit entrer ses informations d’identification deux fois qui constituent les deux situations les moins optimales en matière de redirection manuelle.

Redirection intersite automatique dans Exchange 2010 SP2

Pour que ces deux situations ne se reproduisent pas (situations que Greg qualifient d’absurdes), nous proposons une quatrième possibilité de redirection pour OWA dans Exchange 2010 SP2, appelée redirection intersite automatique. Comme son nom l’indique, elle n’effectue une redirection automatique que pour les demandes adressées au serveur d’accès client situé sur un autre site Active Directory (au sein de la même organisation Exchange) ayant un ExternalURL OWA.

Un nouveau paramètre a été créé pour prendre en charge la redirection intersite automatique, CrossSiteRedirectType. Ce paramètre est disponible avec l’applet de commandes Set-OWAVirtualDirectory et accepte deux valeurs, Manual et Silent. La redirection intersite automatique est désactivée par défaut (la valeur par défaut est Manual), ce qui signifie que si vous effectuez actuellement une redirection manuelle entre serveurs d’accès client de sites Active Directory différents, elle se poursuivra après le déploiement de SP2.

Si vous voulez activer la redirection intersite automatique, définissez CrossSiteRedirectType avec la valeur Silent sur les répertoires virtuels OWA du serveur d’accès client avec accès via Internet :

Set-OWAVirtualDirectory -Identity "Contoso\owa (Default Web site)" -CrossSiteRedirectType Silent

Nous avons mis à jour le processus de connexion OWA pour prendre en charge la redirection intersite automatique. Le serveur d’accès client exécute les étapes suivantes pendant la découverte de service :

  1. Déterminez la version de la boîte aux lettres (Exchange 2007 ou Exchange 2010).
  2. Vérifiez l’emplacement de la boîte aux lettres.
  3. Obtenez l’ExternalURL du serveur d’accès clientcible.
  4. Obtenez le type de redirection sur le serveur d’accès client source.
    1. Si le type est CrossSiteRedirectType=Manual, la redirection sera manuelle.
    2. Si le type est CrossSiteRedirectType=Silent, la redirection sera automatique.
      1. Si l’authentification basée sur les formulairesest activée sur les serveurs d’accès client source et cible, le serveur d’accès client source envoie au navigateur un formulaire masqué qui contient les informations d’identification de l’utilisateur et les paramètres de l’authentification basée sur les formulaires, ainsi que l’URL de redirection.
      2. Si l’authentification basée sur les formulaires n’est pas activée sur les serveurs d’accès client source et cible, seul le serveur d’accès client source adresse une redirection 302.

La redirection intersite automatique peut être assimilée à une authentification unique quand les répertoires virtuels OWA source et cible utilisent l’authentification basée sur les formulaires. Les clients qui ne déploient OWA qu’en interne peuvent aussi bénéficier de l’authentification unique quand le mécanisme d’authentification du répertoire virtuel OWA est l’authentification intégrée de Windows et que les espaces de noms OWA sont ajoutés à la zone de sécurité « Intranet local ».

Pourquoi ne puis-je pas bénéficier de l’authentification unique ?

Voici les scénarios où vous ne pouvez pas obtenir une authentification unique lors de la redirection entre sites Active Directory :

  1. Vous utilisez l’authentification de base sur les répertoires virtuels OWAsource et cible.
  2. Vous utilisez différents paramètres d’authentificationsur les répertoires virtuels OWA source et cible.
  3. Vous utilisez une solution d’authentification à deux critèressur les répertoires virtuels OWA source et cible.
  4. Vous utilisez une solution de pré-authentification(telle que Microsoft Threat Management Gateway 2010) qui emploie différents ports d’écoute Web pour les espaces de noms OWA source et cible.
  5. Le serveur d’accès client local procède à une redirection temporaire vers un autre serveur d’accès client d’un autre site Active Directory.

N’oubliez pas que, même si ces scénarios ne peuvent mettre à profit l’authentification unique, une redirection 302 (ce que nous appelons redirection automatique) continuera de se produire.

La redirection intersite automatique réduit l’insatisfaction de l’utilisateur final qui doit cliquer sur un lien pour accéder à l’infrastructure OWA correcte, et peut de fait supprimer la nécessité d’entrer les informations d’identification une seconde fois. Pour ceux d’entre vous qui ont utilisé jusqu’à présent la redirection manuelle OWA, nous espérons que vous activerez la redirection intersite automatique quand vous déploierez Exchange 2010 SP2 !

Ross Smith IV
Responsable de programme principal
Expérience Client Exchange

Ce billet de blog a été traduit de l’anglais. L’article d’origine est disponible à la page OWA Cross-Site Silent Redirection in Exchange 2010 SP2