ドメインコントローラー(DC)が単一構成の場合、古いバックアップから復旧した瞬間に信頼関係エラーが噴出してしまう事例は少なくありません。特にActive Directoryの情報が大きくズレていると、クライアントPCやその他のデバイスが正しく認証できず、業務に大きな支障が出てしまいます。本記事では、古いバックアップから復旧したDCとクライアント間の信頼関係が失われた際の具体的な対処法や再発防止策を、順を追ってわかりやすく解説していきます。
単一ドメインコントローラー環境におけるトラブルの背景
単一構成のドメインコントローラーでは、バックアップの重要性が非常に高まります。複数のDCが存在するマルチドメインコントローラー環境であれば、ある程度の冗長性によって古いバックアップを使用しても他のDCと同期を行い、致命的な障害を回避できるケースが多いです。しかし単一環境では、バックアップが古いとActive Directory(AD)内部のレプリケーションが行われないまま、その状態がすべての情報源として復元されてしまうため、復旧後に大量の不整合やパスワードの不一致が発生します。
こうした不整合が原因で最も多く起きるのが「ドメインに参加しているクライアントとの信頼関係の破綻」です。DCのセキュリティ識別情報(ドメインコントローラーアカウントと呼ばれるもの)とクライアント側のコンピューターアカウントが認証プロセスで一致せず、結果として「このコンピューターとプライマリドメインとの信頼関係に失敗しました」のようなエラーメッセージが表示されます。
古いバックアップによる信頼関係喪失の主な原因
ADデータとクライアントのパスワード不整合
ドメイン参加しているWindowsクライアントは、一定の周期でコンピューターアカウントのパスワードを自動変更します。古いバックアップから復元したDC側の「認識しているパスワード」と、最新のクライアント側の「実際のパスワード」が乖離すると、どれだけ認証を試みても「正しいパスワードとして認められない」状態になってしまいます。
時刻同期の不備
Windowsのドメイン環境では、Kerberos認証プロトコルを使用することがほとんどです。Kerberos認証は時刻の同期を前提としており、著しく時刻がずれていると「チケットが無効」と判断され、信頼関係のエラーが生じます。古いバックアップに戻すとき、VMの時刻やBIOSの時刻がずれたままになりがちです。
DNS設定の誤り
Active Directory環境はDNSに大きく依存します。単一DCの場合、DNSサーバーも同じマシンで動作しているケースが多いですが、復元直後にDNSサービスが正しく機能していなかったり、クライアントのDNS参照先が別のサーバーになっていると、クライアントは正しいDCを探し当てられません。
対処のための基本チェックポイント
古いバックアップからDCをリストアした際にまず確認すべきポイントを整理すると、以下のようになります。
1. バックアップの整合性と復元ログの確認
- システムイベントログやアプリケーションログにエラーが記録されていないかをチェックします。
- バックアップが破損していなかったかも再度確認しておきます。
- 復元時に失敗や警告が出ていた場合、その原因が信頼関係エラーの根本である可能性があります。
2. 時刻同期の確認
- DCとすべてのクライアントで時刻が正しく同期していることを確かめます。
- 単一DC環境では、DC自体がNTPサーバーとして機能していることが多いため、
w32tm /query /statusなどで時刻の参照元を確認しましょう。 - クライアント側の時刻も
net time /domain:<ドメイン名>などで確認し、ズレがあれば修正します。
3. DNS設定の再確認
- クライアントのTCP/IPプロパティで設定されているDNSサーバーが今回リストアしたDCを正しく指しているかを確かめます。
- DC上のDNSサービスが立ち上がっているか、イベントログにDNSエラーが出ていないかをチェックします。
nslookupコマンドで自ドメインを引けるか、クライアントからDCのホスト名を正しく名前解決できるかをテストしましょう。
具体的な修復手順
次に、実際に信頼関係を修復するための代表的な方法を詳しく解説します。まずは基本的なコマンドや管理ツールを駆使してみて、それでも改善しない場合はさらに深い手段を検討します。
1. netdomコマンドを使用したパスワードリセット
Windows Serverのリソースキットや標準機能として利用できるnetdom resetpwdコマンドは、ドメインコントローラーとクライアントマシンのセキュリティチャネル(安全な接続)をリセットして再構築するための有力な手段です。
以下のようにPowerShellやコマンドプロンプト(管理者権限)で実行します。
netdom resetpwd /Server:<ドメインコントローラー名> /UserD:<ドメイン管理者アカウント> /PasswordD:*/Serverには、対象となるDCを指定します。/UserDと/PasswordDには、ドメイン管理者の資格情報を指定します(*を付けるとパスワード入力を対話的に行えます)。- 成功と表示されても、時刻同期やAD情報の不整合がある場合は実際に修復されていない場合もある点に注意が必要です。
2. Test-ComputerSecureChannelコマンドレット
PowerShellで用意されているTest-ComputerSecureChannelコマンドレットも、信頼関係の確認と修復に役立つツールです。
Test-ComputerSecureChannel -Verbose：詳細ログを出力しながら信頼関係をテストします。Test-ComputerSecureChannel -Repair -Credential <ドメイン管理者アカウント>：信頼関係を修復しようと試みます。
クライアントPC上で実行し、結果がTrueになれば信頼関係は維持または修復されたと考えて良いですが、複数の要因が絡むと一筋縄ではいかないことがあります。
3. ADUC（Active Directoryユーザーとコンピューター）でのコンピューターアカウントのリセット
サーバー管理者がGUIを使って操作する場合は、管理ツール「Active Directoryユーザーとコンピューター(ADUC)」から問題のあるクライアントPCのコンピューターアカウントを右クリックし、「アカウントのリセット」を実行する方法もあります。ただし、この操作だけではクライアント側にも変更が生じるわけではないため、その後にクライアントマシンの再起動や Test-ComputerSecureChannel -Repair コマンドなどを組み合わせる必要があります。
広範囲に及ぶ対処が必要な場合
大規模環境で多くのクライアントに同様のトラブルが発生している場合、一台ずつ手作業で修復するのは現実的ではありません。以下のような手法で効率よくトラブルシュートすることを考えましょう。
1. グループポリシーまたはスクリプトでの自動化
GPO(グループポリシーオブジェクト)にスクリプトを組み込み、クライアントPCの起動時やログオン時に Test-ComputerSecureChannel -Repair を実行させるという運用も検討できます。これにより、手動介入を最小限に抑えられます。ただし、スクリプト実行にはドメイン管理者権限が必要になりやすく、安全性とのバランスを考慮する必要があります。
2. 再参加(ドメインから離脱し、再度参加)を一斉に実施
確実性を優先するなら、問題のクライアントPCをワークグループにいったん移行し、再起動後にドメインに再参加させる方法が最も確実です。既存のユーザープロファイルやセキュリティ設定を継承するためには追加のレジストリ操作などが必要になる場合もあり、手間がかかりますが、どうしても信頼関係が回復しないときの最終手段といえます。
権威ある復元や非権威的復元の検討
Active Directoryには「権威ある復元(Authoritative Restore)」や「非権威的復元(Non-Authoritative Restore)」といったリストア手法があります。これらを正しく使い分けることで、ドメインコントローラー間やADオブジェクトの整合性を保ちながら復元ができる可能性があります。ただし、単一DC環境の場合、権威ある復元も他のDCが存在しないため、状況によっては期待通りの結果を得られないリスクがあります。実施前にテスト環境を用意し、専門家のアドバイスを受けると安全です。
再発防止策
今回のように古いバックアップからDCを復旧しなければならない事態を避けるため、もしくは起きたとしてもダメージを最小限に抑えるための施策をいくつか紹介します。
1. バックアップの定期運用と冗長構成
単一DCが原因で問題が起きるなら、追加のDCを設置し冗長化するのが最善策です。また、どうしても単一構成しか取れない場合は、少なくとも週次または月次でADを含むシステム全体のバックアップを取得し、テストリストアを実施しておきましょう。
2. 別サーバーにDNSを冗長化
DNSが止まるとドメイン内の通信が大幅に混乱します。DNSを別のサーバーにホストしておくか、DCとは別の役割を持つサーバーを立てて、セカンダリDNSとして設定しておくと可用性が高まります。
3. 時刻同期サーバーの明確化
DCがインターネット上のNTPサーバーと同期し、クライアントはDCと同期する形を確立しておくと、時間のズレが起きにくくなります。バックアップから復旧した後でも時刻同期を速やかに行えば、Kerberosエラーを大きく減らすことができます。
4. ドメイン参加クライアントのパスワード有効期限の調整
グループポリシーでコンピューターアカウントのパスワード有効期限を延長しておくと、古いバックアップ復旧時のズレをある程度吸収できる可能性があります。ただしセキュリティリスクも増えるため、変更の際は社内ポリシーや運用体制と相談が必要です。
コマンドや設定値をまとめた参考表
以下は、障害対応に用いる代表的なコマンドや設定項目を整理した表です。必要に応じて活用してください。
| コマンド/設定項目 | 用途 | 実行タイミング |
|---|---|---|
netdom resetpwd | DCとクライアント間のパスワード（信頼関係）をリセットする | DC復旧後、信頼関係エラー発生時に |
Test-ComputerSecureChannel | 信頼関係のテスト＆修復 | クライアント上で実行し、結果を検証 |
w32tm /query /status | DCやクライアントの時刻同期状態を確認 | 障害対応の初期段階で必ずチェック |
| ADUCでの「アカウントのリセット」 | コンピューターアカウントを強制的にリセットする | 個別クライアントの信頼関係再構築時 |
| GPOでのスクリプト実行 | 多数のクライアントに一括で同様の処理を適用する | 大規模障害発生時に効果的 |
| 権威ある復元(Authoritative Restore) | ADの特定オブジェクトを優先的に復元する | ADオブジェクトの大規模破損または削除時に検討 |
| 非権威的復元(Non-Authoritative Restore) | 他の正常なDCからのレプリケーションを優先する復元 | マルチDC環境で部分的に壊れた際に主に利用 |
まとめ
古いバックアップからドメインコントローラーを復旧した場合、クライアントとの信頼関係が失われる問題は非常に厄介です。しかし、時刻同期やDNS設定といった基礎的な部分を見直し、netdom resetpwd や Test-ComputerSecureChannel などのツールを使って慎重に修復を試みることで、ほとんどの場合は問題を解消できます。大規模環境で一斉にトラブルが発生した場合はスクリプトやGPOを活用し、一斉にドメイン再参加を行う必要があるケースもあります。加えて、再発防止のためには定期的なバックアップと複数のドメインコントローラーによる冗長化が最も効果的です。
不測の事態に備え、日頃からドメインコントローラーのバックアップを計画的に取得し、テストリストアを行う習慣をつけておくことを強くおすすめします。もし問題解決が難航する場合は、専門家やMicrosoftサポートなどの力を借りて、安全かつ確実な方法でADを復元しましょう。
コメント