Я установил веб-приложение .net на сервере IIS Windows Server 2003, работающем в пуле приложений как NETWORK SERVICEи подключающемся к SQL Server на другой машине с помощью Integrated Security. Машина SQL Server также работает под управлением Windows Server 2003. Поэтому веб-приложение подключается как идентификаторDOMAIN\COMPUTER$и у этой учетной записи есть логин и пользователь на SQL Server, так что все работает хорошо.
Я также установил службу .net windows на том же сервере IIS, который подключается к той же машине SQL Server. Служба windows работает как LOCAL SYSTEMи должна поэтому подключаться как identityDOMAIN\COMPUTER$. Я установил этот же продукт в более чем дюжине разных компаний, обычно все работает так, как я и ожидал, но в одном недавнем случае служба Windows не смогла подключиться к базе данных, и возникла ошибка:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
Есть идеи, почему это может быть так для LOCAL SYSTEM, а не для NETWORK SERVICE? Чтобы обойти это в краткосрочной перспективе, мне пришлось перейти на использование входа SQL Server, но я бы предпочел использовать Integrated Security, если есть простое решение. В журнале событий Security или System не было сообщений об ошибках, хотя я ничего не делал для включения дополнительного ведения журнала.
Обычно я предполагаю, что это какая-то проблема типа Kerberos/AD, и следую таким статьям, какэтотиэтотпомогло бы. Но тот факт, что это работает из NETWORK SERVICE, говорит о том, что обычные вещи, которые я бы проверил, уже в порядке (например, SPN настроены правильно, а учетная запись домена машины включена для делегирования?). Так какая же настройка работает неправильно?
У меня нет доступа к серверам без помощи ИТ-отдела моего клиента, а на сервере установлены другие приложения, которые мне нужно не забывать нарушать, что делает устранение неполадок немного более деликатным. Любые предложения по устранению неполадок будут высоко оценены!
решение1
Вы можете захотеть подтвердить, является ли безопасное соединение NTLM или Kerberos. Если оно возвращается к NTLM, соединение будет анонимным.
Существует групповая политика, которая позволяет использовать идентификатор компьютера при использовании NTLM.
Безопасность сети: разрешить локальной системе использовать идентификатор компьютера для NTLM
http://technet.microsoft.com/en-us/library/jj852275%28v=ws.10%29.aspx
Для получения дополнительной информации о настройке SPN для упрощения аутентификации Kerberos на вашем сервере SQL:
В частности, обратите внимание на следующее:
SPN для SQL Server состоит из следующих элементов:
- ServiceClass: Это определяет общий класс обслуживания. Это всегда MSSQLSvc для SQL Server.
- Хост: это полное доменное имя DNS компьютера, на котором работает SQL Server.
Порт: это номер порта, который прослушивает служба.
например: MSSQLSvc/myserver.corp.mycomany.com:1433
решение2
Я все еще ставлю на проблему SPN. Не предполагайте, что они там есть. Проверьте правильность регистрации SPN для SQL Server. Также проверьте наличие дубликатов ( setspn -x).
Network Serviceработает, потому что даже если SPN отсутствует, все равно можно вернуться к аутентификации NTLM.
Local Systemне работает, потому что он только получает доступ к сетевым ресурсам, как DOMAIN\Computer$будто он может использовать Kerberos. В противном случае он возвращается к нулевому сеансу, поэтому вы видите Anonymous Logon.