Communications

Connexion à Outlook Web Access avec cartes à puce

Victor Akinnagbe and Ted Dressel and Jason Opdycke

Vue d'ensemble:

• Authentification à deux facteurs
• Délégation contrainte du protocole Kerberos
• Configuration d’ISA Server et d’Exchange

Les employés mobiles présentent un défi de sécurité unique pour les organisations informatiques. Les utilisateurs distants nécessitent l’accès sécurisé aux données et aux services tels que la messagerie électronique. La tragique réalité est cependant que les

liens les plus vulnérables de la chaîne de sécurité impliquent des mots de passe faibles, des logiciels malveillants (tels que les enregistreurs de frappe) et des virus sur les ordinateurs distants qui accèdent aux ressources internes de votre organisation.

La suppression d’un de ces maillons faibles constitue une méthode d’amélioration de la sécurité dans cet environnement mobile. Il s’agit des mots de passe (bien que l’idée de l’autorisation d’accès à un compte sans mot de passe pour l’authentification puisse paraître déroutante). Une technique principale pour l’élimination des problèmes associés aux mots de passe est connue comme l’authentification à deux facteurs (ou parfois authentification multifacteur). Plutôt que de se fier à une seule méthode (un mot de passe) pour autoriser l’accès, l’authentification à deux facteurs oblige l’utilisation de méthodes d’authentification supplémentaires, y compris une combinaison de nom d’utilisateur et mot de passe, un périphérique physique tel qu’une carte à puce ou un identificateur biométrique tel qu’une empreinte digitale.

Si vous avez des utilisateurs distants, vous êtes généralement obligé d’ouvrir votre pare-feu dans une certaine mesure pour permettre l’accès au réseau de l’entreprise. Un pare-feu standard vous offre une atténuation de risque de base avec l’isolation au niveau du réseau entre réseaux interne et externe (voir la figure 1). Pour renforcer la sécurité, les ports sont simplement fermés et, si la communication doit se produire sur un périphérique sur le réseau interne, les ports sont ensuite transférés vers l’emplacement approprié. Ces techniques assurent une protection conséquente au niveau du réseau, mais plusieurs couches de sécurité réseau sont maintenant devenues nécessaires en raison de la sophistication toujours croissante des attaques.

Figure 1** Pare-feu standard avec ports bloqués ou transférés **(Cliquer sur l'image pour l'agrandir)

Puisque les services d’entreprise les plus courants que les employés vont probablement utiliser sont la messagerie électronique et la messagerie instantanée, la configuration de votre infrastructure Exchange revêt plus d’importance que jamais. Offrir l’accès à vos utilisateurs à la messagerie électronique au travers d’Outlook® Web Access (OWA) est une méthode permettant de fournir des services sécurisés aux employés mobiles. La mise en place de l’authentification à deux facteurs pour OWA à l’aide de cartes à puce est une autre étape essentielle. Dans cet article, nous examinerons de plus près les problèmes de configuration et d’installation dont vous devez être conscient avant de mettre en place votre propre déploiement d’OWA avec cartes à puce.

Mieux qu’un pare-feu

L’utilisation de Microsoft® Internet Security and Acceleration (ISA) Server 2006 sur votre réseau peut simplifier la tâche d’ouverture de votre réseau aux utilisateurs distants d’une manière plus sécurisée. ISA Server 2006 inclut des fonctionnalités d’amélioration de la sécurité telles que les réseaux privés virtuels (VPN), l’authentification au protocole LDAP (Lightweight Directory Access Protocol) auprès d’Active Directory® et la délégation contrainte du protocole Kerberos avec prise en charge de cartes à puce. ISA Server est quelque peu différent de ce que vous pourriez traditionnellement penser d’un pare-feu. Il fournit des couches multiples de sécurité non seulement en fonctionnant au niveau de la couche de réseau (ce qu’il peut effectuer à la place de votre pare-feu matériel standard ou en conjonction avec celui-ci), mais également en fournissant des composants de sécurité supplémentaires généralement non pris en charge dans les pare-feux traditionnels, tels que les filtres d’application. Vous ne souhaitez pas que quelqu’un puisse utiliser la méthode HTTP POST sur un site Web hébergé particulier ? Vous voulez forcer la conformité RFC sur les messages SMTP avant qu’ils n’atteignent votre serveur Exchange ? Vous désirez inspecter les paquets HTTP chiffrés au protocole SSL (Secure Sockets Layer) avant qu’ils arrivent sur le réseau ? ISA Server peut gérer toutes ces tâches et davantage pour s’assurer que seul le trafic propre, filtré, est transféré vers votre zone DMZ ou votre réseau interne.

