企業ネットワークにおいて、Active Directoryドメインへ参加したPCが突然ログオンできなくなってしまうと、業務に大きな支障をきたします。特に「The security database on the server does not have a computer account for this workstation trust relationship」などのエラーが表示されると、どう対応すれば良いか戸惑う方も多いでしょう。本記事では、このトラストリレーションシップエラーを解消するための具体的な手順と、再発を防ぐためのポイントを分かりやすく解説していきます。
ドメイン参加PCで発生する「信頼関係が壊れています」問題とは
ドメイン参加しているWindows PCで「The security database on the server does not have a computer account for this workstation trust relationship」や「There are currently no logon servers available to service the logon request」といったメッセージが表示され、ドメインユーザーはもちろんローカル管理者権限を持つアカウントでもログインできないケースがあります。これは、クライアントPCとドメインコントローラー(DC)間で確立されているはずの「信頼関係(トラストリレーションシップ)」が何らかの理由で壊れてしまった状態を意味します。
信頼関係が壊れていると、認証用のセッション鍵などが正しくやり取りできず、ドメインコントローラーによる認証が受けられません。その結果、ドメインユーザーがログインできないだけでなく、状況によってはローカルアカウントすらログオンを拒否される場合もあります。こうしたトラブルに直面したときには、まずどのようにしてPCのローカルアカウントでログインを回避的に行い、その後ドメインとの再接続を行うかがポイントになります。
なぜ信頼関係が壊れるのか
信頼関係の破損は、Active Directory環境において決して珍しいトラブルではありません。主な原因として以下が考えられます。
- コンピューターアカウントのパスワード問題
ドメインに参加したWindowsクライアントは、内部的にコンピューターアカウント用のパスワードをもっています。このパスワードは定期的に変更され、ドメインコントローラー側と同期が保たれています。しかし、何らかの事情で変更が同期されなかったりすると、ドメイン側とクライアント側でパスワード情報が異なり、結果的に認証が失敗するケースがあります。 - ドメインコントローラーの障害・構成変更
ドメインコントローラーがハードウェア的な故障やネットワーク障害などで正常に稼働していない場合や、DCの移行・再インストール時にコンピューターアカウントに関連する情報が失われると、クライアントPCとの信頼関係が壊れることがあります。 - ネットワーク設定や時刻同期の不一致
ドメイン環境ではDNS設定や時刻同期が正しく行われていないと認証プロセスに失敗する場合があります。時刻の大きなずれはKerberos認証が機能しなくなる原因ですし、DNSが正しく設定されていない場合、クライアントPCからドメインコントローラーを正しく見つけられなくなります。 - イメージ複製やSnapshot復元による不整合
仮想環境等でPCのイメージを複製したり、スナップショットを巻き戻したりする場合、コンピューターアカウントのパスワード履歴が不整合を起こして、ドメインとの信頼関係が失われることがあります。
信頼関係エラーの解消方法
実際に信頼関係エラーが起きてしまった場合、最も確実でシンプルな対処法は「ドメインからワークグループへ一度抜け、再度ドメインに参加し直す」という手順です。以下ではその具体的な流れをご紹介します。
1. ローカル管理者アカウントでログインする
LANケーブルを外すなどしてネットワーク接続を遮断したうえで、PCにローカル管理者アカウントでサインインします。ネットワークから物理的に切り離すことで、クライアントはドメインコントローラーへの接続を試みることなくローカルのみで認証されます。
もしローカル管理者アカウントのパスワードが分からない場合は、管理手順やパスワードポリシーを今一度確認しましょう。大規模環境では、ローカル管理者アカウントを無効化している場合もあるため、その場合は事前に対処策を用意する必要があります。
2. 一時的にワークグループへ変更
ログイン後、以下の手順でドメインから一度離脱します。
- 「スタート」メニューなどから「PC(またはThis PC)」を右クリックして「プロパティ」を選択。
- 「システムの詳細設定(Advanced system settings)」を開き、「コンピューター名」タブを表示。
- 「変更(Change)」ボタンをクリックして、ワークグループ(Workgroup)を選び、適当な名称(たとえば
WORKGROUP_TEMPなど)を入力。 - OKを押して再起動し、ドメインを抜けます。
これによって、Active Directoryの管理下から一時的にPCを外すことになります。再起動後は改めてローカル管理者アカウントのパスワードを用いてログオンしてください。
3. 再度ドメインに参加
ドメインから一時的に外れたら、再度ドメイン参加の設定を行います。
- ログイン後、再び「システムの詳細設定(コンピューター名タブ)」へ移動。
- 「変更(Change)」をクリックし、今度は「ドメイン(Domain)」を選択して正しいドメイン名を入力。
- ドメインへ参加するための資格情報(ドメイン管理者アカウントのユーザー名とパスワード)を求められるので入力。
- 正常にドメイン参加できたらPCを再起動し、ドメインユーザーまたはドメイン管理者アカウントでログインを試みる。
これで多くの場合、信頼関係が再確立され、ログオンが可能になります。
4. ネットワークや時刻同期の確認
ドメイン再参加後は以下の点をチェックしましょう。
- ネットワーク接続が正常か
DNSサーバーのアドレスが正しく設定されているか、Active Directoryのサイトが複数存在する場合は適切なサイトに属しているかを確認します。 - 時刻の同期に問題がないか
ドメイン環境ではKerberos認証を使用することが多く、サーバーとクライアントの時刻差が大きい(通常±5分を超える)と認証が失敗します。再参加後に時刻同期が行われているかを念入りに確認してください。
トラブルシューティングと追加の対処方法
上記の基本手順で解決できるケースがほとんどですが、場合によっては別のアプローチや追加の対処が必要になることがあります。
ドメインコントローラー側のコンピューターアカウントを再作成
Active Directory管理ツール(例: AD管理コンソール)で問題のコンピューターオブジェクトを削除し、改めてコンピューターアカウントを作成する方法です。ただし、削除後にクライアント側から再参加し直す手順が必要になるため、すでにクライアント側でワークグループへ離脱するプロセスを踏むことと同義になる場合があります。
ただし、オーガナイゼーショナルユニット(OU)のポリシー設定などがある場合は、コンピューターをどのOUに配置するか再確認が必要です。
netdomコマンドを使った信頼関係の修復
Windows Server環境で管理者がPowerShellやコマンドプロンプトから「netdom」コマンドを使うと、ドメインとの信頼関係を再確立できます。たとえば、以下のような構文で実行します。
netdom reset <コンピューター名> /Domain:<ドメイン名> /UserO:<ドメイン管理者アカウント> /PasswordO:*/PasswordO:*とするとパスワード入力を求められます。成功すると「The secure channel between the local computer and the domain <ドメイン名> has been reset.」のようなメッセージが表示されます。
このコマンドは、GUIからドメイン参加をやり直す手順よりも高速に処理できますが、あらかじめクライアントPCがネットワーク的にドメインコントローラーと通信できる状態にあること、そして実行に必要な管理者権限があることが前提です。
DNS設定とIPアドレスの確認
ドメイン環境におけるクライアントPCのDNS設定は非常に重要です。もしDNSサーバーとして外部DNSのみを指定していると、ドメインコントローラーが正しく解決できず、信頼関係エラーを引き起こす可能性があります。
また、複数のネットワークアダプターが存在し、誤った順序でDNS問い合わせを行っているケースもあります。ipconfig /allやGet-NetIPAddressコマンドなどでIPアドレスとDNSを確認し、問題があれば正しく設定を修正してください。
時刻同期の徹底
ドメイン環境では時刻同期が非常に重要です。特にKerberos認証が動作しない場合は、時刻のずれを疑うのが常套手段です。
クライアント側では以下のようなコマンドを用いると、現在の時刻同期状況を確認できます。
w32tm /query /statusもし時刻ソースが不明になっていたり、同期が行われていない場合は、以下のようにドメインコントローラーから強制的に時刻を同期させる設定を行ってください。
w32tm /config /syncfromflags:DOMHIER /update
net stop w32time
net start w32timeこれで、ドメイン階層(DOMHIER)から自動的に時刻が取得されるようになります。
スナップショットやイメージ復元を行った場合の対処
仮想環境やクローン環境などで、OSのスナップショットやバックアップから復元を行った場合、クライアントPCのコンピューターアカウントのパスワードが古い状態に戻ってしまうことがよくあります。そうなるとドメインコントローラーが認証できず、信頼関係が破損してしまいます。
このような場合、やはり本記事で紹介したようにドメインから一度離脱し、再参加し直す方法が最も確実です。イメージのクローンを行う前に準備として「コンピューターアカウントのリセット」などを行う手もありますが、運用ルールによって異なるため、事前に管理者と相談しておきましょう。
トラブルシュート手順の表
以下のような表を参考に、段階的な手順をチェックして対応するとスムーズです。
| 手順 | 内容 | コマンド例 / 参考 |
|---|---|---|
| 1 | ネットワーク疎通の確認 (pingやnslookupでDCが応答するか) | ping DC名nslookup DC名 |
| 2 | ローカルアカウントでログインし、ドメインからワークグループに変更 | GUI操作 |
| 3 | PCを再起動してドメインから離脱した状態を確認 | － |
| 4 | 再度ドメインに参加 (ドメイン管理者アカウントが必要) | GUI操作 |
| 5 | netdomコマンドでトラブルシュート (管理者向け) | netdom reset ... |
| 6 | w32tmで時刻同期のステータス確認 | w32tm /query /status |
| 7 | 時刻ずれが大きい場合、強制同期 | w32tm /config /syncfromflags:DOMHIER /update |
| 8 | DNS設定の確認 (ドメイン環境のDNSサーバーを指定) | ipconfig /all |
| 9 | AD管理ツールでコンピューターアカウントの存在・状態を確認 | ADユーザーとコンピュータ |
| 10 | 問題が解決しない場合、PC再イメージ化もしくはドメインコントローラー側の再構成を検討 | － |
再発防止のためのベストプラクティス
信頼関係エラーが頻発するような環境では、根本的な原因を取り除くための対策を検討する必要があります。
定期的なActive Directoryヘルスチェック
ドメインコントローラーが複数ある場合は、レプリケーション状態に問題がないかdcdiagやrepadminなどのツールを活用して定期的にチェックしましょう。DC間でのデータ同期に不具合があると、コンピューターアカウント情報の不整合などを招き、結果として信頼関係エラーが発生しやすくなります。
DNSサーバーと時刻同期サーバーの冗長構成
メインとなるDNSサーバーや時刻同期サーバーが停止すると、一時的にドメイン参加クライアントが認証できなくなるリスクが高まります。複数のDNSサーバーを用意し、NTPサーバーも冗長化しておくことで、障害発生時の影響を最小限に抑えられます。
グループポリシーでのパスワードポリシー管理
ドメイン環境ではコンピューターアカウントのパスワードも一定の期間で更新されるように設定されています。グループポリシーで過度に短い間隔を設定すると、クライアント側との同期が追いつかず、問題が起きやすくなることもあります。適切なローテーション期間を設定し、更新失敗時の対策(イベントログの監視など)を行いましょう。
仮想環境のスナップショット運用ルール
VMwareやHyper-Vなどの仮想環境でスナップショットを使う場合は、OSのドメイン参加情報やコンピューターアカウントのパスワード更新が行われるタイミングを考慮して管理しないと、スナップショット復元後に信頼関係エラーが多発します。クローンをとる際には、ドメイン参加したままイメージ化しない、もしくは復元後に再参加を必ず行うなどのルール化を検討しましょう。
よくあるQ&A
Q1: ネットワークを抜かずにローカル管理者アカウントでログオンするには？
A: もしネットワークケーブルを抜かずにローカルアカウントへログインしたい場合は、サインイン画面で「ComputerName\Administrator」のように「コンピューター名\ユーザー名」を明示的に指定してログオンを試みる方法があります。しかし、ドメイン側が強制的にログインを試みる設定になっていると難しい場合もあるため、確実を期すならケーブルを抜くなど物理的に切り離すのが簡単です。
Q2: ローカル管理者アカウントが無効化されている場合の対処は？
A: 組織によってはセキュリティ上の理由でローカルAdministratorを無効化しているケースがあります。この場合は事前に「別途作成したローカル管理者アカウント」を用意しておくか、WinRE(Windows Recovery Environment)などを使用してアカウントを有効化するなどの緊急対応が必要です。
Q3: ドメイン管理者アカウントでもログインできないのはなぜ？
A: 「ドメイン管理者アカウント」は、ドメイン環境で有効なIDです。クライアントPCのセキュアチャネル(信頼関係)が完全に壊れていると、そのアカウント情報すら受け付けなくなります。このため、ローカル環境内の有効なアカウントを使ってOSにログインする必要があります。
Q4: Windows Serverのバージョンが古い場合に何か注意点はある？
A: Windows Server 2008や2008 R2など、古いバージョンを使っている環境では、Kerberosの暗号化方式やグループポリシー設定の既定が最新環境と異なることがあります。パッチレベルや役割(AD DS)の更新状態によっては、クライアントと正しくやり取りできないケースもあるため、常に最新の更新プログラムを適用し、サポート期間を確認してください。
まとめ
ドメイン参加PCで発生する「The security database on the server does not have a computer account for this workstation trust relationship」というエラーは、Windowsクライアントがドメインコントローラーとやり取りするセキュアチャネルの破損が主な原因です。LANケーブルを外してローカル管理者アカウントでログインし、ドメインからワークグループへ一度抜けてから再参加することで、多くのケースで問題を解決できます。
しかし、再発を防ぐためには、DNSや時刻同期などの基本的な設定管理や、Active Directoryのレプリケーション確認、仮想環境でのスナップショット運用ルールなど、環境全体を見直すことが重要です。IT管理者としては、こうした基礎的な構成の整合性を常に確保しつつ、トラブル発生時には迅速に信頼関係を再構築できる手順と権限を手元に用意しておくことが求められます。
コメント