IIS работает как учетная запись службы AzMan

Question

У меня есть требование, чтобы веб-сайт работал в качестве учетной записи службы по причинам IP, я также хочу иметь возможность использовать AzMan для аутентификации / аутентификации пользователей. По некоторым причинам я не могу заставить их работать вместе. Я настроил пример приложения для проверки воды, которая в основном выплевывает некоторые учетные данные пользователя. Помимо Azman и настройки веб-конфигурации, приложение не имеет кода интеграции (без ведения журнала / взаимодействия с БД / веб-сервисом), это один пейджер.

Запуск пула приложений под учетной записью сетевой службы с отказом в доступе Anon. Я получаю:

Windows Identity Check - Name: 'NT AUTHORITY\NETWORK SERVICE'  
Request.LogonUserIdentity.Name = 'CT\rhyc'  
HttpContext.User.Identity.Name = 'CT\rhyc'  
User.Identity.Name = 'CT\rhyc'  
Is in UserRole = 'True'  

.. что все хорошо, все работает, однако учетная запись службы - это услуга сети, а не учетная запись службы, которую я должен использовать. Если я переключаю учетную запись на учетную запись службы, я получаю всплывающее окно с запросом учетных данных пользователя (что мне не нужно, это должен быть единый вход); однако я получал эти учетные данные в предыдущей настройке (ct / rhyc)

Для веб-сайта была запущена команда setspn (по-видимому), но я действительно не знаю, что делает spn, не говоря уже о том, как это проверить. Также, если я разрешаю анонимный доступ к пулу приложений с учетной записью службы, я получу:

Windows Identity Check - Name: 'CT\SVC-PERAT2-T2DEV'  
Request.LogonUserIdentity.Name = 'PERAT2NTAH3WD1\CVX_IUSR'  
HttpContext.User.Identity.Name = ''  
User.Identity.Name = ''  
Is in UserRole = 'False' 

Извините, ребята, я и IIS n00b, обычно это не то, чем я бы занимался, однако наши администраторы, похоже, мало что знают о IIS, так что это оставлено мне ..: (

Answer 1

с SPN вы попадаете в мир Kerberos. Обычно это область неизвестного.

Существует замечательный технический документ, посвященный устранению неполадок безопасности: http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en

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

Подробнее здесь: http://support.microsoft.com/kb/262177

Answer 2

ОК, похоже, мы лаяли не на то дерево. Керброс никогда не требовался, кое-как он проскользнул сквозь китайский шепот. Мы перешли на NTLM, и все хорошо.

см ниже
cscript adsutil.vbs set w3svc / 1152622725 / root / NTAuthenticationProviders "NTLM"

, где 1152622725 был идентификатором сайта

Спасибо за помощь, ребята, урок выучен: не ругайтесь с кербросом, потому что он откусывает назад!