Ця проблема, швидше за все, викликана службою автоматичного відкриття Outlook , що є частиною функції Outlook Anywhere . Автовідкриття надає різну інформацію клієнтові Outlook клієнта про різні послуги, пропоновані Exchange, і де вони можуть бути розміщені; це використовується для різних цілей:
Автоконфігурування профілів Outlook у першому запуску Outlook, який може налаштувати обліковий запис Exchange, використовуючи лише електронну адресу та пароль користувача, оскільки інша інформація автоматично розміщується та отримується.
Динамічне розташування веб-служб, до яких звертається клієнт Outlook, включаючи позаштатний помічник, функціонал уніфікованих повідомлень, розташування панелі управління Exchange (ECP) тощо.
Це фірмова реалізація Microsoft RFC 6186 . На жаль, вони насправді не дотримувались рекомендацій цього RFC у дизайні Outlook Anywhere, але цього, можливо, варто очікувати, оскільки обмін та RPC через HTTPS функціональність не є традиційним сервером IMAP / SMTP.
Як працює функція автоматичного відкриття (для зовнішніх * користувачів)?
Автовідкриття зв’язується з веб-службою на сервері клієнтського доступу (у цьому випадку всі ролі є на сервері SBS) на шляху /Autodiscover/Autodiscover.xml, що відходить від його веб-сайту за замовчуванням. Щоб знайти FQDN сервера для спілкування, він видаляє частину користувача з електронної адреси, залишаючи домен (тобто @ 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 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 та як Outlook перевіряє описані вище URL-адреси:
Якщо https://companyB.com/... URL-адреса вирішить запис хосту, а веб-сервер за цією адресою прослуховує порт 443, і у нього є сертифікат SSL, який не вказаний companyB.comу загальному імені або суб'єктному альтернативному імені, тоді проблема виникне. Не важливо, хост є сервером 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.comSRV відповідно до документації .
- Видаліть
autodiscover.companyB.comхост-запис, якщо він існує, щоб запобігти вирішенню проблеми Outlook та намаганням досягти автоматичного відкриття таким чином.
- Також вирішіть будь-які проблеми з доступом до HTTPS,
https://companyB.comяк зазначено вище, оскільки Outlook буде перераховувати URL-адреси, отримані з електронної адреси користувача, перш ніж перейти до підходу запису SRV.
* Як працює функція автоматичного розкриття (для внутрішніх клієнтів, що приєднуються до домену)?
Я додаю це лише для повноти, оскільки це ще одна поширена причина виникнення цих підказок сертифікату.
Для клієнта, що приєднався до домену, коли він локальний у середовищі Exchange (тобто у внутрішній локальній мережі), вищезазначені методи не використовуються. Натомість Outlook безпосередньо зв’язується з точкою підключення до служби у службі Active Directory (вказана у налаштуваннях доступу до клієнтського доступу), де відображається URL-адреса, де Outlook може знайти службу автовідкриття.
Зазвичай у цих обставинах виникають попередження сертифікатів, оскільки:
- URL-адреса за замовчуванням, налаштована для цієї мети, стосується внутрішньої URL-адреси Exchange, яка часто відрізняється від загальнодоступної URL-адреси.
- Сертифікати SSL можуть не містити в них внутрішню URL-адресу. Наразі це робить ваш, але це може стати проблемою в майбутньому для доменів Active Directory, які використовують
.localі подібні не глобальні суфікси доменних імен gTLD, оскільки рішення ICANN забороняє SSL-сертифікати для таких доменів видаватись після 2016 року.
- Внутрішня адреса може не відповідати належному серверу.
У цьому випадку питання вирішується шляхом виправлення записаної URL-адреси на належну зовнішню адресу (вказану в сертифікаті), за допомогою Set-ClientAccessServerкомандлета за допомогою -AutodiscoverServiceInternalUriперемикача. Сторони, які роблять це, зазвичай також конфігурують DNS з розділеним горизонтом , або тому, що це потрібно зробити через їх мережеву конфігурацію та / або для безперервної роздільної здатності у разі відключення вихідного рішення або відключення з'єднання.