Les sessions SSL constituent un peu un problème pour les pare-feux standard. Lorsque les paquets passent au travers du pare-feu, ils restent chiffrés (ce qui signifie que SSL fonctionne correctement). Ainsi, si une application telle qu’OWA est publiée au travers d’un pare-feu matériel ou logiciel utilisant SSL, il n’existe véritablement aucun type d’inspection acceptable pouvant être effectuée par le pare-feu standard, mis à part une inspection de paquets complète. L’ouverture et la fermeture de ports peuvent provoquer l’exposition d’une zone de surface d’attaque conséquente. Puisque aucune véritable inspection n’a lieu à la périphérie, les paquets non inspectés et non authentifiés peuvent être routés dans votre réseau interne.

ISA Server 2006 peut servir de point SSL final pour les clients HTTP, s’assurant que seul le trafic authentifié atteint le serveur Exchange publié. ISA Server prend également en charge une fonctionnalité pratique, le pont SSL. Habituellement, un paquet est chiffré par un client qui communique à l’aide d’une session SSL standard avec ISA Server. Avec le pont SSL, ISA Server peut mettre fin au chiffrage SSL localement, inspecter le paquet maintenant déchiffré, authentifier l’utilisateur auprès d’Active Directory (si nécessaire), rechiffrer le paquet avec SSL et passer le paquet chiffré au serveur Exchange approprié (voir la figure 2). À l’aide de cette technique, le pont SSL atténue les attaques masquées dans les sessions SSL qui auraient simplement l’air de morceaux de données chiffrées pour un pare-feu incapable de gérer les applications.

Figure 2** ISA Server observe le trafic du point de vue de la couche d’application **(Cliquer sur l'image pour l'agrandir)

Le trafic authentifié au préalable qui atteint le serveur est un point important à noter concernant la délégation contrainte du protocole Kerberos. Dans un pare-feu standard, les ports sont simplement transférés vers le serveur Exchange et le serveur frontal est lui-même responsable de l’exécution des tâches d’authentification à l’encontre de ce qui pourrait être des utilisateurs malveillants. Lorsque l’authentification est requise, ISA Server peut contacter directement Active Directory et faire la demande des informations d’authentification de la part de l’utilisateur. Si l’utilisateur est authentifié avec succès, ISA Server transférera le message au serveur frontal Exchange. Le serveur frontal n’a plus à authentifier de demandes d’utilisateurs inconnus aléatoires et peut être uniquement utilisé pour les requêtes de proxy des serveurs principaux. ISA Server 2006 peut également utiliser la délégation contrainte du protocole Kerberos pour permettre l’accès à base de certificat aux technologies telles que Windows SharePoint Services et Exchange ActiveSync.

Exchange Server 2003 inclut la prise en charge de l’authentification basée sur Kerberos entre les serveurs frontaux et principaux pour les connexions d’OWA. (Vous utilisez bien IPSec pour protéger ce trafic client, n’est-ce pas ?) Exchange Server prend également en charge l’authentification Kerberos auprès des serveurs de boîtes aux lettres en cluster.

Permettre l’authentification avec carte à puce

