ドメインのサインインが急に失敗するようになり、調べてみたら PC の時計が10分ずれていた。Active Directory では、こうしたトラブルがときどき起きます。Kerberos 認証は時計のずれに厳しく、既定では5分を超えると認証に失敗するからです。この記事では、なぜ時刻が大事なのか、ドメインの中で時刻がどの順番で伝わるのか、時刻の元になる PDC エミュレータの設定、仮想マシンの DC での注意点、ずれたときの確認方法を説明します。
- Kerberos が時計のずれ（既定で5分）に厳しい理由
- ドメインの中で時刻が伝わる順番と、PDC エミュレータの役割
- 時刻がずれたときに、w32tm で何を確かめればよいか
なぜ時刻が大事なのか
Kerberos で認証するとき、PC が DC に送るメッセージには、そのときの時刻が入っています。受け取った DC は、その時刻を自分の時計と比べ、ずれが大きすぎれば受け付けません。
時刻を比べる理由は、リプレイ（盗み見たメッセージをあとから送り直すこと）を防ぐためです。メッセージに入っている時刻が「今」から大きく離れていれば、古いメッセージだと判断できます。そのかわり、正しい利用者でも、時計がずれていると認証に失敗します。
許容範囲は、グループポリシーの Kerberos ポリシーにある「Maximum tolerance for computer clock synchronization」（コンピュータの時計の同期の最大許容範囲）で決まり、既定は5分です。広げることもできますが、リプレイを防ぐ効果が弱まるので、時計を合わせるほうで解決します。
時刻のずれが影響するのは Kerberos だけではありません。DC どうしの複製、証明書の有効期限の判定、イベントログの時刻の突き合わせなども、時計が合っていることを前提にしています。
ドメインの中で時刻が伝わる順番
Windows の時刻同期は、Windows Time サービス（W32Time）が受け持ちます。ドメインに参加したコンピュータは、ドメインの階層をたどって時刻を合わせます。この合わせ方を NT5DS と呼びます。ここでは、本社ドメイン（corp.example.com）の下に大阪ドメイン（osaka.corp.example.com）がある構成で考えます。
| コンピュータ | 時刻をもらう相手 |
|---|---|
| PC・メンバーサーバ | 自分のドメインの DC（ふだん認証に使っている DC） |
| DC | 自分のドメインの PDC エミュレータ |
| 子ドメインの PDC | 親ドメインの DC |
| ルートの PDC | 上に合わせる相手がいないので、外部の NTP サーバなどを設定する |
つまり、フォレストのルートドメインの PDC エミュレータが、組織全体の時刻の元になります。ここの時計がずれると、時間をかけてフォレスト全体がずれていきます。PDC エミュレータは、ドメインごとに1台だけ決まっている役割（FSMO の1つ）です。
なお、ドメインに参加していないコンピュータは、既定で time.windows.com から時刻をもらいます。ドメインに参加すると NT5DS に切り替わります。
時刻を合わせるしくみ（NTP）
W32Time は、NTP（Network Time Protocol）で時刻をやり取りします。使うのは UDP の123番ポートです。DC やファイアウォールをまたいで時刻を合わせる場合は、このポートを開けておく必要があります。
ずれが分かったら、W32Time は時計を合わせます。ずれが小さいときは、時計の進む速さを少し変えて、時間をかけて合わせます。時計がいきなり戻ると、ログの順番が前後するなどの不都合が出るからです。ずれが大きいときは、時計をその場で置き換えます。ドメインのメンバーでは、ずれが300秒（MaxAllowedPhaseOffset の既定）を超えると、その場で置き換えます。300秒以下でも、ずれと設定値から計算した結果によっては、その場で置き換えることがあります。
DC には、もう1つ安全装置があります。48時間を超えるずれは自動では直さず、イベントログに記録するだけにします。時刻の元が大きく狂ったときに、DC の時計まで巻き込まれないようにするためです。
ルートの PDC エミュレータを設定する
ドメインを作ったままの状態では、ルートの PDC エミュレータは、自分の時計（ハードウェアの時計）を基準にします。これでは正確な時刻になりません。ルートの PDC エミュレータには、外部の NTP サーバ（またはGPSなどの時刻の機器）を時刻の元として設定します。
設定は、ルートの PDC エミュレータの DC だけで行います。ほかの DC やメンバーは NT5DS のままにしておけば、ドメインの階層から自動で合います。NTP サーバを2台だけ指定すると、どちらが正しいか決められないことがあるため、3台以上を指定するか、片方を予備（フラグ 0x2）にします。
PDC エミュレータを移したときの作業
DC の入れ替えなどで PDC エミュレータの役割を別の DC に移したときは、時刻の設定も一緒に移します。ここでは、ルートドメイン（corp.example.com）の PDC エミュレータを DC01 から DC02 に移す例で説明します。PDC エミュレータの役割は同じドメインの中でしか移せないので、DC01 と DC02 は同じドメインの DC です。設定を変えるのはこの2台だけで、ほかの DC やメンバーは何もしなくてかまいません。
| 作業 | どこで | 内容 |
|---|---|---|
| ① 今の設定を控える | DC01 | w32tm /query /configuration で、Type が NTP であることと、NtpServer に入っている外部の NTP サーバの名前を控える |
| ② 役割を移す | 管理用PC | PDC エミュレータの役割を DC02 に移す |
| ③ 新しい PDC の設定 | DC02 | ①で控えた NTP サーバを設定し、信頼できる時刻源にする |
| ④ 元の PDC を戻す | DC01 | ドメインの階層から合わせる設定（NT5DS）に戻し、信頼できる時刻源をやめる |
| ⑤ 確かめる | DC02・管理用PC | DC02 が外部の NTP から時刻を取れているか、各 DC のずれが小さいかを見る |
管理用PC（PowerShell・管理者）：② PDC エミュレータの役割を DC02 に移す
Move-ADDirectoryServerOperationMasterRole -Identity DC02 -OperationMasterRole PDCEmulator
DC02（コマンドプロンプト・管理者）：③ 外部の NTP サーバを設定し、信頼できる時刻源にする
w32tm /config /manualpeerlist:"ntp1.example.com,0x8 ntp2.example.com,0x8 ntp3.example.com,0x8" /syncfromflags:manual /reliable:yes /update net stop w32time && net start w32time w32tm /resync /rediscover
DC01（コマンドプロンプト・管理者）：④ ドメインの階層から合わせる設定に戻す
w32tm /config /syncfromflags:domhier /reliable:no /update net stop w32time && net start w32time w32tm /resync /rediscover
③のあと、DC02 で w32tm /query /source を実行して外部の NTP サーバの名前が出ること、w32tm /query /configuration で Type が NTP になっていることを確かめます。④のあと、DC01 で w32tm /query /source を実行して DC の名前が出れば戻っています。DC01 のレジストリには NtpServer の値が残りますが、NT5DS のあいだは使われないので、そのままでかまいません。最後に管理用PC で w32tm /monitor を実行し、各 DC のずれを確かめます。ほかの DC は、ドメインの階層をたどって自動で DC02 に合わせます。
- ファイアウォールで外向きの UDP 123 番を「DC01 の IP アドレスだけ許可」にしていると、DC02 から外部の NTP に届かない。ルールに DC02 を足す
- 時刻の設定をグループポリシーで配っている場合は、w32tm で変えてもポリシーで上書きされる。ポリシーのほうを直す。時刻のポリシーに WMI フィルター
SELECT * FROM Win32_ComputerSystem WHERE DomainRole = 5（5 は PDC）を付けておくと、役割を移すだけで設定が新しい PDC に付いていく。ただし元の PDC にはポリシーの値が残ることがあるので、④は行う - DC02 が仮想マシンなら、ホストとの時刻同期の設定を DC01 と同じ方針にそろえる
移し忘れても、時刻が合って見えることがある
③を忘れると、DC02 は NT5DS のまま PDC エミュレータになります。ルートの PDC エミュレータには、階層の上に時刻をもらう相手がいません。この状態になると、DC02 のシステムログに W32Time のイベント ID 12（警告）が記録されます。内容は「ドメインの階層から時刻を取る設定になっているが、自分はルートの PDC エミュレータなので上に相手がいない。信頼できる時刻源か外部の時刻源を設定することを勧める。そうしないと、自分の時計を基準に時刻の元として動く」という趣旨です。
ただし、設定を忘れても、しばらくは時刻が合って見えることがあります。たとえば次のような場合です。
- DC01 が外部の NTP と「信頼できる時刻源」の設定のまま残っていて、DC01 から時刻が回ってくる
- DC02 が仮想マシンで、ホストの正確な時計から時刻をもらっている
- 自分の時計を基準にしているが、まだずれが積み上がっていない
時刻が合っているあいだは、Kerberos もサインインも失敗しません。いわば「結果オーライ」の状態です。ただし、時刻が合っている理由が設定ではなく偶然なので、次のような形で後から問題になります。
PDC エミュレータを移すのは、DC01 を撤去するためであることが多いです。DC01 を降格・撤去した日に、気づかないまま時刻の元が消えます。自分の時計を基準にすると、時計はゆっくりずれていきます。何週間も問題なく動いたあと、ずれが5分を超えた時点で、フォレスト全体のサインインや複製がまとめて失敗します。原因が数か月前の役割の移動なので、切り分けに時間がかかります。仮想化のホストに頼っている場合も、ホストの設定を変えたり別のホストに移したりしたときに、急にずれ始めることがあります。
今の PDC エミュレータが「結果オーライ」になっていないかは、次の3点で確かめられます。右の列に当てはまるものがあれば、今は時刻が合っていても、③と④の作業をしておきます。
| PDC エミュレータで見るところ | 正しく設定できているとき | 結果オーライの疑いがあるとき |
|---|---|---|
w32tm /query /source | 外部の NTP サーバの名前 | ほかの DC の名前、VM IC Time Synchronization Provider、Local CMOS Clock |
w32tm /query /configuration の Type | NTP | NT5DS |
| システムログ | W32Time のイベント ID 12 が出ていない | イベント ID 12 が出ている |
仮想マシンの DC で気をつけること
DC を Hyper-V などの仮想マシンで動かしている場合は、ホストから時刻をもらうしくみ（Hyper-V の統合サービスの「時刻の同期」）にも気をつけます。ドメインの階層とホストの両方から時刻を合わせようとすると、時計が行ったり来たりすることがあります。
Microsoft のドキュメントでは、DC の仮想マシンについて、ホストとの時刻同期を止めるか一部だけ止め（ゲストの W32Time がホストの時刻を使わないようにし）、ドメインの階層から合わせる方法が案内されています。いっぽうで、ホストに正確な時刻を設定して、ホストからの時刻同期を残す考え方も紹介されています。どちらの方法でも、正確な時刻の元が1か所にきちんとつながっていることが大切です。VMware など、ほかの仮想化製品を使う場合は、その製品のドキュメントも確かめてください。
ずれたときの確認と直し方
時刻のずれが疑われるときは、次の順番で確かめます。
| よくある原因 | 直し方 |
|---|---|
| ルートの PDC が 自分の時計を使っている | 外部の NTP サーバを設定する。PDC の役割を移したあとに起きやすい（「PDC エミュレータを移したときの作業」を参照） |
| 手で NTP サーバを 指定したメンバー | ドメインに参加する前の設定が残っている。NT5DS（/syncfromflags:domhier）に戻す |
| UDP 123 番が 通らない | 拠点間や DC の前のファイアウォールで、UDP 123 番を許可する |
| 仮想マシンの DC | ホストとドメインの両方から合わせていないかを確かめる |
| 48 時間を超えるずれ | 自動では直らない。原因を確かめてから w32tm /resync /rediscover などで合わせ直す |
Kerberos のずれのエラーは、DC のセキュリティログ（Kerberos の認証のイベント）や、PC のシステムログに記録されます。サインインやファイル共有が急に使えなくなったときは、まず PC と DC の時計を見比べてみると、原因に早くたどり着けることがあります。
確認に使うコマンド
PC・サーバ（コマンドプロンプト）：時刻をもらっている相手を表示する
w32tm /query /source
PC・サーバ（コマンドプロンプト）：最後に同期した時刻や状態を表示する
w32tm /query /status
PC・サーバ（コマンドプロンプト）：W32Time の設定（Type など）を表示する
w32tm /query /configuration
PC・サーバ（コマンドプロンプト）：DC01 との時刻の差を5回測る
w32tm /stripchart /computer:dc01.corp.example.com /samples:5
管理用PC（コマンドプロンプト）：ドメインの各 DC の時刻のずれを一覧にする
w32tm /monitor /domain:corp.example.com
ルートの PDC（コマンドプロンプト・管理者）：外部の NTP サーバを時刻の元に設定する
w32tm /config /manualpeerlist:"ntp1.example.com,0x8 ntp2.example.com,0x8 ntp3.example.com,0x8" /syncfromflags:manual /reliable:yes /update
元の PDC・メンバー（コマンドプロンプト・管理者）：ドメインの階層から合わせる設定に戻す
w32tm /config /syncfromflags:domhier /reliable:no /update
PC・サーバ（コマンドプロンプト・管理者）：時刻の相手を探し直して同期する
w32tm /resync /rediscover
管理用PC（コマンドプロンプト）：PDC エミュレータの DC を探す
netdom query fsmo
w32tm /query /source の結果が DC の名前ならドメインの階層から、NTP サーバの名前なら手で指定した相手から時刻をもらっています。「VM IC Time Synchronization Provider」なら仮想化のホストから時刻をもらっています。「Local CMOS Clock」は、どこからも時刻をもらえていない状態です。再起動の直後や、設定した相手に届かないときに出ます。ルートの PDC エミュレータでこれが続くなら、外部の NTP サーバの設定と UDP 123 番の通信を確かめます。
まとめ
| 項目 | ひとことで |
|---|---|
| 5分のずれ | Kerberos が受け付ける時計のずれの既定。リプレイを防ぐための制限 |
| NT5DS | ドメインの階層から時刻を合わせる方法。ドメインに参加したコンピュータの既定 |
| ルートの PDC | フォレスト全体の時刻の元。外部の NTP サーバを設定する。役割を移したら設定も移す（時刻が合って見えても確かめる） |
| 仮想マシンの DC | ホストとドメインの両方から合わせない。時刻の元を1か所にする |
| 確認 | w32tm の /query /source、/status、/stripchart、/monitor で順に確かめる |
時刻同期はふだん意識しない設定ですが、ずれるとサインインや複製といった基本的な動きが止まります。ルートの PDC エミュレータの設定と、役割を移したときの設定の引き継ぎだけは、手順書に入れておくと安心です。
- How the Windows Time Service works（Microsoft Learn）
- Windows Time service tools and settings（Microsoft Learn）
- How to configure an authoritative time server in Windows Server（Microsoft Learn）
- How to configure the Windows Time service against a large time offset（Microsoft Learn）
- Configure the Root PDC with an Authoritative Time Source and Avoid a Widespread Time Skew（Microsoft Learn）
- Kerberos protocol registry entries and KDC configuration keys in Windows（Microsoft Learn）
- Kerberos authentication troubleshooting guidance（Microsoft Learn）
- Time accuracy improvements for Windows Server 2016（Microsoft Learn）
- Windows Time Service Technical Reference（Microsoft Learn）
- You receive Windows Time Service event IDs 24, 29, and 38 on a virtualized domain controller（Microsoft Learn）
- Event 142: The time service has stopped advertising as a time source（Microsoft Learn）
- Virtualizing domain controllers with Hyper-V（Microsoft Learn）
- Time sync for Windows VMs in Azure（Microsoft Learn）
- RFC 4120：The Kerberos Network Authentication Service (V5)
- RFC 5905：Network Time Protocol Version 4
コメント