3

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

ただし、Vista に切り替えてから、SSMS を DMZ ドメインのサーバーに接続しようとすると、「ユーザーのログインに失敗しました」というメッセージが表示されます。ユーザーは、信頼できる SQL Server 接続に関連付けられていません。 既定の TCP/IP の代わりに名前付きパイプを使用するように接続オプションを変更すると、キャッシュされた資格情報が送信され、すべて正常に動作します。これは、Windows ファイアウォールがオフであるかオンであるかに関係なく、TCP/IP または名前付きパイプを介して、内部ドメイン (私の開発用 PC が属しているドメインと同じドメイン) 内のサーバーへの接続が正常に機能する場合に当てはまります。

回避策としてこれらの接続に名前付きパイプを使用することはあまり気にしませんが、TCP/IP が推奨される接続方法のようであり、期待どおりに機能しない理由を理解できないのは好きではありません。何か案は？

4

3 に答える 3

1

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

このシナリオでは、クライアントが tcp 接続を行う可能性があり、加えて、SPN が登録されているかどうかに関係なく、ローカル管理者または非管理者のコンピューター アカウントで実行されている場合、クライアントの資格情報は明らかに SQL Server によって認識されません。

ここでの回避策は次のとおりです。

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

詳しく説明しましょう：

両方のワークステーションで同じ NT アカウント (usr1 と呼びましょう) を作成すると、基本的に接続ステーションのローカル アカウントに接続して偽装します。つまり、ステーション 1 からステーション 2 に接続すると、ステーション 2 のアカウントを介して認証されます。したがって、SQL Server の起動アカウント (ステーション 2 で実行されていると仮定します) をステーション 2 の usr1 に設定すると、ステーション 1 の usr1 ログインでステーション 1 から SQL に接続すると、SQL はステーション 2 の usr1 としてユーザーを認証します。

これで、SQL 内で確実に station1 のリソースにアクセスできるようになりました。ただし、どの程度のアクセスがステーション 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から取得

于 2008-10-04T14:49:29.250 に答える
0

これは、Vista がほとんどのアプリケーションを他のアプリケーションから分離して実行するためだと思います。

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

于 2008-09-03T06:46:32.200 に答える
0

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

于 2008-08-25T14:16:34.060 に答える