La mise en place de l’authentification par carte à puce pour OWA constitue un défi. Cependant, une solution a été développée sur la base de la fonctionnalité de délégation contrainte du protocole Kerberos désormais disponible dans ISA Server 2006. La solution permet à un utilisateur de soumettre des informations d’authentification à l’aide d’un certificat afin de réussir à s’authentifier auprès d’OWA. La délégation contrainte du protocole Kerberos est une amélioration bienvenue de la prise en charge de la délégation de Kerberos dans Windows® 2000, qui utilisait une délégation sans contraintes. La fonction de contrainte de Kerberos est plus sécurisée et limite le risque potentiel d’attaques sophistiquées utilisant l’usurpation d’identité.

Dans le scénario avec carte à puce, ISA Server 2006 contacte Active Directory pour authentifier l’utilisateur, puisque l’utilisateur n’a pas d’accès routable à un centre de distribution de clés du réseau externe. ISA Server fait appel au mappage certificat-utilisateur d’Active Directory pour authentifier l’utilisateur et acquiert ensuite les tickets Kerberos respectifs en fonction du nom utilisateur principal (UPN). Dans ce cas, ISA Server fournit la fonctionnalité de délégation contrainte du protocole Kerberos à un serveur frontal Exchange via le filtrage au niveau de l’application et les services de proxy inversé. Si la délégation est tentée sans proxy inverse, le risque d’exploits accru pourrait affecter l’intégrité du réseau ou du domaine Active Directory.

Exchange Server 2003 et Exchange Server 2007 permettent tous deux l’authentification de base et intégrée. Cependant, vous devez appliquer une mise à jour logicielle à Exchange Server 2003 pour que l’authentification avec carte à puce auprès d’OWA puisse fonctionner. (Pour plus d’informations, consultez l’article ayant trait à la « Description de la nouvelle fonctionnalité d’Exchange Server 2003 prenant en charge l’authentification avec carte à puce auprès d’Outlook Web Access ».) Vous devez posséder un domaine en mode fonctionnel natif Windows Server® 2003, tous les serveurs Exchange Server 2003 impliqués doivent avoir le Service Pack SP2 (ou ultérieur) installé et vous avez besoin d’un serveur ISA Server 2006 agissant en tant que proxy inverse pour le site OWA.

Après avoir installé la mise à jour logicielle et configuré vos serveurs ISA et Exchange, les utilisateurs peuvent authentifier une session OWA à l’aide d’une carte à puce. La figure 3 illustre le flux d’événements requis pour l’authentification avec carte à puce. Un utilisateur commence en ouvrant le site OWA dans Internet Explorer® (1). En fait, l’utilisateur se connecte à ISA Server et est invité à présenter un certificat au lieu d’un nom d’utilisateur et d’un mot de passe pour démarrer la session OWA. Le certificat approprié est enregistré sur la carte à puce, pour laquelle l’utilisateur nécessite un numéro d’identification personnel.

Figure 3** Authentification OWA avec carte à puce **(Cliquer sur l'image pour l'agrandir)

La validation de certificat (2) est gérée à l’aide d’une liste de révocation des certificats (CRL) ou une requête au protocole OCSP (Online Certificate Status Protocol), en fonction de la configuration d’ISA Server et des autres logiciels installés. ISA Server effectue une requête au contrôleur de domaine (DC) afin de vérifier les informations d’authentification de l’utilisateur. Si la requête échoue, ISA Server affiche une page d’erreur à l’utilisateur et aucune requête n’atteint le serveur frontal Exchange.

Une fois les informations d’identification vérifiées, le ticket Kerberos est généré et la requête est passée au serveur frontal Exchange à l’aide de l’authentification intégrée (3). Lorsque le serveur frontal Exchange reçoit la requête, il valide le ticket Kerberos et recherche le serveur de boîtes aux lettres principal de l’utilisateur (4).

