2009-05-06 4 views
17

Я всегда думал, что для подключения к SQL-серверу с использованием проверки подлинности Windows с явно указанными учетными данными вы должны LogonUser, Impersonate, а затем подключиться.База данных + Аутентификация Windows + Имя пользователя/Пароль?

Мне кажется, что this link предполагает, что можно подключиться к SQL-серверу без всякой хлопот, просто указав в строке подключения «uid = ...; pwd = ...». Я тестировал этот метод, чтобы быть уверенным, что он не работает, и - вот и вот - это не так. Если бы этот пост в блоге не был на msdn.com, я бы просто уволил его как болтун, но это так.

Есть ли у кого-нибудь идеи, что мне не хватает?

EDIT1: Многие респонденты неправильно поняли, о чем я говорю. Вот копия/вставка того, о чем я говорил. Это не интегрированного SQL, ни что это ASP.NET олицетворение сделали IIS:

string sql4 = String.Format(
    @"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);  
// Database + Windows Authentication + Username/Password 
+0

это, вероятно, для входа в сервер sql. – DForck42

+0

QUOTING: строка sql4 = String.Format (@ "Источник данных = {0}; Integrated Security = SSPI; uid = ; pwd = ", сервер); // База данных + Аутентификация Windows + Имя пользователя/пароль – galets

ответ

27

Существует два различных вида безопасности с SQL Server. «Аутентификация Windows» и «Аутентификация SQL Server». Когда вы видите uid и pwd, вы видите последнее. Uid в этом случае не является директором Windows - ОС ничего не знает об этом.

Таким образом, ответ на ваш вопрос: нет, вы не можете передать имя пользователя и пароль Windows в строке подключения для входа на SQL Server.

+0

Интегрированная безопасность = SSPI [указывает NT auth]; uid = ; pwd = [указывает sql auth] - оба варианта в одной строке, почему они будут использовать его в этом примере? – galets

+2

Это не пример. Это статья. Пойдите, прочитайте статью, и Вы поймете. –

+0

Yep .. Думаю, я просто не читал статью внимательно :( – galets

3

Это зависит - если вы подключаетесь из командной строки или Winforms приложения прямо на ваш SQL Server, вы либо указать «Integrated Безопасность = SSPI;» а затем использовать ваши учетные данные Windows в качестве учетных данных для входа в систему, или вы укажете «user id = ....; pwd = .....» - но это тогда логин SQL - НЕ ваш вход в Windows.

Вы упоминаете «олицетворять, а затем подключаться» - это, похоже, указывает на ASP.NET - это совсем другая история. Если вы олицетворяете себя, то вы в основном используете учетные данные Windows, например. веб-сервер будет «олицетворять» вас и войти в систему как вы (используя учетные данные Windows). В этом случае, опять же, не нужно указывать «uid = ....; pwd = .....» (если это так, оно будет проигнорировано).

Поскольку указанная вами ссылка четко показывает: если вы можете подключиться напрямую, и вы укажете «Integrated Security = SSPI;», тогда это имеет приоритет над любым uid = ...; pwd = .... который вы можете также указывается и регистрирует использование учетных данных Windows; те дополнительные uid = ...; pwd = .... штуки игнорируются.

Марк

2

Статья и сомнительный пункт относится к безопасности SQL, а не интегрированной безопасности. Вы можете передать учетные данные для пользователя SQL и войти таким образом, если включена проверка подлинности SQL (смешанный режим). Если SQL Server настроен на использование интегрированной безопасности, тогда это не сработает. Он также не будет работать, чтобы разрешить вход в систему с использованием учетных данных для входа в систему Windows.

1

В нашем магазине мы обычно используем строки подключения, как вы описываете. Без проблем. Но ваша база данных SQL Server должна быть настроена для использования безопасности sql, а не для проверки подлинности Windows.

Строка подключения образца (от web.config) в нашем приложении выглядит следующим образом:

<connectionStrings> 
<add name="ConfigurationData" connectionString="server=DevServer; 
database=travel_expense_management_dv;uid=userid;pwd=password!;" 
providerName="System.Data.SqlClient" /> 
</connectionStrings> 

С другой стороны, DBA гуру для нашего магазина поставил меня персональную базу данных на главном сервере, который имел интегрированная безопасность с моим входом в Windows.Мне не нужен uid и pwd, потому что он получил мою информацию аутентификации из контекста.

0

Да, как вы говорите, в статье говорится следующее:

string sql4 = String.Format(@"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);  // Database + Windows Authentication + Username/Password 

Но если внимательно прочитать несколько строк позже, он говорит, что это:

строка sql4 -> Журналы с использованием авторизации Windows, , т.е. имеет приоритет над именем пользователя/паролем.

:)

0

Это очень старый, но, может быть, у кого-то такая же проблема.

Вы можете подключиться с помощью WindowsAuthentication и указав идентификатор пользователя и пароль вашей строке соединения, но не на каждом устройстве. Вы можете достичь этого, например, на устройствах WinCE (https://technet.microsoft.com/en-us/library/aa275613(v=sql.80).aspx).

Я не знаю, можете ли вы сделать то же самое на другой ОС только со строкой соединения (без выполнения действия олицетворения).

Надеюсь, это поможет.

0

только вклад для тех, кто все еще сталкивался с такой проблемой. Основываясь на моем опыте, если вы не укажете какого-либо пользователя/пароля при подключении, он автоматически подключится к db, используя проверку подлинности Windows. Это означает, что он получит идентификатор пользователя и его учетные данные пользователя, который вошел в систему на компьютере. Система позволит вам подключиться к базе данных, если она идентифицирует, что ваш идентификатор пользователя существует/создан в базе данных. Но как только вы укажете свой идентификатор пользователя и пароль в своем подключении, он обойдет проверку подлинности Windows и вместо этого использует аутентификацию SQL-сервера.

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