Я нахожу различные результаты в Google, но, похоже, мою проблему не решить.
Я настраиваю новый ящик WINDOWS 2008 R2 на работе, который должен взаимодействовать с существующим ящиком SQL 2012 через веб-инструменты, работающие в IIS 7.5 в нашей интрасети. Мы должны использовать аутентификацию Windows через Out - IE -> Web Server -> SQL. Мы используем Kerberos. При просмотре инструмента локально на веб-сервере все в порядке, но как только я пытаюсь просмотреть его на удаленном клиенте, я получаю ошибку «Ошибка входа для пользователя NT AUTHORITY \ ANONYMOUS LOGON».
Позвольте мне рассказать, как у нас есть веб-сайт - пул приложений, на котором запущена .NET 2.0 в классическом режиме с удостоверением ApplicationPoolIdentity, проверка подлинности Windows включена с расширенной защитой, установленной на Off, включена проверка подлинности в режиме ядра, а включенные поставщики ( по порядку) Согласование и NTLM. Включено олицетворение ASP.NET для олицетворения аутентифицированного пользователя.
Строка подключения SQL в следующем формате:
Data Source=THESQLBOXNAME;Initial Catalog=DATABASENAME;Integrated Security=True
У меня есть тестовая страница, которую я разместил на веб-сервере (в соответствии с указанными выше настройками), на которой отображаются следующие данные:
HttpContext.Current.User.Identity.IsAuthenticated правда
HttpContext.Current.User.Identity.Name ожидаемый пользователь (пользователь, запускающий браузер)
System.Security.Principal.WindowsIdentity.GetCurrent.Name ожидаемый пользователь
Я пытаюсь выполнить базовый запрос sql в поле sql и получаю упомянутую выше ошибку входа в систему.
Я проверил AD и убедился, что в веб-окне задано делегирование: «Доверять этому компьютеру для делегирования только указанным службам / Использовать только Kerberos»
Я запустил эту тестовую страницу на существующем компьютере WINDOWS 2008 R2 под управлением IIS 7.5 (с теми же параметрами, упомянутыми выше), и я не получаю никаких ошибок.
Я проверил настройки SPN для обоих веб-боксов, и они одинаковы (за исключением имени машины):
setspn -L EXISTINGBOX
WSMAN/EXISTINGBOX.domain.com
WSMAN/EXISTINGBOX
TERMSRV/EXISTINGBOX.domain.com
TERMSRV/EXISTINGBOX
HOST/EXISTINGBOX.domain.com
HOST/EXISTINGBOX
RestrictedKrbHost/EXISTINGBOX.domain.com
RestrictedKrbHost/EXISTINGBOX
setspn -L NEWBOX
WSMAN/NEWBOX.domain.com
WSMAN/NEWBOX
TERMSRV/NEWBOX.domain.com
TERMSRV/NEWBOX
HOST/NEWBOX.domain.com
HOST/NEWBOX
RestrictedKrbHost/NEWBOX.domain.com
RestrictedKrbHost/NEWBOX
Я понимаю, что это действует как проблема двойного перехода, но тот факт, что он работает на другом блоке, заставляет меня думать, что это что-то особенное в новом веб-блоке. Какого черта мне не хватает ?????
Последние две вещи, о которых я могу думать, - это проверить, зарегистрированы ли у вас MSSQLSvc SPN под зарегистрированной учетной записью службы SQL-сервера (которая, возможно, у вас уже есть, поскольку у вас есть рабочий сценарий). На всякий случай:
Если это будет сделано, то вернувшись на вкладку AD, где у вас есть параметр доверия, добавьте учетную запись SQL-сервера в качестве одной из разрешенных служб. Если все сделано правильно, вы должны увидеть в списке MSSQLSvc *.
Если указанные выше методы не работают, возможно, вам придется включить трассировку Keberos или использовать трассировку сети для поиска ошибок Kerberos.
Проверьте, установлен ли на неработающем сервере IIS «доверенный компьютер для делегирования»: http://blogs.technet.com/b/taraj/archive/2009/01/29/checklist-for-double-hop-issues-iis-and-sql-server.aspx