Configuration d’une authentification basée sur les formulaires pour Outlook Web App
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2015-03-09
Les authentifications basées sur les formulaires activent une page de connexion pour Exchange Server 2010 Outlook Web App qui utilise un cookie pour stocker les informations d’identification de connexion 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 App 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.
Table des matières
Usage de cookie pour le contrôle d’accès
Déterminer l’activité utilisateur
Configuration de l’invite de connexion utilisée par l’authentification basée sur les formulaires
Comprendre le chiffrement pour la connexion d’utilisateurs à partir d’ordinateurs publics et privés
Utilisation de SSL pour sécuriser Outlook Web App
Usage de cookie pour le contrôle d’accès
La première fois que le nom de l’utilisateur et son mot de passe sont envoyés vers le serveur d’accès au client pour authentifier une session d’Outlook Web App, 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 fermer sa session Outlook Web App, le cookie est effacé. Le nom d’utilisateur et le mot de passe sont envoyés au serveur d’accès au client uniquement pour la connexion initiale de l’utilisateur. Une fois que cette connexion est effectuée, seul le cookie est utilisé pour l’authentification entre l’ordinateur client et le serveur d’accès au client.
Définition de la valeur du délai d’expiration du cookie sur les ordinateurs publics
Par défaut, quand un utilisateur sélectionne l’option Ordinateur partagé ou public sur la page de connexion d’Outlook Web App, le cookie sur l’ordinateur expire automatiquement et l’utilisateur est déconnecté après 15 minutes de non utilisation d’Outlook Web App.
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 App si une session continue à s’exécuter sur un ordinateur public. Par conséquent, veillez à avertir les utilisateurs de prendre des précautions pour éviter les risques. Vous pouvez par exemple leur demander de se déconnecter d’Outlook Web App et de fermer le navigateur après utilisation d’Outlook Web App.
Pour plus d’informations sur la configuration du délai d’expiration du cookie d’un ordinateur public, consultez la rubrique Spécifier le délai d’expiration du cookie d’authentification basée sur les formulaires de l’ordinateur public.
Définition de la valeur du délai d’expiration du cookie sur les ordinateurs privés
Quand un utilisateur sélectionne l’option Ordinateur privé sur la page de connexion d’Outlook Web App, le serveur d’Exchange autorise une longue période d’inactivité avant de terminer automatiquement la session d’Outlook Web App. La valeur du délai d’expiration par défaut pour la connexion privée est de huit heures. Étant donné les relations entre le temps de recyclage des clés de chiffrement et le délai d’expiration configuré sur le serveur, la valeur réelle par défaut du délai d’expiration pour une connexion privée peut être comprise entre huit et douze heures. Pour plus d’informations, consultez la rubrique Comprendre le chiffrement pour la connexion d’utilisateurs à partir d’ordinateurs publics et privés. L’option du délai d’expiration de cookie d’un ordinateur privé est conçue pour bénéficier aux utilisateurs d’Outlook Web App 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 Spécifier le délai d’expiration du cookie d’authentification basée sur les formulaires de l’ordinateur privé.
Retour au début
Déterminer l’activité utilisateur
Après l’inactivité d’une session d’Outlook Web App 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 2010 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ée 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 2010 considère qu’il s’agit d’une activité.
.gif "Remarque")
Remarque :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 App ne sont pas considérés comme une activité. Dans Outlook Web App, 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é. Dans la version allégée d’Outlook Web App toute activité d’utilisateur autre que l’entrée de texte est considérée comme une activité.
Configuration de l’invite de connexion 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 App. Vous pouvez configurer l’invite de connexion pour une authentification basée sur des formulaires via la console de gestion Exchange ou l’environnement de ligne de commande Exchange Management Shell. Les changements de configuration que vous effectuez modifient uniquement le texte de l’invite de connexion. Le format devant être utilisé par l’utilisateur pour se connecter n’est pas modifié. Par exemple, vous pouvez configurer la page de connexion utilisant l’authentification basée sur des formulaires de façon à ce que l’utilisateur fournisse ses 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 de connexion ci-après peuvent être utilisées par l’authentification basée sur les formulaires sur la page de connexion d’Outlook Web App. Sélectionnez l’invite dont la compréhension et l’utilisation seront faciles pour vos utilisateurs.
Domaine complet Il s’agit du domaine et du nom de l’utilisateur au format domaine\nom d’utilisateur. Par exemple, Contoso\Kweku.
Nom d’utilisateur principal Il s’agit du nom UPN. L’UPN comprend deux parties : Le préfixe UPN est le nom de compte de l’utilisateur et le suffixe UPN est 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 App en entrant leur adresse principale de messagerie ou leur UPN.
Nom d’utilisateur 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é.
Remarque :Si nécessaire, vous pouvez changer le format de connexion de l’utilisateur à Outlook Web App en configurant Active Directory et les Services d’Informations Internet (IIS). L’utilisation d’Active Directory et des services 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 App mentionnée plus haut.
Retour au début
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 App implique un ensemble de six codes d’authentification HMAC (Hashed-based Message Authentication Codes). Les HMAC sont des clés sur 160 bits générées sur le serveur d’accès au client. Les codes 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 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. Le délai de recyclage d’une clé correspond à la moitié de la valeur du délai de connexion. Par exemple, lorsque le délai d’expiration de la connexion publique est fixé à 15 minutes, le délai 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 App. 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 App 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çue 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.
Le tableau suivant fournit les informations relatives au 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é.
Délai d’expiration du cookie et temps de recyclage de clés d’authentification par défaut pour chaque type de connexion d’utilisateurs
| Connexion | 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 |
| Remarque : |
|---|
| 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. |
Retour au début
Utilisation de SSL pour sécuriser Outlook Web App
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 le mot de passe sont envoyés non chiffrés lors de la connexion initiale. L’utilisation de SSL permet de chiffrer l’ensemble des communications entre l’ordinateur client et le serveur d’accès au client, et empêche les tiers d’accéder aux informations sensibles de type nom d’utilisateur, mot de passe ou message électronique.
Retour au début
© 2010 Microsoft Corporation. Tous droits réservés.