Partager via

Procédure de configuration d'une authentification basée sur des formulaires pour Outlook Web Access

  • Article

 

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2008-11-24

Cette rubrique explique les authentifications basées sur les formulaires pour Microsoft Office Outlook Web Access dans Microsoft Exchange Server 2007. Les authentifications basées sur les formulaires activent une page de connexion pour Outlook Web Access qui utilise un cookie pour stocker les informations d’identification d’ouverture de session chiffrées d’utilisateur dans le navigateur Internet. Le suivi de l’utilisation de ce cookie active le serveur Exchange pour surveiller l’activité des sessions d’Outlook Web Access sur les ordinateurs publics et privés. Si une session reste inactive pendant longtemps, le serveur bloque l’accès jusqu’à ce que l’utilisateur s’authentifie de nouveau.

La première fois que le nom de l’utilisateur et son passeport sont envoyés vers le serveur d’accès au client pour authentifier une session d’Outlook Web Access, un cookie chiffré est créé pour le suivi des activités de cet utilisateur. Lorsque l’utilisateur ferme le navigateur Internet ou clique sur  Se déconnecter pour déconnecter sa session Outlook Web Access, le cookie est désactivé. Le nom de l’utilisateur et son passeport sont envoyés vers le serveur d’accès au client uniquement pour la connexion d’utilisateur initiale. Après l’achèvement de la connexion initiale, seul le cookie est utilisé pour authentification entre l’ordinateur du client et le serveur accès au client.

Par défaut, quand un utilisateur sélectionne l’option Ordinateur partagé ou public sur la page de connexion d’Outlook Web Access, le cookie sur l’ordinateur expire automatiquement et l’utilisateur est déconnecté après 15 minutes de non utilisation d’Outlook Web Access.

Le délai d'expiration automatique est utile car il permet de protéger les comptes des utilisateurs contre les accès non autorisés. Pour répondre aux besoins de sécurité de votre organisation, vous pouvez configurer les délais d'expiration après inactivité sur le serveur d'accès au client Exchange.

Bien que le délai d'expiration automatique réduise sensiblement les risques d'accès non autorisé, il n'élimine pas la possibilité qu'un utilisateur non autorisé accède à un compte Outlook Web Access si une session continue à s'exécuter sur un ordinateur public. Par conséquent, veiller à avertir les utilisateurs de prendre des précautions pour éviter les risques, en leur signalant de se déconnecter d’Outlook Web Access et de fermer le navigateur après utilisation d’Outlook Web Access.

Pour plus d'informations sur la configuration du délai d'expiration du cookie d'un ordinateur public, consultez la rubrique Procédure de spécification du délai d'expiration du cookie d'authentification par formulaires de l'ordinateur public.

Quand un utilisateur sélectionne l’option Ordinateur privé sur la page de connexion d’Outlook Web Access, le serveur d’Exchange autorise une longue période d’inactivité avant de terminer automatiquement la session d’Outlook Web Access. La valeur du délai d'expiration par défaut pour les connexions privées est de huit heures. L’option du délai d’expiration d’un ordinateur privé est conçue pour bénéficier aux utilisateurs d’Outlook Web Access qui se servent de leur propre ordinateur ou d’un ordinateur d’un réseau d’entreprise. 

Il est important d'avertir les utilisateurs des risques associés à la sélection de l'option Cet ordinateur est privé. Un utilisateur ne doit sélectionner l'option d'ordinateur privé que s'il est le seul opérateur de l'ordinateur et si l'ordinateur est conforme aux stratégies de sécurité de l'organisation.

Pour plus d'informations sur la configuration du délai d'expiration du cookie d'un ordinateur privé, consultez la rubrique Procédure de spécification du délai d'expiration du cookie d'authentification par formulaires de l'ordinateur privé.

Déterminer l’activité utilisateur

Après l’inactivité d’une session d’Outlook Web Access  pendant un certain temps, le serveur d’accès au client perd la clé de déchiffrement permettant de lire le cookie et l’accès est interdit à l’utilisateur jusqu’à ce qu’il s’authentifie de nouveau.

