Azure AD Domain Services（Azure AD DS / Microsoft Entra Domain Services）を導入したものの、用途がなくなりコスト削減のため削除したい。しかし Microsoft 365（Entra ID）のサインインまで影響しないか不安…という方向けに、影響範囲と削除前チェック、削除後の注意点を整理します。
まず押さえる：Azure AD DS は Microsoft 365 の「ログイン基盤そのもの」ではない
結論を急ぐ前に、混同されがちな用語を整理します。Microsoft 365 のユーザー・サインイン・MFA・条件付きアクセスなどの中心は Microsoft Entra ID（旧 Azure AD） です。一方、Azure AD DS（現在の名称は Microsoft Entra Domain Services）は、Entra ID のユーザーやグループを取り込み、LDAP / Kerberos / NTLM / ドメイン参加 / グループポリシー（GPO） といった “AD DS 互換の機能” を、Azure の仮想ネットワーク（VNet）内で提供するマネージドサービスです。
| 項目 | Microsoft Entra ID（旧 Azure AD） | Azure AD DS / Microsoft Entra Domain Services |
|---|---|---|
| 主な役割 | Microsoft 365 / SaaS の認証・認可（モダン認証中心） | Azure 内で AD DS 互換のドメイン機能を提供（レガシー対応） |
| 代表的なプロトコル | OIDC / OAuth2 / SAML（※サービス側により） | LDAP / LDAPS / Kerberos / NTLM |
| ユーザー/グループの“元” | Entra ID（またはオンプレ AD DS から Entra Connect で同期） | Entra ID から取り込み（背景同期） |
| 同期方向 | （ID の本体） | Entra ID → Domain Services の片方向（逆方向はない） |
| 典型用途 | Microsoft 365 サインイン、条件付きアクセス、MFA、SSPR など | ドメイン参加が必須の VM/アプリ、LDAP が必要なレガシーアプリ、GPO 運用など |
この “役割分担” を理解すると、「Azure AD DS を削除したら Microsoft 365 が止まるのでは？」という不安は、かなり整理しやすくなります。
結論：Azure AD DS を削除しても Microsoft 365 のサインインは基本的に影響しない
Azure AD DS は Entra ID からユーザー・グループ・資格情報（パスワードハッシュ等）を片方向で取り込んで マネージドドメインを構成します。逆に、Domain Services 側で作ったもの（例：カスタム OU、GPO、独自 DNS レコード、Domain Services 内のサービスアカウント等）は Entra ID に戻る同期をしない という設計です。
つまり、Azure AD DS を削除しても Entra ID 自体が削除されるわけではない ため、Microsoft 365 のログイン基盤（Entra ID 側の認証）が消えることは通常ありません。さらに、Microsoft のドキュメントでも「同期は一方向であり、マネージドドメイン側の問題が Entra ID 側の機能や環境に影響しない」趣旨が明示されています。
ここがポイント：影響が出るのは「Microsoft 365 のサインイン」ではなく、Azure AD DS に依存して “ドメイン認証” をしていた Azure リソースやアプリです。
削除で影響が出る範囲：Azure AD DS に“ぶら下がっていたもの”だけ
Azure AD DS を削除すると、マネージドドメインのドメインコントローラーは VNet から削除され、Domain Services 側のデータは恒久的に削除されます。また、ドメイン参加していたマシンはドメインとの信頼関係が失われ、通常はドメイン離脱（Unjoin）などの対応が必要になります。
| 対象 | Azure AD DS 削除後 | よくある症状 | 優先して確認すべきポイント |
|---|---|---|---|
| Microsoft 365（Outlook/Teams/SharePoint 等）のサインイン | 基本的に継続 | 通常は変化なし | Entra ID 側で管理しているか（通常はそう） |
| Entra ID のユーザー/グループ | 残る | Azure AD DS 側の削除では消えない | 運用の主が Entra ID であることを確認 |
| Azure AD DS にドメイン参加している VM / サーバー / クライアント | 信頼関係が切れる | ドメインユーザーでログオン不可、RDP で詰む | ローカル管理者で入れるか、離脱/再参加計画があるか |
| GPO 運用（セキュリティ設定、ソフト配布等） | 消える（Domain Services 側のデータ） | ポリシー適用が止まる | GPO のバックアップ、代替（Intune 等） |
| LDAP/LDAPS を使うアプリ（ディレクトリ参照/認証） | 停止 | ログイン不可、認証エラー | 389/636 の接続先が Azure AD DS になっていないか |
| Domain Services 内のカスタム OU / DNS レコード / GMSA 等 | 恒久削除 | 設定が戻らない | 必要なら事前にエクスポートや移行を検討 |
特に注意したいのは、Domain Services 側で作ったものは “戻らない” という点です。カスタム OU に作成したユーザー/グループ/サービスアカウント等は Entra ID へ同期されず、削除と同時に失われます。
削除前にやるべき棚卸し：最短で “依存” を見つけるチェックリスト
「Azure AD DS を使っていないつもり」でも、過去のPoCや一部システムだけが参照しているケースがあります。削除を安全に進めるには、認証経路（誰が、何に、どのプロトコルで認証しているか） の棚卸しが最短ルートです。
| チェック項目 | なぜ重要か | 具体的な確認方法（例） | 代替案の方向性 |
|---|---|---|---|
| ドメイン参加している端末/VMがあるか | 削除後にログオン不能・運用停止になりやすい | 管理用VMのAD管理ツールでコンピューターオブジェクトを確認／Azure内のVM一覧と突合 | Microsoft Entra 参加（Intune管理）へ移行、またはローカル/別ADへ移行 |
| LDAP/LDAPS（389/636）を使うアプリがあるか | Entra ID は LDAP を提供しないため、依存があると即影響 | アプリ設定のディレクトリ接続先、NSG/Firewallログの宛先IP、ロードバランサーの先を確認 | モダン認証対応（OIDC/SAML）へ改修、または AD DS（VM）に置き換え |
| Kerberos/NTLM 前提の仕組みがあるか（SMB等） | ドメイン機能がないと認証できない領域がある | ファイル共有（SMB）、古いミドルウェア、レガシー認証の有無を確認 | Azure Files の別方式（Entra Kerberos 等）や、認証方式の再設計 |
| Azure Files を “Entra Domain Services 認証” で使っていないか | ストレージアカウントが Domain Services と紐づくため、削除で影響が出うる | 対象ストレージの「Identity-based access」が Entra Domain Services になっていないか確認 | オンプレ AD DS / Entra Kerberos など別の identity source へ切替 |
| VNet の DNS 設定が Azure AD DS の IP を指していないか | 削除後、名前解決が崩れて波及障害になりやすい | VNet の DNS サーバー設定、VM の DNS 設定、プライベートDNSゾーンの関連を確認 | Azure 既定 DNS や別DNS へ戻す、手順書化して段階移行 |
| GPO / OU / 独自 DNS レコード等を運用していないか | 削除で恒久的に消える（復元前提にできない） | GPOバックアップ、DNSレコード一覧のエクスポート、OU構成の記録 | Intune/構成管理へ移行、または別ADへ移設 |
Azure Files については、Microsoft のドキュメントで「Azure Files の Entra Domain Services 認証を有効化すると、ストレージアカウントが関連する Domain Services 展開に “暗黙的にドメイン参加” する」旨が説明されています。Domain Services を削除するなら、関連するストレージアカウントが存在しないか（または別方式に移行済みか）を必ず確認してください。
安全に削除するための実践フロー
「削除ボタンを押す」自体は簡単でも、依存関係の剥離が済んでいないと運用停止に直結します。以下は、現場でトラブルになりにくい順番です。
| フェーズ | やること | 狙い | 完了判定（例） |
|---|---|---|---|
| 棚卸し | ドメイン参加端末、LDAP/SMB、DNS、Azure Files 等の依存を洗い出す | 影響範囲を “見える化” する | 依存が「0」または「移行済み」になっている |
| 代替設計 | 各依存先の代替（Entra 参加/Intune、AD DS on VM、アプリ改修 等）を決める | 削除後に困らない状態へ | 移行先の認証経路がテストできている |
| 段階移行 | 影響が大きいものから順に切替（例：Azure Files → アプリ → 端末） | 障害を局所化する | 本番トラフィックが Azure AD DS を参照していない |
| 削除前最終確認 | VNet DNS、NSG、アプリ設定、ストレージ設定を再チェック | 見落とし防止 | 監視/ログ上も参照が消えている |
| 削除 | Microsoft Entra 管理センターで Domain Services を削除 | 課金停止・不要機能の撤去 | 削除完了（DC が VNet から消える） |
| 事後検証 | Microsoft 365 サインイン、主要業務、VM へのアクセスなどを確認 | 影響がないことを担保 | 障害がない/想定内の変更のみ |
削除操作については、Microsoft の手順として「Entra 管理センターにグローバル管理者でサインインし、対象ドメインを選んで Delete を実行する」流れが案内されており、削除時にはドメイン名の再入力で確認が入ります。削除は 15〜20 分以上かかる場合がある点も注意です。
削除後に起きがちなトラブルと、事前にできる回避策
ドメイン参加していた VM/端末にサインインできない
削除後はドメインコントローラーが消えるため、ドメイン参加していたマシンはドメインとの信頼関係を失います。その結果、企業アカウント（ドメインユーザー）でログオンできなくなる ことがあります。基本は ローカル管理者でのログオン経路を確保したうえで、ドメイン離脱・再構成を行います。
- 削除前に、ローカル管理者（緊急アカウント）でのログオンを実機で検証しておく
- 必要なら「Entra 参加」や「別ADへの参加」へ移行してから削除する
LDAP/LDAPS を使っていたアプリが動かなくなる
Entra ID は基本的に LDAP サーバーではないため、レガシーアプリの “LDAP で認証したい/検索したい” 要件を Azure AD DS が肩代わりしているケースがあります。Domain Services は VNet 内に割り当てられ、LDAP や Kerberos/NTLM などを提供する位置づけです。
- 可能ならアプリを OIDC/SAML 等のモダン認証へ移行（将来的な運用コストも下がりやすい）
- どうしても LDAP が必要なら、AD DS を VM 上で運用する/別のディレクトリ基盤を用意するなど “機能を残す” 設計が必要
Azure Files（SMB）が急にアクセスできなくなる
Azure Files の “identity-based authentication” は複数の identity source を選べますが、そのうちの 1 つが Microsoft Entra Domain Services です。ストレージアカウント側の設定により、Domain Services 認証を有効化するとストレージアカウントが関連する Domain Services に結びつきます。
- ストレージアカウントがどの identity source を使っているかを先に確定する
- 必要なら、オンプレ AD DS や Entra Kerberos など別方式へ段階的に切替してから削除する
「削除して、やっぱり再作成した」あとに認証できない
削除そのものは戻せません。さらに、Domain Services は NTLM/Kerberos 用のパスワードハッシュが必要で、削除時点でマネージドドメインに保存されていたハッシュも削除されます。あとから同じテナントで再作成しても、以前のハッシュ情報を “そのまま使い回す” ことはできず、再構成やパスワードハッシュ同期のやり直しが必要になります。
- 「削除＝完全撤去」を前提に、再作成が必要にならないよう依存を潰してから削除する
- 移行目的（別サブスクリプション等）なら、再参加・再設定が発生することを前提に計画する
「別サブスクリプションへ移行したい」は実質 “削除→新規作成” になりやすい
コスト配賦や管理分離のためにサブスクリプションを変えたい、リージョンを変えたい、という相談も多いですが、Domain Services は作成後に移動できない制約があります。Microsoft の FAQ やチュートリアルでも「作成後は別サブスクリプション/リソースグループ/リージョンへ移動できない」旨が明記されています。
そのため “移行” を狙う場合、現実的には次のいずれかになります。
- リージョン変更だけが目的：レプリカセットを追加して段階的に切替できる余地がある（要件により可否が変わる）
- サブスクリプション/設計全体を変えたい：削除→新規作成→ドメイン参加し直し を前提に、端末・アプリ側の再構成まで含めて計画する
Azure Virtual Desktop（AVD）を使っている場合の考え方
AVD のセッションホストが Azure AD DS にドメイン参加している構成だと、Domain Services を削除した時点で影響を受けます。一方で、AVD では Microsoft Entra 参加のセッションホスト という選択肢があり、条件次第では Domain Services（または DC）の必要性を減らせます。
「AVD があるから Azure AD DS は必須」と決めつけず、現行の認証要件（FSLogix、ファイル共有、業務アプリの認証方式） を前提に、どこまで Entra 参加へ寄せられるかを評価すると、コスト削減と運用簡素化が同時に進むケースがあります。
まとめ：判断基準はシンプル。消えるのは “Domain Services にぶら下がった機能”
- Azure AD DS（Microsoft Entra Domain Services）は Entra ID から片方向同期で AD DS 互換機能を提供するサービスです。
- したがって、Azure AD DS を削除しても Microsoft 365 のサインイン基盤（Entra ID）そのものが消えるわけではない ため、Microsoft 365 のログイン運用は通常どおり継続しやすいです。
- 一方で、削除するとドメインコントローラーが消え、Domain Services 側のデータは恒久削除され、ドメイン参加端末は信頼関係を失います。
- 削除前に、ドメイン参加・LDAP・SMB（Azure Files）・DNS を中心に依存関係を棚卸しし、「依存ゼロ」または「代替へ移行済み」にしてから削除するのが安全です。
コメント