IIS работает как учетная запись службы в AzMan
У меня есть требование, чтобы веб-сайт работал в качестве учетной записи службы по соображениям IP, я также хочу иметь возможность использовать AzMan для аутентификации / аутентификации пользователей. По некоторым причинам я не могу заставить их работать вместе. Я настроил пример приложения для проверки воды, которая в основном выплевывает некоторые учетные данные пользователя. Помимо Azman и веб-конфигурации, приложение не имеет интеграционного кода (без ведения журнала / взаимодействия с БД / веб-сервисом), это один пейджер.
Запустив пул приложений под учетной записью сетевой службы с анонимным доступом, я получаю:
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, поэтому он оставлен мне..:(
2 ответа
С SPN вы попадаете в мир Kerberos. Обычно это область неизвестного.
Здесь вы найдете отличный технический документ по устранению неполадок безопасности: http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en
Он объясняет, как включить дополнительные журналы, чтобы добраться до корня проблемы с аутентификацией. Обычно это связано с тем, что делегирование в Exchange не настраивается для передачи учетных данных пользователя и т. Д.
Подробнее здесь: http://support.microsoft.com/kb/262177
Хорошо, похоже, мы лаяли не на то дерево. Керброс никогда не требовался, кое-как он проскользнул сквозь китайский шепот. Мы перешли на NTLM и все хорошо.
см ниже
cscript adsutil.vbs set w3svc/1152622725/root/NTAuthenticationProviders "NTLM"
где 1152622725 был идентификатор сайта
Спасибо за помощь, ребята, урок выучен: не ругайтесь с кербросом, потому что он кусается!