Exchange 2007 utilise les informations suivantes pour déterminer l'activité des utilisateurs :

  • L’interaction entre l’ordinateur client et le serveur d’accès au client initiée par l’utilisateur est considéré comme une activité. Par exemple, si un utilisateur ouvre, envoie ou enregistre un élément, bascule entre des dossiers ou des modules ou actualise l'affichage ou la fenêtre du navigateur Web, Exchange 2007 considère qu'il s'agit d'une activité.

    Notes

    L’interaction entre l’ordinateur du client et le serveur automatiquement généré par le serveur d’accès au client n’est pas considérée comme une activité. Par exemple, les nouvelles notifications de courrier électronique et les rappels générés par le serveur d’accès au client dans une session d’Outlook Web Access ne sont pas considérés comme une activité.

  • Dans Outlook Web Access Light toute activité d’utilisateur autre que l’entrée de texte est considérée comme une activité. Dans Outlook Web Access Premium, toute interaction d’utilisateurs, incluant l’entrée de texte dans un message électronique ou dans une demande de réunion, est considérée comme étant une activité.

Configurer l’invite d’ouverture de session utilisée par l’authentification basée sur les formulaires

À la place d'une fenêtre publicitaire intempestive, l'authentification basée sur des formulaires crée une page de connexion pour Outlook Web Access. Exchange Management Console ou Exchange Management Shell vous permettent de configurer le texte de l'invite d'ouverture de session donné par l'authentification basée sur les formulaires. Les changements de configuration que vous effectuez modifient uniquement le texte de l’invite d’ouverture de session. Ces changements ne modifient pas le format auquel l’utilisateur doit se connecter. Par exemple, vous pouvez configurer la page de connexion d'authentification basée sur des formulaires pour inviter les utilisateurs à fournir leurs informations de connexion, au format domaine\nom d'utilisateur. Cependant, un utilisateur peut également entrer son nom d’utilisateur principal (UPN) pour se connecter.

Les invites d’ouverture de sessions ci-après peuvent être utilisées par l’authentification basée sur les formulaires sur la page de connexion d’Outlook Web Access. Sélectionnez l'invite dont la compréhension et l'utilisation seront faciles pour vos utilisateurs.

  • FullDomain   Il s'agit du domaine et du nom de l'utilisateur au format domaine\nom d'utilisateur. Par exemple, Contoso\Kweku.

  • PrincipalName    l’UPN. L’UPN comprend deux parties : Le préfixe UPN c’est-à-dire le nom de compte de l’utilisateur et le suffixe UPN c’est-à-dire le nom de domaine DNS. Le préfixe et le suffixe sont liés par le signe (@) pour créer le nom d’utilisateur principal complet. Par exemple, Kweku@contoso.com. Les utilisateurs peuvent accéder à Outlook Web Access en entrant leur adresse principale de messagerie ou leur UPN.

  • UserName   Le nom d’utilisateur uniquement. Le nom de domaine n'est pas inclus. Par exemple, Kweku. Ce format de connexion ne fonctionne que si le nom de domaine a été configuré.

    Notes

    Si nécessaire, vous pouvez changer le format de connexion de l'utilisateur à Outlook Web Access en configurant le service d’annuaire d’Active Directory et les Services d’Informations Internet (IIS). L’utilisation d’Active Directory et IIS pour définir les utilisateurs de formats de nom d’utilisateur pouvant entrer pour l’authentification est indépendante de l’invite de l’authentification basée sur les formulaires d’Outlook Web Access  mentionnée plus haut.

Comprendre le chiffrement pour la connexion d’utilisateurs à partir d’ordinateurs publics et privés

Le chiffrement des informations d’identification de connexion d’utilisateurs à la fois pour les types de connexion publique et privée d’Outlook Web Access implique un ensemble de six codes d’authentification de message haché (HMAC). Les HMAC sont des clés sur 160 bits générées sur le serveur d’accès au client. Les HMAC améliorent la sécurité de la connexion en combinant les algorithmes de hachage avec les fonctions cryptographiques pour chiffrer les informations d’identification de connexion d’utilisateurs. Le chiffrement et le déchiffrement d’un cookie sont exécutés par un même serveur d’accès au client. Seul le serveur d’accès au client ayant généré la clé d’authentification a la clé permettant de déchiffrer ce cookie.

