ドメイン参加済みマシンにDeep Freezeをデプロイした際に「このワークステーションとプライマリドメイン間の信頼関係に失敗しました」というエラーが発生した場合、それはあなただけではありません。これは、Active Directory環境を管理するIT管理者が受ける最も一般的な質問の1つです。

まず良いニュースからお伝えします。この問題は適切な設定を行えば完全に回避可能であり、最新バージョンのDeep Freezeではほとんどの場合自動的に処理されます。しかし、なぜ発生するのかを理解することで、最初から正しく設定でき、古いデプロイを引き継いだ場合のトラブルシューティングにも役立ちます。

ここでは、フリーズされたマシンでドメイン信頼関係の問題が発生する正確な原因、Deep Freezeがこれを内部的にどのように処理するか、そしてドメイン参加済みPCを健全に保つために必要なことを詳しく説明します。

A conceptual image of a strawberry frozen inside an ice cube, symbolizing the power of Faronics Deep Freeze in preserving and protecting system configurations from unwanted changes.

ドメイン信頼関係の喪失が実際に発生する原因

問題を理解するには、Active Directoryのコンピューター認証がどのように機能するかを理解する必要があります。

コンピューターがActive Directoryドメインに参加すると、2つのことが起こります。ADにコンピューターアカウントが作成され、そのコンピューターとドメイン間で共有シークレット（パスワード）が確立されます。このパスワードは、Active Directoryと、保護されたレジストリのローカルマシン上の両方に保存されます。

コンピューターが起動してネットワークに接続するたびに、ユーザーがログインする前に、このパスワードを使用してADに認証されます。パスワードが一致すれば、セキュアチャネルが確立され、すべて正常に機能します。

ここで重要な点があります。デフォルトでは、Windowsは30日ごとにこのコンピューターアカウントのパスワードを自動的に変更します。マシンが変更を開始し、ローカルコピーとADコピーの両方を更新し、処理は続行されます。

フリーズされたマシンでは、このプロセスが中断されます。

フリーズされたコンピューターがパスワード変更を開始すると、Active Directoryは正常に更新されます。ADは新しいパスワードを期待します。しかし、マシンが再起動すると、Deep Freezeは新しいパスワードを含むすべての変更を消去します。マシンはベースラインに戻り、古いパスワードが含まれています。

これで不一致が発生します。ADは新しいパスワードを持ち、ローカルマシンは古いパスワードを持ち、認証できません。ドメインログインが失敗します。恐ろしい信頼関係エラーが表示されます。

これはすぐに起こるわけではありません。ADは現在のパスワードと前のパスワードの両方を保持しているため（短い同期ギャップを処理するため）、マシンは通常少なくとも1回のパスワード変更サイクルを乗り越えます。しかし、古いベースラインを持つフリーズされたマシンが、ADが2回のパスワード変更サイクルを終えた後に認証を試みると、信頼関係が壊れます。

Deep Freezeの処理方法（バージョン7.6以降）

この問題は数年前に認識されており、Deep Freezeはバージョン7.6（2013年リリース）以降、自動処理を組み込んでいます。仕組みは以下の通りです。

フリーズ中のパスワード変更の抑制。マシンがフリーズ状態にある場合、Deep Freezeはコンピューターアカウントのパスワード変更を抑制します。マシンはADへのパスワード変更要求を開始しないため、不一致は発生しません。フリーズされたベースラインの現在のパスワードは有効なままです。

解凍時のパスワード同期。マシンが解凍状態（メンテナンスウィンドウ中）に入ると、Deep Freezeは通常のパスワード変更動作を許可します。パスワード変更が必要な場合、解凍中に実行され、ADとローカルマシンの両方に書き込まれ、フリーズし直す際に新しいパスワードが更新されたベースラインにキャプチャされます。

この自動処理により、比較的最近のバージョンのDeep Freezeを実行しており、定期的なメンテナンスウィンドウをスケジュールしている限り、ドメイン信頼関係の問題は発生しないはずです。システムは自己管理します。

重要な注意点：これは定期的な解凍期間がある場合にのみ機能します。マシンが数ヶ月間継続してフリーズされ、一度も解凍されない場合、抑制されたパスワードは更新される機会がなく、最終的にADが期待するものとベースラインの内容との不一致が、マシンが最終的に信頼を再確立する必要がある場合に問題を引き起こす可能性があります。

