Исходные данные:
1. IIS7.
2. Web Server имеет учетную запись компьютера в домене.
3. Имя машины предположим computer.
4. Виртуальный каталог установлен на вебсайт для которо пробиндено имя webserver.mydomain.local (DNS сервер естественно резолвит это имя).
5. Для витуального каталога запрещаем анонимный доступ и включаем Integrated Windows Authentication.
6. Помещаем в виртуальный каталог test.html.
7. На клиентском кампутере запускаем IE7 под доменным пользователем.

Експеримент:
Заходим по URL http://webserver.mydomain.local/Virtualfolder/test.html
Если добавлен сайт webserver.mydomain.local в локал интранет, то я захожу на страницу без необходимоси ввода креденшелов. Если нет, то необходимо ввести имя и пароль доменного пользователя.

Размышления:
Насколько я понял из MSDN при Windows аутетификации веб сервер предлагает использовать клиенту negotiate протокол, т.е. позволяет клиенту выбрать между Kerberos и NTLM. Если бравзер считает, что веб сервер находится не в локальной сети, то он даже не пытается использовать Kerberos, а сразу аутентифицирует пользователя по NTLM для чего и показывает пользователю диалог для ввода креденшелов.
Сложнее дело обстоит со случаем, когда бравзер считает что сервер в локальной сети (интранете). В этом случае клиент использует Kerberos. Как известно для успешной керберос аутентификации клиенту нужно знать так называемый Target Name в качестве которого можно указать либо SPN либо явно имя пользователя под которым выполняется серверное приложение. Имя этого пользователя бравзер знать ну никак не может. Значит он как-то формирует SPN. Можно предопожить что он (Internet Explorer) формирует его согласно рекомендациям Microsoft Т.е. “HTTP/webserver.mydomain.local”. Но в моей Active Directory такой SPN не закреплен ни за одной учетной записью.

Вопросы:
Можите объяснить почему в моем случае Windows аутентификация вообще работает? И как конкретно на протокольном уровне она происходит?

PS Возможно офтоп, но подходяжего раздела не нашел. А проблема возникла именно при написании ASP.NET приложения.

Здравствуйте, Аноним, Вы писали:

А>Сложнее дело обстоит со случаем, когда бравзер считает что сервер в локальной сети (интранете). В этом случае клиент использует Kerberos.
он Пытается использовать Kerberos.
т.е. отсылает запрос в KDC с указанием SPN и если оттуда облом, то дальнейшие движения по NTLM.
есть программулинка WireShark — через неё этот диалог отлично видно.

Здравствуйте, Neco, Вы писали:

N>Здравствуйте, Аноним, Вы писали:

А>>Сложнее дело обстоит со случаем, когда бравзер считает что сервер в локальной сети (интранете). В этом случае клиент использует Kerberos.
N>он Пытается использовать Kerberos.
N>т.е. отсылает запрос в KDC с указанием SPN и если оттуда облом, то дальнейшие движения по NTLM.
N>есть программулинка WireShark — через неё этот диалог отлично видно.

Спасибо за ответ, но меня интересовал ответ вопрос, почему в моем случае аутентификация вообще работает? Причем я так понимаю она происходит по протоколу керберос, потому что бравзер не показывает диалога для ввода креденшелов.

Т.е. перефразировать вопрос можно так. Каким публичным ключем KDC шифрует TGT, который бравзер отсылает веб серверу?
Я так понимаю в моем случае он его должен шифровать публичным ключем пользователя mydomain\computer$, т.к. аппликейшен пул моего веб приложения запущен под пользователем NetworkService.
Напомню что имя хоста по которому бравзер доступается в вебсерверу webserver.mydomain.local т.е. отличается от имени компьютера (computer) в Active Directory. В Active Directory также нету SPN HTTP\webserver.mydomain.local для аккаунта mydomain\computer$.

По поводу Ethereal спасибо за совет. Обязательно попробую, когда буду иметь доступ к среде. А пока хотелось бы собрать больше информации.

Здравствуйте, Makht, Вы писали:

M>Спасибо за ответ, но меня интересовал ответ вопрос, почему в моем случае аутентификация вообще работает?
ну так я и ответил: потому что используется NTLM

M>Причем я так понимаю она происходит по протоколу керберос, потому что бравзер не показывает диалога для ввода креденшелов.
по-моему, это не симптом.

лучше всего глянуть на сырые пакеты — тогда сразу всё станет ясно.

Здравствуйте, Neco, Вы писали:

M>>Причем я так понимаю она происходит по протоколу керберос, потому что бравзер не показывает диалога для ввода креденшелов.
N>по-моему, это не симптом.
Если верить микрософт, то Single Sign On возможен только по керберосу. Пароль также обязательный параметр для NTLM секурити провайдера, а Windows его вроде не кеширует (не должна кешировать), хотя...

вобщем вскрытие покажет

Здравствуйте, Makht, Вы писали:

M>Если верить микрософт, то Single Sign On возможен только по керберосу. Пароль также обязательный параметр для NTLM секурити провайдера, а Windows его вроде не кеширует (не должна кешировать), хотя...
а где можно такое почитать? потому что как-то слабо вериться — предположим у меня экзешник, который стучится в базу, а в базе доступ через доменные группы — это испокон веков работало, хотя никто SPN не прописывает. И мне же не нужно у пользователя пароль спрашивать для этих целей. вроде как...
хотелось бы почитать ваши источники, если можно.
от себя могу скинуть wireshark'овские логи, в которых читается то, про что я говорю — может я не так смотрю, но всё похоже на NTLM.

N>а где можно такое почитать? потому что как-то слабо вериться — предположим у меня экзешник, который стучится в базу, а в базе доступ через доменные группы — это испокон веков работало, хотя никто SPN не прописывает. И мне же не нужно у пользователя пароль спрашивать для этих целей. вроде как...
N>хотелось бы почитать ваши источники, если можно.
N>от себя могу скинуть wireshark'овские логи, в которых читается то, про что я говорю — может я не так смотрю, но всё похоже на NTLM.

Где это можно почитать не скажу, потому что это оказалась неправдой Наверное приснилось.
Только что поставил ваиршарк и проанализировал различные хендшейки между бравзером и вебсервером.
Таки да в моем случае клиент использует NTLM. Причем если добавить в AD соответстующий SPN, то клиент начинает использовать керберос. Причем как я понимаю для самого бравзера это все прозрачно. Так скорее всего реализован секурити провайдер для negotiate. Т.е. сам провайдер сначала пытается получить TGT от KDS для SPN которого нет и после облома решает использовать NTLM.

Вобщем в проблеме полностью разобрался. Тему можно закрывать.
Отдельное спасибо Neco за совет использовать wireshark. За 5 лет он (ethereal) очень сильно изменился. Сейчас реально мега мощный инструмент. Расшифровывает огромное количество протоколов.