Не удается авторизоваться с другим именем сервера

У меня есть веб-служба, работающая в IIS 6.0 в Windows 2003. Ее режим аутентификации — встроенная безопасность Windows (анонимность отключена), а авторизация выполняется с помощью диспетчера авторизации и хранилища авторизации XML. Мой тестовый пользователь является пользователем домена (фактически администратором) с авторизованной ролью.

Я тестирую это (на данный момент) на веб-сервере (localhost) и использую (на данный момент) Internet Explorer для доступа к веб-службе (.asmx).

Я могу успешно открыть страницу веб-службы (wsdl) через локальный хост, например:

http://localhost:8080/MyService/MyService.asmx

При использовании этого URL-адреса интегрированная проверка подлинности Windows проходит успешно (в автоматическом режиме), и AzMan успешно авторизует меня для доступа к службе. То же самое касается имени сервера:

http://myserver:8080/MyService/MyService.asmx

Теперь мне нужно использовать внешнее имя хоста (www.mysite.no) для доступа к сервису (чтобы заставить ssl работать с сертификатом, выданным для этого имени сайта). Для этого я добавляю имя хоста в свой файл HOSTS, например:

127.0.0.1   www.mysite.no

... затем введите это в IE:

http://www.mysite.no:8080/MyService/MyService.asmx

Что происходит тогда, так это то, что авторизация не удалась. Я получаю окно входа в IE/Windows и трижды ввожу свои правильные учетные данные. Затем я получаю 401.1:

HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials.
Internet Information Services (IIS)

Как на авторизацию через AzMan влияет имя хоста?

Редактировать: у меня есть основания полагать, что AzMan не имеет к этому никакого отношения — похоже, что аутентификация не удалась.

Воспроизвел проблему на другом сервере. Суть, по-видимому, в том, что доступ к localhost через запись в файле локального хоста каким-то образом нарушает встроенную аутентификацию Windows между браузером и IIS.

Я работал над проблемой, теперь все, что осталось от моего любопытства...


person Tor Haugen    schedule 09.02.2009    source источник


Ответы (2)


Включите аудит ошибок при входе и проверьте журнал событий безопасности на хосте.
1) На веб-сервере перейдите в Панель управления, Администрирование, Локальная политика безопасности. 2) Заходим в локальные политики, политика аудита. Добавьте сбой для «аудит событий входа в систему».
3) Закройте MMC. Откройте командную строку и введите gpupdate. 4) перейдите на http://www.mysite.no. Вы снова получите ошибку. 5) Запустите средство просмотра событий (панель управления, инструменты администратора, средство просмотра событий). Перейдите к журналу событий безопасности и найдите ошибки входа в систему. Они должны сообщить вам что-то описательное, например, «пользователю не предоставлен указанный тип входа». К сожалению, сам тип входа в систему не является описательным; тип входа 2 — интерактивный (локальный), 3 — «доступ к этому компьютеру по сети», 5 — «вход в систему как служба» (служба NT, а не служба WCF). Необходимые права могут быть предоставлены в локальной политике безопасности.

Кроме того, проверьте, включен ли прокси-сервер в IE. Если ваш трафик направляется на прокси-сервер, возможно, прокси-сервер не поддерживает NTLM. Добавьте хост в качестве исключения прокси-сервера во время тестирования с помощью IE.

person Community    schedule 09.02.2009

Мое первое предположение состоит в том, что это не имя хоста.

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

Сначала установите для сайта IIS анонимный доступ и убедитесь, что вы можете подключить веб-службу. Это подтвердит, что вы обращаетесь к правильному веб-сайту IIS, и это действительно сузит проблему авторизации.

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

person Brandon    schedule 09.02.2009