みなさんごきげんよう。ういこです。
昨日は TechFielders の集い特別編、「Tech Fielders の集い 特別編 － おかげさまで Active Directory 10 周年」が弊社新宿オフィス（通称 OST）で開催されました。 今回私たちのチームで受け持ったセッションのテーマは、「ADSI のトラブル解決のつぼ」でした。文字通りですが、ADSI あるいは .NET Framework System.DirectoryServices 名前空間 (通称 S.DS) を使ったプログラムのトラブルシューティングです。ちなみに、AD の環境面（プログラミング固有ではない部分）などは、ひとつ前の "4. Active Directory よくある質問 （Active Directory サポートエンジニア 北川、渡會）" で AD サポートチームがセッションを持っていました。集いについての記事は以下です！
[閑話休題] “Tech Fielders の集い 特別編 － おかげさまで Active Directory 10 周年” に参加しました！ver 1.0 (1) http://blogs.technet.com/jpilmblg/archive/2010/02/28/tech-fielders-active-directory-10-ver0-1.aspx
お陰さまですべてのセッションの中で一番シンプルというか簡素な出来の PowerPoint でしたが、なぜかご好評を頂いたようで…というか、背景が気になってセッションに集中できなかった皆さまや、ご来場いただけなかった皆さまに、セッション内容を簡単に紹介させていただきます。
【セッション概要】 ADSI を使ったプログラムを動作させた際に直面する問題の解決のために取るアクションの流れです。
1. 問題解決のアプローチ方法を検討する 2. 発生事象の把握と調査シナリオを検討する
【問題解決へのプロセス（環境か？実装か？あるいは両方か？）】 1. 問題解決のアプローチ方法の検討 問題の解決を実施するにあたり、まず確認すべきは以下の 3 つのポイントです。
(1) 状況把握 いつ、どこで、何が、どうなったか？ 正常時と何が違うのか？ (2) 情報収集 現象再現による事実確認 異常動作の痕跡、正常時動作結果の採取 (3) 問題分析 既存事例との関連性、正常時動作との差分比較 エラー情報、監査結果による原因推測 ログ/ネットワークパケット／ダンプ解析(※) (※) 開発案件の担当ですので、上位サポート契約などでは、プログラムのダンプ解析や、ライブデバッグなども実施します。
2. 発生事象と調査シナリオ(1) 上記の 1. のポイントを把握したら、次に生事象の特性を見極めます。 これら特性により調査シナリオが異なっていきます。
・プログラミングの依存性有無 ・動作環境/構成への依存性有無 ・再現性、再現頻度の有無
3. 発生事象と調査シナリオ(2) プログラミング依存の症状と思われる場合は、以下の部分などを疑ったり、確認してみます。
・コーディング依存による事象 ＞ マルチスレッド非対応（ADSI は、残念ながらマルチスレッドには対応していない部分があります。） ＞ ポート枯渇 (セッションごとにポートを使うので、バッチやプログラムで大量オブジェクトを扱う場合、TIME_WAIT からのリサイクルが間に合わず枯渇する場合があります) ＞ プログラミング障害 (プログラムの実装に問題があるなど)
・API 実装による事象 ＞ バージョンによる API 実装差異 ＞ API 実装障害
・パフォーマンス依存による事象（プログラミング動作パフォーマンス） ＞ プログラミング実装障害
4. 発生事象と調査シナリオ(3) 一方、環境/構成依存の症状と思われる場合（プログラムに依存する可能性が低そうな場合など）、以下の点を確認してみます。 ・名前解決関連動作依存 ＞ DNS 構成依存 (FQDN で解決できるか？IP アドレス直打ちで状況が変化するか？) ＞ NetBios 名前解決依存 (NetBIOS 名ではつながるか？)
・認証関連動作依存 ＞ 信頼関係設定 ＞ ダブルホップ問題（ASP / ASP.NET などで、ドメイン コントローラとの間に IIS が入る場合など）
・パフォーマンス依存(サーバ/ネットワークパフォーマンス） ＞ サーバダウン ＞ ネットワーク障害 (回線が細い、伝送効率が悪く、パケットロスが生じるなど。再リクエストによる kerberos リプレイキャッシュ攻撃扱いなど)
4. 発生事象と調査シナリオ(3) 再現性、再現頻度の低い事象の場合、以下の点などに着目します。 ただし、再現性がない調査などの場合、既存痕跡のみでの、事象調査となることになります。代替対応として、次回事象発生時に向けた情報採取を検討し、回答あるいは再現性の確保を継続検討いただくことになることが少なくありません。
・動作タイミング依存 ・長期稼働による低再現事象 ・パフォーマンス依存（高負荷）
5. 発生事象と有効な情報採取方法(1) プログラミング動作依存と思われる場合は以下の情報を確認します。
・統合開発環境での動作トレース ・検証サンプル(スクリプト)での再現事象の簡素化。.NET Framework のプログラムの場合、VBScript で直接 ADSI を呼んで動作が変わるか、など。動作が変われば、.NET Framework のクラスの問題の可能性があるが、動作が変わらなければ実装に依存しない現象の可能性が高くなります。
・デバッグコード挿入による動作ログ採取 ・ダンプ、ライブデバッグ ・MPSReport ・イベントビューア ・ネットワークモニター
6. 発生事象と有効な情報採取方法(2) 動作環境/構成依存の症状と思われる場合は、以下ツールなどでの事象再現有無を検証します。もし、これらのツールでも同じ現象が発生すれば、実装面ではなく、環境面（上記 4. など) を確認します。
・Active Directory ユーザとコンピュータ(ADUC) ・DSQuery、DSAdd コマンド ・ADSI Edit ・LDP.EXE ・MPS Report ・イベントビューア ・ネットワークモニタ ・NsLookup ・NetStat ・RepAdmin
7. 発生事象と有効な情報採取方法 厄介なのは、再現性、再現頻度の低い事象の場合です。問題の本質が何か、またどういった事象なのか（特にエラーコードが一般的なものであった場合など）を正確に把握しないと、調査方針が散漫になり、ぶれてしまい結局本質からどんどんずれてしまうことがあります。こうした場合は、再現頻度や、再現条件の確保などを行うことを第一にすることで結果的にトータルの調査コスト（時間、人的リソース、Labor など）をセーブできることが少なくなりません。
・MpsReport ・イベントビューア ・デバッグコード挿入による動作ログ採取 ・ダンプ採取
【参考事例】 1. 問題事象と解決例－１ 現象 ADSI にて大量のオブジェクトを操作するとエラー(0x80072020)となる
調査方針 ポート枯渇の可能性がある。事象発生時のポート使用量を NetStat コマンドにて確認する ADSI にて、大量オブジェクトを扱うために LDAP サーバーに大量にコネクションを張っている可能性があり、一時ポートの空きがなくなる可能性がある。
調査結果 LDAPアクセスにより、TIME_WAIT状態の大量の一次ポート使用が認められた（現象再現中の netstat コマンド実施、MPS report を再現中に取得するなどで確認可能。）
Proto Local Address Foreign Address State … (省略) … TCP 192.168.0.111:2051 192.168.0.10:389 TIME_WAIT TCP 192.168.0.111:2052
192.168.0.10:389 TIME_WAIT TCP 192.168.0.111:2053 192.168.0.10:389 TIME_WAIT … (省略) …
対処方法 MaxUserPort 値を増やす、または TcpTimedWaitDelay 値を短くする設定を行う
＞ MaxUserPort 値 割り当て可能な一時ポートの限界を設定します。既定は 5000 です。OS は既定では一時ポートとして 1025 番から 5000 番を使用します。この値を変更しない状態で1025 ～ 5000 番を使い切った場合、ポート枯渇が起こる可能性があります。
＞ TcpTimedWaitDelay 値 TCP 接続終了プロセスが完了した (TIME_WAIT 状態の) ポートが再度利用可能になるまでの時間です。既定では 240 秒 = 4 分です。全てのポートが TIME_WAIT 状態になると接続が出来なくなりますので、短時間に大量に接続、切断が行われるような処理においてはTIME_WAIT の時間を短くすることでポートのリサイクルが迅速に行われるため、一時ポートを大量に使用する処理を行うことが事前にわかる場合はこちらの値を設定いただくことが有効です。ただし、処理を自動化し、一気に一時ポートを使い切るようなことも考えられますので、上述の MaxUserPort 値を拡張し、割り当て可能な一時ポート数を増やすこともあわせて行うことが現実的な対処としては良いでしょう。また、帯域の状態なども確認することをお勧めします。
参考 [ADSI TroubleShooting] : 大量のユーザ登録処理とかを一気に行うとポート枯渇が起きる http://blogs.technet.com/jpilmblg/archive/2009/03/27/adsi-troubleshooting.aspx
[ADSI] セッションの張り方に伴う一時ポートの使われ方 ～ 同じ関数の組み合わせでも順序などで使われ方が変わる ～ http://blogs.technet.com/jpilmblg/archive/2009/04/10/ADSI_2D00_Session_5F00_and_5F00_Dynamic_5F00_Port.aspx
2. 問題事象と解決例－２ 現象 ADsOpenObject(OpenDsObject)が特定の DC に対して失敗する。
調査方針 DSQuery コマンドにより、対象 DC のオブジェクト参照が可能か確認するとともに、対象DCの IPアドレスを明示した場合の成否を確認し、名前解決の可否を確認する
調査結果 DSQueryでも同様の事象になり、IPでは接続できる状況から、DNS名前解決の問題と考えられる
対処方法 NslookupでDNS設定を確認し、必要なSRVレコードを設定する
文書番号: 816587 - 最終更新日: 2007年12月3日 - リビジョン: 7.2 ドメイン コントローラの SRV DNS レコードの作成を確認する http://support.microsoft.com/kb/816587/ja
参考 以下は ILM ですが、srv レコードが構築されていない場合の問題の事例です。
[ILM] MA 作成時、1355 エラーが発生！[Configure Directory Pertitions] 、[Containers…] 押してもコンテナが選択できなくてがっかり (1) / 2 http://blogs.technet.com/jpilmblg/archive/2009/02/20/ilm-ma-1355-configure-directory-pertitions-containers-1-2.aspx
[ILM] MA 作成時、1355 エラーが発生！[Configure Directory Pertitions] 、[Containers…] 押してもコンテナが選択できな��てがっかり (2) / 2 http://blogs.technet.com/jpilmblg/archive/2009/02/20/ilm-ma-1355-configure-directory-pertitions-containers-2-2.aspx
3. 問題事象と解決例－３ 現象 ASP.NET アプリケーションから、AD オブジェクトを参照しようとすると 認証エラーになる。
調査方針 IISを介さず、直接スクリプト等でオブジェクト参照が可能か確認する。 参照可能だった場合、イベントログおよびネットワークキャプチャを採取し認証動作を確認する。
- 実施項目 ・イベントログ : 認証ユーザーの確認 ・ネットワークキャプチャー : 認証方式の確認
調査結果 ・スクリプト動作では認証が得られ、正常動作することを確認。 ・イベントログから、Anonymous 認証で行われた状況となる。 ・ネットワークキャプチャー結果より、NTLM認証にてIIS サーバーで 保持されたハッシュされたパスワードを渡している。
対処方法 今回の問題は、ダブルホップ問題であると判断。 対処方法として以下を提示
・Kerberos 認証が有効になるようIIS を構成 - Active Directory 上で委任に対して信頼するのチェックボックスを設定する - web.config の変更
【参考資料群】 文書番号: 818742 - 最終更新日: 2007年12月3日 - リビジョン: 9.4 Microsoft Configuration Capture ユーティリティ (MPS_REPORTS) の概要 http://support.microsoft.com/kb/818742
文書番号: 823393 - 最終更新日: 2007年12月3日 - リビジョン: 4.7 マイクロソフト製品サポートのレポート ツール - PFE エディション (MPS REPORT PFE Edition) ※ 64bit / 32bit 共通 http://support.microsoft.com/default.aspx/kb/823393/ja
文書番号: 933741 - 最終更新日: 2009年5月28日 - リビジョン: 10.0 ネットワーク モニター 3 について http://support.microsoft.com/kb/933741/ja
文書番号: 926027 - 最終更新日: 2007年4月4日 - リビジョン: 1.1 Windows Server 2003 Service Pack 2 で更新された Windows Server 2003 サポート ツール http://support.microsoft.com/kb/926027/ja
Windows Server 2003 Service Pack 1 32-bit Support Tools http://www.microsoft.com/downloads/details.aspx?FamilyId=6EC50B78-8BE1-4E81-B3BE-4E7AC4F0912D&displaylang=en
Windows Server 2003 Service Pack 2 32-bit Support Tools http://www.microsoft.com.nsatc.net/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&DisplayLang=en
Windows XP Service Pack 2 サポート ツール http://www.microsoft.com/downloads/details.aspx?FamilyID=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=ja
Windows 7 用のリモート サーバー管理ツール http://www.microsoft.com/downloads/details.aspx?displaylang=ja&FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d
(これは今回のセッションと関係ないけど) Automated Password Synchronization Solution Guide for MIIS 2003 http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=b65d11f9-cdb7-4eb8-8b58-7530dca8b030&displaylang=en
【参考 : "MPSRPT_PFE.EXE" ツールの実行手順】 1. 対象のコンピュータに管理者権限でログオンし"MPSRPT_PFE.EXE " を実行します。この際、可能な限りリモートではなくローカルのコンソールでご実行ください。
2. Microsoft Platform Support Reporting tool の EULA ( END-USER LICENSE AGREEMENT ) が表示されます。情報の取得を行うには Yes ボタンを押してください。
3. コマンドプロンプトが起動され、以下のメッセージとともに入力要求が示されます。
Include the MSINFO32 report? (defaults to Y in 15 seconds)[N,Y]?
4. 手順 3. で 'Y' を選択して下さい。選択した場合、以下のメッセージが表示されます。 注意事項: システム情報の出力には、環境によって数十秒から数分間の間 CPU が高負荷状態となります。 もし 高負荷の状態が続くことが問題となる恐れが懸念される場合には 'N' を選択し、CPU負荷が高い場合でも問題ない時間帯、あるいは状況を見計らって別途取得くださいますようお願いします。
Running MSINFO32 Data Collection...
*************************************************************** NOTE: MSINFO32.EXE may take several minutes to complete. If this portion of the data collection hangs, please close this DOS window, then run MPSreports again and choose (N) to the option to run MSINFO32. *************************************************************** ........
5. Msinfo32 の出力が終わると、Readme.txt が表示され、各種ログファイルの採取が順次実行されます。
6. すべての情報の採取が終了すると、コマンドプロンプトは自動的に終了し、%SystemRoot%\MPSReports\PFE\Reports\Cab のフォルダが開きます。
7. cab フォルダを開き、中にある .CAB ファイルを開きますと、イベントログや環境の情報などのファイルが展開されます。
注意事項: お客様の環境によっては、 MPS レポート ツールは終了までに平均 5 ～ 15 分程かかることがございます。CPU 高負荷状態が運用に影響を与えることが懸念される場合には、支障のない時間帯または状況下で本ツールを実行してください。なお、本ツールは、レジストリ変更またはオペレーティング システムの変更を行いません。
【参考 : ネットワーク モニタでログを取得する方法】 ネットワーク モニタでログを取るためのプログラムをインストールすることができない場合は、以下の手順 0. と手順 4. を行います。同一ネットワーク内のトラフィックを監視する方法となります。この場合リピータハブが必要になります。一方実機でログ取得可能な場合は、手順 1. から実施ください。
＜ 実行手順 (採取コンピューターが別に構成される場合) ＞ 0. 取得前に、現象が発生するコンピュータをリピータハブに接続します。
接続イメージ -------------- 変更前: 取得対象端末 -- ネットワーク
変更後:
取得対象端末 --+-- リピータハブ --- ネットワーク 情報採取PC --+
＜ 実行手順 (採取コンピューターが 同一時の場合) ＞ 1. 以下のサイトからネットワークモニタをダウンロードし、インストールします。
Microsoft Network Monitor 3.3 http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f#filelist ※ "http" から "#filelist" までが URL になります。本ツールは英語版ですが、日本語環境にもインストールすることも可能です。
2. ネットワークモニタを起動し、メニューから [Tools] - [Options] をクリックします。
3. [Capture] タブの [Temporary capture file] の [Size] を 100 に変更します。
4. UI 上の右上の [Options] ボタン ([How Do I] ボタンの横)を押しますと[Options] ダイアログが表示されますので、[Capture] タブの下から 2 番目の [Enable Conversations (consumes more memory)] にチェックが入っていないことを確認してください。その後、[Start Page] タブの [Recent Caputures] ウインドウ (既定では左上の子ウインドウになります) の "Create : New capture tab..." の "New capture tab..." 部分をクリックします。 (ネットワーク モニタでログを取るためのプログラムをインストールすることができない場合のみ) [Start Page] タブの [Select Networks] ウィンドウで、対象となるネットワークのみチェックします。対象となるネットワークがグレーになっている状態にて、[P-Mode] を選択します。
5. または F5 キーを押してトレースの取得を開始します。
6. 目的のトレースが取得できたら、ネットワークモニタのメニューから [Capture] - [Stop] をクリック、または F11 キーを押してトレースの 取得を終了します。
7. ネットワークモニタのメニューから [File] - [Save As...] をクリックします。
8. [Frame selection] で [All captured frames] をクリックし、ファイル名を付けて保存します。
※お願い 上記で保存したログを解析する際に通信先と、取得環境の IP アドレスが必要になります。(IIS、DC などは必須)
********************
ちょっとセッションの内容にプラスが入ったので長くなっちゃいました。すみません…。 ご参考になれば幸いです。
それではまた！
～ういこう@ウルトラマンは 80 がリアルな世代です。仮面ライダーはスーパー1 ～