AD のドメイン環境での時刻同期のメモ

Active Directory

Active Directory Domain Services を使った、いわゆるADのドメイン環境の時刻同期についてのメモです。

ドメイン環境においては、Kerberos 認証の TGT の仕組みでセキュリティを担保するために、デフォルトで5分以上の時間差があった場合に認証に失敗してしまいます。
ですので、ドメインコントローラーとクライアントで、時刻が同期されていることが必須です。

ちなみに、デフォルトで構築したドメイン環境では、クライアントはドメインコントローラーと時刻同期をするように設定されます。
ですので、なにか障害が発生して初めて気になる箇所かもしれないです。

Windows Server で構築した環境での時刻同期について、詳しく知りたい方は、MS のドキュメントをご覧ください。
https://technet.microsoft.com/en-us/library/cc773013(v=WS.10).aspx

今回のブログを書いたきっかけ

今回のブログを書くきっかけは、職場でActive Directory 関係の質問を受けることが多いのですが、今年度は時刻同期関連の運用障害が何回かありまして、一度、自分の知識を整理するという目的です。

ただ、質問対応をすることで、自分もあまりちゃんと理解してなかったんだなと思ったのですが。。。

今回実験した環境は、以下の通りです。

  • AD サーバは、Windows Server 2012 R2 Update
  • クライアントPCは、Windows 7 sp1 Enterprise

※ ADの環境は、Windows Server 2012 R2 で最初から構築した環境です。
※ これらは、Hyper-V サーバ上に構築し、統合サービスの時刻同期は時間をずらす時だけONとし、その他の時はOFFとしています。

ドメイン環境の時刻同期の概要

(1).クライアントPC の時刻同期

クライアントPCはドメインに参加をすると、ドメインコントローラーと時刻同期するのが規定の設定です。

クライアントPC のコマンドプロンプトより、以下のコマンドを実行すると、Typeが「NT5DS」となっていると思います。

[コマンド]


w32tm /query /configuration

[ドメイン環境]

(2).ドメインコントローラーの時刻同期

最初にインストールしたフォレストルートドメインのPDCエミュレータの役割を持つドメインコントローラーは、そのドメイン環境の基準のNTPサーバとなるみたいです。基準ですので、外部のNTPサーバと時刻同期をとっておくのがよさそうです。

その他のドメインコントローラーは、同期する優先順位はありますが、ドメインコントローラー同士で時刻同期をするような感じです。

優先順位などの詳細は、以下のMSのドキュメントを参照ください。
https://social.technet.microsoft.com/wiki/contents/articles/18573.time-synchronization-in-active-directory-forests.aspx

クライアントPC の時刻が 5 分以上ずれた場合

しきい値の5分は、 以下のGPOの設定によるものです。

Kerberos ポリシーの「コンピューターの時計の同期の最長トレランス」が閾値となります。

ただ、この閾値を超えても「ユーザ チケットを更新できる最長有効期間」の範囲内であれば、ログインはできるみたいです。
ログインはできてもGPOが正しく適用できないなどの目には見えない問題を抱えた状態ではありますが。

[クライアントPCのエラーのイベントログ]


[rsop.msc ]

復旧方法は、時刻を直すだけなのですが、発生をどうやって見つけるかってところが重要です。

ドメインのメンバサーバなどであれば、イベントログ監視でエラーの通知でわかりそうですね。
クライアントPCは、なかなかイベントログの監視までしないと思いますので、ここはなかなか見つけにくいかもですね。
多分、ログインできなくなって初めて連絡が来るような気がします。

ログインできなくなってしまったら、1度ドメインを離脱して、時刻を直して、再度、ドメイン参加するなどの手順が必要となります。

ドメインコントローラーの1台が5分以上時刻がずれた場合

ドメインコントローラーのうちの1台が5分以上時刻がずれた場合、そのドメインコントローラーは、他とレプリケーションができなくなります。

今回実験したときに見つけた、イベントログたち。
色々ダメそうな感じのが沢山でます。

このダメそうなドメインコントローラーを使って認証をしようとすると認証できなかったり、色々と起こりそうな気がします。
早めに気づければいいんですが、これも時間が経つとわけわからんになりそうな感じですね。

[Active Directory サイトとサービス]を使ってレプリケートをしようとしても、こんなエラーが出ます。