Lorsque l’authentification basée sur les formulaires pour Outlook Web Access est utilisée, le serveur d’accès au client fait le tour d’un ensemble de trois clés pour chaque type de connexion, publique et privée, à une vitesse fixe. C'est ce qu'on appelle le délai de recyclage. La temps de recyclage d’une clé équivaut à la moitié de la valeur du délai d’expiration d’une connexion. Par exemple, lorsque la valeur du délai d’expiration de la connexion publique est fixée à 15 minutes, le temps de recyclage de la clé publique est de 7,5 minutes.

Les six clés de connexion sont créées par le serveur d'accès au client au moment du démarrage des répertoires virtuels d’Outlook Web Access. Trois clés sont utilisées avec les connexions d’ordinateurs publics et trois autres avec les connexions d’ordinateurs privés. Quand un utilisateur se connecte, la clé de son type de connexion en cours est utilisée pour chiffrer les informations d’authentification de cet utilisateur dans ce cookie.

Après l’expiration du temps de recyclage, le serveur d’accès au client se déplace vers la clé suivante. Après l’utilisation des trois clés d’un type de connexion, le serveur d’accès au client supprime la plus ancienne clé et en crée une nouvelle. Le serveur d’accès au client maintient toujours trois clés disponibles pour chaque type de connexion : à savoir, la clé en cours et les deux clés les plus récentes. Le recyclage des clés se poursuit au fur et à mesure de l’exécution d’Outlook Web Access sur le serveur d’accès au client. Les mêmes clés sont utilisées pour tous les utilisateurs.

Tout cookie ayant été chiffré à l’aide d’une clé active est accepté. Lorsqu’une requête d’activité d’utilisateur est reçu par le serveur d’accès au client, le cookie pour cette requête est remplacé par un nouveau qui a été chiffré à l’aide de la clé la plus récente. Une session d’utilisateur atteint le délai d’expiration lorsque le cookie qui lui est associé est chiffré par une ancienne clé supprimée.

Étant donné les relations entre le temps de recyclage des clés de chiffrement et le délai d’expiration d’utilisateur configuré sur le serveur, la période réelle du délai d’expiration pour un utilisateur peut se situer entre le délai d’expiration configuré et le délai d’expiration configuré plus la moitié de cette valeur. Par exemple, si le délai d’expiration configuré est de 30 minutes, le délai d’expiration réel de chaque session d’utilisateur pourrait se situer entre 30 et 45 minutes.

La table 1 fournie les informations à-propos du délai d’expiration du cookie et du temps de recyclage de clés d’authentification basées sur une connexion d’utilisateurs à partir d’un ordinateur public ou privé.

Ouverture de session Valeur du délai d’expiration du cookie Temps de recyclage pour la clé d’authentification en cas d’utilisation de la valeur du délai d’expiration par défaut

Public

D’une minute à 30 jours. La valeur par défaut est 15 minutes.

7.5 minutes

Privé

D’une minute à 30 jours. La valeur par défaut est 8 heures.

4 heures

Notes

Le registre vous permet de configurer la valeur du délai d’expiration du cookie en minutes. Le temps de recyclage de la clé d’authentification équivaut à au moins un tiers, et à pas plus de la moitié de la valeur du délai d’expiration du cookie.

Utilisation de SSL pour sécuriser Outlook Web Access

Par défaut, le chiffrement SSL (Secure Sockets Layer) est activé lorsque vous installez le rôle de serveur d’accès au client. Si SSL n’est pas utilisé, le nom d’utilisateur et son passeport sont envoyés en texte clair à la connexion initiale. Lorsque le SSL est utilisé, il chiffre toutes les communications entre l’ordinateur du client et le serveur d’accès au client et empêche les informations sensibles telles que : les noms d’utilisateurs, les mots de passe et les messages électroniques d’être consultés par des parties tierces.

Un certificat SSL par défaut est installé avec le rôle de serveur d’accès au client, mais n’est pas approuvé. Le certificat SSL par défaut doit être approuvé pour être utilisé ou une invite demandera aux utilisateurs s’ils font confiance à ce certificat à chaque fois qu’ils se connectent à Outlook Web Access. Pour plus d'informations sur l'utilisation du certificat SSL par défaut, consultez la rubrique Procédure de remplacement d'un certificat SSL par défaut par un autre certificat approuvé.

Pour plus d'informations