Ce problème est probablement dû au service de découverte automatique d'Outlook , qui fait partie de la fonctionnalité Outlook Anywhere . La découverte automatique fournit diverses informations au client Outlook de l'utilisateur final sur les différents services proposés par Exchange et sur leur emplacement; il est utilisé à diverses fins:
Autoconfiguration des profils Outlook lors de la première exécution d'Outlook, qui peut configurer un compte Exchange en utilisant uniquement l'adresse e-mail et le mot de passe de l'utilisateur, car les autres informations sont automatiquement localisées et récupérées.
Emplacement dynamique des services Web accessibles par le client Outlook, y compris l'assistant d'absence du bureau, la fonctionnalité de messagerie unifiée, l'emplacement du panneau de configuration Exchange (ECP), etc.
Il s'agit de l'implémentation propriétaire de RFC 6186 par Microsoft . Malheureusement, ils n'ont pas vraiment suivi les recommandations de ce RFC dans la conception d'Outlook Anywhere, mais cela est peut-être à prévoir car la fonctionnalité Exchange et RPC sur HTTPS n'est pas un serveur IMAP / SMTP traditionnel.
Comment fonctionne la découverte automatique (pour les utilisateurs externes *)?
La découverte automatique communique avec un service Web sur un serveur d'accès au client (dans ce cas, tous les rôles sont sur le serveur SBS) au niveau du chemin /Autodiscover/Autodiscover.xml, dérivé de son site Web par défaut. Pour localiser le nom de domaine complet du serveur avec lequel communiquer, il supprime la partie utilisateur de l'adresse e-mail, laissant le domaine (c'est-à-dire @ companyB.com). Il tente à son tour de communiquer avec la découverte automatique à l'aide de chacune des URL suivantes:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Si ceux-ci échouent, il tentera une connexion non sécurisée en désactivant SSL et en tentant de communiquer sur le port 80 (HTTP), généralement après avoir invité l'utilisateur à confirmer qu'il s'agit d'une action acceptable (une option défectueuse à mon avis, car les utilisateurs désemparés généralement approuver cela et risquer d'envoyer des informations d'identification sur du texte brut - et les administrateurs système ignorants qui ne nécessitent pas une communication sécurisée des informations d'identification et des données sensibles à l'entreprise sont un risque pour la continuité des activités).
Enfin, une vérification de suivi est effectuée à l'aide d'un enregistrement de service (SRV) dans le DNS, qui existe à un emplacement bien connu hors de l' companyB.comespace de noms et peut rediriger Outlook vers l'URL appropriée où le serveur écoute.
Qu'est-ce qui peut mal tourner?
Un de plusieurs problèmes peut survenir dans ce processus:
Aucune entrée DNS
En règle générale, la racine du domaine ( companyB.com) peut ne pas se résoudre en un enregistrement hôte dans le DNS. Une configuration DNS incorrecte (ou une décision consciente de ne pas exposer le service Outlook Anywhere) peut signifier que l' autodiscover.companyB.comenregistrement n'existe pas non plus.
Dans ces cas, il n'y a pas de problème majeur; Outlook continue simplement de communiquer avec Exchange en utilisant la dernière configuration connue et peut être dégradé en ce qui concerne certaines fonctions Web pour lesquelles il doit récupérer des URL via la découverte automatique (comme l'assistant d'absence du bureau). Une solution de contournement consiste à utiliser Outlook Web Access pour accéder à ces fonctions.
La configuration automatique des comptes Exchange dans les nouveaux profils Outlook n'est pas non plus automatisée et nécessite une configuration manuelle des paramètres RPC sur HTTPS. Toutefois, cela ne provoquera pas le problème que vous décrivez.
Certificats SSL défectueux
Il est tout à fait possible que l'URL utilisée par Outlook pour tenter de contacter le serveur Exchange se résout en un hôte, qui peut ou non être un serveur d'accès au client. Si Outlook peut communiquer avec ce serveur sur le port 443, des certificats seront bien sûr échangés pour configurer un canal sécurisé entre Outlook et le serveur distant. Si l'URL qu'Outlook pense discuter n'est pas répertoriée sur ce certificat - que ce soit en tant que nom commun ou autre nom de sujet (SAN) - cela provoquera Outlook pour présenter la boîte de dialogue que vous décrivez dans votre message initial.
Cela peut se produire pour plusieurs raisons, toutes liées à la configuration du DNS et à la façon dont les URL que j'ai décrites ci-dessus sont vérifiées par Outlook:
Si la https://companyB.com/... URL décide à un enregistrement d'hôte, et le serveur Web à cette adresse écoute sur le port 443, et il dispose d' un certificat SSL qui ne pas la liste companyB.comdans le nom ou le sujet commun Autre nom, le problème se produit. Peu importe que l'hôte soit un serveur Exchange ou non; il peut s'agir d'un serveur Web hébergeant un site Web d'entreprise qui n'est pas correctement configuré. Corrige soit:
- Désactiver l'enregistrement d'hôte à la racine de la
companyB.comzone (obliger les visiteurs du site Web ou d'un autre service à entrer www.companyB.com, ou l'équivalent; ou
- Désactivez l'accès à la machine sur
companyB.comle port 443, ce qui oblige Outlook à rejeter l' companyB.comURL avant l'échange de certificats et à continuer; ou
- Corrigez le certificat à
companyB.compour vous assurer qu'il companyB.comfigure sur ce certificat et que les tentatives de visite https://companyB.comdans un navigateur standard n'échouent pas.
Ce qui précède s'applique, qu'il soit companyB.comrésolu ou non sur Exchange Server; si Outlook peut communiquer avec lui, il découvrira plus tard que le /Autodiscover/Autodiscover.xmlchemin d'accès génère une erreur HTTP 404 (n'existe pas) et continuera.
Si l' https://autodiscover.companyB.com/URL ... résout le serveur Exchange (ou tout autre serveur) mais, encore une fois, autodiscover.companyB.comn'est pas répertorié comme le nom commun ou un autre nom de sujet, vous observerez ce comportement. Il peut être fixé comme ci - dessus en fixant le certificat, ou comme vous l' indiquez à juste titre, vous pouvez utiliser un enregistrement SRV pour rediriger Outlook vers une URL qui est inscrite sur le certificat et lequel Outlook peut communiquer avec.
Votre solution probable à ce problème
Dans ce cas, la solution typique consiste à faire ce dernier; créez des enregistrements SRV dans le nouveau fournisseur DNS pour vous assurer que Outlook est redirigé vers autodiscover.companyA.comlequel (tout autre problème mis à part) fonctionnera correctement car il est répertorié sur le certificat en tant que SAN. Pour que cela fonctionne, vous devez:
- Configurez un
_autodiscover._tcp.companyB.comenregistrement SRV conformément à la documentation .
- Supprimez l'
autodiscover.companyB.comenregistrement d'hôte, s'il existe, pour empêcher Outlook de résoudre ce problème et de tenter d'atteindre la découverte automatique de cette manière.
- Résolvez également tous les problèmes d'accès HTTPS
https://companyB.comcomme ci-dessus, car Outlook énumérera les URL dérivées de l'adresse e-mail de l'utilisateur avant de passer à l'approche d'enregistrement SRV.
* Comment fonctionne la découverte automatique (pour les clients internes joints à un domaine)?
J'ajoute cela simplement pour être complet, car c'est une autre raison courante pour que ces invites de certificat se produisent.
Sur un client joint à un domaine, lorsqu'il est local à l'environnement Exchange (c'est-à-dire sur le LAN interne), les techniques ci-dessus ne sont pas utilisées. Au lieu de cela, Outlook communique directement avec un point de connexion de service dans Active Directory (répertorié dans les paramètres d'accès au client Exchange), qui répertorie l'URL où Outlook peut localiser le service de découverte automatique.
Il est courant que des avertissements de certificat se produisent dans ces circonstances, car:
- L'URL par défaut configurée à cet effet fait référence à l' URL interne d'Exchange, qui est souvent différente de l'URL publique.
- Les certificats SSL peuvent ne pas y lister l'URL interne. À l'heure actuelle, le vôtre le fait, mais cela pourrait devenir un problème à l'avenir pour les domaines Active Directory qui utilisent
.localdes suffixes de noms de domaine gTLD non mondiaux similaires, car une décision de l'ICANN interdit la délivrance de certificats SSL pour ces domaines après 2016.
- L'adresse interne peut ne pas être résolue sur le serveur approprié.
Dans ce cas, le problème est résolu en corrigeant l'URL enregistrée pour faire référence à l'adresse externe appropriée (répertoriée dans le certificat), en exécutant l' Set-ClientAccessServerapplet de commande avec le -AutodiscoverServiceInternalUricommutateur. Les parties qui le font configurent généralement également un DNS à horizon fractionné , soit parce qu'elles sont tenues de le faire par leur configuration réseau et / ou pour la continuité de la résolution en cas de résolveur / panne de connexion en amont.