信頼関係の問題を完全に回避する方法

予防は簡単です。以下に、推奨順にオプションを示します。

オプション1：定期的なメンテナンスウィンドウをスケジュールする（推奨）。これは最もシンプルで最良のアプローチです。Windowsアップデートのために少なくとも月に一度マシンを解凍している場合（これは行うべきです）、コンピューターアカウントのパスワードはそれらの解凍期間中に同期されます。Deep Freezeは残りを自動的に処理します。

ほとんどの組織は、週次または隔週のメンテナンスをスケジュールしています。これは十分すぎるほどです。30日間のパスワード変更サイクルは、正常に完了する十分な機会があります。

オプション2：グループポリシーを使用してマシンアカウントのパスワード変更を無効にする。めったに解凍しない、またはまったく解凍しないマシン（例：キオスク）がある場合は、自動パスワード変更を完全に無効にすることができます。以下のグループポリシーを設定します。

コンピューターの構成 → Windowsの設定 → セキュリティの設定 → ローカルポリシー → セキュリティオプション → ドメインメンバー: コンピューターアカウントパスワードの変更を無効にする → 有効

このポリシーにより、コンピューターはパスワードを変更しようとしないため、不一致は発生しません。ドメイン参加時の元のパスワードは無期限に有効です。

セキュリティに関する考慮事項：一部のセキュリティフレームワークでは、定期的なパスワードローテーションが推奨されています。コンピューターパスワードの変更を無効にすることは、技術的にはこれを弱めます。共有アクセスを必要とする低セキュリティ環境のマシン（学校のラボ、図書館のコンピューター）では、これは通常許容されます。機密データを扱うマシンでは、定期的なメンテナンスウィンドウが推奨されます。

オプション3：パスワード変更間隔を延長する。パスワード変更を完全に無効にするのではなく、間隔を延長することができます。デフォルトは30日ですが、グループポリシーを使用して90日、180日、または365日に設定できます。

コンピューターの構成 → Windowsの設定 → セキュリティの設定 → ローカルポリシー → セキュリティオプション → ドメインメンバー: コンピューターアカウントパスワードの最大有効期間 → [日数]

これにより、メンテナンスウィンドウがまれな場合でも、パスワードローテーションを維持しながら、より多くのバッファが得られます。

オプション4：ポリシーをフリーズされたベースラインに含める。フリーズする前にレジストリ経由でパスワード変更を無効にすることもできます。ベースラインイメージにこれを追加します。

HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange = 1

これはグループポリシーアプローチと同じ結果をもたらしますが、動的に適用されるのではなく、イメージに組み込まれます。

長期安定のためのベストプラクティス

特定のパスワード問題以外にも、Active Directory環境でDeep Freezeをスムーズに実行するための一般的な推奨事項を以下に示します。

Deep Freezeの最新バージョンを使用していることを確認してください。前述の自動パスワード処理はバージョン7.6以降の製品に含まれており、それ以降のバージョンでは動作が改善されています。古いバージョンを使用している場合は、アップグレードしてください。最新バージョンはドメイン統合をはるかにスムーズに処理します。

メンテナンスウィンドウを定期的にスケジュールしてください。Windowsアップデートのための週次または隔週のメンテナンスは、パスワード同期に必要な解凍期間を自然に提供します。マシンを数ヶ月も解凍しないままにしないでください。

メンテナンス後にベースラインを更新してください。マシンが解凍して更新されたら、新しい状態（パスワード変更を含む）で再フリーズする必要があります。ベースラインを手動で管理している場合は、メンテナンス後の状態が新しいベースラインになるようにしてください。

メンテナンスをスキップしたマシンを監視してください。Deep Freeze Cloudは、メンテナンスタスクの完了に関するレポートを提供します。スケジュールされたメンテナンス中に電源がオフになっているマシンは、解凍ウィンドウをスキップします。これらを特定し、追いつくようにしてください。

ドメイン構成を文書化してください。デフォルトのパスワードローテーション、無効化されたパスワード、または延長された間隔を使用しているかどうかを記録してください。次の管理者が感謝するでしょう。

パイロットグループでテストしてください。大規模展開の前に、60〜90日間（複数のパスワード変更サイクルを経験するのに十分な期間）の小規模パイロットを実行してください。広範囲に展開する前に、信頼関係が健全なままであることを確認してください。

