Active Directory で Kerberos 認証失敗が起きたとき、まず疑うべき原因のひとつが時刻ずれです。Kerberos はクライアントとドメイン コントローラーの時刻差に厳しく、既定では 5 分を超えると KRB_AP_ERR_SKEW として認証に失敗します。復旧の近道は、ユーザーPCを個別に触ることではなく、フォレスト ルートの PDC エミュレーターの時刻源を正し、DC とメンバーをドメイン階層に戻してから再同期することです。 (Microsoft Learn)
この記事では、Active Directory で時刻ずれが起きやすい条件、更新や権限・仮想化が絡む見落としポイント、すぐ使える確認コマンド、応急処置ではなく再発しにくい復旧手順まで、現場向けに整理します。 (Microsoft Learn)
なぜ時刻ずれで Kerberos 認証が止まるのか
Windows Time Service（W32Time）は Kerberos V5 と AD DS ベース認証の正常動作に不可欠で、ドメイン コントローラー同士のレプリケーションにも同期した時刻が求められます。Kerberos はタイムスタンプでリプレイ攻撃を防ぐため、時刻差が許容範囲を超えると認証を拒否します。Microsoft の Kerberos ポリシーでは、この許容差の既定値と推奨値は 5 分です。 (Microsoft Learn)
実際のログでは、DC の Security ログ 4768 に 0x25 KRB_AP_ERR_SKEW が出たり、クライアントやサーバー側で Event ID 4 / KERB_AP_ERR_SKEW が出たりします。ここが見えたら、パスワードや SPN より先に時刻系を疑うほうが速いです。 (Microsoft Learn)
Active Directory の既定では、クライアントとメンバー サーバーは認証した DC を時刻源とし、各ドメインの DC は PDC エミュレーターを参照します。さらにフォレスト ルート ドメインの PDC エミュレーターが組織全体の最上位の時刻源になり、外部の信頼できる時刻源と同期する前提です。ドメイン参加コンピューターの既定の同期タイプは NT5DS で、ドメイン階層を使います。つまり、フォレスト ルート PDC の狂いは、個別端末の問題ではなくドメイン全体の問題になりやすいということです。 (Microsoft Learn)
起きやすい条件
フォレスト ルート PDC の外部時刻源が不正
PDC エミュレーターはドメイン内の時刻の要で、フォレスト ルートの PDC は組織全体の基準になります。ここが外部 NTP と同期できていない、または外部時刻源に向いていないと、下位 DC とメンバーが連鎖的にずれます。Microsoft の構成手順でも、PDC を Type = NTP にし、AnnounceFlags = 5、NTP サーバーを有効化し、外部時刻源を設定する流れが示されています。なお、上流との同期が不安定な回線や固定ポーリング間隔を使う場合は、AnnounceFlags = 0xA を検討する注意もあります。 (Microsoft Learn)
メンバーや DC がドメイン階層から外れている
ドメイン参加マシンは本来 NT5DS でドメイン階層に従いますが、手動で NTP を指定したまま残っていたり、過去の設定が残っていたりすると、DC とは別の時計を見に行きます。さらに Microsoft には、特定のインプレース アップグレード後に PDC が外部時刻源との接続を失い、時刻サーバーとして広告しなくなり、他の DC やドメイン メンバーもドメイン階層を使えなくなる既知事象があります。環境更新の直後に症状が出たなら、ここは優先確認です。 (Microsoft Learn)
仮想環境で時刻源が混在している
仮想 DC では、ゲスト OS の W32Time、ホスト側の時刻同期、VMICTimeSync などが混在し、どの時計を正とするかが曖昧になるとズレやすくなります。Microsoft の事例でも、ntp と VMICTimeSync など複数の時刻プロバイダーが混在した結果、不正確な時刻がログオン失敗の根本原因になったケースが示されています。無条件に VMICTimeSync を切ればよいわけではなく、Microsoft は saved state 保護の観点から無効化を推奨しない場合もあるため、重要なのはホストとゲストで別の基準時刻を混在させない設計です。 (Microsoft Learn)
GPO・権限・手動変更で時刻同期を壊している
Change the system time は、単に人が時計を合わせるための権限ではありません。Microsoft はこの権利について、時刻同期を実行するプロセスにも必要だと説明しており、DC の既定では Administrators、Server Operators、Local Service が持っています。セキュリティ強化のつもりでこの権利を削りすぎると、同期処理に影響する可能性があります。また、Security イベント 4616 で Subject\Security ID が LOCAL SERVICE 以外なら、Windows Time Service 以外の人やスクリプトが時刻を変えた可能性を疑えます。さらに、GPO で NtpServer を設定している場合、単純にレジストリを見るだけでは実効設定を見誤ることがあるため、w32tm /query /configuration で有効設定を確認するのが安全です。 (Microsoft Learn)
5分でできる切り分け
最初にやることは、PDC の特定と、PDC・各 DC・障害端末の時刻源の見える化です。管理者権限のコマンド プロンプトで次を実行します。 (Microsoft Learn)
netdom query fsmo
w32tm /query /source
w32tm /query /configuration
w32tm /query /status /verbosenetdom query fsmo で PDC エミュレーターを含む FSMO 役割所有者を確認できます。w32tm /query /source は現在の時刻源、/configuration は実効設定、/status /verbose は詳細な同期状態を見るのに向いています。特に query /configuration を見る理由は、GPO で設定された値がレジストリ値より優先されるケースがあるためです。 (Microsoft Learn)
見るべき判断基準はシンプルです。ドメイン メンバーなら Type = NT5DS が基本、フォレスト ルート PDC なら外部時刻源を向いていること、DC で想定外の仮想化プロバイダーや手動 NTP になっていないことです。/query /status /verbose の Source に VM IC Time Synchronization Provider が見える場合は、仮想化ホスト側の時刻連携が効いている可能性があります。DC で意図せずこれが見えるなら、ホストとドメイン階層のどちらを正とする設計かを再確認してください。 (Microsoft Learn)
次に、実際にどれだけずれているかを測ります。DC 間比較と、基準サーバーとの差分確認は次のコマンドが使いやすいです。 (Microsoft Learn)
w32tm /monitor /computers:dc1,dc2,*pdc01
w32tm /stripchart /computer:pdc01 /dataonly /samples:5/monitor は複数台の比較、/stripchart は特定サーバーとの差分確認に向いています。もし w32tm /resync や stripchart で 「no time data was available」 のようなエラーが出るなら、時刻源の発見や到達性自体が壊れている可能性があります。その場合は System ログの Microsoft-Windows-Time-Service Event 129 も合わせて確認してください。 (Microsoft Learn)
時刻ずれに見えても、実は KDC へ到達できていないだけのこともあります。次のコマンドで DC 検出を確認し、あわせて Kerberos の 88/TCP・UDP と W32Time の 123/UDP、LDAP の 389/TCP・UDP などが通るかを見ます。 (Microsoft Learn)
nltest /dsgetdc:contoso.local /force /kdcログを見るときは、次の4つを押さえると判断が早くなります。
- DC の Security ログで 4768 / 0x25
KRB_AP_ERR_SKEWが出ている。 (Microsoft Learn) - クライアントやサーバーで Event ID 4 /
KERB_AP_ERR_SKEWが出ている。 (Microsoft Learn) - Security 4616 で
SubjectがLOCAL SERVICE以外になっている。 (Microsoft Learn) DCDIAGでis not advertising as a time serverが出ている。 (Microsoft Learn)
復旧手順
復旧は必ず上流から下流へ進めます。下位メンバーを先に手で合わせても、上流の時刻源が狂ったままなら、また戻ります。PDC を直してから DC、最後にメンバーです。 (Microsoft Learn)
- フォレスト ルート PDC の時刻源を正します。
PDC ではType = NTP、AnnounceFlags = 5、NtpServerの設定、NTP サーバー機能の有効化が基本です。固定ポーリングや不安定回線ではAnnounceFlags = 0xAを検討します。設定変更後は Windows Time サービスを再起動します。 (Microsoft Learn) - 非 PDC の DC とメンバーをドメイン階層に戻します。
手動 NTP に寄っているサーバーは、まず既定のdomhierに戻すほうが安全です。 (Microsoft Learn)
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32timeこの手順は、手動指定の時刻源から Active Directory のドメイン階層へ戻す公式のやり方です。PDC 以外の DC やメンバーに向いています。 (Microsoft Learn)
- 時刻源を再検出して再同期します。
PDC と下位サーバーの構成を戻したら、再検出付きの再同期をかけます。 (Microsoft Learn)
w32tm /resync /rediscover/rediscover は、ネットワーク上の新しい時刻源や更新された時刻源を再探索してから再同期するため、構成変更直後の復旧に向いています。 (Microsoft Learn)
- 時刻サーバーとして広告できているかを確認します。
設定だけ直しても、DC が時刻サーバーとして正しく見えていなければ、クライアントは安定しません。 (Microsoft Learn)
dcdiag
w32tm /stripchart /computer:<PDC名> /dataonly /samples:5dcdiag は既定で Advertising テストを含みます。stripchart で NTP 応答とオフセットを確認し、dcdiag で DC が広告できているかを見れば、設定だけでなく実動作まで確認できます。 (Microsoft Learn)
- 認証だけ残るなら Kerberos チケットを更新します。
時刻が直っても、既存セッションのチケットが残っていると失敗が続くことがあります。ログオフ・ログオンが確実ですが、まずはチケット破棄でも切り分けできます。 (Microsoft Learn)
klist purge
klist purge -li 0x3e7klist purge は現在のログオン セッション、klist purge -li 0x3e7 はシステム コンテキストのチケット削除で使います。実行には十分な権限が必要で、破棄後は再認証が必要になります。 (Microsoft Learn)
数時間以上ずれているときは一気に直さない
時刻が数日、数か月、あるいは年単位で飛んでいる場合は、Kerberos 失敗だけで済まないことがあります。Microsoft は、コンピューター アカウントや信頼関係のパスワード不整合、AD レプリケーションの問題まで波及しうると説明しています。また、W32Time には MaxPosPhaseCorrection と MaxNegPhaseCorrection があり、DC では既定 48 時間の境界を超える大きな補正はそのまま受け付けない設計です。大きなズレでは、まず正しい基準時刻を持つ PDC を確定し、その後に下流へ直してください。 (Microsoft Learn)
なお、Kerberos の許容差を広げて延命する方法はおすすめしません。Microsoft は既定どおり 5 分を推奨しており、まず直すべきは許容差ではなく、時刻系そのものです。 (Microsoft Learn)
更新や権限が絡むときの見方
環境更新の直後に発生したなら、Windows Time の設定が戻っていないかを優先確認してください。Microsoft の既知事象では、インプレース アップグレード後に PDC が外部時刻源との接続を失い、時刻サーバーとして広告しなくなり、他の DC やメンバーもドメイン階層を使えなくなるケースがあります。変更前後を比較したいなら、w32tm /query /configuration /verbose の出力を保存して見比べるのが実務的です。 (Microsoft Learn)
また、Kerberos のトラブルシューティング ガイダンスでは、DC・クライアント・対象サーバーの Windows Update とアプリ更新状態を確認し、更新後は再起動してから再度認証を試すことが案内されています。特に「DC だけ更新済み」「アプリだけ再起動なし」といった中途半端な状態は、切り分けを難しくします。 (Microsoft Learn)
権限まわりでは、Change the system time の見直しが必要です。この権利は時刻同期処理にも必要で、DC の既定では Administrators、Server Operators、Local Service が持っています。加えて、Security 4616 を監査して LOCAL SERVICE 以外の主体による時刻変更を拾えば、管理者の手作業やバッチ、監視製品が時刻を変えていないかを追えます。 (Microsoft Learn)
再発防止の実務ポイント
- 外部 NTP を見るのはフォレスト ルート PDC だけにし、他の DC とメンバーはドメイン階層へ寄せます。ドメイン参加マシンを個別に外部 NTP へ向けると、AD の設計とずれます。 (Microsoft Learn)
- アップグレード後や GPO 変更後は
w32tm /query /configurationとdcdiagを定例確認にします。設定が入ったつもりでも、実効設定や広告状態が壊れていることがあります。 (Microsoft Learn) - 仮想 DC はホストとゲストの時刻源を設計書に明記し、VMICTimeSync を使うか使わないかを環境単位で決めます。saved state やホスト時刻連携を含めた一貫性が重要です。 (Microsoft Learn)
- 4616、4768/0x25、Event 129、DCDIAG の Advertising 警告を監視すると、ユーザー問い合わせ前に異常を検知しやすくなります。 (Microsoft Learn)
まとめ
Active Directory で時刻ずれが Kerberos 認証失敗を招くとき、見る順番は PDC → DC → メンバーです。Kerberos の 5 分ルールだけ覚えても解決せず、実際には PDC の時刻源、ドメイン階層、仮想化、GPO、更新、権限が絡みます。根本解決は「正しい基準時刻を 1 つ作り、下流をそこへ揃える」ことです。 (Microsoft Learn)
今すぐ動くなら、次の順番で進めるのが安全です。
netdom query fsmoで PDC を特定する。 (Microsoft Learn)- PDC・各 DC・障害端末で
w32tm /query /sourceとw32tm /query /configurationを確認する。 (Microsoft Learn) - 非 PDC の DC とメンバーを
w32tm /config /syncfromflags:domhier /updateでドメイン階層へ戻す。 (Microsoft Learn) w32tm /resync /rediscoverで再同期し、dcdiagとw32tm /stripchartで確認する。 (Microsoft Learn)- まだ認証が残る端末だけ
klist purgeか再ログオンでチケットを更新する。 (Microsoft Learn)
コメント