使った、いわゆるADのドメイン環境の時刻同期についてのメモです。仕組みでセキュリティを担保するために、デフォルトで5分以上の時間差があった場合に認証に失敗してしまいます。ドメインコントローラーとクライアントで、時刻が同期されていることが必須です。ちなみに、デフォルトで構築したドメイン環境では、クライアントはドメインコントローラーと時刻同期をするように設定されます。なにか障害が発生して初めて気になる箇所かもしれないです。ドキュメントをご覧ください。関係の質問を受けることが多いのですが、今年度は時刻同期関連の運用障害が何回かありまして、一度、自分の知識を整理するという目的です。質問対応をすることで、自分もあまりちゃんと理解してなかったんだなと思ったのですが。今回実験した環境は、以下の通りです。最初から構築した環境です。サーバ上に構築し、統合サービスの時刻同期は時間をずらす時だけONとし、その他の時はOFFとしています。時刻同期クライアントPCはドメインに参加をすると、ドメインコントローラーと時刻同期するのが規定の設定です。コマンドプロンプトより、以下のコマンドを実行すると、Typeが「NT5DS」となっていると思います。最初にインストールしたフォレストルートドメインのPDCエミュレータの役割を持つドメインコントローラーは、そのドメイン環境の基準のNTPサーバとなるみたいです。基準ですので、外部のNTPサーバと時刻同期をとっておくのがよさそうです。その他のドメインコントローラーは、同期する優先順位はありますが、ドメインコントローラー同士で時刻同期をするような感じです。優先順位などの詳細は、以下のMSのドキュメントを参照ください。以下のGPOの設定によるものです。ポリシーの「コンピューターの時計の同期の最長トレランス」が閾値となります。チケットを更新できる最長有効期間」の範囲内であれば、ログインはできるみたいです。ログインはできてもGPOが正しく適用できないなどの目には見えない問題を抱えた状態ではありますが。]復旧方法は、時刻を直すだけなのですが、発生をどうやって見つけるかってところが重要です。ドメインのメンバサーバなどであれば、イベントログ監視でエラーの通知でわかりそうですね。クライアントPCは、なかなかイベントログの監視までしないと思いますので、ここはなかなか見つけにくいかもですね。ログインできなくなって初めて連絡が来るような気がします。ログインできなくなってしまったら、1度ドメインを離脱して、時刻を直して、再度、ドメイン参加するなどの手順が必要となります。ドメインコントローラーの1台が5分以上時刻がずれた場合ドメインコントローラーのうちの1台が5分以上時刻がずれた場合、そのドメインコントローラーは、他とレプリケーションができなくなります。今回実験したときに見つけた、イベントログたち。ダメそうな感じのが沢山でます。このダメそうなドメインコントローラーを使って認証をしようとすると認証できなかったり、色々と起こりそうな気がします。早めに気づければいいんですが、これも時間が経つとわけわからんになりそうな感じですね。サイトとサービス]を使ってレプリケートをしようとしても、こんなエラーが出ます。レプリケートの状態を確認しても、こんな感じで、レプリケートできてないのが確認できます。この状態は、イベントログにエラーログがあがるので、イベントログ監視だけしてればどうにかなりますし、発見したらそのマシンの時間を合わせてあげれば解決するはずです。時刻を合わせて、レプリケートの状態とかドメインコントローラーが正常に動作しているとかは確認しないといけないですけどね。これらの事象は、時間がずれているってわかって一時対処として、手で時刻を修正することになると思います。オンプレミスの場合で多いのは、CMOSの時間がずれている状態で再起動したときに、OSから見える時間がずれてしまう場合のような気がします。あとは、時刻同期がうまく動いていない場合。以下のコマンドで確認します。/status結果はこんな感じ。ソースがドメインコントローラーになっていればいい感じです。CMOS等になっていたら、うまく時刻同期できてないかも。NTPサーバを指定している場合は、ソースはNTPサーバになっていればOK。同期先を探して再同期をさせる場合もし、同期先がCMOSになっているのでしたら、うまく同期ができてないので、一度再同期を試行してみるといいと思います。/rediscoverこれをやった後に、同期の状態を確認した場合、なんも問題が起きてないときはこんな感じ。失敗するようなら、何か設定がおかしい感じがします。ドメイン環境で同期先の一覧を取得する場合ドメイン環境で時刻同期の同期先を取得する場合は、以下のコマンドを実行します。ワークグループ環境の場合、エラーにみたいですが、自分は試したことがないです。/monitor実行結果はこんな感じ。4警告:逆名前解決が最適な方法です。実装間で異なっており、IPアドレスを使用していない場合があるため、名前が正しくない可能性があります。同期先を設定を確認する場合は、以下のコマンドを実行します。/verboseドメインに参加しているクライアントで実行した時の実行結果はこんな感じです。TypeがNT5DSになってる場合は、ドメイン環境の中での同期の仕組みがうごいていて、NTPになってる場合は個別にNTPサーバに参照しに行ってるって感じですね。ポートを利用するみたいです。通信ポートの確認は、以下のコマンドで確認します。-aonb結果は試してみてください。「:123」で結果を検索すればすぐにわかると思いますので。UDP:123ポートが正しくバインドできないエラーがあったみたいで、KBがリリースされています。ファイアウォール」の受信の規則をみたのですが、123ポートで許可というルールは見つけられませんでした。svchost経由でw32tmが動いてるっぽいから、その辺の絡みで見せてないのかな・・?ドメインコントローラ側では、以下の設定がありました。デバッグログをとることもできます。あるみたいなので、自分が参考にさせてもらった、「素敵なおひげさん」のブログのリンク張らせてもらっちゃおっと。(許可もらってないけど・・)その他その他には、パケットキャプチャ取って通信内容を確認するのもいいと思います。traceFile=ほげほげとかで、取れますので。あと、問題発生時の切り分けの時はイベントログを見るのも大切です。見るときは、エラーや警告だけでなく、該当時間の情報のログも見ておいた方がよいかと。その他には、ドメインコントローラーのリプレイスの時に、リプレイス前のドメインコントローラーを正しくドメイン離脱をさせてなくDNSに積まれたままになっていて、その結果クライアントが存在しないドメインコントローラーに同期を試みてエラーとなったケースもあるみたいですね。まとめドメイン環境の時刻同期は、デフォでそのまま動くので、問題がおきると原因がわかりにくい感じがします。あと、今時ハードウェアクロックがずれることがあるのか?って言われることもあるので、本質的な原因切り分けと違う労力も必要だったりってときもあるし、色々やっちゃってるケースもあるし。あと、ドメインコントローラ2台構成の場合に、2台とも外のNTPサーバと時刻同期をしている環境も多く見るけど、1サイトで運用している場合だったらPDCエミュレータの役割をもつドメインコントローラーだけでいいんじゃないかなって思います。連携したりと、クラウドにも張り出すことが増えると思うので、一貫した時刻を持たせるってことは運用上も大切になるのかもしれないなってちょっと思いました。コメントをキャンセルメールアドレスが公開されることはありません。Serverのインストール5/27,28に行われたde:codeに参加してきました。