現在のコンピューターログインアカウントとは異なるWindowsアカウントを使用してDSN(ODBCからSQL Server)を作成する可能性はありますか? SQL ServerへのシステムDSNを作成しようとしていますが、管理者アカウントを使用してWindows認証を使用してこの接続を作成したいと思います。通常のWindowsアカウントを使用してこのDSNを作成しています。
定義上、システムDSNは、使用されているログオンアカウントに関係なく、コンピューター全体に適用されます。したがって(質問を正しく読んでいる場合)、(1)答えは「はい」であり、(2)管理者が必要です。 DSNを作成する権限。
ちなみに、DSNのない接続として見たことがありますか?これらは要件にはるかに適していると思います。また、アプリを使用する前にクライアントを構成する必要がなくなります。
「runas」コマンドを使用して、通常のアカウントでログインしているときに、管理者アカウントでODBC Data Source Administratorを起動することもできます。これにより、「」を受信せずに接続を構成およびテストできます。ユーザーは信頼できるSQL接続に関連付けられていません」エラー。
コマンドプロンプトコマンドの例を次に示します。
runas /netonly /user:domain\adminusername "C:\Windows\System32\odbcad32.exe"
ジミーが言ったように、DSN定義は管理者アカウントに関連付けられませんが、後で接続を使用するときにログインしたWindows認証アカウントを使用します。 (したがって、管理者アカウントでログインしていない限り、接続を使用したプログラムを起動するには、「runas」を再度使用する必要があります。)
はい、これは間違いなくODBC接続をセットアップするために機能し、しばらくの間は機能します。おそらくKerberos認証がアクティブである限り、機能します。残念ながら、Macの回答に追加します。 、これはシステムDSNに使用する永続的な認証ではありません。odbcad32.exeの起動に使用するバッチファイルは次のとおりです。
Net Use \\dbserver-Host /user:DOMAIN\username
runas /netonly /user:DOMAIN\username C:\Windows\syswow64\odbcad32.exe
これにより、2回ログインするように求められる可能性がありますが、runas自体よりも一貫して機能しているようです。
Windows CredentialManagerの使用は非常にうまく機能することがわかりました。 Windows資格情報を直接追加できます。秘訣は、ポートを含む完全修飾ドメイン名と、ドメイン修飾子を含む完全なActive Directoryユーザー名を持っている必要があるため、mydb.myinternaldomain.com:1433
やmyinternaldomain\myusername
などのパスワードを使用することです。次に、mydb.myinternaldomain.com
をODBCソースとして追加すると、Windowsは適切な資格情報を魔法のように交換します。これはSQL Server ManagementStudioでも機能します。
Windows以外のネイティブアプリでは機能しないようですが、それでもルーン文字が必要です。
私はこれを行う能力があるとは思わない。 SQL Serverへの信頼できるNT接続を使用するということは、サーバーへの認証中にパスワードが送信されず、既存のNTトークンが認証に使用されることを意味します。つまり、SQLServerはNT認証を「信頼」します。接続時にログインしているユーザーを使用します。