最終回 NTP時刻同期サービスのトラブルシューティング：Windowsネットワーク時刻同期の基礎とノウハウ（改訂版）（2/3 ページ）

[小鮒通成，マイクロソフトMVP]

w32timeデバッグ・ログによる時刻同期のデバッグ

　時刻同期のトラブルシュートを行う際、Windows Timeサービスが実際にどのように時刻同期を行っているのかについて詳しく知りたい場合がある。また、イベント・ログに記録された時刻同期の状態は「逐一」ではなく、エラーがあってもすぐには記録されないため（ある程度の間隔で記録される）、直近の状態を把握するログが必要な場合はWindows Timeサービスのデバッグ・ログ（以下w32timeデバッグ・ログ）が役に立つ。

　w32timeデバッグ・ログはデフォルトでは設定されておらず、「w32tm /debug」オプションか、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Config\FileLogName」レジストリ値などで設定できる。設定方法の詳細については、第3回「w32tmコマンドとレジストリによるWindows Timeサービスの制御 - 4．Windows Timeサービスのレジストリ設定」を参照されたい。

ワークグループ環境での時刻同期のトレース

　それではw32timeデバッグ・ログで時刻同期の実際を確認してみよう。w32timeデバッグ・ログでは、Windows Timeサービスが動作する様子を確認できるが、原則的に以下のような動作で時刻同期が行われる。

Windows Timeサービスによる時刻同期の様子（1）
ワークグループ環境での時刻同期の様子。各項目については以下の説明を参照のこと。

　（1）まず初期設定の動作として、「Windows Timeプロバイダ（時刻同期のためのコンポーネント）」の設定が呼び出される。プロバイダには、「NtpClient（NTPクライアント）」「NtpServer（NTPサーバ）」「VMICTimeProvider（Hyper-V用プロバイダ）」の3種類があるが、Hyper-Vの時刻同期機能を利用しない場合、VMICTimeProviderの設定には影響されない。この環境では、NtpServerプロバイダが無効（Enabledが0）になっていることから、NTPサーバとしては機能しないことが分かる。

　（2）次に「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config」レジストリ・キーの値が読み込まれる。このログにより、レジストリ・エディタを使わなくてもサービスの設定値が確認できる。

　（3）lastClockRateの初期値が設定された後、NtpClientプロバイダが起動される。その際必要となる「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient」および「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters」レジストリ・キーの値が読み込まれる。NtpServerレジストリ値の内容から、「0x9」（Clientモードで、かつSpecialPollIntervalの間隔で同期する）や、同期の間隔（0x93a80＝604,800秒＝168時間＝7日間で同期する）などが分かる。

Windows Timeサービスによる時刻同期の様子（2）
Stepモードにおける時刻同期の様子。

　（4）ピア一覧が構成され、問い合わせパケットが送信される。NTPサーバから応答があれば、応答パケットの内容が記録されるため、ここでパラメータの内容を確認できる（ここではオフセット値が48秒遅れている）。送信パケットの内容は記録されない。なお、Windows Time起動時の同期に限り、問い合わせパケットは2回送信されるが、1回目の応答パケットはWindows Time側で破棄される（ここでは2回目の応答について記載する）。

　（5）応答パケットの内容をタイム・サンプルとして受け取った場合、累計して記録される。タイム・サンプル値は過去5回分まで記録され、精度判定のための統計データとして使われる。

　（6）タイム・サンプル値を受け取った際、イベントID 37が記録されたことを示すログ。最初に成功した時にだけ記録される。

　（7）受け取ったタイム・サンプル（Sample 0）を有効なサンプルと認定し、システム時刻と同期する。48秒の時刻差からStepモードで同期されたことを示す「ClockDispln Discipline: *SET*TIME」が記録されていることに注意する。なお、タイムサンプルによる同期が行われた場合、モードを問わず「ClockDispln Discipline: *SKEW*TIME」があわせて記録されるようである。

　（8）タイムサンプル値からシステム時刻を同期した際、イベントID 35が記録されたことを示すログ。最初に成功した時にだけ記録される。

　（9）Stepモードで変更された時刻を、CMOS（バッテリ・バックアップされたシステム・クロック・ユニット）に反映したことを示す記録。Windows TimeがStepモードで同期する際使われる関数（setSystemTime）の仕様上の動作（時刻を設定するとCMOSもあわせて変更する）と思われる。Slewモードで同期を行った場合も、Windows Timeの動作そのものはStepモードと変わらない。そのためトレース内容についても上記の内容とほとんど同一であり、わずかな部分の違いしかない。

Windows Timeサービスによる時刻同期の様子（3）
Slewモードにおける時刻同期の様子。先のStepモードの同期と同じ部分の状態。

　この画面は、Stepモードの（7）と（8）の部分に相当する所を抜粋したものだが、Stepモードで同期されたことを示す「ClockDispln Discipline: *SET*TIME」が記録されていないこと、CMOSに時刻が反映されていない（（9）の項目がない）以外の違いはない。

　時刻同期に失敗した場合、w32timeデバッグ・ログにその内容が記載されるが、これを見ると詳細な理由について確認できる。次のログは、参照先NTPサーバが有効な時刻情報を持っていないため（正しく上位と同期していない）、同期ができないことを示している。