Le serveur frontal demande un ticket Kerberos pour le serveur principal approprié à l’aide de la délégation contrainte de Kerberos et transfère la requête de boîte aux lettres au serveur principal en utilisant l’authentification intégrée (5). La requête est traitée par le serveur principal (6) et les données de boîte aux lettres sont renvoyées au serveur frontal Exchange (7). Les données HTML pour la page OWA sont passées au ISA Server (8), qui les repasse ensuite à l’ordinateur client (9).

Configuration de l’environnement Exchange

L’article de la base de connaissances mentionné plus haut décrit la mise à jour logicielle pour Exchange Server 2003 et inclut des informations qui contribueront à vous guider au travers du processus d’activation de la délégation contrainte Kerberos avec ISA Server 2006 et Exchange Server 2003.

L’action principale de la mise à jour logicielle est l’automatisation du processus de délégation contrainte Kerberos depuis le serveur frontal Exchange vers les serveurs principaux respectifs. La mise à jour n’automatisera pas le processus de délégation contrainte Kerberos depuis ISA Server vers le serveur frontal, car ISA Server ne fait pas la partie de l’organisation Exchange. Cette délégation devra être activée manuellement depuis chaque instance d’ISA Server vers chaque serveur frontal Exchange.

La mise à jour logicielle ajoute un nouvel onglet dans le Gestionnaire du système Exchange (ESM) vous permettant de désigner un serveur Exchange frontal comme KCD-FE (voir la figure 4), qui permet ensuite à ce serveur d’être inscrit dans l’onglet de délégation des serveurs principaux Exchange.

Figure 4** Activation de la délégation contrainte de Kerberos **

La nouvelle interface utilisateur vous permet également de spécifier dans les propriétés du groupe administratif les informations d’authentification à utiliser pour renseigner l’attribut msDS-AllowedToDelegateTo (A2D2), comme indiqué à la figure 5. C’est l’attribut qui est responsable de la délégation contrainte de Kerberos.

Figure 5** Définition du compte qui contrôle la délégation **

En respectant le principe de moindre privilège, vous pouvez utiliser un compte utilisateur standard et lui accorder la capacité de déléguer des utilisateurs et des ordinateurs à l’aide d’un Objet de stratégie de groupe (GPO). Une fois que le compte s’est vu accorder cette autorisation élevée, il peut être utilisé comme compte de service pour automatiser le processus de délégation contrainte Kerberos pour le groupe administratif respectif.

Veillez à suivre les étapes appropriées pour vous assurer que les utilisateurs malveillants ne pourront pas compromettre le compte de service de la délégation contrainte Kerberos. Même si le compte n’est pas administrateur de domaine, l’accès à celui-ci pourrait permettre des attaques sophistiquées en profitant de la délégation Kerberos. Puisque le compte aura la capacité d’établir de nouvelles associations Kerberos, il devra être utilisé avec précaution. Prenez les précautions nécessaires afin d’assurer la sécurité et l’intégrité de ce compte : un mot de passe long et complexe, un audit accru, des techniques de désactivation de compte et ainsi de suite.

La mise à jour logicielle d’Exchange apporte également une modification très importante à l’interface du Gestionnaire du système Exchange en ce qui concerne l’authentification intégrée. Auparavant, dans Exchange Server 2003, lorsqu’un serveur était désigné comme serveur frontal, l’option d’activation de l’authentification Windows intégrée pour les annuaires virtuels HTTP (sous Serveur virtuel HTTP) était grisée (voir la figure 6).

Figure 6a** La mise à jour permet l’authentification intégrée **

Figure 6b** La mise à jour permet l’authentification intégrée **

Ceci est survenu car l’authentification intégrée n’était pas prise en charge sur les serveurs frontaux Exchange en raison de problèmes techniques tels que le fait que les serveurs proxy interrompaient les sessions NTLM, les utilisateurs employant l’authentification Kerberos nécessitaient une connexion à Active Directory et les utilisateurs d’Internet ne faisaient habituellement pas partie du domaine. La mise à jour décrite dans l’article de la base de connaissances mentionné ci-dessus supprime ces restrictions. Avec la mise à jour installée, vous pouvez simplement accéder à l’annuaire virtuel et activer la case à cocher correspondant à l’authentification Windows intégrée comme mécanisme de vérification des informations d’authentification de l’utilisateur. Lorsque celle-ci est activée, un attribut nommé msexchAuthenticationFlags est défini sur l’objet d’annuaire virtuel dans Active Directory (vous pouvez le voir en utilisant le composant logiciel enfichable Adsiedit.msc dans Microsoft Management Console).

