У меня проблемы с доступом к Exchange WebDav / OWA с любого компьютера, кроме сервера IIS и Exchange.
У нас есть небольшой домен разработки под управлением Windows 2003. Один сервер (который мы назовем IIS_box) запускает IIS и Exchange 2003. IIS_Box имеет настройку Outlook Web Access на /Exchange/ виртуальный каталог, разрешения запрещают анонимным пользователям и включены как базовая проверка подлинности, так и встроенная проверка подлинности Windows.
В IIS_Box доступ к http://IIS_Box.ourDomain.net/Exchange/ представляет пользователям приложение OWA без запроса имени пользователя / пароля. Однако собираясь http: // IIS_Box / Exchange / пользователю предоставляется диалоговое окно имени пользователя и пароля.
Если пользователь не вводит имя пользователя и пароль, он получает 401.2 Unauthorized: Access denied due to server configuration ошибка. Если пользователь пытается ввести имя пользователя и пароль, он получает 401.1 Unauthorized: Access is denied due to invalid credentials.
С любого другого компьютера пользователю предоставляется диалоговое окно имени пользователя и пароля, и он получает сообщение об ошибке 401 независимо от того, используют ли они полное доменное имя или просто имя сервера.
Кто-нибудь знает, в чем проблема и как ее исправить?
РЕДАКТИРОВАТЬ:
Следуя из Джефф ответ ниже клиенты используют IE7.
В IIS_Box добавление URL без полного доменного имени в зону «интрасеть» на IIS_Box позволяет этому URL работать. Фантастика!
Однако добавление как простых URL-адресов, так и URL-адресов с полным доменным именем в зону «интрасеть» на других машинах - нет. Теперь URL-адреса отображаются как «Локальная интрасеть», но я все еще получаю запросы базовой аутентификации и ошибки 401.
Если я захожу в настройки IE клиента, в разделе Advanced..Security, если я ОТКЛЮЧИТЬ «Включить встроенную проверку подлинности Windows» все работает нормально (если это в зоне интрасети). Мне не нужно было отключать этот параметр в IIS_Box!
Однако он отлично работает только в IE, а не в коде с использованием интерфейса WebDAV - я пробовал запускать / отлаживать в Visual Studio и как скомпилированный / автономный исполняемый файл. А-а!
РЕДАКТИРОВАТЬ 2:
После некоторые копать, похоже, что «Включить встроенную проверку подлинности Windows» на самом деле разрешает взаимодействие между Kerberos и NTLM (по крайней мере, в IE7).
Когда он отключен, используется NTLM.
Если он включен, Kerberos или NTLM запрещены. Если Kerberos не поддерживается, используется NTLM. Если поддерживается но терпит неудачу, NTLM - это не используемый.
Итак, я собираюсь посмотреть, есть ли у нас проблемы с Kerberos ...
Какой браузер? Я знаю, что в IE правила о том, что такое «интрасеть» и, следовательно, разрешено отправлять NTLM-аутентификацию на веб-сервер, довольно византийские.
В принципе, я подозреваю конфигурацию клиентского браузера, особенно если браузер - это IE. Браузер должен полагать, что URL-адрес является «внутренней сетью» для отправки учетных данных NTLM; если он считает, что URL не интранет, он даже не будет пытаться отправить NTLM-аутентификацию.
Оказывается, у меня было две проблемы.
Веб-сайт не был распознан как «сайт интрасети» и, следовательно, он, вероятно, вообще не пытался выполнять аутентификацию Kerberos / NTLM.
У нас были ошибки Kerberos за кулисами. Я обращался к IIS_Box, и в журнале событий были ошибки с KRB_AP_ER_MODIFIED сообщение о host/IIS_Box.ourDomain.net не соответствует HTTP/IIS_Box.ourDomain.net.
Первая проблема была исправлена по предложению Джеффа - спасибо.
Второй был отсортирован путем выполнения следующей команды на контроллере домена:
setspn -A HTTP/IIS_Box.ourDomain.net IIS_Box
Я публикую это решение на случай, если у кого-то еще возникнут похожие проблемы, и они найдут этот вопрос. (Я ненавижу обнаруживать, что у множества людей была та же проблема, что и у меня, но я не могу найти, как они ее исправили.)