Назад | Перейти на главную страницу

Веб-приложение, работающее как СЕТЕВАЯ СЛУЖБА, может подключаться к SQL Server, но служба Windows, работающая как ЛОКАЛЬНАЯ СИСТЕМА, не может

Я установил веб-приложение .net на сервере IIS Windows Server 2003, работающее в пуле приложений как NETWORK SERVICE и подключение к SQL Server на другом компьютере с помощью встроенной безопасности. Компьютер SQL Server также работает под управлением Windows Server 2003. Таким образом, веб-приложение подключается как удостоверение. DOMAIN\COMPUTER$ и у этой учетной записи есть логин и пользователь в SQL Server, поэтому все работает хорошо.

Я также установил службу Windows .net на том же сервере IIS, который подключается к тому же компьютеру SQL Server. Служба Windows работает как LOCAL SYSTEM и поэтому должен также подключаться как личность DOMAIN\COMPUTER$. Я установил этот же продукт в более чем дюжине разных компаний, обычно все работает так, как я ожидал, но в одном недавнем случае служба Windows не смогла подключиться к базе данных, получив сообщение об ошибке:

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

Есть идеи, почему это будет иметь место для ЛОКАЛЬНОЙ СИСТЕМЫ, а не для СЕТЕВОГО ОБСЛУЖИВАНИЯ? Чтобы обойти это в краткосрочной перспективе, мне пришлось переключиться на использование имени входа в SQL Server, но я бы предпочел использовать интегрированную безопасность, если есть простое решение. В журналах событий безопасности или системных событий не было сообщений об ошибках, хотя я ничего не делал для включения дополнительного журнала.

Обычно я предполагаю, что это какая-то проблема типа Kerberos / AD, и следующие статьи, такие как этот и этот помог бы. Но тот факт, что он работает из NETWORK SERVICE, предполагает, что обычные вещи, которые я проверяю, уже в порядке (например, SPN настроены правильно, а учетная запись домена машины включена для делегирования?). Так какая настройка идет не так?

У меня нет доступа к серверам без помощи ИТ-команды моего клиента, и на сервере установлены другие приложения, которые мне нужно помнить, чтобы не нарушать работу, что делает устранение неполадок немного более деликатным. Приветствуются любые предложения по устранению неполадок!

Вы можете подтвердить, используется ли безопасное соединение NTLM или Kerberos. Если он возвращается к NTLM, соединение будет анонимным.

Существует групповая политика, которая позволяет использовать удостоверение компьютера при использовании NTLM.

Сетевая безопасность: разрешить локальной системе использовать удостоверение компьютера для NTLM
http://technet.microsoft.com/en-us/library/jj852275%28v=ws.10%29.aspx


Дополнительные сведения о настройке SPN для упрощения проверки подлинности Kerberos для вашего SQL-сервера:

http://blogs.msdn.com/b/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx

В частности, обратите внимание на следующее:

SPN для SQL Server состоит из следующих элементов:

  • ServiceClass: определяет общий класс обслуживания. Это всегда MSSQLSvc для SQL Server.
  • Хост: это полное доменное имя DNS компьютера, на котором работает SQL Server.
  • Порт: это номер порта, который прослушивает служба.

    например: MSSQLSvc / myserver.corp.mycomany.com: 1433

Я все еще ставлю на проблему SPN. Не думайте, что они там есть. Проверьте правильность регистрации имен SPN для SQL Server. Также проверьте наличие дубликатов (setspn -x).

Network Service работает, потому что, когда SPN отсутствует, он все равно может вернуться к проверке подлинности NTLM.

Local System не работает, потому что он обращается только к сетевым ресурсам как DOMAIN\Computer$ если он может использовать Kerberos. В противном случае он возвращается к нулевому сеансу, поэтому вы видите Anonymous Logon.