Les utilisateurs vérifiant leur messagerie électronique par le biais d’OWA peuvent connaître le nom de leurs serveurs principaux Exchange et se connecter à ceux-ci à l’aide de l’authentification intégrée lorsqu’ils sont sur l’intranet de l’entreprise. La différence dans l’environnement de l’utilisateur avec l’authentification intégrée est que, puisque vous êtes connecté sur le réseau, vous n’êtes pas invité à entrer un nom d’utilisateur et un mot de passe parce qu’Internet Explorer vous authentifiera automatiquement auprès du site Web. C’est idéal pour les utilisateurs qui sont sur le réseau de l’entreprise, mais les utilisateurs externes (et les utilisateurs d’OWA sont de manière plus générale externes) ne sont habituellement pas connectés à un domaine lorsqu’ils proviennent de l’extérieur du réseau à destination d’un serveur frontal Exchange. (Ce processus est expliqué en détail dans l’article de la base de connaissances « Comment IIS authentifie les clients Navigateur ».)

Dans Exchange Server, la mise à jour remplit l’onglet Délégation pour l’utilisation de l’attribut A2D2 plutôt que l’attribut Nom du service principal (SPN) dans Active Directory. En examinant l’objet ordinateur Exchange avec Adsiedit.msc, vous remarquerez deux attributs distincts : L’attribut A2D2, qui est la liste de délégation contrainte Kerberos et l’attribut SPN, qui sert de localisateur Kerberos et de point de spécification de compte. Bien qu’il soit vrai que les deux attributs travaillent conjointement pour que la délégation contrainte Kerberos fonctionne, vous devez seulement modifier l’attribut A2D2 par le biais de l’interface graphique.

Windows peut utiliser l’alias SPN HÔTE intégré comme alias pour la localisation d’autres services. Ceci signifie que setspn.exe ne nécessite pas d’être utilisé pour que la délégation contrainte Kerberos fonctionne avec la délégation de serveur frontal vers serveur principal Exchange. (Même si l’utilisation de HTTP/Nomserveur dans la liste d’attributs SPN fonctionne avec cette solution, elle peut être source d’un plus grand nombre d’erreurs pour l’administrateur et n’est pas nécessaire pour que la délégation contrainte Kerberos fonctionne.) La délégation contrainte Kerberos recherche l’attribut A2D2 dans Active Directory. Lorsque cet attribut n’est pas renseigné (ou affecté d’une valeur de SPN incorrecte), la délégation contrainte Kerberos ne fonctionne pas entre les serveurs respectifs. Sur un cluster Exchange, cependant, l’attribut A2D2 du serveur frontal nécessite uniquement de pointer sur le compte d’ordinateur de nœud de cluster pour fonctionner convenablement.

Comme indiqué précédemment, un domaine Windows Server 2003 contenant des serveurs Exchange 2003 doit être en mode fonctionnel natif Windows Server 2003. La délégation contrainte Kerberos nécessite ce niveau de fonctionnalité de domaine pour pouvoir être utilisée. Si votre domaine est toujours en mode mixte et que vous installez la mise à jour logicielle décrite précédemment, il semblera fonctionner, mais les inscriptions SPN échoueront. La délégation contrainte Kerberos est également une fonction de domaine et non de niveau forêt. Ceci signifie que pour Exchange Server 2003, ISA Server et les serveurs frontaux et principaux Exchange doivent être membres du même domaine (bien que les utilisateurs de domaines différents puissent toujours s’authentifier avec la délégation contrainte Kerberos). Une instance ISA Server qui n’est pas membre d’un domaine ou qui est membre d’un domaine différent ne fonctionnera pas dans le cadre de cette solution.

