Эта проблема, скорее всего, вызвана службой автообнаружения Outlook, которая является частью функциональности мобильного Outlook. Автообнаружение предоставляет клиенту 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.xml
• https://autodiscover.companyB.com/Autodiscover/Autodiscover.xml

Если это не удастся, он попытается установить незащищенное соединение, отключив SSL и попытавшись установить связь через порт 80 (HTTP), обычно после того, как пользователю будет предложено подтвердить, что это приемлемое действие (на мой взгляд, некорректный вариант, поскольку невежественные пользователи обычно утверждают это и рискуют посылать учетные данные в виде простого текста - и неосведомленные системные администраторы, которым не требуется защищенный обмен учетными данными и конфиденциальными данными, представляют риск для непрерывности бизнеса).

Наконец, дополнительная проверка выполняется с использованием служебной записи (SRV) в DNS, которая существует в известном месте за пределами companyB.com пространство имен и может перенаправить Outlook на правильный URL-адрес, где сервер прослушивает.

Что может пойти не так?

В этом процессе может возникнуть одна из нескольких проблем:

Нет записей DNS

Как правило, корень домена (companyB.com) может не разрешить запись узла в DNS. Неправильная настройка DNS (или сознательное решение не предоставлять службу Outlook Anywhere) может означать autodiscover.companyB.com запись тоже не существует

В этих случаях нет серьезных проблем; Outlook просто продолжает взаимодействовать с Exchange, используя последнюю известную конфигурацию, и может быть ухудшен по отношению к определенным веб-функциям, для которых ему необходимо извлекать URL-адреса с помощью автообнаружения (например, помощник при отсутствии на работе). Обходной путь - использовать Outlook Web Access для доступа к таким функциям.

Автоматическая настройка учетных записей Exchange в новых профилях Outlook также не автоматизирована и требует ручной настройки параметров RPC через HTTPS. Однако это не приведет к описанной вами проблеме.

Неисправные SSL-сертификаты

Вполне возможно, что URL-адрес, который Outlook использует для попытки связаться с Exchange Server, разрешается на хост, который может быть или не быть сервером клиентского доступа. Если Outlook может обмениваться данными с этим сервером через порт 443, сертификаты, конечно, будут обмениваться для установки безопасного канала между Outlook и удаленным сервером. Если URL-адрес, который, по мнению Outlook, он использует, отсутствует в этом сертификате - будь то в качестве общего имени или альтернативного имени субъекта (SAN) - это приведет к тому, что Outlook представит диалоговое окно, которое вы описали в своем первоначальном сообщении.

Это может произойти по нескольким причинам, все зависит от того, как настроен DNS и как URL, которые я описал выше, проверяются Outlook:

• Если https://companyB.com/... URL-адрес преобразуется в запись хоста, и веб-сервер по этому адресу прослушивает порт 443 и имеет сертификат SSL, который не отображается в списке. companyB.com в общем имени или альтернативном имени субъекта, тогда возникнет проблема. Не имеет значения, является ли хост сервером Exchange или нет; это может быть веб-сервер, на котором размещен веб-сайт компании, который настроен неправильно. Исправьте либо:

  • Отключить запись хоста в корне companyB.com зона (требующая посетителей сайта или другого сервиса для входа www.companyB.com, или эквивалент; или же
  • Отключить доступ к машине на companyB.com на порту 443, в результате чего Outlook отклоняет companyB.com URL перед обменом сертификатами и продвижение; или же
  • Исправить сертификат на companyB.com для обеспечения companyB.com указан в этом сертификате, и что пытается посетить https://companyB.com в стандартном браузере не подводят.

  Вышесказанное применяется независимо от того, companyB.com разрешается на Exchange Server; если Outlook может общаться с ним, он позже обнаружит, что /Autodiscover/Autodiscover.xml Путь выдает ошибку HTTP 404 (не существует) и идет дальше.

• Если https://autodiscover.companyB.com/... URL-адрес разрешается на сервер Exchange (или любой другой сервер), но, опять же, autodiscover.companyB.com не указан в качестве общего имени или альтернативного имени субъекта, вы будете наблюдать это поведение. Это можно исправить, как указано выше, исправив сертификат, или, как вы правильно указали, вы можете использовать запись SRV для перенаправления Outlook на URL-адрес, который указан в сертификате и с которым Outlook может взаимодействовать.

Ваше вероятное решение этой проблемы

В этом случае типичным решением является последнее; создайте записи SRV в новом поставщике DNS, чтобы убедиться, что Outlook перенаправлен на autodiscover.companyA.com, который (любые другие проблемы в стороне) будет работать успешно, так как он указан в сертификате как SAN. Чтобы это работало, вам нужно:

• Настроить _autodiscover._tcp.companyB.com Запись СРВ в соответствии с документацией.
• Удалить 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 с разделением горизонта, потому что они обязаны делать это из-за конфигурации своей сети и / или для обеспечения непрерывности разрешения в случае сбоя преобразователя / соединения в восходящем направлении.