[ADSI TroubleShoot] 問題解決ステップ (1) "問題はサーバかクライアントのいずれにあるか、それが問題だ"
みなさんごきげんよう。ういこです。
最近チャリ通勤を再開しました。2 年前まではチャリ通勤をしていたのですが、右足が動かなくなるわ、腰が痛いと思ったらぎっくり腰一歩手前といわれるわで断念していたのです。
…というのは公式の理由で、実際には、電動自転車と勝負して負けたのに限界を感じたからだったりします。ちぇ、コーナーでは離せるんだけど、直線がなぁ…。
ちなみに私の愛機は丸石自転車の “ふらっか～ず Como” だったりします。おいおいママチャリなんてお話にならない Yo なんていうそこの君、ママチャリなめちゃダメですよ！！シマノのギアつきで加速は最高ですのよホホホ。
さて、今日の話題は「サーバとの通信がなんだかうまくいかないときの調査の仕方 (※ADSI などアプリケーション対象) 」です。
サーバーとクライアント、どちらの問題であるか問題を切り分ける
1. Network Trace って素敵ですのよ奥様
ネットワークも、10Base-T がすげぇとか言ってた時代も終わり、いまじゃ伝送なんてすごいことになってますよね。それなのに、どーも Active Directory (AD) へ認証オ・ネ・ガ・イ★ って言ってんのにえっらいおっそいということが発生したとします。皆さん、こんなときどうしてますか？
調査の最初のポイントはまず「サーバ側に問題があるのか、クライアント側に問題があるのか切り分ける」ということです。そこで威力を発揮するのがネットワークトレースです。
トレースから、クライアントとサーバのネットワークのやりとりを確認することができます。
たとえば、LDAP Search に対してドメイン コントローラがレスポンスを返してないとか、パケットがロストしたので再送されてるとか、Kerberos の応答パケットがないので同じチケットで再送しちゃってはねられちゃってるとかわかっちゃったりします。
たとえば、クライアント側で変な一般的なエラー（そのエラー番号だけではなんのことやらさっぱり系の大雑把な内容の場合）で途方にくれていると、現象発生時刻にサーバから切断されていたとか、逆にパケットがまったく流れないとかということから内部で何が起こっているかについてより細かく正確に判断することができたりして、なかなか侮れません。
私たちもたとえば、ADSI とかでレスポンス遅いんです！とかお問い合わせをいただくと、最初にネットワーク トレースを取得くださいませとお願いすることが少なくありません。
(※ ネットワーク トレースのとり方は、こちらの記事を参照ください → https://blogs.technet.com/jpilmblg/archive/2009/05/15/adsi-troubleshoot-2-netmon.aspx)
なお、弊社までお問い合わせいただく際は、以下の点を添えてください。
・クライアントとサーバの IP アドレス
・DNS など、間を経由するサーバがいればその IP アドレス
また、IP アドレスを隠したり、フィルタしたログをご提供いただいたりしても、状況把握が遅れたり、調査方針がずれたりするのでそのままの姿を頂きたいなと思います。(機密保持契約書をお出しすることも出来ます)
2. ツールを使っても同じ現象になるか見てみよう
さて、ネットワーク トレースを取っていただいたら、あわせてやってみたいのが、「OS 付属のツール / 管理用ツールなどでも発生するか」という点です。
要は、プログラム固有の現象なのか、それともクライアントが何であれ起きる現象なのかを把握するってことを目的とした検証です。
たとえば、ADSI を使ってユーザを追加しようとしてもうまくいかない！という現象が起こったとします。できないとしたら、dsadd コマンドを使ってもやっぱりだめかな？と試すなどです。
ちなみに、プログラム内でユーザ偽装をしている場合は、ツールやコマンドを使う際にユーザ アカウントを指定しない場合、そのプロセスのユーザアカウントで実行されてしまうという点に注意が必要です。
つまり、実際には認証されているユーザが違うので、比較対象として意味を成しえない可能性があるということです。
たとえば、上述の dsadd などコマンド ラインから実行するツールの動作を比較対象とするとしましょう。この場合は、コマンドプロンプト(cmd.exe) を偽装に使っているのと同じユーザで起動し、その後に dsadd などを行ってみる、というアクションが必要になります。
結果が同じであれば、サーバ側の問題の可能性が高いです。ツールではおきない場合は、プログラムの設定がサーバの動作に影響しているかなどをさらに判断するデバッグ作業などを行うことになりますが、それはまたの機会にご紹介させていただきます。
おまけ : RunAs ってなによ？
はてはて、上で出てきた RunAs。あらたに配属された新人の皆様など、耳慣れない方もいらっしゃるかと思いますので、ちょっと説明させてくださいです。
RunAs は、現在ログオンしているユーザと違うユーザでプログラムを実行するための手段です。RunAs がよく使われそうな場面としてはこんな感じでしょうか。
・自分管理者だけど、普段からドメインの Administrator 権限で PC の作業し続けるのってなんかやらかしちゃいそうで怖い
・でも、自分の使ってるメインマシンからドメインの管理できちゃったらいいな★
お気に入りの URL のたっぷり詰まった、開発環境やツールもマイカスタマイズ完了な愛機ちゃんは、ドメインの非管理者ユーザで普段はログイン、だけどドメインの作業するたびにリモートデスクトップとか超面倒ということもありません？そんなとき RunAs がイケてますのよ奥様。
こんな風につかいます。
> runas /user:<偽装したいID> <動かしたいプログラム>
実際に例を見てみましょう。たとえば、fareast\uikou でログオンしてるセッション上で fareast\shinichw で コマンドプロンプト (cmd.exe) を起動したいわという場合は、こんな風になります。
runas /user:fareast\shinichw cmd.exe
◆コマンド プロンプトからさらにコマンド プロンプトを呼んじゃったぞな感じ
◆[ファイル名を指定して実行] に直で Runas コマンドを打ち込んじゃった場合 (vista だと、スタート メニューの ”検索の開始“ でも OK。
パスワードを入れてほしいとおねだりされるので、激しく指定してやって認証が通ればこっちのモンです。以下はついに fareast\shinichw で起動できちゃったところです。さて、何をしてやろうかなフフフフフ。(メニューバーに注目！)
では、これがなぜうれしいか？
なんと、RunAs で起動したプロセスの子プロセスも指定したユーザで動くですよ。つまり、Runas で起動したアプリおよびその子プロセスから認証をつなぎにいくと、認証に RunAs で指定したアカウントが使われるということです。おお～便利。
ちなみに、RunAs で直接起動したプロセスは、↑にあるように、つつましく「私、ここの中で別のユーザで起動されちゃってます★」と言わんばかりにメニューバーに実行ユーザが書いてありますが、子供プロセスにはかいてません。見た目じゃわかんないですね。こういうときはタスクマネージャで一発確認してあげれば誰の子供なのかわかるんですよ。便利！
以下の例では、fareast\shinichw で起動した cmd.exe から、notepad.exe、windbg.exe、mspaint.exe、ldp.exe を起動したところです。
タスクマネージャのユーザのところを見ると、確かに shinichw とありますね。つまり、この子プロセスはちゃんと RunAs で fareast\shinichw で起動したコマンド プロンプトと同じく、fareast\shinichw が使われているということがわかります。
そのほかはすべて uikou ですね。この cmd.exe から起動される子プロセスでもし、認証する処理を持つものがある場合は、認証に fareast\shinichw が使われることになります。
RunAs でユーザをかえて同じ端末上で検証する、というのも認証関連系の案件の場合は非常に有効です。プログラムの問題か、認証につかわれるアカウントの問題かなどがわかりますから。
その他、サーバかクライアントかいよいよわからなくなった場合は、ドメイン コントローラの LDAP ログレベルをあげてイベントをみるというのも有効です。設定したサーバの負荷が高くなっちゃうのが難点ですが、サーバの「内部」で何がおこっているかが細かく把握できるという高いメリットがあるのも事実です。
これについてはお父さんの以下の記事が参考になるかとおもいますです。
Dsadd などコマンド ラインについては以下をご参照くださいませ。
それではまた～。
～ ういこう@通勤時のおしりの痛さに人間サスペンションの限界を感じる今日この頃 ～