Dans l’environnement Office 365, les problèmes de connexion voire d’authentification peuvent être nombreux et peuvent être issu de différentes causes. Dans cet article nous allons expliquer comment procéder pour déterminer la causalité de ces problèmes de connexion.
Nous attacherons spécifiquement au client Outlook 2016 dans un environnement Windows 7 ou Windows 10. L’objectif de ce document est donc de vous proposer une méthodologie d’investigation qui devrait vous permettre de comprendre et de résoudre ses problèmes récurrents.
Les problèmes d’authentification de connexion dans un environnement Office 365 peuvent avoir effectivement plusieurs causes. Ces causes sont souvent directement liées à l’environnement de production mais également à l’environnement de connexion.
En effet le client Outlook réagit, s’adapte en fonction de l’environnement qu’il soit uniquement basé sur Office 365, ou basé sur un environnement hybride, comportant des serveurs Microsoft Exchange sur site, et une partie des boîtes aux lettres sur Exchange Online.
Selon votre environnement, et selon l’emplacement des ressources auxquelles Outlook va tenter d’accéder le diagnostic sera plus complexe à établir. En effet dans les environnements hybrides il n’est pas rare de constater qu’une partie des ressources de type boîte aux lettres soit répartie entre les deux environnements Exchange Online et Exchange sur site. Dans ce cas, le client Outlook devra vraisemblablement se connecter sur ses deux environnements et il est possible que vous constatiez des fenêtres d’authentification liée spécifiquement à un environnement bien déterminé. L’objectif de ce document est donc de vous familiariser avec ces processus de connexion pour vous puissiez déterminer quelle en est la cause.
Cas 1 : toutes les ressources de messagerie sont hébergées sur Exchange Online
Pour commencer nous allons partir d’un cas très simple qui consiste à considérer que toutes les boîtes aux lettres ainsi que toutes les autres sources de messagerie, sont hébergées dans l’environnement Exchange Online.
Dans ce cas précis environnement hybride n’existe pas. Si vous rencontrez des problèmes de connexion à ce stade, la première chose à faire, et de vérifier via un client Web si vous pouvez avoir accès à la boîte aux lettres. Cette première étape qui permettra de savoir si la boîte aux lettres est correctement paramétrée et si celle-ci est fonctionnelle. Dans la plupart des cas la connexion va s’effectuer via une interface Web et une authentification dite moderne. C’est authentification va générer un jeton d’accès qui sera réutilisé si celui-ci n’est pas effacé, lors des connexions suivantes, évitant à l’utilisateur de ressaisir ces informations connexion.
Si vous avez pu avoir accès à la boîte aux lettres de l’utilisateur c’est que celle-ci fonctionne correctement. Reste alors à savoir pourquoi le client Outlook ne se connecte pas.
La plupart du temps, les problèmes de connexion d’un client Outlook vers Exchange Online, proviennent de deux facteurs que sont la résolution DNS et les services de proxy. Ainsi la première chose à faire, et de vérifier depuis le poste de travail en question si la résolution DNS vers les services Office 365 est correcte et si les services proxy ne vous empêchent pas de vous connecter à l’environnement Exchange Online.
Pour ce qui est du DNS voici quelques vérifications que vous devez effectuer. En utilisant une fenêtre de commande depuis la station de travail, effectuez les commandes suivantes et vérifier que la résolution DNS fonctionne en plus du Ping.
Si la résolution de ces deux noms ne fonctionne pas alors il s’agit d’un problème DNS. Si cette résolution fonctionne, nous allons vérifier que la connexion via le protocole https peut s’effectuer. Pour cela nous allons utiliser le programme client Telnet qu’il vous faudra peut-être installer sur la machine Windows. En utilisant les deux commandes suivantes, vous allez tenter depuis le poste en question une connexion sur le port 443 utilisée par le protocole https vers les points de connexion Exchange Online.
Si la connexion s’établit l’écran sur sa fiche avec un curseur qui clignote. 
Dans le cas contraire l’interface de commande vous renvoi un message d’erreur.
Si vous ne parvenez pas à établir ses connexions cela signifie que le port 443 n’est pas ouvert vers l’environnement Office 365 ou que votre serveur proxy vous empêche d’établir ces connexions. Pour vérifier la connexion via votre serveur proxy si votre station de travail en utilise un, utilisez cette technique.
Depuis votre explorateur essayer de joindre cette URL
https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
Vous devriez être inviter à entrer vos informations de connexion.
Dans le cas contraire soit le port 443 est fermé soit votre serveur proxy ne vous autorise pas accéder à cette ressource. En entrant vos informations de connexion vous devriez obtenir le résultat suivant
Cela peut provenir soit de votre système de protection installée sur votre poste de travail, soit de votre pare-feu qui protège votre réseau local d’Internet.
Dans ce cas il faudra prendre contact avec les services de votre entreprise pour vérifier faire ouvrir ses ports de connexion à destination des services Exchange Online.
Pour comprendre comment s’établi la découverte automatique d’un client Outlook vous devez assimiler les différentes étapes que ce dernier parcours dans sa quête de boite aux lettres. Elles sont au nombre de 11 et sont détaillées ci-dessous :
Etape d’autodécouverte suivie par le client Outlook 2016
Étape 1 : Vérification des scénarios de redémarrage
Dans certains cas, par exemple lorsque vous ajoutez un deuxième compte pendant l’exécution d’Outlook, l’information Autodiscover est mise en cache dans un fichier local pour être utilisée lors du redémarrage du client Outlook. La toute première étape d’Autodiscover est de vérifier dans le registre les informations spéciales de « boot » qui indiquent à Outlook que vous êtes au milieu d’un de ces scénarios de redémarrage et de lire l’information d’Autodiscover dans le fichier local spécial.
Étape 2 : Vérification de la préférence pour les données locales
Outlook fournit une GPO permettant aux administrateurs de déployer un fichier XML Autodiscover spécifique à utiliser pour la configuration. Si l’administrateur a déployé cette clef de registre et créé un fichier autodiscover.xml, Outlook lit l’information Autodiscover de ce fichier. Encore une fois, il s’agit d’un cas rare qui n’est généralement pas la cause des problèmes génériques d’Autodiscover.
Étape 3 : Vérification des données du dernier bien connu (LKG)
Lorsque l’autodiscover récupère avec succès une information XML à n’importe quelle étape, l’information peut être mise en cache localement en tant que configuration « last known good ». Le chemin du dernier bon fichier XML connu provient du profil Outlook.
L’étape LKG sert uniquement à découvrir la configuration de la boîte aux lettres principale. Si la recherche d’Autodiscover concerne une boîte aux lettres non primaire (boîte aux lettres alternative, déléguée, dossier public, boîte aux lettres de groupe, et ainsi de suite), l’étape LKG est alors automatiquement ignorée.
Étape 4 : Vérifier si O365 est prioritaire
Outlook utilise une méthode heuristique pour déterminer si le compte utilisateur fourni provient d’Office 365. Si Outlook détermine que vous êtes un utilisateur O365, il essaie de récupérer l’information Autodiscover à partir des points de connexion O365 connus (généralement https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml ou https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). La clef de registre servant à contrôler ce comportement est : ExclureExplicitO365Endpoint.
Étape 5 : Vérification des données SCP
Si l’ordinateur est relié à un domaine, Outlook exécute une requête LDAP pour récupérer les données du point de connexion de service qui renvoie un chemin d’accès du fichier XML Autodiscover. Chaque URL renvoyée par la recherche SCP est ensuite essayée pour tenter de récupérer l’information Autodiscover. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 6.
Etape 6 : Vérifier le domaine racine
Pour cette étape, Outlook construit une URL à partir du nom de domaine de l’adresse initiale dans le format https://<domain>/autodiscover/autodiscover.xml et essaie de récupérer l’information de l’URL résultante. Comme de nombreux domaines racine ne sont pas configurés pour Autodiscover, Outlook réduit volontairement au silence les erreurs de certificat qui se produisent pendant la tentative de récupération. Si cette étape ne permet pas de récupérer une information Auodiscover, Outlook passe à l’étape 7.
Etape 7 : Vérifier le domaine Autodiscover
Pour cette étape, Outlook construit une URL à partir du nom de domaine de l’adresse initiale dans le format https://autodiscover.<domain>/autodiscover/autodiscover.xml et essaie de récupérer l’information de l’URL résultante. Comme il s’agit de l’URL principale généralement utilisée pour les données Autodiscover, Outlook ne supprime pas les erreurs de certificat qui se produisent lors de la tentative de récupération. Si cette étape ne récupère pas de charge utile, Outlook passe à l’étape 8, dont la valeur de contrôle est la suivante : ExclureHttpsAutoDiscoverDomain.
Étape 8 : Vérification des données locales
Dans l’étape 2, Outlook a vérifié si l’administrateur avait déployé une stratégie pour vérifier spécifiquement l’information Autodiscover en tant que préférence. S’il n’y a pas de politique en place, mais que les étapes précédentes n’ont pas permis de récupérer une information, Outlook tente de récupérer une information à partir du fichier local, même sans le paramètre PreferLocalXML en place. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 9.
Etape 9 : Vérifier les redirections Http
Pour cette étape, Outlook envoie une requête à l’URL du domaine Autodiscover (http://autodiscover.<domain>/autodiscover/autodiscover.xml) et teste les réponses de redirection. Si une information XML Autodiscover réelle est retournée et non une redirection, Outlook ignore la réponse XML Autodiscover réelle car elle a été récupérée sans sécurité (http). Si la réponse est une URL de redirection valide, Outlook suit la redirection et tente de récupérer une information XML depuis la nouvelle URL. Outlook effectuera également des vérifications de certificats pour empêcher la redirection vers des URL potentiellement nuisibles lors de cette étape. Si cette étape ne permet pas de récupérer une information Autodiscover, Outlook passe à l’étape 10. Vous pouvez contrôler ce comportement via la clef de registre : ExclureHttpRedirect.
Étape 10 : Vérifier les données sur les SRV
Pour cette étape, Outlook fait une requête DNS en « _autodiscover._tcp.<domain name> » et parcourt les résultats à la recherche du premier enregistrement qui utilise https comme protocole. Outlook essaie alors de récupérer l’information à partir de cette URL. Si cette étape ne permet pas de récupérer une information, Outlook passe à l’étape 11. Vous pouvez contrôler ce comportement via la clef de registre : ExclureSrvRecord
Étape 11 : Vérification de l’O365 en tant que Sécurité-Défaut
Si toutes les étapes précédentes n’ont pas retourné une information d’autodécouverte, Outlook utilise une méthode heuristique moins restrictive pour décider si une dernière tentative aux points de connexion O365 est potentiellement utile. Si Outlook décide qu’une tentative en vaut la peine, il essaie les points de connexion Autodiscover connus au cas où le compte est un compte O365. Cette tentative utilise les mêmes URL cibles que l’étape 4, et ne diffère que par le fait qu’elle est utilisée en dernier recours et non plus tôt dans le processus Autodiscover. Vous pouvez contrôler ce comportement via la clef de registre : ExclureExplicitO365Endpoint.
L’emplacement des clef de registre peuvent étre trouvée ici HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover et pour rappel sont les suivante
- PreferLocalXML
- ExclureHttpRedirect
- ExclureHttpsAutoDiscoverDomain (DécouverteDomaine)
- ExclureHttpsRootDomain
- ExclureScpLookup
- ExclureSrvRecord
- ExclureLastKnownGoodURL (s’applique uniquement à Outlook 2010 version 14.0.7140.5001 et versions ultérieures)
- ExclureExplicitO365Endpoint (s’applique uniquement à Outlook 2016 version 16.0.6741.2017 et versions ultérieures)
Comment connaitre la méthode que votre Outlook Utilise pour retrouver l’information Autodiscover ?
Vous pouvez utiliser les étapes suivantes dans Outlook pour déterminer la méthode par laquelle Outlook essaie de récupérer les informations d’Autodiscover dans Exchange :
Lancez Outlook.
- Appuyez sur la touche CTRL, cliquez avec le bouton droit de la souris sur l’icône Outlook dans la zone de notification, puis cliquez sur Test E-mail AutoConfiguration.
- Vérifiez que l’adresse e-mail est correctement saisie dans la zone Adresse e-mail.
- Entrez votre mot de passe si vous n’êtes pas connecté à un domaine ou si vous accédez à une boîte aux lettres différente de la vôtre.
- Cliquez sur pour décocher les cases Utiliser Guessmart et Authentification Guessmart sécurisée.
- Cliquez sur Tester.
- Passez en revue les détails dans l’onglet Journal.
Dans la seconde partie nous étudierons le comportement d’autodécouverte en environnement Hybride
Laurent TERUIN
Anthony Costeseque
cbopenhost
Teruin laurent
Marion Diné
David ANDRE
David PEKMEZ
Yohan Boullier
and the result is (With Remote Connectivity)
Si dans votre tenant vous avez ouvert l’environnement Team pour les accès invités, il est possible que celui-ci ne fonctionne pas dans le cas suivant :
