Outlook et l’authentification en Exchange 2010
Les versions récentes d’Outlook (2007 et 2010) sont capables d’utiliser les services web proposés par Exchange serveur 2010. Outlook établit donc des connexions HTTP en plus des connexions RPC habituelles pour MAPI. Or avec Echange 2010, toutes ces connexions sont établies vers un serveur unique : le serveur CAS.
Nous allons voir que ces 2 types de connexions sont différents et n’utilisent pas obligatoirement la même méthode d’authentification.
Les connexions RPC (MAPI) :
Leur statut peut être vérifié dans le statut de connexion d’Outlook (CTRL – Clique droit – Etat de la connexion) :
Le type d’authentification intégrée peut être choisi dans les paramètres du profil:
Si l’authentification en mode intégré (NTLM ou Kerberos) échoue, Outlook présente une fenêtre d’authentification :
Si cette authentification n’est pas validée, les connexions RPC ne sont pas établies et les services de messagerie de base ne fonctionnent pas (pas de réception de message) :
Les connexions http :
Pas de possibilité de vérifier leur statut.
Pas de possibilité non plus de spécifier le type d’authentification.
Outlook utilise l’interface WINHTTP pour faire les requêtes http.
Il est possible de valider un traçage des appels WINHTTP lors de la connexion Outlook.
Pour Windows XP : Positionner des valeurs dans la base de registre avec l’outil WinHttpTraceCfg.exe
Pour Vista et Windows 7 : netsh winhttp set tracing trace-file-prefix="C:\Temp\WinHttpLog" level=verbose format=hex state=enabled
Puis affichage de la trace dans l’outil debugview.
En examinant la trace au démarrage d’Outlook, on peut voir les étapes suivantes :
Une requête vers un serveur sur le port 443:
WinHttpConnect(0x6d75000, "HUBE10.CARAPUCE.COM", 443, 0x0)
pour autodiscover
WinHttpOpenRequest(0x6d7b000, "POST", "/Autodiscover/Autodiscover.xml", "", "", 0x0, 0x00800100)
Un fois la connexion établie, on voit la requête http complète :
POST /Autodiscover/Autodiscover.xml HTTP/1.1
Content-Type: text/xml
User-Agent: Microsoft Office/12.0 (Windows NT 5.2; Microsoft Office Outlook 12.0.6535; Pro)
Host: HUBE10.CARAPUCE.COM
Content-Length: 352
Connection: Keep-Alive
Cache-Control: no-cache
Pragma: no-cache
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="https://schemas.microsoft.com/ex change/autodiscover/outlook/requestschema/2006">
<Request><EMailAddress>e14man@CARAPUCE.COM</EMailAddress> <AcceptableResponseSchema>
https://schemas.microsoft.com/exchange /autodiscover/outlook
/responseschema/2006a</AcceptableResponseSchema> </Request></Autodiscover>
La réponse du serveur est
HTTP/1.1 401 Unauthorized car cette première requête est toujours essayée en anonyme.
Le serveur IIS indique ensuite les méthodes d’authentification qu’il supporte :
WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM
WWW-Authenticate: Basic realm="HUBE10.CARAPUCE.COM"
Outlook envoie ensuite une requête authentifiée :
POST /Autodiscover/Autodiscover.xml HTTP/1.1
Authorization: Negotiate YIIEzgYGKwYBBQUCoIIEwjCCBL6gJDAiBgkqhkiC9xIBAgIG CSqGSIb3EgECAgYKKwYBBAGCNwICCqKCBJQEggSQYIIEjAY
Et est authentifié avec succès :
HTTP/1.1 200 OK
On peut ensuite voir le contenu demandé au service autodiscover ainsi que les autres services web (OAB, Out of Office…)
Si l’authentification en mode intégré (NTLM ou Kerberos) échoue pour http, Outlook présente une fenêtre d’authentification :
Tant que cette fenêtre ne sera pas renseignée, les services web (oof, availability) ne fonctionneront pas.
On pourra donc être dans la situation où l’authentification RPC a fonctionné, les services de base de messagerie fonctionne mais Outlook est toujours en attente d’un mot de passe pour http. Ceci peut être source de confusion pour l’utilisateur :
En conclusion, il faut donc se rappeler que les fenêtres d’authentification Outlook peuvent être causées par 2 types de connexions différentes.