Configuration du site OWA

Le programme d’administration IIS ne doit pas être utilisé pour les modifications d’authentification avec OWA, quelles qu’elles soient. Bien qu’OWA s’exécute sous IIS et réponde aux modifications de la métabase comme tout autre site Web, Exchange apporte un brin de complexité au processus DS2MB (Directory Services to Metabase). Le processus DS2MB répliquera les modifications d’Active Directory à la métabase IIS dans un processus unilatéral qui écrasera toute modification apportée directement à IIS. L’impact de ce processus est que si un administrateur accède directement à la métabase IIS pour y effectuer une modification (telle que la définition de l’authentification intégrée), la solution semblera fonctionner, jusqu’au cycle de réplication DS2MB suivant.

L’option d’activation de l’Authentification Windows intégrée pour les répertoires virtuels HTTP a été mise en place dans ESM car ESM effectue ses modifications directement dans Active Directory, ce qui provoque ensuite la réplication des modifications dans la métabase IIS. Gardez à l’esprit que bien que l’arrêt du service Surveillance système arrête également le processus DS2MB (ce qui vous permet d’apporter des modifications à la métabase IIS et de faire en sorte que celles-ci ne soient pas écrasées), cette solution n’est pas recommandée. Au démarrage suivant du service Surveillance système, celui-ci recherchera les modifications provenant d’Active Directory et la solution sera ensuite automatiquement désactivée.

L’onglet Délégation contient les options Utiliser uniquement Kerberos et Utiliser tout protocole d’authentification. La logique évidente serait de sélectionner Utiliser uniquement Kerberos puisque la solution que nous décrivons utilise la délégation contrainte Kerberos, mais nous avons ici affaire à l’une de ces situations courantes en informatique pour laquelle la logique habituelle ne s’applique pas. Sélectionnez donc plutôt l’option Utiliser tout protocole d’authentification (comme illustré à la figure 7) car la requête ne provient pas d’une requête Kerberos. Elle provient plutôt d’une requête HTTP avec un certificat correspondant mappé à un compte d’Active Directory.

Figure 7** Correction des paramètres d’authentification pour les cartes à puce **

Dans ce cas, ISA Server demande le certificat utilisateur PKI sur SSL. La requête entrante n’est pas un ticket Kerberos, et une transition doit survenir pour que la délégation contrainte Kerberos fonctionne convenablement. Par conséquent, en spécifiant Utiliser uniquement Kerberos, la chaîne de communication au ISA Server est interrompue. Remarquez cependant que l’option Utiliser uniquement Kerberos fonctionnera avec la délégation de serveur frontal vers serveur principal Exchange puisque le serveur frontal recevra uniquement les tickets Kerberos d’ISA Server.

Les répertoires virtuels \Exchange et \Public sont les seuls emplacements qui doivent contenir des informations privées sur l’utilisateur et de dossier public. La configuration SSL dans Exchange n’est pas une nouveauté de la délégation contrainte ou de l’authentification avec deux facteurs, mais un portage de l’activation standard de SSL pour OWA avec les informations d’authentification de base. Vous devez suivre les méthodes décrites pour activer SSL avec OWA, car forcer SSL de manière inadéquate peut empêcher le fonctionnement d’OWA et provoquer également des problèmes avec le Gestionnaire du système Exchange.

Détails de configuration supplémentaires

Pour la mise en œuvre de cette solution, il est beaucoup plus facile de déployer au préalable ISA Server et Exchange de manière standard. Ne plongez pas dans la solution complète de délégation contrainte Kerberos avec tous les paramètres configurés (surtout si ISA Server ne figurait pas précédemment dans votre déploiement). Ceci peut compliquer le processus de dépannage en cas d’échec d’un composant ou d’une étape du processus. Il est beaucoup plus facile de déployer ISA Server et Exchange de manière standard (avec nom d’utilisateur et mot de passe, mais sans l’authentification basée sur les formulaires), de s’assurer que l’installation fonctionne et d’effectuer ensuite la transition vers la délégation contrainte Kerberos et l’authentification de certificat.

