Windows Server環境でドメインに参加していると、数日後に突然ログインエラーが発生してしまうと慌ててしまうことも多いでしょう。本記事では「The security database on the server does not have a computer account for this workstation trust relationship」エラーを中心に、原因や対処法を幅広くご紹介します。安定したサーバー運用にお役立てください。
「The security database on the server does not have a computer account for this workstation trust relationship」エラーの概要
このエラーは、Windows Server環境でドメインに参加しているマシンとドメインコントローラー(以下DC)との間で、コンピューターアカウントの信頼関係が破損した場合に起こる典型的な事象です。Kerberos認証において、マシン側とDC側でコンピューターアカウントのパスワードが一致しない、あるいはアカウント自体が見つからない状態になると発生します。
実際に遭遇しやすいケースとしては、仮想マシン(VM)を複製したりスナップショットから復元したりしたときに、ドメインとVMの情報がずれてしまうことが挙げられます。また一時的に解消しても、何日か経って再び同じエラーが出る場合、時刻同期やDNS設定などの継続的な問題が潜んでいる可能性があります。
よくある原因と根本的な対処ポイント
ドメイン参加時の信頼関係エラーは一時的な回避策だけでなく、根本対処が重要です。以下では考えられる原因と対処方法を具体的に掘り下げていきます。
1. コンピューターアカウントの不整合
ドメインに参加しているマシンのコンピューター名と、Active Directory上に登録されたコンピューターアカウント名が一致していないと、認証エラーが発生します。また、重複アカウントや誤って削除されてしまったアカウントがあると、さらに問題が複雑化します。
アカウントの状態を確認する手順
以下はPowerShellを利用した簡単な確認方法の例です。
# Active Directoryモジュールがインストールされている環境で実行
Get-ADComputer -Identity <コンピューター名> | Select-Object Name, Enabled, DNSHostName- Name: コンピューターアカウントの実際の名前
- Enabled: アカウントが有効かどうか
- DNSHostName: DNS上のホスト名
このコマンドで返ってくる情報と、VMのシステムのプロパティにあるコンピューター名が一致しているかをまず確認してください。もしアカウントが無効になっていれば有効化し、不要な重複アカウントがあれば削除して整理しましょう。
2. 時刻同期の問題
Kerberos認証では、サーバーとクライアント(ここではVM)の時刻差が一定の範囲を超えると、チケット発行がうまくいかずにログインエラーを引き起こすケースがあります。スナップショットから復元したVMなどでは、ホスト時刻との同期がずれてしまうことが原因で、数日経過した後に初めて異常が顕在化することもあります。
時刻同期の確認ポイント
- VMの時刻元: Hyper-VやVMwareなどのホスト側から時刻を同期しているか、それともNTPサーバーから直接同期しているかを明確化
- DCの時刻元: DCがどのNTPサーバーと同期しているか、外部NTPと差異が生じていないかをチェック
- Windows Time Serviceの稼働状況:
services.mscや PowerShellでGet-Service W32Timeを実行して状態を確認
例として、ホストとゲストOSが二重に時刻同期を行ってしまうと、かえって誤差が生じる場合があります。仮想環境においてはホスト側の時刻同期を無効にし、ゲストOSが直接NTPサーバーと同期する設定が安定することも多いです。
3. 重複Service Principal Name(SPN)の存在
SPNが重複して登録されていると、Kerberosでの認証時にどのアカウントを参照すればいいのか混乱が生じて失敗します。特にマシンアカウントを再参加したり複製したりする際に、古い情報が残っていることが原因です。
SPNを確認・整理するコマンド
setspn -L <コンピューターアカウント名>上記のコマンドで登録済みSPNを一覧表示できます。もし別のアカウントにも同じSPNが記載されているならば、以下のようにして重複するSPNを削除します。
setspn -D <SPN名> <コンピューターアカウント名>重複が解消したら、再度ドメイン参加を行ってみてエラーが再発するか確認してください。
4. DNS設定の不備
ドメイン参加やKerberos認証では、DNSによる名前解決が欠かせません。とくに複数のDNSサーバーが混在していたり、キャッシュが古い情報を参照していると、意図せぬエラーが多発します。
DNS設定の点検リスト
| 項目 | 確認内容 |
|---|---|
| DNSサーバーアドレス | プライマリDNSにDCのアドレスが設定されているか |
| 名前解決テスト | nslookupまたはpingで正しくFQDNを解決できるか |
| DNSキャッシュのリセット | ipconfig /flushdnsで不正キャッシュをクリア |
| DNSフォワーダ | 外部DNS参照に問題がないか、フォワーダ設定を見直す |
DNSが正常に動作していないと、ドメイン参加に必要なLDAPやKerberosのサービスロケータ(SRVレコード)を正しく取得できず、結果的に「エラーが出るまで数日かかる」という厄介な状況を招きやすいです。
5. グループポリシーの不整合
ドメイン内で定義されているグループポリシーが、VM上にうまく反映されていない場合もトラブルの要因となります。特にセキュリティポリシーやKerberos関連のパラメータが食い違っていると、マシンアカウント更新時にエラーが生じやすくなります。
gpupdateコマンドでの強制更新
gpupdate /forceこのコマンドによって最新のグループポリシーを強制的に取得し、ローカルに適用します。適用後は再起動を行い、ログオンエラーが解消されるかを確認してください。
なお、イベントビューアのApplicationやSystemログを監視し、ポリシー取得に失敗していないかも合わせてチェックしましょう。
6. コンピューターアカウントのパスワードリセット
Windowsドメイン環境では、定期的にコンピューターアカウントのパスワードが自動更新される仕組みがあります。これが何らかの理由で破損・同期ずれを起こすと、今回のようなエラーが発生します。
netdomコマンドによるリセット例
netdom resetpwd /server:<ドメインコントローラー名> /userd:<ドメイン名>\<ユーザー名> /passwordd:* /force/server: パスワードをリセットするDCを指定/userd: ドメイン管理者などの認証に使用するユーザー/passwordd:*: パスワードを対話的に入力/force: 強制実行
上記コマンドを正常に完了させることで、コンピューターアカウントのパスワードが再設定されます。その後、VMを再起動し、ドメインログインできるかテストしてください。
7. イベントビューアのAudit Failure確認
問題の解消に行き詰まったとき、重要な手掛かりを得るのに役立つのがイベントビューアです。特にセキュリティログに記録されるAudit Failureの詳細を確認することで、原因特定の糸口が見つかることがあります。
エラーコード0xC000018Bの意味
0xC000018Bは「STATUS_TRUSTED_RELATIONSHIP_FAILURE」に対応しており、直訳すれば「信頼関係が破損している」という状態です。このコードが記録されている場合、アカウントのパスワードや資格情報の不一致がほぼ確実に疑われます。
VM固有の要因に注意
問題が特定の1台のVMにのみ発生している場合、そのVM自体の構成やHypervisorの設定に焦点を当ててみることが大切です。特に以下の点をチェックすると、思わぬヒントを得られるかもしれません。
8. ネットワークアダプターとファイアウォール
- 仮想スイッチの設定: Hyper-VやVMwareで、該当VMに割り当てられている仮想スイッチが正しいサブネットに接続されているか
- 静的IP構成: IPアドレスが手動設定の場合、サブネットマスクやDNSサーバーが誤っていないか
- ファイアウォールのポート設定: 135、139、445、LDAP用ポート(389など)がブロックされていないか
ファイアウォールやネットワークアダプターの誤設定があると、一見すると正常に稼働しているようでも、一定時間後にドメインとの通信が途切れがちになります。
9. スナップショットやクローンの影響
スナップショットから復元したVMは、時間を巻き戻すのと同等の動作をするため、Windowsドメイン環境が保持している最新のコンピューターアカウント情報と食い違いを起こす可能性があります。
もしスナップショット運用が必須の場合、スナップショット復元後に以下の操作をセットで行うのがおすすめです。
- コンピューターアカウントのマシンパスワードリセット
- DNSキャッシュクリアおよび登録の再実行
- 時刻同期の強制リフレッシュ
例として、以下のPowerShellコマンド一式をスクリプトにまとめて運用する方法も有効です。
# DNSキャッシュクリア
Clear-DnsClientCache
# ADコンピューターアカウントのパスワードリセット
netdom resetpwd /server:DC01 /userd:MYDOMAIN\Administrator /passwordd:* /force
# グループポリシーの強制更新
gpupdate /forceスナップショットを使う場合は、ドメイン情報と時刻情報の整合性を常に意識するようにしましょう。
トラブルシューティングを効率化するツール活用
問題解決が長引く場合、ツールやログ解析によって根本原因をより正確に特定するアプローチが効果的です。
10. ネットワークトラフィック解析
- Wireshark: ドメイン参加時のTCP/UDPパケットをキャプチャし、KerberosのAS-REQやTGS-REQに異常がないか調べる
- Microsoft Message Analyzer(旧Network Monitor): Microsoft製ツールで、KerberosやSMBなどMicrosoft独自のプロトコル解析を強化
トラフィックを細かく見てみると、Kerberosチケットのやり取りで失敗している段階や、LDAPでコンピューターアカウントが見つからないエラーが返されている様子がわかりやすくなります。
11. Active Directoryの属性確認ツール
- ADSI Edit: コンピューターアカウントの属性(例えば
userAccountControlやservicePrincipalName)を直接参照・編集 - LDP.exe: LDAPブラウザツールとして、ディレクトリ情報を詳細に確認可能
これらのツールを活用することで、GUI管理ツール(Active Directory ユーザーとコンピューター)では見えない細部にアプローチしやすくなります。
根本解決への流れをまとめたステップガイド
実際に対策を行う際、やみくもに試すのではなく、可能な限り順序立てて取り組むことが大切です。下表では基本的な流れをまとめました。
| ステップ | 内容 | チェックポイント |
|---|---|---|
| 1 | VM側の時刻・ホストの時刻同期確認 | NTPサーバー設定が正しいか |
| 2 | AD上のコンピューターアカウント確認 | 名前の重複や無効化アカウントがないか |
| 3 | SPNの重複チェック | setspn -L コマンドで重複なしを確認 |
| 4 | DNS設定の再確認 | プライマリDNS=DC、FQDN解決が正常か |
| 5 | コンピューターアカウントのパスワードリセット | netdomコマンドでエラーなく完了するか |
| 6 | グループポリシー強制適用 | gpupdate /force 実行後再起動 |
| 7 | 再発確認とイベントログ解析 | セキュリティログ、システムログにエラーなし |
これらを順番に実施することで、抜け漏れを減らし、より効率的に問題箇所を特定・解消できるでしょう。
専門家への相談と環境全体の再検証
上記の方法をすべて試しても改善しないケースでは、Active Directory全体の複雑な構成やネットワーク構成が影響している場合があります。
以下のような場合は、より高度な専門知識を持つ技術者やMicrosoftサポートに相談することが得策です。
- 多数のDCがレプリケーション構成になっており、サイト間レプリケーションに遅延が生じている
- フォレストやドメインが複数存在し、信頼関係が階層的に組まれている
- セキュリティポリシーが複雑で、グループポリシーでの制限が多岐にわたる
また、適切な検証環境を用いて再発シナリオを再現し、段階的に切り分けを行うことも重要です。VM環境であればクローンを作って試験的に複数の施策を実施し、どの施策でエラーが抑止されるか検証してみると効果的です。
まとめと安定運用へのヒント
「The security database on the server does not have a computer account for this workstation trust relationship」エラーは、一時的にドメインから外して再参加するだけでは根本的な解決に至らないケースが多いです。
時刻同期やDNS、コンピューターアカウントのパスワード更新プロセスなど、多岐にわたる要因が複合的に絡み合っている場合もあるため、情報を整理しながら一つひとつ対策を検証していくことが大切です。
- 時刻同期の安定化: ホストとゲストOSの同期戦略を明確にして、不要な二重同期を避ける
- DNS構成の一本化: 可能な限り、ドメイン内で確立されたDNSサーバーを優先的に利用する
- グループポリシーとコンピューターアカウント管理: 定期的にエラーが出る場合は、アカウントの自動パスワード更新が正常動作しているかチェック
- 仮想マシンのライフサイクル管理: スナップショット運用のルールを決めておき、復元時には必ず時刻とドメイン情報をリセットするフローを取り入れる
これらのポイントを踏まえて運用することで、同様のエラーを最小限に抑えられるでしょう。もしトラブルが発生しても、この記事で挙げたステップを順番に実行しながらログ解析を行えば、問題解決までの時間を短縮できるはずです。
コメント