2008-10-10 3 views
3

У меня есть приложение asp.net, которое должно обращаться к данным с двух SQL-серверов. Один из SQL-серверов присутствует на том же компьютере, что и IIS (назовем его SQLSERVER1), тогда как другой SQL-сервер присутствует на другом компьютере (SQLSERVER2).Проблемы с аутентификацией Windows с использованием asp.net

Строки подключения доверяют как для SQL-серверов. В моем файле web.config значение олицетворяется true. Я использую проверку подлинности Windows как в IIS, так и в web.config.

Когда я пытаюсь получить доступ к данным из SQLSERVER2, я получаю логин с ошибкой для ошибки пользователя (null). Пользователь, через который я вошел в систему через Windows, существует как учетная запись SQL-сервера в SQLSERVER2.

В чем может быть причина?

ПРИМЕЧАНИЕ:Это вопрос новичков IMHO.

ПРИМЕЧАНИЕ: IIS используется 6.0 (Windows 2003). Он не настроен на режим изоляции IIS 5.0.

EDIT: Пользователь получение олицетворением является пользователем домена

Дополнение

Я также хочу заявить, что я получаю сообщение об ошибке, когда я получить доступ к нему в качестве клиента из сервер, на котором работает IIS. Другими словами, позвольте мне сказать, что я работаю на машине А, IIS и SQLServer1 находятся на машине B, и SQLSERVER2 на машине С.

Я не получаю сообщение об ошибке, когда я работаю на машине B Это меня больше утомляет.

+0

Является ли пользователь, выдающий себя за пользователя локальной машины (созданного на обеих машинах) или пользователя домена? – Darksider 2008-10-10 12:08:06

ответ

3

Возможно, вы столкнулись с этой проблемой, поскольку олицетворение на основе не-Kerberos (NTLM) действует только на локальной машине (веб-сервере). Если вы хотите использовать эти учетные данные для доступа к другой машине, вам нужно будет убедиться, что вы используете Kerberos.

Попробуйте это: http://support.microsoft.com/kb/810572

0

Ваш аутентификации на веб-сервер не передается через сервер SQL. Веб-сервер аутентифицируется на SQL Server, используя учетную запись, в которой работает пул приложений.

+0

Почему это так? При олицетворении в потоке следует использовать токен безопасности пользователей, который должен информировать SSPI-соединение с SQL-сервером. – AnthonyWJones 2008-10-10 12:50:37

+0

@anthonywjones - см. Ответ @yadyn .. он более тщательный, чем я мог бы придумать :) – 2008-10-10 15:42:22

0

Необходимо проверить, что учетная запись машины для SQLSERVER1 доверена для делегирования. В противном случае SQLSERVER2 не будет доверять олицетворению, выполняемому на SQLSERVER1. Это в дополнение к подтверждению того, что Kerberos используется для настройки олицетворения в первую очередь. Это также предполагает, что серверы и пользователи являются членами одного и того же домена.

BTW, вы уверены, что хотите так поступать, в конечном итоге вы создаете гораздо больше соединений, потому что они в конечном итоге являются уникальными для пользователя?

7

Это абсолютно Делегация проблема. Как указал один человек, вам необходимо убедиться, что используется аутентификация Kereberos. Старый стиль NTLM не собирается сокращать его. Вот еще на Kerberos vs. NTLM.

В двух словах, если у вас есть веб-сервер и база данных, и вы хотите, чтобы веб-сервер выдавал себя за пользователя при выполнении запросов к базе данных (чтобы вы могли настраивать разрешения для базы данных непосредственно для каждого пользователя или группы пользователей), вы выполняете двойной прыжок. Учетные данные должны проходить сначала с компьютера пользователя на веб-сервер и снова в базу данных. Как вы можете себе представить, база данных должна доверять веб-серверу, чтобы «не делать зла», или это может быть чрезвычайно опасная дыра в безопасности. В результате вы должны настроить то, что вызывается в мире Windows Server «Делегация» ...

У Microsoft есть хорошая статья обо всем этом here. Кроме того, вы можете просмотреть статью, например, this, чтобы получить представление о том, как настроить все. Мы часто сталкивались с этим, и сначала это может быть больно, тем более что, поскольку разработчик, вероятно, не контролирует серверы напрямую (особенно производственные), и вам придется потратить много времени на ребята-серверы по коридору.

0

Вы пытались получить доступ к базе данных на сервере2 с помощью администратора SQL SErver с Server1 и сделали успешное соединение?

Если нет, это может быть вызвано тем, что по умолчанию SQL Server устанавливает себя с отключенным tcp по умолчанию.

Вам нужно будет убедиться, что это включено для сервера2, чтобы сервер 1 мог подключаться. У сервера 1 нет проблем с подключением из-за того, что он может использовать соединение с общей памятью.

Смежные вопросы