Généralement, l’authentification basée sur les formulaires ne peut pas être utilisée avec OWA en conjonction avec les cartes à puce. L’authentification basée sur les formulaires indique qu’un utilisateur dispose d’un nom d’utilisateur et d’un mot de passe à soumettre par le bais du formulaire Outlook standard. Cependant, avec l’authentification par carte à puce à deux facteurs, l’utilisateur disposera uniquement d’une carte à puce et non d’un mot de passe. Par conséquent, l’authentification basée sur les formulaires n’aura pas de possibilité d’accepter ou de soumettre uniquement le certificat pour authentification. L’utilisation de l’authentification basée sur les formulaires à un emplacement quelconque de la chaîne (par exemple, sur un serveur frontal derrière ISA Server) provoquera l’échec de la configuration d’OWA avec carte à puce. Si vous activez l’authentification basée sur les formulaires, le répertoire virtuel Exchange sera défini de force pour l’authentification de base et, par conséquent, la métabase IIS utilisera également l’authentification de base.

Si vous disposez d’un mélange d’utilisateurs possédant mots de passe/noms d’utilisateur et cartes à puce, vous pouvez activer le basculement d’authentification sur le port d’écoute Web ISA et, lorsqu’un utilisateur appuiera sur la touche Échap après avoir été invité à entrer ses informations d’authentification à base de certificat, il sera invité à entrer ses informations d’authentification standard (nom d’utilisateur et mot de passe) même si authentification Intégrée est activée derrière ISA Server sur le serveur Exchange. En outre, ISA Server peut affecter la session SSL d’un délai d’attente, pour un fonctionnement similaire à celui de l’authentification basée sur les formulaires.

Conclusion

La prise en charge des cartes à puce pour l’authentification auprès d’OWA est un ajout opportun à Exchange Server 2003 et Exchange Server 2007. Avec la capacité de se connecter à OWA en utilisant un certificat, un utilisateur n’a plus besoin de se soucier de se rappeler de mots de passe longs et complexes, et les administrateurs ont maintenant un outil efficace contre les enregistreurs de frappe et autres formes de logiciels malveillants qui peuvent renifler les informations d’authentification de l’utilisateur d’un système infecté. Reportez-vous à la barre latérale « Ressources » pour plus d’informations.

La configuration correcte d’ISA Server pour l’authentification à deux facteurs avec cartes à puce améliore encore davantage la sécurité globale en effectuant un filtrage au niveau de l’application sur une application OWA publiée. En outre, ISA Server 2006 dispose d’une prise en charge intégrée pour Exchange Server 2003 et Exchange Server 2007 par le biais d’Assistants de publication simples, et donc ISA Server demeure un investissement solide pour les organisations effectuant la transition vers Exchange Server 2007.

Ressources

• Comment partager les fichiers supprimés par la fonctionnalité de filtrage "Safe HTML" dans Outlook Web Access for Exchange Server 2003
• Dépannage de la délégation Kerberos
• Service de mise à jour de métabase
• Authentification dans ISA Server 2006
• Transition vers le protocole Kerberos et la délégation contrainte
• Webcast TechNet : Implémentation de l’authentification multifacteur avec cartes à puce

Victor Akinnagbeest ingénieur de terrain principal chez Microsoft dans la région de Washington D.C. Ses activités principales sont la sécurité, l’infrastructure et la messagerie.

Ted Dresselest consultant chez Microsoft dans la région de Washington D.C. Ses activités principales sont la sécurité et l’infrastructure.

Jason Opdycke est ingénieur de terrain principal chez Microsoft et travaille dans la région de Charlotte. Ses activités principales sont la sécurité et l’infrastructure.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.