DHCPサーバーの認証がADに反映されないときは、まず DHCP 側の画面表示ではなく、AD 上に認証オブジェクトが正しく作成されているか を確認するのが先です。ドメイン参加した DHCP サーバーは AD DS 上の承認状態を LDAP で 1 時間ごとに確認し、一覧に自分の情報が見つからないと未承認扱いになります。実際の原因は、権限不足、DC への接続や DNS の問題、旧サーバーの認証情報の残骸、AD レプリケーション不整合のどれかに集約されることが多いです。 (Microsoft Learn)
この記事では、DHCPサーバーの認証がADに反映されないときの見方を、Get-DhcpServerInDC での確認、イベント ID 1046 / 1059 の読み方、権限と DNS の落とし穴、復旧コマンド、再発時の監査まで、実務でそのまま使える順番で整理します。 (Microsoft Learn)
まず切り分けの全体像
実務では、次の4パターンに分けると原因をほぼ外しません。 (Microsoft Learn)
| 確認結果 | 可能性が高い原因 | 最初にやること |
|---|---|---|
Get-DhcpServerInDC に出ない | 権限不足、AD登録失敗、旧エントリ残存 | Enterprise Admin 権限で再承認、旧エントリ確認 |
| 一度は出るが数時間〜数日で消える | AD から削除されている、レプリケーション不整合 | 監査有効化、CNF オブジェクトとレプリケーション確認 |
| 一覧には出るのに未承認になる | DC 到達性、DNS 設定、LDAP 389/TCP の問題 | Test-NetConnection と DC 側の名前解決確認 |
| 更改直後から不安定 | 旧 DHCP 情報の残骸、DNS が古い IP を返している | Remove-DhcpServerInDC → Add-DhcpServerInDC を DNS 名と IP で明示 |
DHCP認証がADに反映されないとき、何が起きているか
この話は、ドメイン参加した DHCP サーバー が前提です。Microsoft も、ドメイン環境では DHCP サーバーを AD で承認する必要があり、承認されていないサーバーは正常に機能せず、DHCP クライアントへ IP アドレスをリースしないと案内しています。ワークグループ環境なら、AD 反映ではなく別の問題として切り分けるべきです。 (Microsoft Learn)
承認情報は AD の Configuration コンテナー側に作成されます。判断基準は DHCP コンソールの見た目だけではなく、AD の authorized servers list に対象サーバーが存在するか です。確認には Get-DhcpServerInDC または netsh dhcp show server が使えます。GUI で承認した場合も反映には数秒かかることがあり、成功するとコンソール側では緑の状態で確認できます。 (Microsoft Learn)
Get-DhcpServerInDC
netsh dhcp show serverこの一覧に出ないなら、AD への登録自体ができていません。逆に一覧に出るのに DHCP サービスが未承認扱いなら、登録そのものよりも DC への到達性、LDAP 通信、DNS 名前解決 を疑う方が早いです。 (Microsoft Learn)
イベントログも必ず見ます。Event Viewer では Applications and Services Logs > Microsoft > Windows > DHCP-Server を開き、失敗時は 1046 と 1059、復旧後は 1043 または 1044 が出ているかを確認すると判断しやすくなります。 (Microsoft Learn)
原因別に見る対処ポイント
権限不足で AD に書き込めていない
DHCP のスコープ管理権限と、AD へ承認オブジェクトを書き込む権限は同じではありません。Microsoft のトラブルシュートでは Enterprise Administrator アカウント での承認を案内しており、Enterprise Admins はフォレスト基盤の変更権限として DHCP サーバーの承認を含みます。一方、DHCP Administrators は DHCP の各種管理やバックアップ/リストアはできますが、役割は DHCP サービスに限定されます。実務上、DHCP Administrators には入っているのに AD に反映されない なら、最初に疑うべきは権限不足です。 (Microsoft Learn)
DC に届いていない、または DNS がずれている
手動承認時に「指定したドメインが存在しないか、接続可能です」に近いエラーが出るなら、AD へ書けないというより DC に届いていない 可能性が高いです。Microsoft は ping と Test-NetConnection -Port 389 で DHCP サーバーから DC への基本疎通と LDAP ポートを確認するよう案内しています。さらに AD レプリケーションの診断では DNS 名前解決が依存関係として挙げられているため、DC の FQDN 解決や誤った DNS 設定も同時に見直すべきです。 (Microsoft Learn)
Test-NetConnection -ComputerName <DC-IP> -Port 389ここで失敗するなら、DHCP の再承認を何度繰り返しても根本解決になりません。先にファイアウォール、ルーティング、参照 DNS、DC 到達性を直すべきです。 (Microsoft Learn)
DNS 名と IP が食い違っている
これは更改時にとても多い原因です。Add-DhcpServerInDC を -DnsName だけで実行すると、AD に記録する IP は DNS から引かれます。サーバー更改直後や IP 変更直後に A レコードが古いままだと、承認したつもりでも別の IP で登録され、1 時間ごとの再確認で未承認へ戻る流れが起きやすくなります。入れ替え時は、-DnsName と -IPAddress をセットで明示する方が安全です。 (Microsoft Learn)
Add-DhcpServerInDC -DnsName dhcp01.contoso.local -IPAddress 10.0.0.10特に「GUI では承認したはずなのに、しばらくするとまた未承認になる」なら、DNS に古い IP が残っていないかを優先的に見てください。DHCP 自体ではなく、認証対象として AD に載っている情報が違う 可能性があります。 (Microsoft Learn)
旧 DHCP サーバーの認証情報が残っている
サーバー更改後に不安定になった場合は、旧 DHCP サーバーの認証情報が邪魔をしていないかを確認します。まず Get-DhcpServerInDC で一覧を確認し、不要な旧エントリは Remove-DhcpServerInDC で外すのが正攻法です。削除時は IP だけの指定はできない ため、DNS 名と IP をセットで渡す方が確実です。 (Microsoft Learn)
Remove-DhcpServerInDC -DnsName olddhcp.contoso.local -IPAddress 10.0.0.9
Add-DhcpServerInDC -DnsName newdhcp.contoso.local -IPAddress 10.0.0.10Add/Remove のどちらの cmdlet も、AD オブジェクトの追加・削除に加えて DHCP サービス側の認証チェックを起動します。Add 側は “already authorized” の場合でも認証チェックを走らせるため、状態の再評価にも使えます。 (Microsoft Learn)
AD レプリケーション不整合や CNF 競合オブジェクトがある
複数 DC 環境で「ある端末では見えるのに別の端末では見えない」「手動承認しても通らない」なら、AD レプリケーション不整合を疑います。Microsoft は NetServices 配下の CNF タグ付き競合オブジェクト を確認するよう案内しており、これがあると承認に失敗することがあります。CNF オブジェクトを削除する場合は、先に AD バックアップを取ってから実施するのが前提です。 (Microsoft Learn)
repadmin /showrepl * /csv > showrepl.csv
dcdiagDC 側の健全性確認には repadmin /showrepl と dcdiag が有効です。Microsoft もレプリケーション状態の確認に repadmin、DC の異常検出に DCDiag を案内しています。DHCP の問題に見えても、根は DC 側のレプリケーションや名前解決であることは珍しくありません。 (Microsoft Learn)
手動で直るのに、数日後また未承認へ戻る
いちばん厄介なのがこのパターンです。Microsoft は、手動承認では直るのに再発する場合、AD から DHCP エントリが削除されている 可能性を挙げています。再発時は DC で Audit Directory Service Changes を有効にし、Configuration コンテナーの NetServices に対して Write All Properties、Delete、Delete Subtree を監査すると、誰が変更・削除したかを Security ログで追えます。 (Microsoft Learn)
すぐ復旧したいときの手順
以下は、現場で最短復旧を狙うときの順番です。Microsoft の確認・再承認・削除/再追加・イベント確認の手順を、運用向けに並べ替えています。 (Microsoft Learn)
- Enterprise Admin 権限、または同等の承認権限を持つアカウント で作業します。まず権限不足を排除しないと、以降の確認がすべてノイズになります。 (Microsoft Learn)
Get-DhcpServerInDCとnetsh dhcp show serverを実行し、今 AD に何が登録されているかを採取します。GUI だけではなく、AD 上の実状態をここで固定します。 (Microsoft Learn)- Event Viewer の DHCP-Server ログを見て、1046 と 1059 が出ているかを確認します。復旧後の確認では 1043 / 1044 が分かりやすい目安になります。 (Microsoft Learn)
- 旧サーバーや誤ったエントリが残っているなら、
Remove-DhcpServerInDC -DnsName <旧名> -IPAddress <旧IP>で明示的に外します。IP だけでは削除できません。 (Microsoft Learn) - 現行サーバーを
Add-DhcpServerInDC -DnsName <現行FQDN> -IPAddress <現行IP>で再登録します。DNS の古い記録に引っ張られないよう、DNS 名だけでなく IP も明示 してください。 (Microsoft Learn) - 数秒待って DHCP コンソールを更新し、
Get-DhcpServerInDCに現行サーバーが出ることを確認します。GUI が追いつかなくても、PowerShell 側で見えていれば次に進めます。 (Microsoft Learn) - それでも未承認なら、
Test-NetConnection -Port 389、repadmin /showrepl、dcdiagの順で、通信経路 → レプリケーション → DC 健全性 を確認します。 (Microsoft Learn) - 「直ったのにまた消える」場合だけ、AD の監査を有効にして、誰が NetServices 配下の DHCP エントリを変更・削除しているかを追います。 (Microsoft Learn)
失敗しやすいポイント
DHCP コンソールの表示だけで判断しないこと。 承認は数秒で見えることもありますが、最終確認は Get-DhcpServerInDC とイベントログで行う方が確実です。見た目だけで「反映されていない」と判断すると、実際には GUI の更新待ちだった、という無駄が起きます。 (Microsoft Learn)
DHCP Administrators を AD 承認権限と混同しないこと。 DHCP の管理はできても、AD の Configuration 側へ認証情報を書き込む話は別です。権限で迷うなら、切り分け段階では Enterprise Admin で一度成功させる方が早いです。 (Microsoft Learn)
再承認を -DnsName だけで済ませないこと。 更改や IP 変更の直後は、DNS が古い情報を返しているだけで AD へ誤登録されることがあります。入れ替え時は DNS 名と IP の両方を明示する方が安全です。 (Microsoft Learn)
ADSI Edit を最初の手段にしないこと。 CNF 競合や削除監査の確認には有効ですが、誤操作の影響が大きい場所です。Microsoft も競合オブジェクトを削除する前に AD バックアップを推奨しています。 (Microsoft Learn)
まとめ
DHCPサーバーの認証がADに反映されないとき、最初にやるべきことは Get-DhcpServerInDC を実行し、イベント 1046 / 1059 の有無を確認することです。そこで 一覧に出ない なら権限か登録、一覧にあるのに未承認 なら DC 到達性や DNS、一度直ってまた消える なら削除監査とレプリケーション確認へ進んでください。この順序で見れば、闇雲な再インストールや危険な AD 直編集を避けながら、かなり高い確率で復旧できます。 (Microsoft Learn)
コメント