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

イベントID 37／イベントID 35

　Windows Timeサービスによる時刻同期の状況は、イベント・ビューアの「システム ログ」に、「Time-Service」イベントとして記録される。Windows Timeサービスが起動し、時刻同期を試行した結果は、成功した場合も失敗した場合も、Time-Serviceイベントに記録される。時刻同期に成功した場合、イベントID 37およびイベントID 35が記録される。イベントID 37は「参照先NTPサーバから時刻情報（時刻サンプル）を受け取った」ことを意味し、イベントID 35は「（受け取った）時刻サンプルを使って実際にシステム時刻を変更した」ことを意味する。

イベントID 37のログの例
これは、参照先NTPサーバから時刻情報（時刻サンプル）を受け取ったことを表すイベント。

イベントID 35のログの例
これは、（受け取った）時刻サンプルを使って実際にシステム時刻を変更したことを表すイベント。

　注意してほしいのは、イベントID 37が記録されただけでは「時刻同期が行われた」ということにならない点である。イベントID 37が記録されているのに、イベントID 35が記録されていない場合、受け取った時刻サンプルが有効でない、といった理由でWindows Timeサービスが同期を行わなかったことが考えられる。同期に失敗した場合はID 35とは異なるIDのイベントが記録されるため、実際にはこのイベントの内容で判断することになる。

イベントID 47

　イベントID 47は、「NTP問い合わせに対する応答がなかった」といった際に記録される。具体的な理由として、存在しないコンピュータのIPアドレスやNTPサーバでないコンピュータにアクセスしようとした場合が対象となる。またWindows Server 2008 R2がNTPサーバの場合、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\Enable」レジストリ値（NTPサーバの有効化）が設定されていなかったり、WindowsファイアウォールでUDPのポート123番（入力／出力方向とも）が解放されていない、という理由が考えられる。

イベントID 47のログの例
これは、NTP問い合わせに対する応答がなかったことを表すイベント。

イベントID 134

　イベントID 134は、「DNS名前解決が原因でアクセス先が指定できない」といった際に記録される。具体的な理由としては、Windows Server 2008 R2で「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NTPServer」レジストリ値（NTPサーバ名の指定）の値が適切でなかったり、ネットワーク接続のTCP/IPプロパティにある「優先DNSサーバ」のIPアドレスが誤っている、などでDNS名前解決が失敗しているといったことが考えられる。

イベントID 134のログの例
これは、DNS名前解決が原因でアクセス先が指定できなかったことを表すイベント。

イベントID 36

　イベント ID 36は、「長時間時刻同期を行うことができずに時刻が不正確な状態になっている」といった際に記録される。RFC 1305では、有効（正確）な状態の時刻サンプルは「86,400秒（＝1日）」の間に同期を行っていなければならず、それを超えた場合長時間同期を行っていないものとして、不正確なサンプルとみなされる。

　Windowsの時刻同期は、ワークグループ環境の場合、「604,800秒（＝7日）」ごとにtime.windows.comというNTPサーバに同期を行うよう設定されている。おそらくは「必要以上にネットワークを利用しない」と「ある程度正確な時刻に合わせる」を両立しようとした実装であると思われ、NTPクライアントとしての実用上に大きな問題はない。

イベントID 36のログの例
これは、長時間時刻同期を行うことができずに時刻が不正確な状態になっていることを表すイベント。

　しかし、比較的正確な時刻情報（例えば0.5秒以内の誤差）を必要とする場合や、NTPサーバとしてWindowsを利用したい場合、86400秒以内に同期を行うよう、設定を変更しなければならない。それにはNTPサーバの動作モードを適切に選択する必要がある。

NTPサーバの動作モードの選択について

　NTPサーバの動作モードを選択するには、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NTPServer」の値の「第 2パラメータ」を、次の（1）か（2）のいずれかに設定する。どちらを選択してもNTPサーバとして動作はするが、前者であれば時刻同期の間隔を明示的に制御できるメリットがあり、後者であればRFC 1305に準拠した業界標準の時刻同期の動作が行われるメリットがある。Linuxなどの非Windowsマシンの時刻同期を考慮する場合は、後者を選択したほうがいいだろう。また、非Windowsマシンの外部NTPサーバと時刻同期する場合、Clientモードを選択したほうがよい。Symmetric Activeモードで同期を行った場合、同期先NTPサーバから（peerモードに沿った）相互同期を行う要求を拒否され、時刻同期が失敗することがあるためである。

