Назад | Перейти на главную страницу

Добавлена ​​привязка IIS, теперь Outlook запрашивает учетные данные бесконечно

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

Клиенту нужно было пройти сканирование PCI, и последним важным элементом было то, что когда определенное сообщение HTTP было отправлено на сервер CAS (на самом деле просто взорвано IP-адрес, на котором размещается сервер CAS / сервер обмена), без указанного URL-адреса оно было все еще отвечает сообщением, в котором раскрывается его внутренний IP-адрес.

Исправление (по крайней мере, для прохождения сканирования) заключалось в добавлении «привязки» в IIS для «веб-сайта по умолчанию», на котором размещается CAS и который в настоящее время является единственным слушателем для HTTPS / 443, структурированным как:

Хотя сканирование теперь проходит (предположительно, потому что, когда приходит неквалифицированный заголовок, нет соответствующей привязки - до того, как существовала привязка, как упомянуто выше, у которой не было значения в поле 'hostname'), пользователи сообщали о всплывающем окне, предлагающем им войти в систему из мировоззрение. Когда они вводят учетные данные, он просто повторяет их. Если вы закроете приглашение, оно будет отсутствовать в течение переменного времени, но в конечном итоге появится снова. Доставка почты не затронута.

Я уже пробовал удалить кэшированные учетные данные из диспетчера учетных данных, и пользователь вводил новые учетные данные безрезультатно.

С нетерпением жду любых отзывов / помощи - заранее спасибо !!

CASURLHERE должно быть полным доменным именем, а не URL-адресом.

URL-адрес будет http://host.fqdn.com

Хост и доменное имя host.fqdn.com без префикса http: // - полное доменное имя.

Предполагая, что теперь у вас есть привязка сайта к host.fqdn.com, это интересно. Я бы предположил, что его, возможно, не было в вашей зоне локальной интрасети, но мгновенное возвращение подсказки указывает, что проверка подлинности, возможно, вообще не выполняется, и что, возможно, стоит посмотреть журнал событий безопасности, когда этот тип проблема возникает. Также стоит посмотреть журналы HTTPERR (c: \ windows \ system32 \ logfiles) и W3C (c: \ inetpub \ logs).

Также может быть полезно добавить host (т.е. неквалифицированное имя хоста), а также - если сайт настроен для заголовков хоста, теперь он будет принимать только эти заголовки хоста, и если кто-то по какой-либо причине использует короткое имя хоста, оно теперь будет отклонено (и все, что имеет точка в нем по умолчанию считается Интернетом и т. д.).

Вы не указали явно, был ли HTTPS новым, но сломанный (или не подлежащий проверке отзыв) сертификат также может привести к аналогичным кажущимся проблемам.

Какая у вас версия сервера Exchange? Сталкивались ли вы с какой-либо проблемой в OWA?

По умолчанию служба клиентского доступа RPC на сервере клиентского доступа Exchange 2010 использует порт TCP End Point Mapper (TCP / 135) и динамический диапазон портов RPC (6005-59530) для исходящих подключений каждый раз, когда клиенты Outlook устанавливают подключение. обменять.

Нам нужно настроить статические порты RPC на сервере клиентского доступа Exchange 2010.

https://social.technet.microsoft.com/wiki/contents/articles/864.configure-static-rpc-ports-on-an-exchange-2010-client-access-server.aspx?Redirected=true