1か月オフライン後にドメイン信頼が切れた？まず確認すべきこと

ノート PC が六週間 VPN の外にあり、戻ってきたところ、ユーザーはドメインアカウントでサインインできない。エラーは信頼関係に触れているため、誰かがコンピューターアカウントをリセットし、あるいはユーザーをフルトンネルに強制すると、問題は消えたように見える。どちらの対応も、何が壊れていたのかを証明していない。Windows のメンバーは、通常のマシンパスワード間隔をはるかに超えてオフラインのままでも自動的に信頼を失うことはない。したがって最初の作業は、到達性の失敗と本当のシークレットの不一致を切り分けることだ。

エラーは信頼に見えるが、三つの状態は似ている

ユーザーは キャッシュされたドメイン情報でサインインする かもしれず、ワークステーションがドメインコントローラーを見つけられないのか、メンバーとドメインがコンピューターアカウントについて本当に食い違っているのかもしれない。厳密な意味で壊れた信頼関係は三番目だけである。

AD レプリケーションの正常性は四番目の観察であり、このワークステーションとはまったく関係がない。それはドメインコントローラー間の合意を表すもので、健全なレプリケーションのダッシュボードは、このマシンのローカルシークレットがコンピューターアカウントと一致することを証明しない。

よく知られた 30 日の既定値は変更ポリシーであり、オフラインでの有効期限ではない。Microsoft の マシンアカウントのパスワードについての説明 は、調整された変更プロセスを説明しており、組織は別の間隔を構成できる。

VPN のアイコンはセキュアチャネルについて何も証明しない

どのテストも意味を持つ前に、接続はドメインサービスに届く程度に良好でなければならない。つまり、意図したドメインの DNS リゾルバー、見つけられるコントローラー、到達可能な認証サービス、Kerberos に十分近い時計である。

フルトンネルはここでは完全に妥当な設計になり得る。分割トンネルへの変更は健全なドメイン関係の前提条件ではなく、前提条件として扱うと診断がアーキテクチャ変更にすり替わる。ワークステーションが実際にどのコントローラーを選ぶかを確認し、その名前をエラーと一緒に残す。

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

DNS サーバー、解決されたコントローラー、エラーの正確な文言を記録する。接続済みと報告する VPN クライアントが示すのはトンネルの存在であり、ドメイン経路が機能していることではない。Kerberos ポートには応答するがディレクトリポートには応答しないコントローラーは、ファイアウォールの所見であり、信頼の所見ではない。

修復する前にメンバーをテストする

承認された Windows ドメインメンバーでは、Test-ComputerSecureChannel -Verbose はマシンとドメインの間のチャネルに対する読み取り専用の確認である。調査対象のマシンのコンテキストで実行し、ドメインコントローラーから実行しない。後者は役割も復旧規則も異なる。合格や不合格という言葉ではなく、出力と終了ステータスを記録する。そのビルドに cmdlet がない場合、モジュールは別の問題である。

結果には依然として文脈が必要である。マシンが選択されたコントローラーに到達できない、またはそこで認証できない場合、失敗したテストはオフラインのパスワードが期限切れになった独立の証拠にはならない。実際のエラーと使用したコントローラーを残し、経路が既知の良好になってからテストを繰り返す。

インシデント前後のメンバーおよび該当コントローラーの Netlogon イベントを相関させる。マシン名、送信元アドレス、時刻、アカウント変更のあらゆる証拠を保存する。他のユーザーのサインイン成功や健全なコントローラーのダッシュボードは、このマシンのやり取りの代わりにはならない。

証明できた関係だけを修復する

接続が安定し、管理者が修復が適切だと確認したら、承認された資格情報による cmdlet の -Repair モードは、メンバーワークステーションでサポートされる操作の一つである。これは関係を変更するもので、もう一つの読み取り専用テストではない。

変更の前に、承認されたローカル回復アカウントと管理経路を用意しておく。ドメインコントローラーは回復の役割が異なり、この手順で通常のワークステーションとして扱ってはならない。複数のリセットツールを順に実行して一つが正しいことを期待するのではなく、組織の回復ワークフローを使う。

修復後は、新しいセキュアチャネルのテストと元のドメイン操作を検証する。ユーザープロファイルとアプリケーションの状態を保存し、削除と再参加を最初の説明のつかない操作にしない。

障害が再発したときに確認すること

障害が再発した場合は、同じアカウントを再びリセットするのではなく、ロールバック、重複した ID、アカウント変更のタイミングを確認する。復元されたイメージ、スナップショット、複製されたマシン ID、他所で実行されたコンピューターアカウントのリセットは、いずれも調査に値する。

一時的に成功したリセットは有用な復旧の証拠だが、断続的な VPN が元の不一致を引き起こした証拠ではない。原因が本当に取り除かれたかどうかは、次の発生が教えてくれる。

コントローラー、DNS サーバー、テスト出力をチケットに書く。この記録が、本当の信頼の失敗と、単にドメインを見つけられなかったノート PC を区別する。