Exchange 2013 ECP, петля перенаправления с универсальным сертификатом

Вопрос или проблема

Недавно мы не смогли войти в ECP, после успешного входа нас перенаправляет обратно на экран входа на наших двух серверах Exchange, и никаких изменений в конфигурации не было произведено, мы используем подстановочный сертификат и работаем в гибридной конфигурации с Office365.

После попытки воссоздания каталогов ECP и backend и проверки настроек аутентификации проблема все равно сохранялась.

Поэтому я решил добавить новый сервер Exchange, и затем, когда я установил на него подстановочный сертификат, я столкнулся с петлей перенаправления, как и на других серверах, я вернулся к самоподписанному сертификату для доступа к ECP.

Есть у кого-нибудь идеи по этому поводу? Спасибо.

Да, при выборе изменения сертификата обычно происходит изменение на фронтенде ECP в IIS.

Проверьте и убедитесь, что сертификат на фронтенде соответствует сертификату, используемому на бэкенде, в IIS для сайта Exchange (по умолчанию) на всех серверах Exchange.

/******************/
Чтобы убедиться, что все внутренние и внешние URL корректны, выполните следующие действия, измените URL на тот, что используется в вашей компании:

 Get-OabVirtualDirectory | Set-OabVirtualDirectory –ExternalURL https://mail.company.com/oab
 Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalURL https://mail.company.com/ews/exchange.asmx
 Get-OutlookAnywhere | Set-OutlookAnywhere –ExternalHostname mail.company.com –ExternalClientsRequireSsl $true
 Get-MapiVirtualDirectory | Set-MapiVirtualDirectory –ExternalURL https://mail.company.com/mapi
 Set-OrganizationConfig -MapiHttpEnabled $true

И выполните тест снаружи вашей компании с помощью этого:
https://testconnectivity.microsoft.com/

Автообнаружение работает с 4 методами, так что должна быть запись @ или “autodiscover” в публичном DNS.

Посмотрите этот ответ в моем блоге:

http://mcsemessaging.blogspot.mx/2014/12/blank-screen-after-login-via-owa-in.html

Проблема в IIS, перейдите на сайт backend и измените сертификат, используемый портом 444, чтобы соответствовать вашему подстановочному сертификату.

По неизвестной причине, когда вы изменяете сертификат на фронтенде используя команды, которые я публиковал ранее.

Ответ или решение

Недавно возникла проблема с бесконечным перенаправлением при попытке входа в панель управления Exchange (ECP) на серверах Exchange 2013. Успешная авторизация приводила к повторному появлению формы входа. Эта ситуация возникла на двух серверах Exchange, к тому же без каких-либо изменений конфигурации. Проблема связана с использованием wildcard-сертификата и гибридной конфигурацией с Office 365.

Первоначально, попытки восстановить каталоги ECP и backend, а также проверка настроек аутентификации не дали результатов. Однако при установке wildcard-сертификата на новый сервер ситуация повторилась. Временное решение было найдено в использовании самоподписанного сертификата для доступа к ECP.

Анализ проблемы:

Настройки сертификатов: Необходимо убедиться, что настраиваемый wildcard-сертификат применяется одинаково на всех сайтах IIS, как на фронтенде, так и на бекенде. Это часто упускается из виду и может вызвать ошибки в маршрутизации запросов.

Настройки виртуальных директорий: Проверьте, чтобы все внутренние и внешние URL-адреса для компонентов Exchange были корректно настроены. Используйте следующие командлеты, заменяя ‘mail.company.com’ на ваш фактический домен:

Get-OabVirtualDirectory | Set-OabVirtualDirectory –ExternalURL https://mail.company.com/oab
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory –ExternalURL https://mail.company.com/ews/exchange.asmx
Get-OutlookAnywhere | Set-OutlookAnywhere –ExternalHostname mail.company.com –ExternalClientsRequireSsl $true
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory –ExternalURL https://mail.company.com/mapi
Set-OrganizationConfig -MapiHttpEnabled $true

Проверка соединения: Используйте внешний тест, такой как Тест соединения Microsoft, чтобы удостовериться в корректности внешних настроек.
Настройки Autodiscover: Убедитесь, что Autodiscover настроен с использованием верной DNS-записи (например, "autodiscover" или "@") в публичной DNS-зоне.
Изменение сертификата на порту 444 в бекенде IIS: Часто проблема заключается в несовпадении сертификатов на фронтенде и бекенде, особенно на порту 444. Проверьте и замените сертификат на нужный в настройках IIS для бекенд-сайта.

Для полного решения проблемы рекомендуется посетить ресурс или блог, где описаны аналогичные сценарии и их решения. Одним из таких источников может быть материал на тему пустого экрана после входа в OWA.

Вывод:
Правильно настроенные сертификаты и виртуальные директории, а также правильные тесты соединения являются ключами к устранению проблемы зацикливания при входе в Exchange 2013 ECP. Всегда важно помнить о влиянии изменений в сертификатах на различные уровни IIS.