[repadmin /showerpl ] でレプリケートの状態を確認しても、こんな感じで、レプリケートできてないのが確認できます。

でも、この状態は、イベントログにエラーログがあがるので、イベントログ監視だけしてればどうにかなりますし、発見したらそのマシンの時間を合わせてあげれば解決するはずです。
時刻を合わせて、レプリケートの状態とかドメインコントローラーが正常に動作しているとかは確認しないといけないですけどね。

これらの事象は、時間がずれているってわかって一時対処として、手で時刻を修正することになると思います。
オンプレミスの場合で多いのは、CMOSの時間がずれている状態で再起動したときに、OSから見える時間がずれてしまう場合のような気がします。

あとは、時刻同期がうまく動いていない場合。

最後に時刻同期した時の同期先の確認

以下のコマンドで確認します。


w32tm /query /status

結果はこんな感じ。ソースがドメインコントローラーになっていればいい感じです。
もし、CMOS等になっていたら、うまく時刻同期できてないかも。
※ NTPサーバを指定している場合は、ソースはNTPサーバになっていればOK。

同期先を探して再同期をさせる場合

もし、同期先がCMOSになっているのでしたら、うまく同期ができてないので、一度再同期を試行してみるといいと思います。


w32tm /resync /rediscover

これをやった後に、同期の状態を確認した場合、なんも問題が起きてないときはこんな感じ。
resync に失敗するようなら、何か設定がおかしい感じがします。

ドメイン環境で同期先の一覧を取得する場合

ドメイン環境で時刻同期の同期先を取得する場合は、以下のコマンドを実行します。
ワークグループ環境の場合、エラーにみたいですが、自分は試したことがないです。


w32tm /monitor

実行結果はこんな感じ。ドメインコントローラーが2台いて、PDCエミュレータの役割をもつドメインコントローラーは外部のNTPサーバと同期している環境なのが丸わかりw
エラーになった場合は、クライアントのTypeがNT5DSになってないのか、もしくはDNSでちゃんと引けてきてない場合かな?


w2k12r2ad01.w12r2dom.local *** PDC ***[192.168.0.121:123]:
ICMP: 0ms 遅延
NTP: +0.0000000s w2k12r2ad01.w12r2dom.local の時刻からのオフセット
RefID: ntp2.jst.mfeed.ad.jp [210.173.160.57]
階層: 3
w2k12r2ad02.w12r2dom.local[192.168.0.122:123]:
ICMP: 0ms 遅延
NTP: -0.0012255s w2k12r2ad01.w12r2dom.local の時刻からのオフセット
RefID: w2k12r2ad01.w12r2dom.local [192.168.0.121]
階層: 4

警告:
逆名前解決が最適な方法です。タイム パケット内の
RefID フィールドは NTP 実装間で異なっており、IP
アドレスを使用していない場合があるため、名前が正しくない可能性があります。

時刻同期の同期の設定内容を確認する場合

同期先を設定を確認する場合は、以下のコマンドを実行します。


w32tm /query /configuration /verbose

ドメインに参加しているクライアントで実行した時の実行結果はこんな感じです。
TypeがNT5DSになってる場合は、ドメイン環境の中での同期の仕組みがうごいていて、
NTPになってる場合は個別にNTPサーバに参照しに行ってるって感じですね。


[構成]

EventLogFlags: 2 (ローカル)
AnnounceFlags: 10 (ローカル)
TimeJumpAuditOffset: 28800 (ローカル)
MinPollInterval: 10 (ローカル)
MaxPollInterval: 15 (ローカル)
MaxNegPhaseCorrection: 4294967295 (ローカル)
MaxPosPhaseCorrection: 4294967295 (ローカル)
MaxAllowedPhaseOffset: 300 (ローカル)

FrequencyCorrectRate: 4 (ローカル)
PollAdjustFactor: 5 (ローカル)
LargePhaseOffset: 50000000 (ローカル)
SpikeWatchPeriod: 900 (ローカル)
LocalClockDispersion: 10 (ローカル)
HoldPeriod: 5 (ローカル)
PhaseCorrectRate: 1 (ローカル)
UpdateInterval: 30000 (ローカル)

