Contents
セキュアチャネル破損とは
ドメインコントローラ(DC)で保持するコンピュータアカウントのパスワードとドメインメンバで保持しているコンピュータパスワードが不一致の場合に、ドメインメンバが OS 起動時にセキュアチャネルを確立できないことを言います。
・セキュアチャネルが確立するときのイメージ
・セキュアチャネルが破損するときのイメージ
セキュアチャネルが破損すると、ログオン試行時に「このワークステーションとプライマリドメインとの信頼関係に失敗しました。」といったメッセージが出て、ログオンできなくなるのが特徴です。
つまりドメインにログオンするには、まずセキュアチャネルを確立しないといけないのです。
基本的な対処方法
ドメインコントローラ(DC)で保持するコンピュータアカウントのパスワードとドメインメンバで保持しているコンピュータパスワードを一致させればよいのですが、その方法は以下の 3つが挙げられます。
ドメイン再参加
WORKGROUP に降格し、OS 再起動を行い、起動後に再度同ドメインに参加する方法です。
WORKGROUP に離脱するなり、ドメインに再参加なりは以下の画面から行いますが、
以下の手順でパッと上記画面が出てきますよ^^
1. “Windows キー” と “R” キーを押して [ファイル名を指定して実行] を起動し、
2. sysdm.cpl と入力して [OK] をクリックすると、上記の画面が出てきます。
また以下のページで GUI ではなく、コマンドによる自動離脱及び自動参加を紹介しているので、そちらも確認してみてください。
Test-ComputerSecureChannel
ローカル管理者アカウントでコンピュータにログオンして、Test-ComputerSecureChannel コマンドを利用して修復する方法で、最も簡単です。
Powershell を管理者権限で立ち上げ、以下のコマンドを実行します。
Test-ComputerSecureChannel -credential Administrator -repair
パスワード入力が求められるので、ドメインの Administrator のパスワードを入力し、True と返ってきたらセキュアチャネルの破損を修復できたことになります。
注意点として、Windows 8/Windows Server 2012 以降は既定で利用可能ですが、残念ながら Windows 7/Windows Server 2008 R2 では Powershell 3.0 以降でないと利用できません
Powershell バージョンは以下のコマンドで確認してください。
$PSVersiontable
Powershell バージョンをあげて、本コマンドを利用する場合には、過去に私が書いたページを参照ください。
ネットワーク ID ウィザード
クライアント OS のみに限って可能な手順になります。
サーバ OS の場合、ネットワーク ID という項目が存在しません。
1. “Windows ロゴキー” と “R キー” を同時に押して [ファイル名を指定して実行] を起動し、
2. sysdm.cpl と入力して [OK] をクリックする
3. [ネットワークID] をクリックする。
4. [ネットワークIDウィザード] が起動したら、[このコンピュータはビジネスネットワークの一部です…]を選択して、[次へ]をクリックする。
5. [ドメインを使用している] を選択して [次へ] をクリックする。
6. ドメイン参加のために必要な項目の一覧を表示されるので軽く確認して、[次へ]をクリックする。
7. ドメインユーザー名及びパスワード、ドメイン名を指定して、[次へ]をクリックする。
8. [ドメインにこのコンピューターのアカウントが検出されました…] というメッセージが出るので、[はい] をクリックする。
9. [ドメインユーザアカウントを追加しない] を選択し、[次へ]をクリックする。
10. 指定したユーザのアクセスレベルを適宜指定し、[次へ]をクリックする。
11. ウィザード最終画面で [完了] をクリックして、メッセージにしたがってコンピュータを再起動すると、ドメインへのログオンが可能に。
ドメイン再参加は OS 再起動が 2回必要ですが、こちらは 1回で済むので、少し楽になるかな、という感じですね。
例外ケース – DC間でのセキュアチャネル破損
これまでの話はドメインメンバーと DC間でセキュアチャネルが破損したときの話でしたが、
DC 同士でセキュアチャネルが破損することがあります。
DC 同士でセキュアチャネルが破損している場合、DC 間の複製(RPC通信)やドメインメンバから DC に対する LDAP 通信などが失敗します。
これは DC 間でセキュアチャネルが破損していることにより、Kerberos認証における事前認証の失敗や Kerberos認証で付与されたサービスチケットを復号化できなくなる事象が発生することによります。
せっかくなので、DC 間でセキュアチャネルが破損しているときに DC 間の複製が失敗する動きを図解してみようと思います。
なお、Kerberos認証の大体の動き(AS Request/Response や TGS Request/Response)について知見がないと理解が難しいかもしれません。
以下サイトの補講第4回～8回あたりを一読いただくことをオススメします。
DC 間でセキュアチャネルが破損しているときに複製が失敗する仕組み
以下のように東京と大阪で2台の DC が存在するような状況を想定します。
コンピュータパスワードを鍵マークで表していて、大阪 2号機のADデータベース上には、1号機の誤った古いコンピュータパスワードが格納されてしまっていると仮定しています。
1号機が 2号機から情報を複製しようとするケースで、1号機が自身に対して Kerberos認証の事前認証を行った場合には 1号機の AD データベースが持つ1号機のコンピュータパスワードと 1号機がレジストリで保持するコンピュータパスワードが一致しているので成功します。
また 1号機の AD データベースが持つ 2号機のコンピュータパスワードと 2号機の AD データベースが持つ 2号機のコンピュータパスワードが一致しているので、1号機から 2号機へ提示するサービスチケットを 2号機で復号化できます。
したがって、1号機は 2号機から情報を複製することができます。
次に 2号機が 1号機から情報を複製しようとするケースでは、2号機が自身に対して Kerberos認証の事前認証を行った場合には 2号機の AD データベースが持つ2号機のコンピュータパスワードと 2号機がレジストリで保持するコンピュータパスワードが一致しているので成功します。
一方で 1号機の AD データベースが持つ 1号機のコンピュータパスワードと 2号機の AD データベースが持つ 1号機のコンピュータパスワードが一致していないので、2号機から 1号機へ提示するサービスチケットを 1号機で復号化できません。
したがって、2号機は 1号機から情報を複製することができません。
つまり互いの DC が自身に対して Kerberos認証を行っていると、1号機の情報が 2号機へ正しく反映されないという状況に至ります。
結果、1号機のADデータベース上に1号機の正しいコンピュータパスワードが格納されていますが、2号機のADデータベース上には反映されません。
DC 間でセキュアチャネル破損しているときの対処方法
対処方法としては以下の2つがあげられます。
・DC の再昇格
・netdom コマンド
先に述べますが、推奨されるのは DC の再昇格です。
理由は USN ロールバックが発生している場合には、netdom コマンドの利用だけでは復旧不可である一方で、DC の再昇格は USN ロールバックに対しても有効なためです。
DC 間でセキュアチャネルが破損するケースでは大体 USN ロールバックも同時に発生している可能性が高いです。
DC の再昇格
DC を通常降格し、再度 DC として追加する方法が一般的です。
降格させる DC が FSMO の場合には、FSMO の転送処理も必要になってきますのでご注意ください。
一方で DC を通常降格させて失敗する場合や降格する前に DC をネットワークから切り離して対応したい場合などは DC を強制降格させる必要があります。
以下のサイトに降格～再昇格の手順がまとまっておりますので、確認してみてください。
DC の再昇格は DC で USN ロールバックが発生している場合などにも有効で、確実な対処と考えられます。
netdom コマンド
以下の Microsoft社文書に手順の記載があります。
ただ少しわかりにくいので、上記で出した東京1号機と大阪2号機でセキュアチャネルが破損し、1号機の情報が 2号機へ正しく反映されない状況の場合にどのような手順で修正するか以下に記載してみようと思います。
なお、USN ロールバックが発生している場合には、この対処だけでは復旧することができないのでご注意ください。
1. 東京1号機でサービス一覧を表示し、Kerberos Key Distribution Center サービスを停止し、[スタートアップの種類] を [手動] に変更する。
2. 東京1号機のコマンドプロンプトから次のコマンドを実行し、kerberos チケットをクリアする。
klist purge
3. 東京1号機のコマンドプロンプトから次のコマンドを実行し、コンピュータパスワードをリセットする。
netdom resetpwd /s:大阪2号機のホスト名 /ud:ドメイン名\administrator /pd:*
※東京1号機のコンピュータパスワードを変更し、大阪2号機の AD データベース内のコンピュータアカウント(東京1号機)のパスワードと同期しているものと思われます。
4. 東京1号機の OS 再起動を行う。
※大阪2号機から東京1号機の複製は成功している状況なので、東京1号機の AD データベース内のコンピュータアカウント(東京1号機)のコンピュータパスワード変更が反映されます
5. Kerberos Key Distribution Center の[スタートアップの種類] を [自動] に変更して、サービスを起動する。
上記のようになりますが、この手順はどの複製の向きが失敗していて、どのコンピュータパスワードが不一致になっているかをちゃんと整理しなければなりません。
また上記のように簡単なセキュアチャネルの破損の場合には、大阪2号機の KDC サービスを停止して OS 再起動させるだけで解決されうる上に、事象が複雑な場合、例えば USN ロールバックが発生しているとこの方法では回復できないので、あまり使う場面が多くないイメージです。
補足
Test-ComputerSecureChannel はドメインメンバ専用のコマンドで、DC 間のセキュアチャネルが破損したときには利用できません。
一方で netdom resetpwd はドメインコントローラ専用コマンドではないみたいで、ドメインメンバと DC 間でセキュアチャネルが破損したときに、ドメインメンバ側で netdom resetpwd で修正可能なようです。
ただあまり情報がないので、正式なものではないのかな..? と考え上記では案内を控えています。
Comments
powershell で再認証する方法、とてもありがたい情報でした
アカウントはADからキックアウトされないのに、PCがドメインからはじかれるようです。私のPC設定のせいでしょうか？リネームして、ドメインにリジョインすると、数日はそれで過ごせるのですが。2－3日後にまたドメインからはじかれて、数分はつながるのに数分後にPCだけがキックアウトされます。ネットワークエンジニアがあほなので、まったく解決策を考えてくれません。教えてください神様。。。