Эта проблема, скорее всего, вызвана Автообнаружение сервис, часть 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). Он пытается установить связь с Autodiscover, используя по очереди каждый из следующих 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, разрешает хост, который может быть или не быть сервером клиентского доступа. Если 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 path выдает ошибку HTTP 404 (не существует) и двигайтесь дальше.

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

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

В этом случае типичное решение - сделать последнее; создать записи 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либо потому, что это требуется в соответствии с их сетевой конфигурацией, и / или для непрерывности разрешения в случае отказа восходящего преобразователя / соединения.

Вам необходимо создать запись SRV в доменах B и C, которая соответствует одному из имен в сертификате (autodiscover.companyA.com). Это сообщает Outlook, что это имя обрабатывает автообнаружение для доменов B и C.

Прочтите здесь записи SRV в разделе DNS:

https://jaapwesselius.com/2011/08/28/autodiscover-redirect-srv-record/