FileLogName: (未定義または未使用)
FileLogEntries: (未定義または未使用)
FileLogSize: 0 (未定義または未使用)
FileLogFlags: 0 (未定義または未使用)

[タイム プロバイダー]

NtpClient (ローカル)
DllName: C:\Windows\system32\w32time.dll (ローカル)
Enabled: 1 (ローカル)
InputProvider: 1 (ローカル)
CrossSiteSyncFlags: 2 (ローカル)
AllowNonstandardModeCombinations: 1 (ローカル)
ResolvePeerBackoffMinutes: 15 (ローカル)
ResolvePeerBackoffMaxTimes: 7 (ローカル)
CompatibilityFlags: 2147483648 (ローカル)
EventLogFlags: 1 (ローカル)
LargeSampleSkew: 3 (ローカル)
SpecialPollInterval: 3600 (ローカル)
Type: NT5DS (ローカル)
NtpServer: (未定義または未使用)

VMICTimeProvider (ローカル)
DllName: C:\Windows\System32\vmictimeprovider.dll (ローカル)
Enabled: 1 (ローカル)
InputProvider: 1 (ローカル)
NtpServer (ローカル)
DllName: C:\Windows\system32\w32time.dll (ローカル)
Enabled: 0 (ローカル)
InputProvider: 0 (ローカル)

通信ポートを確認する場合

時刻同期には、UDP:123 のポートを利用するみたいです。

通信ポートの確認は、以下のコマンドで確認します。


netstat -aonb

結果は試してみてください。「:123」で結果を検索すればすぐにわかると思いますので。

ちなみに、Windows 2003,2008,2008R2 では、UDP:123ポートが正しくバインドできないエラーがあったみたいで、KBがリリースされています。
https://support.microsoft.com/ja-jp/kb/2493006

ちなみに、Windows 7 の環境で、「セキュリティが強化された Windows ファイアウォール」の受信の規則をみたのですが、123ポートで許可というルールは見つけられませんでした。svchost経由でw32tmが動いてるっぽいから、その辺の絡みで見せてないのかな・・?

ドメインコントローラ側では、以下の設定がありました。

時刻同期のデバックログ

w32tm のデバッグログをとることもできます。

色々あるみたいなので、自分が参考にさせてもらった、「素敵なおひげさん」のブログのリンク張らせてもらっちゃおっと。
(許可もらってないけど・・)

w32tmデバッグログについて - しばたテックブログ
w32tmコマンドでデバッグログを取得する方法ついては@ITさんの以下の記事に詳しく記載されていますが、個人的に補足しておきたい点があったので備忘録的にエントリを書いておきます。 Windowsネットワーク時刻同期の基礎とノウハウ 第2回 ...

その他

その他には、パケットキャプチャ取って通信内容を確認するのもいいと思います。

netsh trace start capture=yes traceFile=ほげほげ

とかで、取れますので。

あと、問題発生時の切り分けの時はイベントログを見るのも大切です。
見るときは、エラーや警告だけでなく、該当時間の情報のログも見ておいた方がよいかと。

その他には、ドメインコントローラーのリプレイスの時に、リプレイス前のドメインコントローラーを正しくドメイン離脱をさせてなくDNSに積まれたままになっていて、その結果クライアントが存在しないドメインコントローラーに同期を試みてエラーとなったケースもあるみたいですね。

まとめ

ドメイン環境の時刻同期は、デフォでそのまま動くので、問題がおきると原因がわかりにくい感じがします。

あと、今時ハードウェアクロックがずれることがあるのか?って言われることもあるので、本質的な原因切り分けと違う労力も必要だったりってときもあるし、色々やっちゃってるケースもあるし。。。

あと、ドメインコントローラ2台構成の場合に、2台とも外のNTPサーバと時刻同期をしている環境も多く見るけど、1サイトで運用している場合だったらPDCエミュレータの役割をもつドメインコントローラーだけでいいんじゃないかなって思います。

今後、オンプレのドメインコントローラは、Azure に張り出してVNETでつないだIaaSの中にRODC(読み取り専用)を置いたり、ADFSで外部サービスと連携したり、Azure Active Directory と連携したりと、クラウドにも張り出すことが増えると思うので、一貫した時刻を持たせるってことは運用上も大切になるのかもしれないなってちょっと思いました。

コメント

タイトルとURLをコピーしました