（1）一定間隔での時刻同期が必要な場合、0x9（Clientモード）または0x1（Symmetric Activeモード）を選択する。
（2）RFC 1305に準拠した時刻同期が必要な場合は、0x8（Clientモード）もしくは、0x4かパラメータなし（Symmetric Activeモード）を選択する。

NTPサーバの動作モードの設定（1）
一定間隔での時刻同期が必要な場合の設定。
　 （1）NtpServerの第1パラメータにはNTPサーバのIPアドレス、第2パラメータには、0x09（Clientモード）か0x1（Symmetric Activeモード）を設定する。

NTPサーバの動作モードの設定（2）
RFC 1305に準拠した業界標準の時刻同期が必要な場合の設定。
　 （1）NtpServerの第1パラメータにはNTPサーバのIPアドレス、第2パラメータには0x8（Clientモード）もしくは、0x4かパラメータなし（Symmetric Activeモード）を設定する。

●時刻同期の間隔をレジストリ値で調整する

　前項の（1）を選択した場合と（2）を選択した場合で確認するレジストリ値が異なるので注意する。

　時刻同期の間隔については、16秒以上の間隔（一般的なNTPソフトウェアの最短同期間隔）で、自分の時刻の同期精度と相手先NTPサーバへの負荷を考えながら決定する必要がある。例えばNICTではNTPサーバへの負荷を考慮して「1時間に20回（3分に1回）」を目途にしているが（NICTの公開NTPサーバに関するFAQ「ポーリング間隔に制限はありますか？」参照）、一定間隔で3分ごとに同期するより、最初は1分間隔で同期して、時刻が安定してきたら同期間隔を（自動的に）延ばす方法が、正確な時刻の取得と負荷の軽減を両立できる（RFC1305の同期間隔の挙動はこのような背景で定められていると思われる）。一般的なNTPソフトウェア（デーモン・タイプのもの）では、64〜1024秒の可変間隔で同期間隔が設定されたものが多いので、筆者もこの設定を個人的にはお勧めする。

（1）一定間隔での時刻同期が必要な場合、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval」レジストリ値を「秒数」で設定
（2）RFC 1305に準拠した時刻同期が必要な場合、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\MinPollInterval」および「MaxPollInterval」レジストリ値を「2を基底とした対数」で設定。例えば6を設定すると2の6乗＝64秒、10を設定すると2の10乗＝1024秒を表すことになる。

一定間隔での時刻同期が必要な場合のレジストリ設定
一定間隔での時刻同期が必要な場合は、SpecialPollIntervalのレジストリ値を設定する。
　 （1）時刻同期間隔（秒数）。

RFC 1305に準拠した時刻同期が必要な場合のレジストリ設定
RFC 1305に準拠した時刻同期が必要な場合は、MinPollIntervalとMaxPollIntervalのレジストリ値を設定する。
　 （1）最小ポーリング間隔。「2を基底とした対数」で（秒数）を指定する。ここでは0x0a＝10（10進数）なので2の10乗＝1024秒が設定されている。
　 （2）最大ポーリング間隔。「2を基底とした対数」で（秒数）を指定する。ここでは0x06＝6（10進数）なので2の6乗＝64秒が設定されている。

●Windowsファイアウォールの設定

　NTPサーバとして利用する場合は、まず「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\Enable」レジストリ値を1に設定する。

NTPサーバの有効化のためレジストリ設定
NTPサーバを有効にするには、Enableのレジストリ値を1に設定する。
　 （1）これを1に設定する。

　次に［セキュリティが強化されたWindowsファイアウォール］管理ツールで、「受信の規則」に「プロトコルの種類＝UDP」「ローカル ポート＝123」「リモート ポート＝123」を許可した新しい規則を作成して、接続可能な状態にする。

