明示的に指定された資格情報を使用してWindows認証を使用してSQLサーバーに接続するには、LogonUser、Impersonate、次に接続する必要があるといつも思っていました。
this link は、接続文字列で「uid = ...; pwd = ...」を指定するだけで、この面倒な作業なしでSQLサーバーに接続できることを示唆しているようです。私はこの方法をテストして、それが機能しないことを確認しました-驚いたことに-機能しませんでした。そのブログ投稿がmsdn.comになかった場合、私はそれをnoobトークとして却下しただけですが、それは事実です。
私が何を欠いているのか誰かが誰か知っていますか?
EDIT1:多くの回答者が、私が言及していたことを誤解しました。ここに私が話していた内容のコピー/貼り付けがあります。これは統合SQLではなく、IISによって作成されたASP.NET偽装でもありません。
string sql4 = String.Format(
@"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server);
// Database + Windows Authentication + Username/Password
SQL Serverには、2種類の異なるセキュリティがあります。 「Windows認証」および「SQLサーバー認証」。 uidとpwdが表示されている場合は、後者が表示されています。この場合のuidはWindowsプリンシパルではありません-OSはそれについて何も知りません。
したがって、質問の答えはnoです。Windowsユーザー名とパスワードを接続文字列に渡してSQL Serverにログインすることはできません。
状況によって異なります。コマンドラインまたはWinformsアプリから直接SQL Serverに接続する場合は、 "Integrated Security = SSPI;"を指定します。 OR指定した「ユーザーID = ....; pwd = .....」-Windows資格情報をログオン資格情報として使用しますが、これはSQLログオンです-Windowsではありませんログオン。
あなたは「偽装して接続する」と言及します-これはASP.NETを示しているようです-これもまたまったく別の話です。偽装する場合は、基本的にWindows資格情報を使用しています。 Webサーバーが "偽装"し、(Windows資格情報を使用して)ログオンします。その場合も、「uid = ....; pwd = .....」を指定する必要はありません(指定されている場合は無視されます)。
あなたが言及したそのリンクが明確に示しているように-直接接続でき、 "Integrated Security = SSPI;"を指定した場合、これは指定した可能性のあるuid = ...; pwd = ....よりも優先され、ログに記録しますWindows資格情報を使用している。これらの余分なuid = ...; pwd = ....ピースは無視されます。
マーク
問題の記事とポイントは、統合セキュリティではなく、SQLセキュリティに関するものです。 SQL認証(混合モード)が有効になっている場合は、SQLユーザーの資格情報を渡し、この方法でログインできます。 SQLサーバーが統合セキュリティのみを使用するように設定されている場合、これは機能しません。また、Windowsログオン資格情報を使用してログインすることもできません。
はい、あなたが言うように、記事はこれについて言及しています:
string sql4 = String.Format(@"Data Source={0};Integrated Security=SSPI;uid=<uid>;pwd=<pid>", server); // Database + Windows Authentication + Username/Password
しかし、後で数行を注意深く読むと、次のようになります。
文字列sql4-> Windowsログインでログインします。ユーザー名/パスワードよりも優先されます。
:)
これは非常に古いですが、多分誰かが同じ問題を抱えています。
君は できる を使用して接続する WindowsAuthentication そして 接続文字列でユーザーIDとパスワードを指定するが、すべてのデバイスに搭載されているわけではありません。たとえばこれを達成できます winCE デバイス( https://technet.Microsoft.com/en-us/library/aa275613(v = sql.80).aspx )。
他のOSで接続文字列だけを使用して(偽装を行わずに)同じことができるかどうかはわかりません。
それが役に立てば幸い。
当店では、ご説明のとおり接続文字列を日常的に使用しています。問題ありません。ただし、SQLサーバーデータベースは、Windows認証ではなくSQLセキュリティを使用するように設定する必要があります。
アプリのサンプル接続文字列(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は必要ありませんでした。
まだこのような問題が発生している一部の人にも貢献しただけです。私の経験に基づくと、接続でユーザー/パスワードを指定しない場合、Windows認証を使用して自動的にデータベースに接続します。つまり、ユーザーIDを取得し、マシンにログオンしたユーザーの資格情報を取得します。システムは、ユーザーIDがデータベース内に存在または作成されていることを識別した場合に、データベースへの接続を許可します。ただし、接続でユーザーIDとパスワードを指定すると、Windows認証がバイパスされ、代わりにSQLサーバー認証が使用されます。