信頼関係の問題が発生した場合の修正方法

すでに信頼関係の失敗に遭遇した場合は、以下の手順で解決してください。

ステップ1：影響を受けるマシンを解凍してください。ローカル管理者アカウント（ドメインアカウントではなく、ドメイン認証が壊れているため）でログインする必要があります。変更が保持されるようにマシンを解凍してください。

ステップ2：コンピューターアカウントのパスワードをリセットしてください。いくつかのオプションがあります。

PowerShell（推奨）：管理者権限でPowerShellプロンプトを開き、以下を実行します。

Reset-ComputerMachinePassword -Server YourDomainController -Credential Domain\Admin

または以下を使用します。

Test-ComputerSecureChannel -Repair -Credential Domain\Admin

どちらのコマンドもコンピューターパスワードをリセットし、ADと同期します。成功すれば、ドメイン認証はすぐに機能するはずです。

Active Directory ユーザーとコンピューター：または、ドメインコントローラーまたは管理ワークステーションからADUCを開き、コンピューターオブジェクトを見つけて右クリックし、「アカウントのリセット」を選択します。その後、クライアント側からマシンを再参加させます。

ステップ3：修正された状態で再フリーズしてください。信頼関係が復元されたら、マシンを再フリーズします。新しく正しいパスワードがフリーズされたベースラインの一部になります。

ステップ4：再発を防止してください。上記で説明した予防戦略のいずれか（定期的なメンテナンスウィンドウ、無効化されたパスワード変更、または間隔の延長）を実装して、これが再び起こらないようにしてください。

よくある質問

これは実際にどのくらいの頻度で発生しますか？

最新バージョンのDeep Freezeと定期的なメンテナンスウィンドウを使用している場合、まれです。主に2つのシナリオで見られます。自動パスワード処理のない非常に古いDeep Freezeバージョンを実行しているレガシーデプロイメント、または長期間（数ヶ月）解凍されていないマシンです。適切に設定された最新のデプロイメントでは、この問題は発生しません。

これはDeep Freezeのバグですか？

いいえ、これはリブート・トゥ・リストア技術がActive Directoryのパスワードローテーションメカニズムと相互作用する方法の自然な結果です。再起動時に状態を復元するシステムはすべて同じ課題に直面します。Deep Freezeは、フリーズ中はパスワード変更を抑制し、解凍期間中に許可することでこれに対処します。これは、メンテナンスが定期的にスケジュールされている場合にシームレスに機能します。

信頼関係の問題は完全に回避できますか？

はい。定期的なメンテナンスウィンドウをスケジュールするか（推奨）、グループポリシーを使用してコンピューターアカウントのパスワード変更を無効にするかのいずれかです。どちらのアプローチも、パスワードの不一致の可能性を排除します。数千の組織が、これらのアプローチのいずれかを設定しているため、信頼関係の問題なしにドメイン参加済みマシンでDeep Freezeを実行しています。

これはAzure AD参加済みマシンに影響しますか？

Azure AD（現Entra ID）は、従来のActive Directoryとは異なる認証メカニズムを使用しています。ここで説明する特定のコンピューターアカウントパスワードローテーション動作は、オンプレミスのADドメイン参加に適用されます。Azure AD参加済みおよびハイブリッド参加済みマシンには、独自の考慮事項があります。Azure AD環境にデプロイしている場合は、当社にご連絡ください。具体的なガイダンスを提供できます。

ローカル管理者パスワードがわからない場合はどうなりますか？

これは一般的な問題です。信頼関係が壊れていて、ローカル管理者資格情報がない場合、ネットワークから切断された状態でキャッシュされたドメイン資格情報を使用してログインを試みることができます。または、パスワード回復ツールを使用するか、再イメージングする必要があります。これは、ローカル管理者資格情報が文書化され、アクセス可能であることを確認すること、またはそれらを管理するためにLAPS（ローカル管理者パスワードソリューション）を使用することの利点です。

すべてのフリーズされたマシンでパスワード変更を無効にすべきですか？

最も簡単なアプローチですが、必ずしも必要ではありません。すでに定期的なメンテナンス（週次または隔週）をスケジュールしている場合、パスワードは解凍期間中に自然に同期され、無効化は不要です。無効化は、めったに解凍されないマシン（例：専用キオスク）や、単純さが厳密なパスワードローテーション要件よりも優先される環境で最も意味があります。