今回は表題にあるエラーでWindowsログオンができない場合の1解決事例をご報告します。
Active Directory環境限定の話ではありますがシステムの内蔵時計が重要だという一つのシステム管理現場の話としてご覧ください。
環境は、以下の環境です。
OS：Windows7、Windows8.1の混在環境
Professionalエディションのみ、Homeエディションはありません。
Active Directoryでドメインを構成している
症状は以下です。
ドメインコンピュータのうち、何台かでWindowsログオン時にドメインアカウント指定でログオンを試行すると
「ユーザ名またはパスワードが間違っています」
と表示されログオンに失敗する。
パスワードに誤りはない、ローカルのユーザアカウントでログオンは成功する。（ローカルAdministratorなど）
以下の原因でした。
ドメインコントローラとの内部時計の時刻差が5分以上ずれがある。
対処法：
PC,サーバの内部時計を修正しドメインコントローラの内部時計と同一（5分以内の時間差）にする。
てっきりドメインコントローラの内部時計にドメインのメンバ（サーバもクライアントも）は時刻同期する、と認識していたのですがそういうわけではないようです。
さらに今回話をややこしくしたのが、Hyper-V上のゲストOSでドメインクライアント（OS：Windows7）を動作していたことが誤認の原因でした。
最初はセキュアチャネルの破損を疑ってドメインの再参加をしましたが、症状は解決せず、原因が不明なまましばらく時が過ぎていました。
よくよく見てみると、ゲストOSのWindows7だけではなく、Hyper-VホストOS側もドメインコントローラとの時刻差が5分以上になっていました。
ゲストOSはホストOSのシステム時計から時刻を同期する（のがデフォルト）ようになっているので、Hyper-VホストOSの時刻を正確にしておかなければゲストOSのドメイン参加クライアントは全滅です。
システム時刻はActive Directory管理の基本でしたが、ついうっかりと時刻差が出ているのを見過ごしていました。
Active Directoryのドメインコントローラはイントラネット内の時計サーバ（clockspeed：Debian8 jessieでもclockspeedが使いたい。 - treedown’s Report）に対して時刻同期を実施しているので、ある程度信頼できる状態なのですがドメイン内のクライアントPCなどはあまり厳密に時刻同期を考えてはいませんでした。
しかも一部のクライアントは2台あるドメインコントローラのうち、PDCエミュレータではない方のドメインコントローラを参照していました。このため、ドメイン内でさらに動作の差異が生じ問題の切り分けができていませんでした。
※Active Directory内で時刻の基準となる時計はPDCエミュレータの役割を有しているドメインコントローラの時計を基準時計としてドメイン全体の時刻の時差について判定をしています。
これが5分以上ズレてしまうことで、Active Directoryのログオン認証処理に支障をきたします。
よって時計を修正します。
1) 手動で5分以内に修正する
2) w32tmコマンドで修正、NTPサーバを指定して自動同期する
3) サードパーティー（フリーソフト）などで時刻同期を実行する
どれで実施するにしろ「ドメインコントローラとの時刻差が5分以内になること」が重要です。
Active Directory環境環境にて「ユーザ名またはパスワードが間違っています」のエラーが出てログオンが成功しない場合の解説と対処方法は以上になります。
Active Directoryの内蔵時計の時刻同期
大切です。
