Эта проблема, скорее всего, вызвана службой автообнаружения Outlook, которая является частью функциональности Outlook Anywhere . Автообнаружение предоставляет клиенту Outlook конечного пользователя различную информацию о различных службах, предлагаемых Exchange, и о том, где они могут быть расположены; это используется для различных целей:
Автоконфигурация профилей Outlook при первом запуске Outlook, который может настроить учетную запись Exchange, используя только адрес электронной почты и пароль пользователя, поскольку другая информация автоматически обнаруживается и извлекается.
Динамическое расположение веб-служб, к которым обращается клиент Outlook, включая помощника по отсутствию на рабочем месте, функции единой системы обмена сообщениями, расположение панели управления Exchange (ECP) и т. Д.
Это собственная реализация Microsoft RFC 6186 . К сожалению, они на самом деле не следовали рекомендациям этого RFC в дизайне Outlook Anywhere, но этого, вероятно, следовало ожидать, поскольку функциональность Exchange и RPC через HTTPS не является традиционным сервером IMAP / SMTP.
Как работает автообнаружение (для внешних * пользователей)?
Автообнаружение связывается с веб-службой на сервере клиентского доступа (в этом случае все роли находятся на сервере SBS) по пути /Autodiscover/Autodiscover.xml, удаленному от веб-сайта по умолчанию. Чтобы найти полное доменное имя сервера, с которым необходимо установить связь, он удаляет пользовательскую часть адреса электронной почты, оставляя домен (то есть @ companyB.com). Он пытается установить связь с автообнаружением, используя каждый из следующих URL-адресов:
https://companyB.com/Autodiscover/Autodiscover.xmlhttps://autodiscover.companyB.com/Autodiscover/Autodiscover.xml
Если это не удастся, он попытается установить незащищенное соединение, отключив SSL и попытавшись установить связь через порт 80 (HTTP), как правило, после того, как пользователь предложит подтвердить, что это приемлемое действие (на мой взгляд, некорректный вариант, поскольку невежественные пользователи будут обычно это одобряют и рискуют отправлять учетные данные в виде простого текста - и неосведомленные системные администраторы, которым не требуется защищенный обмен учетными данными и конфиденциальными данными, представляют риск для непрерывности бизнеса).
Наконец, дополнительная проверка выполняется с использованием служебной записи (SRV) в DNS, которая существует в известном месте вне companyB.comпространства имен и может перенаправить Outlook на правильный URL-адрес, где сервер прослушивает.
Что может пойти не так?
В этом процессе может возникнуть одна из нескольких проблем:
Нет записей DNS
Как правило, корень домена ( companyB.com) может не преобразовываться в запись узла в DNS. Неправильная настройка DNS (или сознательное решение не предоставлять службу мобильного Outlook) может также означать, что autodiscover.companyB.comзапись не существует.
В этих случаях нет серьезных проблем; Outlook просто продолжает взаимодействовать с Exchange, используя последнюю известную конфигурацию, и может быть ухудшен по отношению к определенным веб-функциям, для которых ему необходимо извлекать URL-адреса с помощью автообнаружения (например, помощник при отсутствии на работе). Обходной путь - использовать Outlook Web Access для доступа к таким функциям.
Автоматическая настройка учетных записей Exchange в новых профилях Outlook также не автоматизирована и требует ручной настройки параметров RPC через HTTPS. Однако это не приведет к описанной вами проблеме.
Неисправные сертификаты SSL
Вполне возможно, что URL-адрес, который Outlook использует для попытки связаться с сервером Exchange, разрешается на хост, который может быть или не быть сервером клиентского доступа. Если Outlook может обмениваться данными с этим сервером через порт 443, сертификаты, конечно, будут обмениваться для настройки безопасного канала между Outlook и удаленным сервером. Если URL-адрес, по которому Outlook считает, что он говорит, не указан в этом сертификате - будь то общее имя или альтернативное имя субъекта (SAN) - это приведет к тому, что Outlook представит диалоговое окно, которое вы описали в своем первоначальном сообщении.
Это может произойти по нескольким причинам, все зависит от того, как настроен DNS и как URL, которые я описал выше, проверяются Outlook:
Если https://companyB.com/... URL рассасывается к записи хоста, и веб - серверу по этому адресу прослушивает порт 443, и он имеет сертификат SSL , который делает не список companyB.comв общем названии или Subject Alternative Name, то проблема будет происходить. Не имеет значения, является ли хост сервером Exchange или нет; это может быть веб-сервер, на котором размещен веб-сайт компании, который настроен неправильно. Исправьте либо:
- Отключите запись хоста в корне
companyB.comзоны (требуется, чтобы посетители веб-сайта или другой службы входили www.companyB.com, или аналогичные; или
- Отключите доступ к компьютеру
companyB.comпо порту 443, в результате чего Outlook отклонит companyB.comURL-адрес до обмена сертификатами и продолжит работу; или
- Исправьте сертификат,
companyB.comчтобы убедиться, что companyB.comон указан в этом сертификате, и что попытки посетить его https://companyB.comв стандартном браузере не завершаются неудачей.
Вышеуказанное применяется независимо от того, companyB.comразрешается ли сервер Exchange; если Outlook может связаться с ним, он позже обнаружит, что /Autodiscover/Autodiscover.xmlпуть выдает ошибку HTTP 404 (не существует), и будет двигаться дальше.
Если https://autodiscover.companyB.com/URL-адрес ... сопоставляется с сервером Exchange (или любым другим сервером), но, опять же, autodiscover.companyB.comне указан в качестве общего имени или альтернативного имени субъекта, вы будете наблюдать это поведение. Это может быть исправлено , как указано выше, фиксируя сертификат, или как вы правильно указать, вы можете использовать SRV запись для перенаправления Outlook , к URL , который находится в списке на сертификате и который прогноз может взаимодействовать с.
Ваше вероятное решение этой проблемы
В этом случае типичным решением является последнее; создайте записи SRV в новом DNS-провайдере, чтобы убедиться, что Outlook перенаправлен autodiscover.companyA.com, что (за исключением любых других проблем) будет работать успешно, поскольку оно указано в сертификате как SAN. Чтобы это работало, вам необходимо:
- Настройте
_autodiscover._tcp.companyB.comзапись SRV в соответствии с документацией .
- Удалите
autodiscover.companyB.comзапись узла, если она существует, чтобы Outlook не разрешил эту проблему и не попытался таким образом обратиться к автообнаружению.
- Также разрешите все проблемы с доступом HTTPS,
https://companyB.comкак указано выше, поскольку Outlook перечислит URL-адреса, полученные из адреса электронной почты пользователя, прежде чем перейти к подходу записи SRV.
* Как работает автообнаружение (для внутренних клиентов, подключенных к домену)?
Я добавляю это просто для полноты, так как это еще одна распространенная причина появления этих сертификатов.
На клиенте, присоединенном к домену, когда он локальный для среды Exchange (т. Е. Во внутренней локальной сети), описанные выше методы не используются. Вместо этого Outlook напрямую связывается с точкой подключения службы в Active Directory (указанной в настройках клиентского доступа Exchange), в которой указан URL-адрес, по которому Outlook может найти службу автообнаружения.
При таких обстоятельствах обычно встречаются предупреждения сертификатов, потому что:
- URL-адрес по умолчанию, настроенный для этой цели, относится к внутреннему URL-адресу Exchange, который часто отличается от общедоступного URL-адреса.
- Сертификаты SSL могут не указывать на них внутренний URL. В настоящее время это так, но это может стать проблемой в будущем для доменов Active Directory, которые используют
.localи аналогичные неглобальные суффиксы имен доменов gTLD, поскольку решение ICANN запрещает сертификаты SSL для таких доменов, которые будут выпущены после 2016 года.
- Внутренний адрес может не указывать на нужный сервер.
В этом случае проблема решается путем исправления записанного URL-адреса для обращения к правильному внешнему адресу (указанному в сертификате) путем запуска Set-ClientAccessServerкомандлета с -AutodiscoverServiceInternalUriпереключателем. Стороны, делающие это, обычно также настраивают DNS с разделением горизонта , потому что они обязаны делать это из-за конфигурации своей сети и / или для обеспечения непрерывности разрешения в случае сбоя преобразователя / соединения в восходящем направлении.