社内のユーザーから業務で使用しているプログラムでエラーが出るとの連絡
エラーメッセージを確認すると以下のようなもの
◆初期対応
新規にユーザーを作成し、元々のユーザーのプロファイルが使用していた
ファイルのリソースをコピーして使用してもらった経緯がある
とりあえず調査と言う訳で、以下のような順番で状況を調べてみる
① サーバーのIPアドレスでPingの確認
⇒ 正常
② サーバーのホスト名でPingを発信
⇒ これまた正常
③ サーバー側のSqlServerは生きているか
⇒ 問題なく稼働中
④ 他の端末からは接続できるか?
⇒ こちらも問題なし
⑤ 問題の端末から別のSqlServerを利用するプログラムは動くか?
⇒ 正常に接続できる
結果、この端末から特定のSqlServerへの接続だけが出来ない状況と判断
◆環境
ちなみにクライアントとサーバーの構成は大体以下の通り
クライアント
OS : Win XP SP3 プログラムは VB6 で作成
サーバー
OS : Win7 SP1 , SQLSERVER 2000 SP4 名前付きパイプ で待ち受け
クライアントとサーバーは、ワークグループ環境で運用している
◆悪戦苦闘
ここからMDACの最新版を入れたり、Windows Update で最新の修正モジュールを入れたりと
まぁそれなりに色々とやってみたが、全く改善せず
◆パケットキャプチャで意外な原因判明
何をやっても改善しないので、最終手段でクライアントに「WireShark」をインストールして
実際にどんなパケットがやり取りされてるかを確認してみる
すると、以下の通り思いもしないパケットが表れた
何故か「SMB」のパケットがずらっと並ぶ
結局「NTLM」の認証を行おうとして失敗しているようにしか見えない
で、黒く隠したユーザー名のところをみると、この端末で新規に作成したアカウント名が表示
よくよく考えると、サーバー端末にはこのアカウントは作成していない
で、試しにクライアントと同じユーザー名/パスワードのアカウントを作成して
もう一度プログラムを起動してみると......
あっけなく、接続に成功
◆結論
まさかSQLSERVERに接続するときに NTLM認証を行っているとは思いもしなかった
でも、名前付きパイプもサーバー側の共有リソースとして管理しているから
そのリソースにアクセスする際に共有フォルダアクセスと同様の認証が入っても
後から考えれば不自然でもないのかも知れない
ややこしいので、サーバー側の接続設定を「TCP/IP」にすることも検討してみることにします
まぁ、とにかく一件落着
0 件のコメント:
コメントを投稿