Двойная проверка подлинности Windows
У меня проблема с работой проверки подлинности Windows (Kerberos) при передаче учетных данных от пользователя в IIS, а затем из IIS в SQL. Я настроил SPN для SQL и настроил учетную запись сервера IIS, чтобы разрешить делегирование.
Если я настрою учетную запись компьютера IIS, чтобы разрешить делегирование для любой службы, она будет работать: 
Однако, если я настроил его для определенных служб, учетные данные не передаются, и я получаю сообщение об ошибке при подключении к анонимному пользователю:
Как видите, я подключаюсь к SQL Express Instance и настроил несколько SPN, чтобы попытаться решить эту проблему, но ни с одним из них не повезло. Очевидно, тот факт, что он работает при разрешении любой услуги, говорит мне, что в этом списке услуг отсутствует что-то еще, но я не знаю, что именно!
Для всех, кто мог столкнуться с этой проблемой, проблема заключалась в использовании аутентификации в режиме ядра с учетной записью пользователя домена для учетной записи пула приложений.
Аутентификация в режиме ядра выполняет за вас большую часть работы в отношении имен SPN IIS, однако предполагается, что вы будете использовать системную учетную запись для удостоверения пула приложений. Если вы используете учетную запись домена, вам необходимо настроить HTTP SPN для этого пользователя. Затем вам нужно будет делегировать доступ к SQL для этой учетной записи пользователя, а не для учетной записи IIS Machine, как обычно при аутентификации в режиме ядра.
В прошлом у меня это работало с IIS6, Windows 2003 и SQL 2005, но я давно не смотрел на это, но на случай, если это поможет, вот что я могу узнать:
В AD на веб-сервере есть одна запись для SQL-сервера, настроенная на «доверять только указанным службам», «использовать любой протокол аутентификации», и эта запись имеет имя хоста SQL, а не полное доменное имя. Тип службы - MSSQLSvc, порт - 1433.
Учетная запись компьютера SQL Server не является доверенным для делегирования.
Я также помню, что при настройке мне приходилось использовать setspn в командной строке, а настройки, которые я получил с помощью setspn -L webserver, следующие:
HTTP/intranet.domain.example.org:80
HTTP/intranet:80
HOST/webserverhostname
HOST/webserverhostname.domain.example.org
Где 'intranet' - это псевдоним, который мы используем для веб-сайта, и указываем ваши настоящие FQDN, а не example.org, например
setspn -A HTTP/intranet:80 webserver
и так далее.
Кроме того, это выглядит как довольно тщательный контрольный список: http://blogs.technet.com/b/taraj/archive/2009/01/29/checklist-for-double-hop-issues-iis-and-sql-server.aspx
Я обнаружил, что независимо от конфигурации SPN веб-сервера мне нужно было создать SPN для SQL Server, используя запись HOST для имени SQL Server, а не псевдоним CNAME.
То есть, чтобы охватить все базы, я добавил следующие SPN;
setspn -A MSSQLSvc / sqlserverhostname.example.org SQLServerServiceAccountName
setspn -A MSSQLSvc / sqlserverhostname: 1433 SQLServerServiceAccountName
setspn -A MSSQLSvc / sqlserverhostname.example.org: 1433 SQLServerServiceAccountName
setspn -A MSSQLSvc / sqlserverhostname SQLServerServiceAccountName
.. обеспечение того, чтобы "sqlserverhostname" было зарегистрировано в DNS как запись HOST.