ログイン画面に「このワークステーションとプライマリドメインとの信頼関係に失敗しました」と表示され、ドメインユーザーでログインできなくなる。特にVM環境で頻発するこのエラーについて、その原因を解説していきます。
このエラーの正体
このエラーの原因は、ほとんどの場合コンピューターアカウントのパスワード不一致です。
セキュアチャネル（Secure Channel）
コンピューター（ドメインメンバー）とドメインコントローラーの間で確立される、暗号化された通信経路。この経路の認証には、コンピューターアカウント固有のパスワードが使われる。
Windowsのドメイン参加端末は、ユーザーとは別に「コンピューターアカウント」という固有のアカウントを持っています。このアカウントのパスワードは端末側とAD側の両方に保存されており、両者が一致していることで セキュアチャネル が確立されます。
どちらかの記録が古くなり、もう一方と一致しなくなると、このエラーが発生します。
なぜスナップショット環境で多発するのか
VMのスナップショット機能は、ディスクの状態を丸ごと凍結して保存します。
当然、端末側が保持しているコンピューターアカウントのパスワードも、スナップショットを取った時点の状態のまま固定されます。
問題は、AD側のパスワードは止まらないことです。コンピューターアカウントのパスワードは既定で自動更新され続けるため、スナップショットを長期間放置してから復元すると、端末側が持っているパスワードとAD側の最新のパスワードがズレてしまいます。検証環境やテンプレートVMで「復元するたびにログインできなくなる」という現象は、これが原因である可能性が高いです。
この記事で紹介する対策をしない限り、ADやメンバーサーバに変更を加えた際に、すべてのマシンのスナップショットを取り直す必要があり、台数が多ければ多いほど手間が発生し非効率です。
コンピューターアカウントのパスワードはどう管理されているか
コンピューターアカウントのパスワード
ドメイン参加端末が持つ、ユーザーパスワードとは別の認証用パスワード。既定では30日ごとに端末側から自動的に変更要求が送られ、AD側で更新される。
AD側は「現在のパスワード」と「1つ前のパスワード」の2世代を保持しています。そのため多少のズレ（更新前後のタイミングのズレなど）は許容されますが、スナップショットのように何世代も前の状態まで巻き戻ると、両方とも一致しなくなりエラーが発生します。
参考：コンピューター アカウントのパスワード処理の詳細 | Microsoft Learn
対策① パスワード変更を止める：クライアント側の設定
頻繁にスナップショットへ戻す運用が避けられない環境では、そもそもパスワードの自動更新を止めてしまうのが有効な対処です。
端末側で以下のレジストリを設定します。
キー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
値の名前：DisablePasswordChange
種類：REG_DWORD
データ：1コンピューターの構成 → ポリシー → Windowsの設定 → セキュリティの設定
→ ローカルポリシー → セキュリティオプション
→ ドメイン メンバー：コンピューター アカウント パスワードの変更を無効にする対策② パスワード変更要求を拒否する：AD側の設定
端末側だけでなく、AD側（すべてのドメインコントローラー）でパスワード変更要求そのものを拒否する設定も存在します。
キー：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
値の名前：RefusePasswordChange
種類：REG_DWORD
データ：1GPOの設定パスは以下の通りです。
コンピューターの構成 → ポリシー → Windowsの設定 → セキュリティの設定
→ ローカルポリシー → セキュリティオプション
→ ドメイン コントローラー：コンピューター アカウント パスワードの変更を拒否するこの設定はすべてのDCに適用する必要があります。1台のDCだけ拒否しても、他のDCが変更要求を受け付けてしまえば意味がありません。
古いパスワードのまま固定される状態は、セキュリティ的にはトレードオフがあることも知っておいてください。
パスワードが更新されないコンピューターアカウントは、万が一資格情報が漏洩した場合に長期間悪用されるリスクが上がります。
検証環境・テンプレートVMなど、影響範囲が限定された用途に絞って適用するのが無難です。
壊れてしまった時の修復方法
すでにエラーが発生している場合、まず試すべきはセキュアチャネルの修復です。
ドメインから一度も切り離さずに直せるため、影響範囲が一番小さい方法です。
ドメインユーザーでログインできないため、ローカル管理者権限が付与されているユーザーでログインします。
# 現在のセキュアチャネルの状態を確認する
Test-ComputerSecureChannel
# 破損していた場合、修復する（要ドメイン管理者権限の資格情報が必要）
Test-ComputerSecureChannel -Repair -Credential <ドメイン名>\<ユーザー名>-Credentialで指定するアカウントには、対象コンピューターアカウントのパスワードをリセットできる権限が必要です。既定でこの権限を持つのはDomain Adminsですが、対象に対してコンピューターアカウントのパスワードリセット権限だけを委任した専用アカウントを用意する方が、最小権限の観点から望ましいです。
委任の具体的な設定手順は、環境（OU構成・権限モデル）によって細部が変わるため、Active Directoryの委任機能に関する公式ドキュメントを参照してください。
参考：Active Directory オブジェクトの管理を委任する | Microsoft Learn
nltestコマンドでも同様の操作ができます。
nltest /sc_reset:ドメイン名\DC名これらのコマンドは、対象のDCと通信できる状態（ネットワーク的に到達可能、かつADの認証情報を提供できる状態）であることが前提です。ネットワークが分離された環境では実行できません。
ドメイン再参加という選択肢、おすすめしない理由
修復コマンドで直らない場合の最終手段として、ドメインから一度脱退して再参加する方法もあります。ただし、これは基本的に最後の手段として扱ってください。
再参加によってコンピューターアカウントが新規作成し直されると、ローカル権限が外れたり、SID（セキュリティ識別子）が変わることがあります。これにより、そのコンピューターSIDに紐づけて設定していたGPOのセキュリティフィルタリング、BitLockerの回復キーの格納先、LAPSのパスワード情報など、そのアカウント固有の情報が一式失われる可能性があります。
特に、複数のグループポリシー・監査設定・アプリケーションのライセンス認証などがそのコンピューターアカウントに紐づいている環境では、再設定の手間がかなり大きくなります。セキュアチャネルの修復（Test-ComputerSecureChannel -Repair）で直る場合は、そちらを優先してください。
現場で確認しておくべきこと
自分の環境でスナップショットを多用するVM（検証環境・テンプレートVM）があれば、DisablePasswordChangeの設定が入っているか確認してください。
入っていなければ、次にスナップショットを巻き戻したタイミングでこのエラーに遭遇する可能性があります。事前に設定しておくことで、そもそもエラーを発生させないようにできます。
AD全体の設計・運用については「Active Directoryとは？Windows認証基盤の仕組みと設計の基本」もあわせてご覧ください。
コメント