キャッシュされた資格情報を使用してドメイン境界を越えてSQL 2005に接続する

Question

SSMSのようなクライアントツールからDMZアクティブディレクトリドメイン内のSQL Serverに接続することは以前からVistaに移行して以来、 。 XPでは、サーバー上で何らかの方法で認証されていれば（たとえば、\ server.dmzdomain \ c $にエクスプローラを誘導し、有効なクレジットをログインプロンプトに入力するなど）、SSMSはこれらのキャッシュされた資格情報を使用して接続します。

しかし、Vistaに切り替えてから、DMZドメイン内のサーバーにSSMSを接続しようとすると、メッセージが表示されます。ユーザー 'にログインできませんでした。ユーザーは、信頼できるSQL Server接続に関連付けられていません。既定のTCP/IPの代わりに名前付きパイプを使用するように接続オプションを変更すると、キャッシュされた資格情報が送信され、すべて正常に動作します。これは、Windowsファイアウォールがオフまたはオンで、内部ドメイン（my dev PCと同じドメイン）内のサーバーへの接続がTCP/IPまたは名前付きパイプで正常に動作するかどうかです。

回避策として、これらの接続に名前付きパイプを使用しても大したことはありませんが、TCP/IPが推奨される接続方法であると思われます。 。何か案は？

Answer 1

昇格モードでSSMSを実行しようとしましたが、クライアントに最新のSPがインストールされていますか？

Answer 2

これは、Vistaがほとんどのアプリケーションを別のアプリケーションと区別して実行しているためです。

内部ドメインのユーザー名とパスワードに合わせてDMZのユーザー名とパスワードを設定するか、名前付きパイプを使用して接続することをお勧めします。

Answer 3

"ユーザーのログインに失敗しました。ユーザーは信頼できるSQL Server接続に関連付けられていません"。

このシナリオでは、クライアントはtcp connetionをローカル管理者または管理者以外のマシンアカウントで実行することができますが、SPNが登録されているかどうかにかかわらず、クライアント資格情報は明らかにSQL Serverによって認識されません。

回避策はここにある：

は、ターゲットSQL Serverマシン上で同じパスワードを使用してクライアントマシン上のものと同じアカウントを作成し、アカウントに適切な権限を付与します。

はのは、より詳細に説明しましょう：あなたは、両方の のワークステーション上（のは、それをUSR1呼びましょう）同じNTアカウントを作成するときは、基本的に 接続駅のローカルアカウントを

接続し、偽装します。あなたがステーション1からステーション2に接続すると、 ステーション2のアカウントで認証されています。したがって、 SQL Serverの起動アカウント（ステーション2で実行されていると仮定します）を のstation2のusr1に設定すると、ステーション1のusr1 ログインでステーション1からSQLに接続すると、SQLはステーション2のusr1として認証します。

ここで、SQLでは、確実にステーション1のリソースにアクセスできます。ただし、どのように多くのアクセスが はステーション1のusr1権限に依存しますか。

これまでSQLでは、 SQL Server内のsysadminロールの一部であるユーザーのみが処理されます。他のユーザー（非sysamdin）がネットワークリソースにアクセスできるようにするには、 プロキシアカウントを設定する必要があります。詳細は の記事をご覧ください。 から取られるhttp://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx