treedown’s Report

システム管理者に巻き起こる様々な事象を読者の貴方へ報告するブログです。会社でも家庭でも"システム"に携わるすべての方の共感を目指しています。

※https化しました。その影響でしばらくリンク切れなどがあるかもしれませんが徐々に修正していきます。 リンク切れなどのお気づきの点がございましたらコメントなどでご指摘いただけますと助かります。

RDP認証エラーで確認したい時計

今日はリモートデスクトップの認証エラーが発生した際に確認してみたいポイントをご報告します。

この記事の発端となったのは、以下のエラーが出てリモートデスクトップ接続ができなかったときのことです。

エラーの内容

----------------------------------------------
[Window Title]
リモート デスクトップ接続

[Content]
認証エラーが発生しました。
ローカル セキュリティ機関にアクセスできません

リモート コンピューター: COMPUTERNAME
パスワードの有効期限が切れていることが原因である可能性があります。
パスワードの有効期限が切れている場合は、パスワードを更新してください。
サポートが必要な場合は、管理者またはテクニカル サポートに問い合わせてください。

[OK]
----------------------------------------------
このエラーは実はエラーメッセージとエラーの要因が全くかみ合っていないエラーメッセージ出力となっています。

要因

エラーメッセージにあるようなパスワードの問題は全くない(考えられない)、という場合に
Active Directory環境でこれが出てきたときは、対象のローカルコンピュータの内蔵時計(システム時計)を疑ってみるのは一つのトラブルシューティングの確認事項となります。
特に久々に起動したPCの場合時刻がくるっていることが多いです。

コンピュータの内部時計に関しましては本ブログでもいくつか記事になっておりますが、PCの内蔵時計が狂っている場合には認証エラーが発生する、という覚え方をしてもいいと言えます。

以前にも似たようなことがありました。
ユーザ名またはパスワードが間違っています - treedown’s Report

対象の環境がActive Directory環境の場合には時計を確認するポイントが増えます。

  1. 認証される、アクセス元となるPC
  2. 認証するActive Directoryのドメインコントローラ
  3. 認証を要求した、アクセス先となるサーバ(PC)

この3つの時計が合致している必要があります。(仕様上は、最低でも時刻のズレが5分以内に収まっている必要があります。)

システム時計はズレる

時計は意外とズレが生じます。Hyper-VのゲストOSともなると、

  1. ゲストインスタンス上での時計合わせ
  2. ホストOSとの統合サービスでの時計合わせ
  3. Active Directoryのドメインコントローラとの時刻同期

といったいくつかの時計合わせがバックグラウンドで動作しているために、誤った時刻ソースから時刻を取得して自時計を合わせてしまうと時計のズレによる認証エラーが発生する、という状況に陥ります。しかも気づきにくい。
最近ではWindows8以降クライアントHyper-Vも手軽に利用できるようになってきているので、自インフラ内のシステム時計の同期は普段から気を付けておいたほうがよさそうです。

PCの時計は認証やログ収集で利用される「重要なデータ」なのですが、それほど精度はよくありません。あまり精度を上げたとしてもそれほどメリットにならないからだと思われます。現代に「このPCはシステムの内蔵時計が他のPCより精度が高いです!」と言われても響く人はたぶん居ないから、特にメーカとしても力を入れる必要は感じないのがその理由の一つだと思います。PCにとって時計は信頼できる外部リソースから時刻データを収集して同期しましょう、という程度のデータでしかないからなんだと思います。

時計を合わせるときに

手動で現在の時刻を入力して時刻合わせをするのがもちろん手っ取り早いのですが、必ずしも手動で時刻合わせすることが手っ取り早くない状況だってありますね。対象の台数が多いとか物理的に別の場所に設置してあるからリモートデスクトップが使えないと時刻合わせができなくなる、とかです。
手動で時刻合わせするためにリモートデスクトップ接続しようと思ったのに上記の認証エラーで時刻合わせができない、というのは卵が先か鶏が先かの話にも思えます。

そこで、NTPですね。Windowsでも標準にNTPサービスは利用できますし、社内にLinuxサーバがあれば社内の時刻同期用にNTPサーバを用意する、ということもできます。
台数が多いのであれば一日一回、イントラネット上のNTPサーバに対して時刻同期するように全ノード(PC、サーバやマネージドスイッチ、UPSなども含めすべて、です)にNTPサーバとの時刻同期を実施するような設定を入れておけば、NTPサーバが刻んでいる時刻に一日一回の同期で時刻がそれほどまでに大きくズレるという事態も防ぐことはできます。
よし、NTPサーバを用意しよう、と思い立ったそこのシステム管理者の方、
LinuxでNTPサーバを構築するのであればオススメしたいのが、もう一ポイントあります。
このNTPに加えてこの記事

blog.treedown.net

ここにある、clockspeedというツールを組み合わせて、NTPでタイムソースと時刻を合わせつつ、自分自身の内蔵時計の正確性も上げるという二重の構えで時計サーバの時刻の正確性を確保する、というのがお勧めしたい構成です。
※ただしclockspeedの利用には、CPUがPentium互換でRDTSC命令という機能をカバーしている必要があります。ARMプロセッサなどではこれがないかもしれません。

このclockspeedはCPUのカウンタを利用してコンピュータの内蔵時計の進み方を制御することで正確な時刻に近い値を刻むことを実現するプログラムです。もともとはオフライン・オンラインに関わらず単体のPCが正確な時刻を刻み続けるために生まれたプログラムです。
NTPはオンラインが必須ですが、clockspeedはオフライン(社内LANなどから隔離されたクローズ環境)でもclockspeedがインストールされたLinuxを一台用意しておくだけで正確な基準時間の提供が可能になります。CPUの性能にもよりますが数週間に一回程度NTPサーバを参照して時刻を確認するだけで正確な時間をイントラネット内で提供できるようになります。

ある程度の規模になってくると時計サーバで社内LAN内に基準時計となる時刻が統一されているほうがトラブルは少なく済みます。(きっと)