У меня есть приложение asp.net, которое должно получать доступ к данным с двух серверов SQL. Один из SQL-серверов находится на том же компьютере, что и IIS (назовем его SQLSERVER1), тогда как другой SQL-сервер находится на другом компьютере (SQLSERVER2).
Строки подключения являются доверенными для обоих серверов SQL. В моем файле web.config для олицетворения установлено значение true. Я использую проверку подлинности Windows как в IIS, так и в web.config.
Когда я пытаюсь получить доступ к данным из SQLSERVER2, я получаю ошибку входа в систему из-за ошибки пользователя (null). Пользователь, через которого я вошел в систему через Windows, существует как учетная запись SQL-сервера в SQLSERVER2.
В чем может быть возможная причина?
ПРИМЕЧАНИЕ:Это вопрос новичка ИМХО.
ПРИМЕЧАНИЕ. Используемый IIS - 6.0 (Windows 2003). Он не установлен в режим изоляции IIS 5.0.
Обновлено: пользователь, выдающий себя за другое лицо, является пользователем домена
Добавление:
Я также хочу заявить, что я получаю это сообщение об ошибке, когда обращаюсь к нему как к клиенту сервера, на котором работает IIS. Другими словами, позвольте мне сказать, что я работаю на машине A, IIS и SQLSERVER1 находятся на машине B, а SQLSERVER2 - на машине C.
Я не получаю это сообщение об ошибке, когда работаю на машине B. Это меня еще больше ставит в тупик.





Вы, вероятно, столкнулись с этой проблемой, потому что олицетворение не на основе Kerberos (NTLM) действует только на локальном компьютере (веб-сервере). Если вы хотите иметь возможность использовать эти учетные данные для доступа к другому компьютеру, вам необходимо убедиться, что вы используете Kerberos.
Попробуйте это: http://support.microsoft.com/kb/810572
Ваша аутентификация на веб-сервере не передается на сервер sql. Веб-сервер аутентифицируется на SQL Server, используя учетную запись, под которой работает ваш пул приложений.
Почему это так? При олицетворении в потоке следует использовать токен безопасности пользователя, который должен информировать SSPI-соединение с SQL-сервером.
@anthonywjones - см. ответ @yadyn .. он более подробный, чем то, что я мог придумать :)
Вы должны убедиться, что учетная запись компьютера для SQLSERVER1 является доверенным для включения делегирования. В противном случае SQLSERVER2 не будет доверять олицетворению, запущенному на SQLSERVER1. Это в дополнение к подтверждению того, что Kerberos используется в первую очередь для настройки олицетворения. Это также предполагает, что все серверы и пользователи являются членами одного домена.
Кстати, вы уверены, что хотите сделать что-то таким образом, в конечном итоге вы создадите намного больше соединений, потому что они в конечном итоге будут уникальными для пользователя?
Это абсолютно проблема делегация. Как заметил один человек, вам нужно убедиться, что используется аутентификация Кереберос. Старый стиль NTLM его не сокращает. Подробнее о Kerberos против NTLM.
Вкратце, если у вас есть веб-сервер и база данных, и вы хотите, чтобы веб-сервер олицетворял пользователя при выполнении запросов к базе данных (чтобы вы могли настраивать разрешения для базы данных непосредственно для каждого пользователя или группы пользователей), вы: повторное выполнение двойного прыжка. Учетные данные должны сначала пройти с компьютера пользователя на веб-сервер и снова в базу данных. Как вы понимаете, база данных должна доверять веб-серверу, чтобы «не делать зла», иначе это может быть чрезвычайно опасной дырой в безопасности. В результате вам нужно настроить то, что в мире Windows Server называется "делегация" ...
У Microsoft есть хорошая статья обо всем этом здесь. Кроме того, вы можете просмотреть статью типа это, чтобы получить представление о том, как все это настроить. Мы часто сталкиваемся с этим, и поначалу это может быть неприятно, тем более что как разработчик вы, вероятно, не контролируете серверы напрямую (особенно производственные), и вам придется проводить много времени с серверные парни в коридоре.
Вы пытались получить доступ к базе данных на server2 с помощью администратора SQL SErver с Server1 и установили успешное соединение?
В противном случае это могло быть связано с тем, что по умолчанию SQL Server устанавливает себя с отключенным по умолчанию tcp.
Вам нужно будет убедиться, что он включен для server2, чтобы сервер server1 мог подключиться. server1 не имеет проблем с подключением, потому что он может использовать соединение с общей памятью.
Я могу подключить SQLSERVER2 с помощью Enterprise Manager из SQLSERVER1
Является ли пользователь, которого олицетворяют, пользователем локальной машины (созданным на обеих машинах) или пользователем домена?