Active Directoryのレプリケーションエラーは、運用管理者にとって大きな課題のひとつです。ドメインコントローラー間の同期が崩れると、ユーザー管理や認証に深刻な影響を及ぼします。本記事では、典型的なエラーメッセージと解決策をわかりやすく解説します。
ADレプリケーションとは何か
Active Directoryのレプリケーションは、ドメイン内に存在する複数のドメインコントローラー(DC)間でディレクトリ情報を同期する仕組みです。ユーザーアカウントやグループ、コンピューターアカウントなどの情報が整合性を保って運用されるためには、ドメインコントローラー同士が正しく情報を複製し合うことが不可欠です。もしレプリケーションに失敗すると、アカウントの更新が片方のDCだけで反映されてしまう、認証トラブルが発生する、グループポリシーが一部の端末だけ適用されないなど、企業システムの安定稼働を揺るがす事態につながります。
よくあるADレプリケーションエラーと原因
ADレプリケーションでは、さまざまな原因によってエラーが発生します。代表的なものとしては以下が挙げられます。
1. ネットワーク関連のエラー
- DNS設定の不備
- 名前解決ができない(pingやnslookupが失敗する)
- ファイアウォールによる通信ポートのブロック
ADレプリケーションでは、ドメインコントローラー間の通信に特定のポートが利用されます。たとえばRPC(135/TCPなど)やLDAP(389/TCP)、Kerberos(88/UDP/TCP)等が開放されていないとエラーの原因となります。また、DNSエントリに誤りがあるとレプリケーション先のDCを正しく検出できず、同期が失敗するケースが多くみられます。
2. セキュリティ関連のエラー (Access is denied など)
- ドメイン管理者権限の不足
- コンピューターアカウントのパスワード同期失敗
- SPN (Service Principal Name) の不整合
「Access is denied」や「The target principal name is incorrect」というメッセージは、ドメインコントローラーのマシンアカウントのパスワードやSPN登録に起因するケースが多く、ドメイン管理者権限を持ったアカウントで操作しているかどうかも重要なポイントになります。
3. 時刻同期やタイムサービスの問題
Active Directoryは時刻同期を厳密に扱う仕組みを持っています。時刻が大きくずれているとKerberos認証が失敗し、結果としてレプリケーションも失敗につながることがあります。NTPサーバーの設定やWindows Time Serviceの設定を確認することが重要です。
4. FSMOロールの問題
ADには5つのFSMO(Flexible Single Master Operations)ロールがありますが、特にPDC Emulatorはドメイン全体のパスワード変更複製など、レプリケーションに密接に関わる役割を担います。複数ドメインコントローラーの中でどのサーバーがFSMOロールを保持しているかを正確に把握し、そのDCとの通信が問題なく行われているかをチェックすることが必要です。
エラー事例:「Access is denied」「The target principal name is incorrect」など
ここからは、実際に発生しやすいエラー事例と対処方法をさらに詳しく見ていきましょう。
エラーコードの例
- Network error: 5(0x5)「Access is denied」
- 0x80090322 「The target principal name is incorrect」
- 1256(0x4e8)「リモートシステムが利用できない」
これらは、ドメインコントローラーのレプリケーションコマンド(repadmin /syncall /AdePなど)を実行したときに記録されることが多いエラーです。特に「The target principal name is incorrect」はKerberos認証関連で、ドメインコントローラーのコンピューターアカウントパスワードやSPNに起因することがあります。
よく行うレプリケーション確認コマンド
AD環境のトラブルシュートでは、コマンドプロンプト(またはPowerShell)から以下のようなコマンドを使用して状況を確認することが一般的です。
repadmin /syncall /AdeP
repadmin /showrepl
repadmin /replsum
repadmin /showrepl * /csv > c:\repsum.csv
これらを実行することで、どのドメインコントローラーとのレプリケーションが失敗しているのか、どのエラーコードが報告されているのかを一目で把握できます。ただし、管理者権限でコマンドプロンプトを起動していなかったり、ドメイン管理者アカウントを使っていないと、正しい結果を得られないことがあるので注意してください。
トラブルシュートのための具体的な対処手順
ここでは、先述のエラーが発生している場合の典型的な解決策を順を追って解説します。
1. 管理者特権でコマンドプロンプト(またはPowerShell)を起動する
レプリケーションの管理やドメインコントローラーの操作には十分な権限が必要です。ドメイン管理者、またはエンタープライズ管理者などの資格情報を用いて、必ず「管理者として実行」したコンソール上でコマンドを実行しましょう。
2. DNSとネットワーク設定の徹底確認
DNSが正しく動作していないと、ドメインコントローラー同士が見つけられず、レプリケーションは失敗します。以下のポイントをチェックしてください。
DNSサーバー設定
確認項目 | 説明 |
---|---|
優先DNS | Active DirectoryドメインをホストしているDNSサーバーを指定しているか |
代替DNS | 優先DNSがダウンした場合に備えて正しいサーバーを指定しているか |
逆引き確認 | DCのホスト名とIPアドレスが正しく対応しているか(nslookup で要確認) |
ネットワークの基本疎通テスト
ping ドメインコントローラー名
nslookup ドメインコントローラー名
上記コマンドで名前解決が成功し、応答が返ってくるかどうかチェックしましょう。もし失敗する場合は、DNSゾーンの設定やレコードの有無を再度確認してください。
3. ファイアウォールや通信ポートの確認
企業ネットワークではセキュリティ対策のためにファイアウォールが構成されていることが多いため、ADレプリケーションに必要なポートが開放されているかどうかも確認します。たとえば、RPC(135/TCP)やKerberos(88/TCP, 88/UDP)、LDAP(389/TCP)などがブロックされている場合は通信が失敗します。また、DC間でDFS Replicationなどを使用している場合は追加のポートが必要になることもあります。
4. ドメインコントローラーのコンピューターアカウントパスワードをリセット
「The target principal name is incorrect」というエラーは、ドメインコントローラーのコンピューターアカウントパスワードが何らかの理由で同期不整合を起こしているときによく見られます。特に問題のドメインコントローラーがPDC Emulator以外の場合、以下の手順でパスワードをリセットし再起動すると改善する可能性があります。
netdom resetpwd /s:<PDCまたはターゲットDC名> /ud:<ドメイン名>\domain_admin /pd:*
コマンドのポイントは以下の通りです。
オプション | 説明 |
---|---|
/s:<サーバー> | PDCの役割を持つドメインコントローラーなど、パスワード情報を同期する相手を指定 |
/ud:<ドメイン>\User | ドメイン管理者アカウントなど、十分な権限を持つユーザーを指定 |
/pd:* | パスワードを非表示で入力するための指定。コマンド実行後にパスワード入力を求められる |
このコマンドを実行した後、対象のドメインコントローラーを再起動し、レプリケーション状態を再度確認します。パスワードリセットによってKerberos周りの認証不整合が解消されるケースが多いです。
5. 時刻同期 (Windows Time Service) の確認
AD環境では、時刻のズレが大きいとKerberos認証自体が失敗するためレプリケーションもエラーとなります。ドメインコントローラーの時刻同期は、PDC Emulatorを参照して正確に行われる仕組みが推奨されます。PDC Emulatorが外部NTPサーバーと正しく同期し、他のドメインコントローラーがPDC Emulatorと同期をとっているかどうかを確かめることが大切です。
代表的な確認コマンドは次の通りです。
w32tm /query /source
w32tm /query /status
ここでソースが予期せぬサーバー(ループバックアドレスや誤ったNTPサーバー)になっていないかに注意して確認しましょう。
6. レプリケーションの状態を再確認する
上記の対策を行った後は、再度以下のコマンドでレプリケーションの状態をチェックします。
repadmin /syncall /AdeP
repadmin /showrepl
repadmin /replsum
repadmin /showrepl * /csv > c:\repsum.csv
これらのコマンドを実行すると、どのドメインコントローラーとのレプリケーションが成功し、どこが失敗しているのかのステータスを確認できます。とくに「repadmin /replsum」では失敗数の一覧が簡単に把握できるため便利です。
その他の確認ポイントと運用ベストプラクティス
エラーが解消されない場合、もしくはそもそも問題が頻繁に起こる場合には、以下の点にも注目するとよいでしょう。
1. SPN (Service Principal Name) の登録状況
SPNが重複登録されている、または登録されていないときにKerberos認証エラーが発生します。setspnコマンドを使い、ドメインコントローラーのHOSTやLDAPサービスに対応するSPNが正しく登録されているかを確認しましょう。
2. イベントビューアーのログを精査する
Active Directory関連のイベントは「Directory Service」ログや「System」ログに記録されることが多いです。エラーメッセージの詳細を精読し、レプリケーション以外のサービス障害やネットワーク関連の警告が出ていないかを見逃さないようにします。
3. FSMOロールホルダーの健全性チェック
FSMOロールが正しく動作していない場合、レプリケーション以外にもドメイン機能に障害が出ることがあります。以下のコマンドでFSMOロールの場所を確認し、そのサーバーのイベントログや稼働状況を点検しましょう。
netdom query fsmo
4. DCプロモーションやドメイン参加における考慮
新しいドメインコントローラーを追加した際や、既存のDCを再インストールしたケースなどは、とくにレプリケーションの不整合が生じやすくなります。セットアップ直後に必ずrepadminコマンドで同期状況を確かめ、不要なオブジェクトやメタデータが残存していないかチェックしてください。
5. 定期的なヘルスチェックと監視
運用の現場では、レプリケーション状態を定期的にモニタリングすることが大切です。repadminコマンドを定期実行するバッチを組む、あるいはSystem Centerなどの監視ツールで「イベントID 2087」や「イベントID 1311」「イベントID 1864」などのレプリケーションに関連したイベントを監視しておくと、トラブル発生時に迅速に対処できます。
まとめ:確実なレプリケーションのために
Active Directoryのレプリケーションは、組織全体のアカウント管理や認証を支える基盤機能です。そのため、レプリケーションエラーが生じるとユーザー体験やセキュリティに深刻な影響が及びます。実際には、DNS設定の不備や時刻同期の不具合など、基本的な構成ミスが原因となるケースが意外と多いです。
また、「The target principal name is incorrect」や「Access is denied」のようなエラーが出た場合は、ドメインコントローラーのコンピューターアカウントパスワードリセットやSPNの確認が突破口となることが多く、Kerberos認証の仕組みを再確認する良い機会にもなります。
本記事で紹介した手順を踏めば、多くの場合はエラーを解消できるはずです。もしどうしても改善しない場合は、マイクロソフトの公式ドキュメントやサポートを活用し、イベントログの詳細なメッセージやデバッグログを解析してさらなる原因究明を行いましょう。
追加のヒント:Kerberosトラブルシューティング
ADレプリケーションの根幹にはKerberos認証が存在します。Kerberosに問題があると、クライアント認証だけでなくDC間の認証も失敗するため、レプリケーションがうまくいかなくなるケースが出てきます。以下にKerberosのトラブルシューティングで役立つポイントを挙げます。
1. klistコマンドの活用
Windows OS上でKerberosチケットの一覧を確認するときは、klistコマンドが便利です。クライアントPCやドメインコントローラー上でコマンドプロンプトを開き、以下を実行すると取得済みのチケットを確認できます。
klist
問題のあるチケットが表示されている場合は、ログオフ・ログオンや、klist purgeでチケットをクリアしてから再取得を試すといった手段が有効です。
2. SPN重複の検知
SPNが重複していると、Kerberos認証がどのアカウントを参照して良いのか分からなくなる可能性があります。以下のようにsetspnコマンドでSPNの重複をチェックできます。
setspn -X
重複が見つかった場合は、正しいアカウントにのみSPNを登録し、不要な方を削除することで解決します。
3. krbtgtアカウントの状況確認
Active Directoryにはkrbtgtという特別なアカウントがあります。これはKerberosチケットを発行するためのキーを保持するアカウントであり、このパスワードが漏洩したり、同期不整合を起こすと広範囲な認証障害に発展します。通常は再設定やローテーションを行う際に慎重な計画が必要ですが、一度でもセキュリティ侵害の疑いがある場合はパスワードリセットなどの措置を検討せざるを得ない場合もあります。
最後に
Active Directoryのレプリケーションを正常に維持することは、企業のIT運用において極めて重要です。レプリケーションに問題が起こると、ユーザーがドメインにログオンできない、グループポリシーが適用されないなど、深刻な影響が連鎖的に発生しやすいからです。
本記事でご紹介した内容を踏まえて、まずは基本的なDNS・ネットワーク構成、管理者権限の確認、ドメインコントローラーのマシンアカウントパスワードリセット、時刻同期のチェックなどを順序立てて行っていただければ、多くのADレプリケーションエラーは解消されるはずです。もしそれでも解決しないときは、イベントビューアーの詳細ログやFSMOロールの状態、Kerberosトラブルシューティングをさらに深掘りして対処してみてください。
組織の規模やセキュリティポリシーに応じて、運用ベストプラクティスを定期的に見直すことも忘れずに行いましょう。IT環境がますます複雑化するなか、Active Directoryを堅牢に保ち続けることが、安定したシステム運用とセキュアな認証基盤の維持につながります。
コメント