時刻同期とは、ネットワーク上にあるコンピューター端末のシステム時刻を正確にあわせる仕組みのことを指します。ネットワーク上にある各コンピューター端末にて、正確な時刻を共有することはシステムの運用/管理において重要です。
時刻同期の代表的なプロトコルとして、NTP(Network Time Protocol)があります。Windows OS でもシステム時刻の時間をあわせるために、NTP を利用して時刻同期を行っています。特に Active Directory ドメインを構築している環境では、主な認証方式に Kerberos 認証が利用されているため、ドメイン内の端末間で時刻ずれがおきないように NTP で時刻同期を行い、同じシステム時刻を共有しています。
今回は、NTP の基礎知識やドメイン環境での時刻同期の仕組みの概要について紹介します。
NTP(Network Time Protocol)とは
NTP(Network Time Protocol)とは、ネットワーク上にあるコンピューター端末や機器の時間を正確に維持するためのプロトコルです。NTP により複数のコンピューターのシステム時刻の時刻同期を行うことで、指定時間に正しくサービスを動作させたり、アクセスログに記録された時間を正しく管理することができます。
ほとんどのコンピューターには、RTC(Real Time Clock)と呼ばれる内部時計を持っています。コンピューターは起動時に RTC から時刻を読み込みます。そして起動後においては、起動時からの経過時間を加算して現在時間を算出し、システム時刻として使用します。RTC はバッテリーを内蔵しているため、コンピューターに電源が供給されていない状態でも時刻を刻むことができます。
しかし、RTC のバッテリーの電源不足や、RTC が保持している時間がそもそもずれているなどの理由などで、コンピューターのシステム時刻がずれてしまうことがあります。システム時刻がずれていると、日付や時間を必要とするサービスや機能に影響を与えることがあります。Windows OS の場合では、タスクスケジューラーや Kerberos 認証の機能などが例として挙げられます。
システム時刻の時刻ずれによる問題の発生を防ぐために、GPS や原子時計などのハードウェア時計をインストールする方法があります。しかし、そのようなハードウェア時計を導入していないコンピューターにおいては、正確な時刻を提供しているコンピューターと定期的に同期を行い、システム時刻を正確に保っています。
時刻同期の代表的なプロトコルとして、NTP(Network Time Protocol)があります。Windows OS も NTP のプロトコルを利用して時刻同期を行い、システム時刻を正確に保つ機能が用意されています。
Windows Time サービス
Windows Time サービス(W32Time サービス) とは、Windows コンピューターにて NTP 時刻同期を行うための機能です。
Windows Server 2003 以降の OS では、時刻同期のプロトコルとして NTP Version 3 が採用されており、W32Time サービス (w32time.dll) にて実装されています。W32Time サービスは、NTP サーバーとしては Version 3 で動作しますが、NTP クライアントとしては Version 1 から 4 までの NTP と SNTP に対応しています。
Windows Time サービスは、秒単位やミリ単位での細かい精度での時刻同期を想定した設計となっていませんでした。従来の Windows Time サービスの設計思想は以下の通りです。
- Kerberos 認証が正しく動作できる時刻同期を提供
- クライアント コンピューターにゆるやかな時刻同期を提供
Kerberos 認証は「５分以上の時刻ずれ」があると、Kerberos チケットは無効とされて認証は失敗します。そのため、ドメイン内で管理している各端末が５分以上の時刻ずれが発生しないように NTP 時刻同期を行っています。このように NTP ネットワーク内で 5 分以上の時刻差が発生しない程度の時刻同期を提供するシステムであるため、秒単位の細かい精度での時刻同期は目的となっていませんでした。
しかしながら、Windows Server 2016 / Windows 10 以降の OS においては、ミリ単位の精度の時刻同期が行えるように Windows Time サービスの仕組みが見直されております。そのため、それ以降の OS であれば秒単位でのシステム時刻の精度が提供できることが見込まれます。
NTP ストラタム
NTP は階層構造をもち、上位のサーバーから時刻の情報を受けて同期を行う構造となっています。この階層構造のレベルを数値は、NTP のストラタム(stratum)として表現されます。ストラタムの数値は 1 から 15 の範囲となり、最上位の NTP サーバーのストラタムが 1 で、数値が大きくなるほど下位の NTP サーバーとなります。
最上位のストラタム 1 の NTP サーバーは、NTP ネットワークの中で最も正確な時刻を管理しています。ストラタム２の NTP サーバーは、１つ上位の NTP サーバーから時刻に関する情報を受信して同期します。下位の階層も同様に、１つ上位の NTP サーバーから時刻同期を行い、ストラタムの数値が大きくなるにつれて、時刻情報はより階層的に伝播されます。
下位の NTP サーバーはネットワークを経由して時刻同期を行うため、その際にはネットワークの処理遅延が発生します。NTP ではネットワークの処理遅延を考慮した設計とはなっていますが、多少の誤差が発生する可能性が考えられます。そのため、ストラタムの数値の大きい NTP サーバーほど(階層構造の中で下位のサーバーほど)、ネットワークの処理遅延が積算されて誤差が大きくなる傾向があると考えられるため、ストラタムの数値が小さい NTP サーバーほど、より正確な時刻を提供しています。
NTP と Active Directory ドメイン サービス
Active Directory ドメイン環境では、Kerberos 認証を利用できるように NTP による時刻同期を行っています。
Active Directory のドメイン環境では、ユーザーやコンピューターなどのリソースを一元管理できますが、その際の認証方式の基盤は Kerberos 認証で実現されています。Kerberos 認証の仕組みにより、シングル サインオン(SSO)が実現でき、一度の認証でドメイン内にある様々なリソースにアクセスできるようになります。
Kerberos 認証では、Kerberos チケットの盗聴による「なりすまし」を防ぐために、チケットにタイムスタンプ(送信時間)が記録されています。チケットを受領したコンピューターは、チケットのタイムスタンプと端末のシステム時刻に５分以上のずれがあるとチケットを無効と判断して認証は失敗します。
そのため、ドメイン環境下では管理対象となるコンピューターが 5 分以上の時刻ずれが発生しないように、NTP 同期する動作となっています。ドメイン環境の NTP ネットワークでは、既定では全てのドメイン コントローラーが NTP サーバーとして動作し、ドメイン内で管理している各端末に時刻を提供しています。フォレストのルートドメインにある PDC エミュレーターの役割をもつドメイン コントローラーが、最上位の NTP サーバー(ストラタム１)となります。
フォレスト内にある各ドメイン コントローラーの NTP 階層構造は自動で決まります。ドメイン コントローラーの同期先は、以下の表のスコア付けアルゴリズムに従って各ドメイン コントローラーに点数をつけ、点数が最も高いドメイン コントローラーを同期先として選出して時刻同期を行います。各ドメイン コントローラーのストラタムは、同期先となるドメイン コントローラー(NTP サーバー)のストラタムの数値に＋１とした数値となります。
| 順番 | 条件１ | 条件２ | 条件３ | 点数 |
| １ | 同一サイト | 親ドメインの DC | GTIMESRV：14点 そのほか：10点 |
|
| ２ | 同一サイト | 同一ドメインの DC | GTIMESRV | 12点 |
| ３ | 同一サイト | 同一ドメインの PDC | 9点 | |
| ４ | 別サイト | 親ドメインの DC | GTIMESRV：6点 そのほか：2点 |
|
| ５ | 別サイト | 同一ドメインの DC | GTIMESRV | 4点 |
| ６ | 別サイト | 同一ドメインの PDC | 1点 |
〇 レジストリ Config\AnnounceFlags の 0x4 のフラグが ON
〇 レジストリ Config\AnnounceFlags の 0x8 のフラグが ON であり、フォレスト ルート ドメインの PDC エミュレーターで Local CMOS Clock を参照していること
NTP 時刻同期のシーケンス
NTP クライアントは、以下のシーケンスで NTP サーバーと時刻同期を行います。
- Peer Search
- Send NTP Request
- Receive NTP Response
- Add Sample / Packet Test
- Select Best Sample / Clock Discipline
シーケンスにある各ステップの詳細について説明します。
① Peer Search
Peer Search(ピア検索)は、NTP クライアントが同期先として利用する NTP サーバー(ピア)を探索する過程です。Windows OS にて Peer Search が行われるタイミングは以下の２通りです。
- Windows Time サービスの起動時
- 使用中の Peer から８回連続で正常な時刻サンプルが得られず、ピアを破棄した場合
ドメイン参加している NTP クライアントが Peer Search を行う場合、DsGetDCName 関数で TIMESERV フラグをもつドメイン コントローラーを検索する動作となります。通常は、ログオン先のドメイン コントローラーがピアに選定されます。ドメイン参加端末は OS 起動後にはセキュアチャネル確立のために DsGetDCName 関数が実行され、TIMESERV フラグをもつドメイン コントローラーの情報が Netlogon サービスにキャッシュされているためです。
DsGetDCName 関数については、以下の記事にて詳細しております。
Active Directory ドメイン サービスで構築されたドメイン環境では、ドメイン コントローラーがユーザーやコンピューターの管理をしています。Active Directory の仕組みを利用して認証や設定の配布するためには、ドメイ[…]
ドメインに参加していない Windows OS の NTP クライアントは、参照 NTP サーバーの設定にある NTP サーバーがピアとなります。
Peer Search に失敗した場合の動作は以下の通りです。
- レジストリ TimeProviders¥NtpClient¥ResolvePeerBackoffMinutes 分を待機時間として、待機後に再度 PeerSearch を行います。
- NTP サーバーが見つからない場合には、待機時間を 2 倍にして、1 の手順を繰り返します。
- レジストリ TimeProviders¥NtpClient¥ResolvePeerBackoffMaxTimes 回、1 の手順を繰り返した後は、待機時間を 2 倍にはせずに、PeerSearch を繰り返します
- NTP サーバーが見つかるまで、3 の手順を繰り返えします。
② Send NTP Request
NTP クライアントは時刻同期を行うために、ピアとなった NTP サーバーに対して NTP リクエストを送ります。
NTP クライアントは一定の間隔で NTP リクエストを送信し、時刻同期を行います。時刻同期の間隔は、レジストリの設定値により決まります。
③ Receive NTP Response
ピアの NTP サーバーから、時刻情報が含まれる NTP Response を受領します。NTP Response には以下の情報が含まれています。
| Mode | 同期モード |
| Stratum | 階層構造のストラタムの数値 |
| Polling Interval | ポーリング間隔 |
| Source | NTP サーバーの IP アドレス |
| Root Delay |
ルート遅延 |
| Root Dispersion | ルート分散値 |
| Reference Timestamp | サーバーのシステム時計が最後にセットあるいは修正された時刻 |
| Originate Timestamp | クライアントが NTP パケットを送信したタイミングのクライアントの時刻 |
| Receive Timestamp | サーバーが NTP パケットを受信したタイミングのサーバーの時刻 |
| Transmit Timestamp | サーバーが NTP パケットを送信したタイミングのサーバーの時刻 |
| 署名データ | パケットの改ざんを検知するためのデジタル署名のデータ Active Directory のフォレスト内のコンピューター間で時刻同期を行う場合のみ使用される |
同期モード
NTP 同期モードは、時刻同期を行う様式を表します。
NTP の同期モードには、「Client/Server」モードと「Symmetric Passive/Active」モードがあります。Client/Server モードには、どちらの端末が NTP クライアントか NTP サーバーかを明確にして時刻同期をとる方法です。一方、Symmetric Passive/Active モードとは、クライアントもしくはサーバーなどの役割を決めずに、お互いが同期をとる時刻同期の方法となります。時刻同期を行う際に、どちらが NTP サーバーとなるかを自動的に決めて時刻同期を行います。Symmetric Passive/Active モードは、一般的には同じ階層の NTP サーバー同士で時刻同期を行うときのモードとなります。
ルート遅延
ルート遅延は、NTP サーバーと NTP クライアントとの間の遅延の時間を表します。
ルート遅延は、NTP パケットに含まれる「クライアントが NTP パケットを送信したタイミングのクライアントの時刻(Originate Timestamp)」、「サーバーが NTP パケットを受信したタイミングのサーバーの時刻(Receive Timestamp)」、「サーバーが NTP パケットを送信したタイミングのサーバーの時刻(Transmit Timestamp)」「クライアントが NTP パケットを受信したときのクライアントの時刻」を用いて算出されます。
ルート分散値
ルート分散値は、ネットワーク上の遅延やクロックの不安定性などによる時刻のばらつきを表します。
ルート分散値は、NTP サーバーから受け取った時刻情報の信頼性を確認するために使用されます。具体的には、NTP クライアントが NTP サーバーから応答を受け取った際に、その応答パケットに含まれるルート分散値を参照して、NTP サーバーの正確性や安定性を確認します。ルート分散値はミリ秒単位で表され、値が小さいほど NTP サーバーの時刻情報の信頼性が高いことを示します。
④ Add Sample / Packet Test
Add Sample の処理にて、受信した NTP Response の Packet Test を行います。Packet Test に失敗した場合は、時刻サンプルとして利用せずに破棄します。Packet Test は 8 つあります。各 Packet Test の詳細は以下の通りです。
Packet Test 1
| テスト内容 | 以前の時刻同期時の受信した NTP パケットと重複していないか確認 |
| 失敗原因 |
過去に同じパケットを受信 |
Packet Test 2
| テスト内容 | 受信した NTP Response が自身の NTP Request に対する応答かどうか確認 |
| 失敗原因 | 送信した NTP Request の応答ではない NTP Response を受信 |
Packet Test 3
| テスト内容 | 受信したパケットのヘッダーに含まれる Originate Timestamp と Receive Timestamp の値を確認し、両方が 0 ではないことを確認 |
| 失敗原因 | NTP サーバーから NTP Request パケットを受信 |
Packet Test 4
| テスト内容 | NTP Request を送信してから NTP Response を受信するまでの遅延時間が許容できる範囲かを確認 |
| 失敗原因 | ルート遅延が大きい |
Packet Test 5
| テスト内容 | NTP の認証が有効な場合、正しく機能しているか暗号化の手続きを確認 |
| 失敗原因 | なし。Windows に関しては、Packet Test 5 は実装されていないため |
Packet Test 6
| テスト内容 | 前回の時刻同期した時間からの間隔に問題がないか確認 |
| 失敗原因 |
ピアの NTP サーバーが、さらに上位の NTP サーバーと同期できていない場合などに発生 |
Packet Test 7
| テスト内容 | NTP の階層構造(ストラタム)に問題が発生していないか確認 |
| 失敗原因 | ストラタムの数値が０もしくは１５を超えている場合 |
Packet Test 8
| テスト内容 | ルート分散値が許容できる範囲であるか確認 |
| 失敗原因 | 上位に存在する NTP サーバーと最上位の NTP サーバーとの遅延時間や分散値の合計が一定値以上である場合に発生 |
⑤ Select Best Sample / Clock Discipline
Add Sample の処理にて全ての Packet Test を合格した時刻サンプルで、システム時刻の調整を行います。
複数の NTP サーバーから時刻サンプルを取得している場合には、RFC 1305 の 4.2 Clock Selection Procedure に準拠したアルゴリズムで最も優先度の高い時刻サンプルを選択します。ドメインに参加している端末においては、一般的にはレジストリの Type は NT5DS となっているため、Peer Search によって１台のドメイン コントローラーのみがピアの NTP サーバーとなるため、複数の時刻サンプルから選択する処理は行われません。
ポチップ