NTPサーバの有効化のためWindowsファイアウォール設定
WindowsファイアウォールでNTPサーバに対する新しい受信規則を作成し、クライアントからの接続を許可しておく。許可する規則の内容は、プロトコルの種類＝UDP、ポート番号＝123とする。
　 （1）UDPポートを選択する。
　 （2）「123」を設定する。
　 （3）「123」を設定する

イベントID 50

　イベント ID 50は、「一定間隔（900秒）の間にNTPサーバとの時刻ずれが縮まらない」という場合に記録される。この状況は、原則的には参照先NTPサーバ側でslewモード（時間のずれを少しずつ減らしながら同期させるモード）が発生し、時刻ずれが続いた場合に起こることがある。UNIXやLinuxのntpdといった一般的なNTPソフトウェアでは、NTPクライアントが同期のたびに時刻ずれを感知しないように、ごく小さい範囲でslewモードの補正をしているため（1秒あたり0.5ミリ秒の補正）、こういったことは生じにくい。一方Windows ServerがNTPサーバだった場合、1秒あたりの補正値はオフセットに依存するため（大きく時刻がずれているうちは補正値を大きくとり、正しい時刻に近づくと補正値が小さくなる）、このような問題が起こることがある。

イベントID 50のログの例
これは、一定間隔（900秒）の間にNTPサーバとの時刻ずれが縮まらないということを表すイベント。

　Windows Timeサービスにおける、この補正値の仕様は非公開であるため、上記が原因の場合は、「最初から正しい時刻に手動で合わせてから、Windows Timeサービスを動作させる」以外の解決策はない。ただVMwareやHyper-Vといった仮想環境のゲスト・マシンで発生した場合、仮想環境特有の理由による場合が少なくない。

　ハイパーバイザ型のゲスト・マシンでは、Clock Tickと呼ばれるOS内部の時刻カウンタがソフトウェアでエミュレートされているが、高負荷がかかるとこれが正常に（時間通りに）カウントされず、結果的に時刻が遅れていく傾向がある＊1。これを補正するため、ゲスト仮想マシンで対応ドライバ・ソフトウェア（Hyper-Vの場合は「Hyper-V統合サービス」）をインストールすると時刻に関する修正が1分ごとに行われるようになる。

　この機能を無効にした場合、発生した時刻ずれがイベントID 50の条件に一致すると、Windows Timeは時刻ずれの原因が自分自身なのか、参照先NTPサーバなのかを判定できないため、このイベントが記録されることがある。

　仮想環境のゲスト・マシンでこの状況が発生した場合、根本的に原因を解消する方法はないので、時刻同期の条件を最適化するといった対処が必要になる。具体的には次のどちらかを選択することになるだろう。

（A）自分自身しか存在しない、または1台のホスト・マシンでホストされた仮想環境のみであれば、「統合サービス」などの時刻同期サービスを有効にする。単純な環境であれば、この方法が最も簡単で、手間や時間がかからない。

（B）ほかの物理マシンや、複数台のホスト・マシンでホストされた仮想環境であれば、「統合サービス」の時刻同期サービスは無効に設定したうえ、各ゲスト・マシンのWinodws Timeサービスが時刻同期の階層を構成するよう設定する。複数の物理マシン間で時刻同期させるとそれぞれが影響しあって動作を邪魔する可能性があるため、統合サービスの同期性は1台のホスト・マシン上でのみ有効にするのがよい。

　あわせて、各ゲスト・マシンの時刻同期間隔は通常より短く設定し、特に時刻同期の最上位となるゲスト・マシンについては、物理マシンとなるNTPサーバにさらに短い間隔で時刻同期を行うよう設定する。Clock Tickの遅れを補正するためには、短い間隔で時刻同期を行う以外に方法はないこと、ゲスト・マシン間での時刻同期は不正確さが伴うため、少なくとも最上位のゲスト・マシンは、正確な時刻を担保できる物理マシンから同期を行う必要がある。

　仮想環境の状況に依存するが、1分以内の時刻同期間隔を保つ必要があるケースもあり、（NICTなどの）公共の外部NTPサーバから直接同期するのではなく、自社内に物理マシンによる基準NTPサーバを用意して、これをゲスト・マシンの時刻同期に利用した方がよいだろう。

