Azure AD（Microsoft Entra ID）参加端末を本格的に導入すると、「PC名で社内サーバーに名前解決できない」「リモート操作ツールから端末が見つからない」といった悩みがよく発生します。多くの場合、オンプレミスDNSに自動登録されていないことが原因です。本記事では、その仕組みと現実的な4つの解決パターンを、設計・運用の観点から詳しく解説します。
Azure AD（Microsoft Entra ID）参加端末とオンプレDNSの基本を整理する
まず、「なぜ Azure AD 参加端末だけではオンプレミス DNS に自動登録されないのか」を整理しておきます。ここを理解しておくと、後の対策が腹落ちしやすくなります。
オンプレ AD 環境での “普通の” 動的 DNS 更新
従来のオンプレミス Active Directory ドメイン参加端末では、以下のような流れで DNS にレコードが登録されます。
- 端末がドメインに参加している（コンピュータアカウントを AD に持っている）。
- 端末自身、または DHCP サーバーが、ドメインコントローラー上の DNS に対して 動的更新（Dynamic Update） を行う。
- 更新は Kerberos などのドメイン認証を使って行われるため、安全に A レコード / PTR レコードが作成・更新される。
このとき、DNS サーバー側ではゾーンを 「安全な動的更新のみ（Secure only）」 にしておくのが一般的です。つまり「ドメインに所属する主体（端末 / DHCP サービスアカウント）だけが更新できる」状態になっています。
Azure AD（Microsoft Entra ID）は DNS を提供しない
ここで重要なのが、Azure AD（Microsoft Entra ID）は認証・認可のサービスであって、DNS サービスではないという点です。
- オンプレ AD DS（ドメインサービス）…ユーザー / コンピュータアカウント ＋ Kerberos 認証 ＋ DNS 連携
- Azure AD（Microsoft Entra ID）…IDaaS（クラウドID基盤）であり、DNS レコード管理機能は持たない
そのため、端末を「Azure AD 参加」しただけでは、オンプレ DNS に対して「自分の A レコードを登録しておいて」と頼むための資格情報（AD コンピュータアカウント）がありません。これが、Azure AD 参加のみの端末で DNS 自動登録が動かない根本理由です。
オンプレ AD 参加 / Azure AD 参加 / ハイブリッド参加の違い
| 項目 | オンプレ AD 参加 | Azure AD 参加のみ | ハイブリッド Azure AD 参加 |
|---|---|---|---|
| 認証先 | オンプレ AD DS | Azure AD（Microsoft Entra ID） | オンプレ AD DS ＋ Azure AD の両方 |
| コンピュータアカウント | オンプレ AD に存在 | なし | オンプレ AD に存在 |
| DNS 自動登録 | クライアント / DHCP からの動的更新が利用可能 | 既定では不可（仕組みなし） | オンプレ AD 参加と同様に可能 |
| GPO 適用 | 可能 | 不可（ローカルポリシー / Intune 管理など） | GPO も Intune も併用可能 |
この表から分かる通り、「DNS に自動登録する仕組み」があるのはオンプレ AD にコンピュータアカウントを持っているケースだけです。Azure AD 参加のみの端末では、この部分を別の手段で補う必要があります。
結論：Azure AD 参加のみではオンプレ DNS に自動登録されない
まとめると、次のようになります。
- Azure AD（Microsoft Entra ID）にのみ参加した端末は、そのままではオンプレ DNS に自動登録されない。
- オンプレ DNS 側から見れば、ただのワークグループ端末とほぼ同じ扱いになる。
- その結果、PC 名での名前解決ができない / ツールから端末を検索できないといった問題になりやすい。
しかし、実運用では「Azure AD 参加端末を使いながら、オンプレミスのファイルサーバーや管理ツールから PC 名で引きたい」といったニーズは多く存在します。そこで次のような４つのアプローチで、DNS の動的更新を疑似的に実現していきます。
DNS 自動登録を実現する 4 つのアプローチ
Azure AD 参加のみの端末でオンプレ DNS の自動更新を実現する代表的なパターンは以下の 4 つです。
| 方式 | 概要 | 向いているケース |
|---|---|---|
| ハイブリッド参加 | オンプレ AD にもドメイン参加させ、同時に Azure AD に登録する。 | 社内リソースが多く、既存 AD 運用も継続する組織。 |
| DHCP 代理更新 | DHCP サーバーが端末の代わりに DNS レコードを更新する。 | 常時社内ネットワークにつながる端末が多い環境。 |
| クライアントスクリプト | Intune 等で PowerShell を配布し、端末自身に DNS 更新コマンドを実行させる。 | テレワーク・出張が多く、ネットワーク条件が多様な環境。 |
| VPN 接続時登録 | VPN 接続イベントをトリガーにスクリプトを実行する。 | 社外から VPN 経由でのみ社内へアクセスする端末が多い場合。 |
ここからは、それぞれの方式について、仕組み・設定のポイント・向き不向きを具体的に見ていきます。
ハイブリッド Azure AD 参加で DNS 自動登録を維持する
最も「AD らしい」方法が、ハイブリッド Azure AD 参加（Hybrid Azure AD Join）です。既にオンプレ AD がしっかり存在しており、今後も当面はなくならないのであれば、この方式がもっとも自然です。
ハイブリッド参加の全体イメージ
- 端末は従来通り、オンプレ AD ドメインに参加している。
- 同じ端末オブジェクトが Azure AD（Entra ID）にも登録され、クラウド認証・Intune 管理なども利用できる。
- DNS に関しては、オンプレ AD 参加端末としての仕組み（クライアントまたは DHCP による動的更新）がそのまま使える。
つまり、Azure AD 参加端末としての利便性を享受しつつ、DNS 周りは従来のオンプレ AD と同じ挙動にできます。
構成の流れ（ざっくり）
- オンプレ AD と Azure AD 間に Entra Connect（旧 Azure AD Connect） を構成する。
- オンプレ AD で管理しているユーザー / コンピュータオブジェクトを Azure AD に同期させる。
- グループポリシーや手動操作により、端末をハイブリッド参加状態にする。
- 以降、端末の DNS 更新は従来のドメイン参加端末と同様に動作する。
もちろん、詳細な手順や前提条件（UPN サフィックスの統一、同期対象の OU 設計など）は別途検討が必要ですが、「DNS のために余計なワークアラウンドを増やさなくて良い」というのが最大の強みです。
メリット・デメリット
| 観点 | メリット | 注意点 |
|---|---|---|
| 運用 | 既存 AD のノウハウ・GPO をそのまま活かせる。 | オンプレ AD を今後も維持する前提になる。 |
| DNS | 動的更新の挙動が従来と同じで分かりやすい。 | AD DS と DNS の設計ミスがある場合、そのまま引きずる。 |
| セキュリティ | 従来の Kerberos + セキュアな動的更新が利用できる。 | オンプレ側のパッチ運用・監視なども継続が必要。 |
「クラウドに寄せたいが、オンプレ AD を今すぐ無くす予定はない」という組織では、ハイブリッド参加をベースにシンプルに考えるのが結果として近道になることが多いです。
DHCP による DNS 代理更新（プロキシ更新）
次に、DHCP サーバーに DNS 更新を「肩代わり」させる方法です。端末が常に社内ネットワークから IP アドレスを取得する前提ならば、もっとも手離れの良い方法です。
DHCP 代理更新の仕組み
Windows Server DHCP を例にすると、DHCP サーバーは次のように動作します。
- クライアントが DHCP で IP アドレスを取得する。
- DHCP サーバーが、クライアントのホスト名（FQDN）と IP アドレスを元に、DNS サーバーへ A レコード / PTR レコードの更新要求を送る。
- この更新要求は、DHCP サーバー自身の資格情報（コンピュータアカウント、または指定したサービスアカウント）で行われる。
クライアント側がワークグループであっても、DHCP サーバーに十分な権限があれば、DNS レコードを「代理で」作成してくれるわけです。
Windows DHCP サーバーでの設定ポイント
Windows Server DHCP での代表的な設定箇所をまとめます。
| 設定箇所 | 項目 | 推奨設定 |
|---|---|---|
| DHCP 管理コンソール IPv4 （またはスコープ）プロパティ > DNS タブ | 「常に DNS レコードを動的に更新する」 | チェックを入れる（クライアントが要求しない場合でも更新する）。 |
| 同上 | 「クライアントが動的更新を要求しない場合にもレコードを更新する」 | チェックを入れて、Azure AD 参加端末なども確実に更新対象にする。 |
| IPv4（サーバー）プロパティ > 詳細 | DNS 更新の資格情報 | 専用のドメインユーザー（サービスアカウント）を指定し、最小権限で運用。 |
| IPv4（サーバー）プロパティ > 詳細 | Name Protection（名前保護） | 私物端末の持ち込みが多い環境では有効化を検討。 |
サービスアカウント設計のコツ
DNS 更新用のサービスアカウントは、次のようなポリシーで設計すると安全です。
- 専用のドメインユーザーを作成し、人間がログオンしない前提にする。
- 対象の DNS ゾーンに対して A / PTR レコードの作成・更新ができる最低限の権限だけを付与する。
- パスワードは十分に長くし、定期的なローテーションを OS の機能（gMSA など）で自動化することも検討。
この方式が向いている環境
- 端末の大半が社内 LAN に常駐しており、IP を必ず社内 DHCP から取得する。
- DHCP サーバーを集中管理しており、ゾーンやスコープの設計が整理されている。
- 端末の種類（AD 参加 / Azure AD 参加 / ワークグループ）が混在していても、一括で DNS を管理したい。
逆に、自宅やカフェなどの NAT 配下の IP を DNS に登録しても意味がないため、テレワーク主体の組織では、後述のスクリプト方式や VPN 連動方式と組み合わせるケースが多くなります。
クライアント側スクリプトで DNS 登録を行う
三つ目の方法は、端末自身に DNS 登録コマンドを実行させる方式です。Azure AD 参加端末は Intune や各種 MDM で管理されることが多いため、それを活かして柔軟に制御できます。
代表的なコマンド
Windows クライアントから DNS の再登録を行う代表的なコマンドは次の 2 つです。
Register-DnsClient（PowerShell）ipconfig /registerdns（コマンドプロンプト）
より細かく制御したい場合は PowerShell の Register-DnsClient を使うのがおすすめです。例えば、特定のインターフェイスだけを対象にするサンプルは以下の通りです。
# DNS サフィックスとインターフェイス名で対象を絞る例
$dnsSuffix = "corp.example.local"
$if = Get-DnsClient |
Where-Object {
$_.ConnectionSpecificSuffix -eq $dnsSuffix -and
$_.InterfaceAlias -like "Ethernet*"
} |
Select-Object -First 1
if ($if) {
Register-DnsClient -InterfaceIndex $if.InterfaceIndex -Verbose
}
このようにしておくと、社内ネットワーク用のインターフェイスが有効なときだけ DNS 更新を行うことができます。
Intune での配布・実行例
Intune（Microsoft Intune / Endpoint Manager）を利用している場合、次のような流れでスクリプトを展開できます。
- 上記のような PowerShell スクリプトを作成し、端末に配布する。
- Intune の「デバイス構成」または「スクリプト」機能でスケジュールを設定する。
- 「サインイン時に実行」「1 日 1 回実行」といったルールを設定する。
- 必要であれば、VPN 接続有無やネットワーク到達性をスクリプト内で判定し、条件を満たさない場合は何もしないようにする。
社内ネットワークに到達できない状態で実行しても意味がないどころか、余計なログを生むだけなので、到達性チェック（DNS サーバーへの疎通確認など）をスクリプト内で行うのがポイントです。
実運用での注意点
- DNS ゾーンのプロパティで、動的更新を許可しているか（セキュアのみ / 非セキュアも許可）を確認する。
- 非セキュアな更新を許可する場合は、なりすまし更新のリスクを理解したうえでネットワークセグメントを限定する。
- スクリプトの失敗やタイムアウトが続くと、イベントログがノイズだらけになるため、リトライ回数やログ出力を適切に制御する。
テレワーク主体の組織では、「社内に来たときだけ」「VPN で社内にトンネルしたときだけ」更新するロジックを組み込んでおくと、不要な DNS レコードを作らずにすみます。
VPN 接続時だけ DNS 登録を行う設計
次に、VPN 接続のタイミングだけ DNS 更新を行う方式です。外出やテレワークが多く、「社内にいるとき＝VPN を張っているとき」という前提が成り立つ場合に有効です。
VPN 連動の考え方
多くの VPN クライアント（Always On VPN 含む）は、次のような仕組みを持っています。
- VPN 接続が確立したときにスクリプトを実行する「接続後処理（Post-Connect）」機能。
- Windows のイベントログに、接続 / 切断のイベントを出力する機能。
これらを利用して、VPN 接続直後に Register-DnsClient を実行するようにしておけば、社内 DNS には「社内に到達可能なときだけ」レコードが登録されます。
接続後スクリプトの例
VPN クライアントが接続後スクリプトをサポートしている場合、非常にシンプルです。
# VPN 接続後に実行される想定のスクリプト
$dnsServer = "10.0.0.10" # 社内 DNS サーバー
if (Test-Connection -ComputerName $dnsServer -Count 1 -Quiet) {
Register-DnsClient -Verbose
}
Test-Connection で DNS サーバーへの疎通確認を行い、到達可能な場合だけ DNS 更新を実行しています。これにより、VPN 側の障害や接続失敗時の無駄な処理を減らせます。
イベントログをトリガーにしたタスクスケジューラ連携
VPN クライアントがスクリプトフックを提供していない場合でも、Windows タスクスケジューラでイベントログをトリガーにする方法があります。
- VPN 接続時に出力されるイベント ID（RAS、VPN クライアント固有のログなど）を確認する。
- そのイベントをトリガーとするタスクを作成し、PowerShell スクリプトを実行するようにする。
- スクリプトの中で DNS 更新を実行する。
多少手間はかかりますが、クライアント種別に依存しづらい汎用的な手法として覚えておくと役に立ちます。
どの方式を選ぶべきか：設計の目安
4 つの方式を見てきましたが、実際にどれを選ぶかは、「組織のネットワークと運用の現実」で決まります。よくあるパターンを整理してみます。
社内リソース中心で、オンプレ AD を今後も使い続ける場合
- 第一候補：ハイブリッド Azure AD 参加
- 既に GPO やログオンスクリプト、ファイルサーバー等がオンプレ AD に強く依存している場合、無理にピュア Azure AD 参加に振り切るよりも、ハイブリッドで安定させる方が現実的です。
- DNS については従来と同じ仕組みが使えるため、追加のスクリプトや DHCP 再設計の負担も減らせます。
常時社内ネットワークにいる端末が大半で、DHCP をしっかり管理できる場合
- 第一候補：DHCP による DNS 代理更新
- 端末の種類が混在していても、IP を配る「入口」を抑えているだけで DNS 登録も同時に管理できます。
- 特に、工場やコールセンターなど、物理的に社内から動かない端末が多い環境では相性が良いです。
テレワーク主体で、外出が多いモバイル端末が中心の場合
- 第一候補：クライアントスクリプト ＋ VPN トリガー方式
- 自宅や外出先の IP を DNS に登録しても意味がないため、「社内に到達できるときだけ登録」という発想が重要になります。
- Intune 配布スクリプトと VPN 連動スクリプトを組み合わせ、社内到達性チェックを入れたうえで DNS 更新を行う設計が現実的です。
複数方式の組み合わせも有効
実際の現場では、
- 本社のデスクトップ PC：DHCP 代理更新
- ノート PC（出張が多い）：VPN トリガー付きスクリプト
- サーバーや特殊端末：静的 DNS 登録
といったように、用途ごとに方式を使い分けることが多くなります。「すべての端末を単一方式で揃えよう」と考えすぎると、かえって設計が複雑になることもあるため注意が必要です。
DNS・DHCP 側の運用テクニックと落とし穴
どの方式を採用するにしても、DNS / DHCP 側の設計と運用が整っていないと、すぐに「名前解決がおかしい」「古いレコードが残る」といった問題につながります。ここでは代表的なポイントを挙げます。
DNS レコードのガベージコレクション（Scavenging）
動的更新を使っているゾーンでは、古くなったレコードを自動的に掃除する仕組み（Scavenging）を有効にすることが重要です。
- ゾーンごとに「No-refresh interval」「Refresh interval」を適切に設定する。
- 短くしすぎるとレコードの消え・再作成が頻繁になり、DNS 負荷やログが増える。
- 長すぎると、退職者 PC や廃棄端末のレコードがいつまでも残る。
実運用では、「PC の入れ替えサイクル」や「IP アドレス再利用の頻度」を踏まえて期間を決めると良いでしょう。
Name Protection（名前保護）の活用
私物端末や IoT 機器が多い環境では、ホスト名の競合が起こりがちです。Windows DHCP の Name Protection 機能を使うと、
- 同じホスト名で別のクライアントが DHCP リースを要求してきた場合に、意図しない上書きを防ぐことができる。
- DNS 側の所有者情報と DHCP のクライアント識別子を照合してくれる。
ただし、既存のゾーンに対して後から有効化する場合は、一時的に競合が多発する可能性もあるため、検証環境で事前検証してから本番に適用することをおすすめします。
DNS サフィックスと FQDN の整理
Azure AD 参加端末では、
- Azure AD のドメイン（例：contoso.onmicrosoft.com）
- オンプレ AD のドメイン（例：corp.contoso.local）
といった複数のドメインが絡みます。DNS 更新に利用したいのは通常、オンプレ側のドメインなので、
- クライアントの「接続固有の DNS サフィックス」が正しく設定されているか。
- VPN 接続時に、社内ドメインのサフィックスが付与されているか。
- スクリプト内で FQDN を生成する場合、誤ったサフィックスを結合していないか。
などを確認しておくとトラブルを防ぎやすくなります。
トラブルシューティングのポイント
最後に、DNS 自動登録が思った通りに動いていないときのチェックポイントを簡単にまとめます。
クライアント側で確認するポイント
ipconfig /allで、- DNS サーバーのアドレス
- 接続固有の DNS サフィックス
- ホスト名
ipconfig /registerdnsまたはRegister-DnsClient -Verboseを手動実行し、エラーが出ないか確認する。- イベントビューアの「Microsoft-Windows-DNS Client Events」ログを確認し、動的更新に関するエラーがないか確認する。
DNS / DHCP サーバー側で確認するポイント
- 対象ゾーンが「動的更新を許可する」設定になっているか。
- DHCP サーバーの DNS タブ設定が想定通りか（常に更新する、資格情報など）。
- DNS イベントログに、更新拒否や権限不足に関するイベントが出ていないか。
- キャッシュの影響を避けるため、別の端末から
nslookup <ホスト名>を行い、DNS サーバーを指定して確認する。
DNS の問題は「たまたま動いてしまう」ケースもあるため、意図した仕組みで安定して動いているかを、ログやテスト用端末で確認しておくことが重要です。
まとめ：Azure AD 参加だけでは DNS 自動登録されない。運用に合った方式を選ぶ
本記事のポイントをあらためて整理します。
- Azure AD（Microsoft Entra ID）にのみ参加した端末は、既定ではオンプレ DNS に自動登録されない。
- オンプレ DNS はオンプレ AD との連携を前提としているため、Azure AD 参加のみの端末はワークグループ端末とほぼ同じ扱いになる。
- DNS 自動登録を実現する現実的なアプローチは、主に次の 4 つ。
- ハイブリッド Azure AD 参加：AD 運用が堅く社内リソース中心なら最有力。
- DHCP 代理更新：常時社内ネットワークにいる端末が多いなら手離れが良い。
- クライアントスクリプト：Intune 等で柔軟に制御でき、テレワークに向く。
- VPN 連動：社内到達時だけピンポイントで DNS 更新したい場合に有効。
- いずれの方式でも、DNS ゾーン設計・Scavenging・Name Protection・サフィックス設計といった基盤側の整理が欠かせない。
「Azure AD 参加にしたら名前解決がうまくいかなくなった」という悩みは、裏を返せば DNS / DHCP 設計を見直す絶好のタイミングでもあります。自社のネットワーク構成と運用体制に最もフィットする方式を選び、必要に応じて複数方式を組み合わせながら、無理なく移行・運用できる形を目指してみてください。
コメント