ソースとして使用している外部NTPサーバーの1つ（現在はプライマリサーバー）は、NTP呼び出しに応答していないようです。残念ながら、コアルーター（Cisco 6509）では、NTP機能は予想どおりにセカンダリNTP外部サーバーに切り替わりませんでした。その結果、主要な内部NTPソースであるコアルーターは2分遅れています。

外部NTPソースを現在動作しているものにすることで、外部ルーターの問題を修正する予定です。 2分間の変更がユーザーとサービスにどの程度影響するのでしょうか？特に最近では、証明書ベースの認証に大きく依存しています。

私たちはWindows / Ciscoのショップです。

内部NTPセットアップ：

[コアルーター1 / Cisco 6509]：
2つの外部NTPサーバー（プライマリサーバーがNTP呼び出しに応答していない）を監視

[コアルーター2]：
コアルーター1（プライマリ）と同期、動作中の外部ルーター（セカンダリ）

[その他のシスコネットワークデバイス]：
コアルーター1（プライマリ）、コアルーター2（セカンダリ）との同期

[ドメインコントローラー]：
コアルーター1との同期

[すべてのWindowsクライアント/サーバー]：
ドメインコントローラーとの同期

極めて正確な計時がミッションクリティカルである場合を除き、クロックが2分変化することを除き、ユーザーに認識できる影響はありません。

可能性のある例外は、大きな変更の結果としてNTPサーバーが「異常」であると宣言する場合です（影響を受けるシステムでNTPサービスを再起動してクロックを強制的に同期させる必要がありますが、停止）。

これを修正している間、他のいくつかのポインタがあります：

• 外部のNTPソースを参照するシステムを、パブリックNTPプールプロジェクトの複数の（4〜5）サーバー（できれば地理的に適切なサーバー）を参照するように構成する必要があります。
  より多くのNTPサーバーを使用すると、選択アルゴリズムが壊れたり狂ったりするものを無視し、時計を正確に保つことができます。

• あなたのような構成では、外部クロックソース（互いにではない）をポイントCore Router 1しCore Router 2ます。
  これにより、相互に数ミリ秒以内にあるはずの独立して同期した2つのクロックが得られますが、ルーターの1つが異常になったとしても、もう1つを傷つけることはできません。

• あなたのような構成では、ドメインコントローラーを両方のコアルーターに向けます（1つがダウンするのを防ぐため）。
  クロックが異常な状態にならないように保護したい場合は、3番目の権限のあるNTPサーバーを追加する必要があります（またはルーターの1つを2回リストし、気が散らないものではないことを望みます）。

Windowsのドメインのデフォルトでは、認証が機能しなくなる前に時間を+/- 300秒オフにすることができるため、問題ありません。 ドメインレベルのGPOでタイムスキューの許容範囲を変更する方法についても言及している、このテーマに関するかなり網羅的な記事を次に示します。それはATのComputer Configuration> - Policies- > Windows Settings- > Security Settings- > Account Policies- > Kerberos Policy- > Maximum tolerance for computer clock synchronization。

ただし、信頼できるタイムソース（通常はWindowsドメインでPDCエミュレーターの役割を保持しているドメインコントローラー）は、などの外部ntpソースと同期する必要がありますpool.ntp.org。 Technetの詳細については、こちらをご覧ください。

そして、他の答えに応じて、これはダウンタイムを必要としません。信頼できるタイムソースを再指定するだけで、ドメインに参加している他のコンピューターも同様に同期されます。

編集：@ voretaq7がそれを言及したので、私たちは1つのシステムだけが外部のタイムソース、私たちのPDCエミュレータを見ることができることを指摘する必要があります。ネットワークギアを含むすべてのデバイスが同期します。ネットワーク機器は時間のずれにより認証を拒否しませんが、Kerberosを使用するドメインに参加しているコンピューター（これはすべて私たちにとっては）であるため、これはより良い配置であることがわかります。そのため、ネットワーク機器で正確な時間をとることは特に重要ではありませんが、Windowsサーバーでも1時間ごとの従業員のために時間管理ソフトウェアを実行しているため、Windowsシステムでは二重になっています。

Windowsクライアントは、実際にはログインに問題はありません。Maximum tolerance for computer clock synchronization最近、ポリシーの説明はかなり不正確です。

クロックがひどく間違っているクライアントは、クロック間のスキューを確立するサーバーから応答を受け取ります-その後、認証は正常に進みます（クライアントは、見かけのクロックスキューを考慮して自身を調整します）。

説明は1つの点について正しいです。ポリシーは依然としてリプレイ攻撃のタイマーを効果的に設定しますが、正当なトラフィックに関しては、通信は大きなクロックスキューに対して堅牢です。

詳細については、このMS KBの記事を参照してください。

コアCisco機器以外の他のNTPサーバーを検討することを検討してください。深刻なNTPトラフィックは、ネットワークの問題を引き起こす可能性のあるCisco機器に高いCPU負荷を与えます。

明らかに、小さなダウンタイムをスケジュールすることはできませんか？影響を受けるすべてのサーバーでntpサービスを再起動するために、ダウンタイムをプッシュします。それが不可能な場合は、しばらく待つ必要があります。

（これをvortaq7の答えにコメントするつもりでしたが、多くの人がこの間違いを犯すので、それはそれ自体で繰り返すに値すると思います。）

NTPのアルゴリズムが正しい時間に正確に収束するためには、少なくとも3つ（好ましくは4〜6）の時間ソースが必要です。NTPに2つの主要なソースしかなく、両方ともかなりの量が出ている場合、NTPにはどちらを信頼すべきかを知る方法がありません。

これを理解する上で最も大きな助けとなったのは、サンブループリントの9ページにある「NTPを使用したシステムクロックの制御と同期、パートIII：NTPの監視とトラブルシューティング」の図でした。このドキュメントは、OracleがSunを購入したときに表示されなくなりましたが、Wayback Machineで確認できます。また、タイトルを検索すると、ウェブの周りにたくさんのヒットがあります。