イベントID 12

　イベント ID 12は、「PDCエミュレータ役割のドメイン・コントローラが外部から時刻同期を行うよう設定されていない」といった際に記録される。PDCエミュレータ役割のドメイン・コントローラは、時刻同期の最上位のNTPサーバとして、外部のNTPサーバと同期するか、自分自身をStratum 1のNTPサーバとして設定しないと、ほかのサーバやクライアントが適切に時刻同期できない。

イベントID 12のログの例
これは、PDCエミュレータ役割のドメイン・コントローラが外部から時刻同期を行うように設定されていない場合に記録されるイベント。

　ドメイン・コントローラの時刻同期設定については、第2回の「Active Directoryおよびワークグループ環境での時刻同期 - 2．Active Directory環境で、PDCエミュレータを権威ある時刻サーバに設定する」を参照されたい。

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が含まれないため、ドメイン・コントローラは必ず応答を返すので心配はいらない。

読み取り専用ドメイン・コントローラにおける時刻同期処理

　「読み取り専用ドメイン・コントローラ（Read Only Domain Controller。以下RODC）」は、ユーザー情報の書き込みが不可能なこと、アカウントのパスワード情報を持たせないことなどで、誤操作や盗難によるクラッキングに対応した、ブランチ・オフィス（遠隔地の事務所）向けのドメイン・コントローラである。

　RODCの時刻同期は、ドメイン・コントローラでありながら通常のドメイン・コントローラ（書き込み可能なドメイン・コントローラ：RWDC）とは異なる。NTPクライアントとしてのRODCは、原則として複製元のWindows Server 2008以降のRWDCから時刻同期を行い、ほかのRODCや同じフォレスト内の親ドメインのRWDCからは時刻同期を行わない。RWDC間の時刻同期の詳細については、第3回「Active Directoryおよびワークグループ環境での時刻同期― 1．Active Directory環境での時刻同期」を参照していただきたい。

　またNTPサーバとしてのRODCの挙動も多少複雑である。というのも、RODCはパスワード情報を持っていないからだ。クライアントから認証要求があった場合、通常は複製元のRWDCに認証を委任しているのだが、設定変更（各アカウントの［パスワード レプリケーション］プロパティ）でパスワード情報を個別に複製し、委任を行わないで認証することもできる。クライアント・コンピュータのアカウントのパスワード複製が行われているかどうかによって、挙動が変化するのだ。

パスワード複製が行われていない場合の時刻同期

　ドメイン環境の時刻同期では、認証に必要な署名を作成するため、ドメイン・コントローラ側がコンピュータ・アカウントのRID情報と資格情報を知っている必要があることは、すでに述べた通りだ。RODCの場合、オブジェクトからRIDは分かってもパスワード情報（資格情報）が分からないため、クライアントのための署名を生成できない。そのため、署名の生成を複製元のRWDCに委任し、自らはプロキシ（代理）的な役割を担う。その挙動は以下の通りである。

　この状況は以下のパケット・キャプチャの内容から確認できる。この環境での各コンピュータのIPアドレスは、RWDCは192.168.10.98、RODCは192.168.10.101、クライアントは192.168.10.100である。

　まずクライアントがRODCにNTPの問い合わせパケットを送信する。

クライアントからRDOCへの送信
クライアントがRDOCへNTPの問い合わせパケットを送信する。
　 （1）クライアントからRODCへのNTPパケットにRIDが含まれていることが分かる。

　するとRODCは複製元のRWDCに問い合わせパケットを代理で送信する。

RODCからRWDCへの代理送信
RODCは複製元のRWDCに問い合わせパケットを代理で送信する。
　 （1）RODCからRWDCへのNTPパケットにRIDが含まれている。

　RWDCはRODCに応答パケットを返送する。

RWDCからRODCへの応答パケットの返送
RWDCはRIDに対応した署名を作成し、RODCに応答パケットを返送する。
　 （1）RODCからRODCへのNTPパケットには、RIDと署名が含まれている。

　応答パケットを受け取ったRODCは、問い合わせ元のクライアントにそれを返送する。