時刻同期に失敗した場合の例
参照先NTPサーバが有効な時刻情報を持っていないので同期ができない場合のログの例。
　 （1）参照先NTPサーバからの応答パケットの内容について、LeapIndicator、Stratum、ReferenceClockIdentifierなどが正常でないことが確認できる。
　 （2）RFC 1305で定められたテスト項目6（適切な間隔で同期できていない）および7（階層構成が正しくない）により、サンプルが拒否されたことが確認できる。

ドメイン環境による時刻同期のトレース

　Active Directoryドメイン環境の時刻同期については、原則としてはワークグループ環境と変わらないものの、一つ異なる点がある。それは、クライアントからの時刻同期の要求をドメイン・コントローラ側で認証していることである。次の例は、Wiresharkというパケット・キャプチャ・ソフトウェアで取得した、クライアントとドメイン・コントローラ間の通信ログである（WiresharkについてはTIPS「Wiresharkでネットワーク・プロトコルを解析する」参照）。

　まずクライアントからNTPサーバへ問い合わせパケットが送信される。

ドメイン環境における時刻同期の様子（1）――問い合わせパケット
ドメイン環境でのクライアントからドメイン・コントローラへの問い合わせパケットの例。
　 （1）ドメイン・コントローラに、クライアントの個別番号に相当する「RID」を送信する。

　送信している問い合わせパケットには、クライアントの「RID（相対識別子:オブジェクトの個別番号に相当し、SIDの一部を構成する）」情報が含まれている点に注目していただきたい。

　これに対するNTPサーバ側の応答は次の通りである。

ドメイン環境における時刻同期の様子（2）――応答パケット
ドメイン・コントローラからクライアントへの応答パケット。
　 （1）ドメイン・コントローラからRIDとシグネチャを受信する。

　ドメイン環境独自のフィールドである「Key ID」にはクライアントのコンピュータ・オブジェクトのRIDが、「Message Authentication Code」にはコンピュータ・アカウントに対応した署名が含まれている。

　次の画面は、上記のコンピュータ・アカウントのobjectSID属性をADSIエディタで表示したものだが、SID（S-1-5-21-…となっている識別用の数値）を16進数で表示した場合の最下位8桁が「Key ID」になっていることが分かる。この桁はRIDに相当するバイト・データであり、0x451（上位バイトと下位バイトが逆になっている）を10進数にすると、RID（SIDの最後の部分がRID）と一致することが分かる。

ADSIエディタでSID中のRIDの値を確認する
SIDの末尾には、RIDの値が含まれている。NTPクライアントからの問い合わせでは、このRIDの値をNTPサーバに渡している。
　 （1）objectSID属性の値を確認する。
　 （2）SID中のRIDの値は、10進数で「1105」。
　 （3）16進数では「0x0451」となる。前述のキャプチャされたパケットに含まれるRID（Key ID）と一致することが分かる。

　ドメイン環境の時刻同期では、クライアントは自身のコンピュータ・アカウントのRID（相対識別子:SIDのうち個別番号に相当する）をドメイン・コントローラに送信し、ドメイン・コントローラ側では、RIDに合致するコンピュータ・アカウントの資格情報から署名を作成して、クライアントに返信する。クライアント側では、署名が正しいかどうかを（自分自身の資格情報で）検証して、正しい署名であれば、タイム・サンプルを受け入れるようになっている。

　この認証が成功した場合、w32timeデバッグ・ログには次のように記録される。

ドメイン環境における時刻同期ログの例
ドメイン環境において、ドメイン・コントローラとクライアントが正しく通信できた場合の時刻同期ログの様子。先ほどのワークグループ環境でのログの（5）〜（8）に相当する部分。

　上記は、ワークグループ環境のデバッグ・ログ（5）〜（8）に相当する部分を抜粋したものだが、（5）の中で応答パケットを受け取った直後、署名の検証を行って成功したことが 「Response received from domain controller dc100.example.com authenticated successfully.」 として記録されている。異常な状態、例えばドメイン・コントローラ側でコンピュータ・アカウントを削除してしまったような場合、以下のようなログが記録される。

ドメイン環境における時刻同期の失敗例のログ
クライアントのコンピュータ・アカウントが見つからないなどの問題があると、ドメイン・コントローラは時刻同期要求に対して応答を返さない。
　 （1）クライアントから送信された時刻同期要求に対して応答がないため、タイムアウトしている。

　（1）の項目では、「Sending packet to dc100.example.com (ntp.d|0.0.0.0:123-＞192.168.10.98:123) in Win2K detect mode, stage 1.」 から、dc100.example.comに対して問い合わせパケットが送信されていることが分かるが、そのあとの応答パケットが戻らない状況になっている。これは、問い合わせのあったRIDを含むコンピュータ・アカウントが存在しないため、不正なクライアントからの問い合わせとして応答を行わないためと考えられる。

　なおワークグループのクライアントがドメイン・コントローラに対して時刻同期を行う際には、問い合わせパケットにRIDが含まれないため、ドメイン・コントローラは必ず応答を返すので心配はいらない。