RODCからクライアントへの応答パケットの返送
RODCは、RWDCから受け取った返送パケットをクライアントへ返す
　 （1）RODCからクライアントへのNTPパケットには、RIDと署名が含まれている。

　このモードで動作するRODCでは、「Chaining Table」と呼ばれる情報が一時的にメモリ上にキャッシュされる。Chaining Tableは、「RWDCからRODCへのNTP応答パケット」をRODCが受け取った際、正当な情報かどうか（改ざんされていないか）確認したり、自身のWindows Timeサービスの要求か、それともクライアントからのプロキシ要求かを区別するために使われる。

　Chaining Tableには「クライアントのIPアドレス」「RID」「OriginateTimestamp」「ArrivalTime」が含まれるが、RODCは応答パケットに含まれる「RID」「OriginateTimestamp」の2つをChaining Tableから検索し、存在すればプロキシ応答とみなしてクライアント（のIPアドレス）に送信し、存在しなければ自分自身のWindows Timeのタイム・サンプルとして利用する。

　あわせて、同一クライアントから新たにNTP問い合わせが行われる際、Chaining Tableの以前のエントリが存在することで問題が起こらないよう、エントリは生成から16秒後に消去される仕組みになっている。ドメインによる時刻同期ではRFC 1305に準拠した間隔で同期が行われ、（RFC 1305の仕様により）最少16秒の問い合わせ間隔になっているためである。

パスワード複製が行われている場合の時刻同期

　RODCでは「Allowed RODC Password Replication Group」にアカウントを登録すると、RODCへのログオン時にRODCにパスワードが複製され、以後はキャッシュとして機能する。

Allowed RODC Password Replication Groupプロパティ
Allowed RODC Password Replication Groupに登録すると、パスワード情報がキャッシュされるようになる。
　 （1）追加登録したメンバー。

パスワードがキャッシュされているアカウントの一覧
このコンピュータ上でパスワードがキャッシュされているアカウントの一覧を確認しているところ。
　 （1）キャッシュしているアカウントの表示。
　 （2）このアカウントのパスワードがキャッシュされている。

　このような状態であれば、RODC上でRIDに対応した署名を生成できるため、RODCはRWDCに資格情報を問い合わせることなく、直接クライアントに署名を送信できる。そのため、動作としてはRWDCとクライアントと同じ挙動になる。

　以下のパケット・キャプチャの内容から、上記の挙動を確認できる。上記同様、この環境での各サーバのIPアドレスは、RODCは192.168.10.101、クライアントは192.168.10.100という構成である。

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

クライアントからRDOCへの送信（キャッシュ編）
クライアントがRDOCへNTPの問い合わせパケットを送信する。
　 （1）クライアントからRODCへのNTPパケットにRIDが含まれている。

　今度はRODCからクライアントへすぐに応答が返されている。

RODCからクライアントへの応答パケットの返送（キャッシュ編）
RODCは、すぐに返送パケットをクライアントへ返している。
　 （1）RODCからクライアントへのNTPパケットには、RIDと署名が含まれている。

RODC特有のレジストリ設定

　RODC特有のレジストリ値については以下の4つが存在する。いずれも Chaining Tableの挙動を制御するものだが、基本的には変更する必要は少ないだろう。レジストリ値を含むRODCの時刻同期設定については、「Appendix A: RODC Technical Reference Topics（マイクロソフトTechNetサイト）」の「How the Windows Time service works on an RODC」を参照していただきたい。

●Chaining Tableエントリの有効時間

●Chaining Tableエントリの最大数

●Chaining Tableエントリを利用する最大ホスト数

●Chaining Table機能の無効化

　Windows Server 2008 R2の時刻同期については、Windows Timeサービスの変更仕様や、RODCに関する特別な動作などの小さな変更はあるが、その根幹自体は以前と変わっていない。ただ、使い勝手の面では、前回紹介したように、w32tm /queryコマンドを使って直近の同期状態を確認できることでトラブルシュートがやりやすくなっていたり、イベント・ログの内容も説明や対応方法が分かりやすく記載されており、運用上の助けになると思われる。本記事を参考していただければ筆者として幸いである。