ADとEntra IDの権限設計比較｜オンプレとクラウドで何が変わるのかを整理する

ADとEntra IDは同じMicrosoftのID管理製品ですが、設計の考え方は根本的に異なります。ADの「OU・GPO・セキュリティグループ」という構造をそのままEntra IDに持ち込もうとすると、うまく機能しない部分が出てきます。

本記事では2つの権限設計の違いを整理し、ハイブリッド構成での注意点を解説します。

Entra IDとオンプレADの連携設計については「Entra IDとオンプレAD連携｜ハイブリッド構成の設計と注意点」を参照してください。

ADとEntra IDの根本的な違い

ADとは

Active Directory（AD）
Microsoftが提供するオンプレミスのディレクトリサービス。ユーザー・コンピューター・グループ・ポリシーをドメイン単位で管理する。認証にはKerberosプロトコルを使用し、グループポリシー（GPO）でセキュリティ設定を一括配布できる。

ADとは、社内のWindowsサーバー・クライアントPCをドメインとして一元管理するオンプレミスのID管理基盤です。ADの権限設計の特徴は「OU（組織単位）を使った階層構造」と「GPOによるポリシー配布」です。ユーザーとコンピューターをOUに配置し、そのOUにGPOをリンクすることでセキュリティ設定を適用します。

Entra IDとは

Microsoft Entra ID（旧称：Azure Active Directory / Azure AD）
Microsoftが提供するクラウドベースのID・アクセス管理サービス。Microsoft 365やAzureへの認証・認可を担う。認証にはOAuth 2.0・OpenID Connect・SAMLなどのモダン認証プロトコルを使用する。

Entra IDとは、Microsoft 365・Azure・SaaSアプリへのアクセスを管理するクラウドベースのID管理基盤です。Entra IDにはADのような「OU」や「GPO」は存在しません。代わりに「ロール（役割）」と「条件付きアクセスポリシー」でアクセス制御を行います。

2つの最大の違い：「OU・GPO」と「ロール・ポリシー」

ADとEntra IDの設計思想の違いをまとめます。

項目	Active Directory	Microsoft Entra ID
管理対象	オンプレミスのPC・サーバー・ユーザー	クラウドアプリ・SaaS・Azure
認証プロトコル	Kerberos・NTLM	OAuth 2.0・OIDC・SAML
構造の単位	OU（階層構造）	フラット（階層なし）
ポリシー適用	GPO（コンピューター・ユーザーに適用）	条件付きアクセス（サインイン時に評価）
管理者権限	Domain Admins・Enterprise Admins	ロール（グローバル管理者等）
デバイス管理	ドメイン参加（GPOで管理）	Entra参加・Intune管理

最大の違いは「ADはコンピューターに設定を適用する」のに対して「Entra IDはサインイン時にアクセスを評価する」という点です。

権限設計の比較：ADとEntra IDで何が変わるか

ユーザー・グループ管理の違い

ADでもEntra IDでもユーザーとグループを作成して権限を管理しますが、グループの役割が異なります。

Active Directoryでは、セキュリティグループに権限を付与し、ユーザーをグループに追加することでリソースへのアクセスを制御します。AGDLP（アカウント→グローバルグループ→ドメインローカルグループ→アクセス許可）という設計パターンが広く使われています。

Entra IDでは、Microsoft 365グループ・セキュリティグループ・動的グループの3種類があります。動的グループは部門・役職などの属性に基づいてメンバーを自動追加・削除できるため、入社・異動・退職時の権限管理が自動化できます。

動的グループ（Dynamic Group）
ユーザーの属性（部門・役職・場所など）に基づいてメンバーを自動的に追加・削除するEntra IDのグループ機能。例えば「部門が営業」という条件を設定すると、営業部員が自動的にグループに追加され、異動時には自動的に削除される。

ADのグループ設計と最小権限の原則については「ADのユーザーとグループ管理｜最小権限を実現する設計パターン【AGDLP】」を参照してください。

管理者権限の設計の違い

ADとEntra IDでは管理者権限の粒度が大きく異なります。

Active Directoryでは以下のような権限構造になっています。

権限	範囲
Enterprise Admins	フォレスト全体
Domain Admins	ドメイン全体
OU管理者（委任）	特定のOU配下のみ

ADでは「Domain Admins」が最も使われる管理者グループですが、範囲が広すぎる問題があります。Tierモデルを使って特権アカウントを分離することが推奨されています。

Entra IDにはより細かいロール（役割）が用意されています。

ロール	主な権限
グローバル管理者	Entra ID全体・すべてのMicrosoft 365サービス
ユーザー管理者	ユーザー・グループの管理のみ
Exchange管理者	Exchange Onlineの管理のみ
セキュリティ管理者	セキュリティ設定の管理のみ
条件付きアクセス管理者	条件付きアクセスポリシーの管理のみ

Entra IDでは「グローバル管理者」を日常業務に使うのは禁物です。必要な操作に対して最小限のロールを付与する設計が基本です。Azure PIM（特権アクセス管理）を使って必要な時だけ一時的に管理者ロールを付与する運用が推奨されています。

PIMの設定と運用については「PIMとは？Azure特権アクセス管理の仕組みと実務設定ガイド」を参照してください。

デバイス管理の違い

項目	ADドメイン参加	Entra ID参加
管理ツール	GPO・RSAT	Intune・Microsoft Endpoint Manager
認証	Kerberos（DC経由）	Entra ID（クラウド）
適した環境	オンプレミス中心	クラウド・リモートワーク中心
ポリシー適用	GPOで設定を配布	IntuneでMDMポリシーを配布

ハイブリッド環境では「ハイブリッドEntra参加」という構成も使われます。ADドメインに参加しながら同時にEntra IDにも登録することで、GPOとIntuneの両方で管理できます。

ハイブリッド構成での注意点

ADとEntra IDを同期する際の設計原則

ハイブリッド構成ではMicrosoft Entra Connect（旧称：Azure AD Connect）を使ってADのユーザー・グループをEntra IDに同期します。

Microsoft Entra Connect
Active DirectoryとEntra IDのIDを同期するオンプレミスのアプリケーション。ADのユーザー・グループをEntra IDに同期し、シングルサインオンを実現する。同期方式はパスワードハッシュ同期（PHS）・パススルー認証（PTA）・フェデレーション（AD FS）の3種類がある。

Entra Connectのサーバーはドメインコントローラーに準じる重要度を持つため、Tier 0資産として管理することが推奨されています。Entra Connectが侵害されると、攻撃者はADとEntra ID両方の管理権限を奪取できる可能性があります。

特権アカウントは同期させない

ASD「Detecting and Mitigating Active Directory Compromises」では、ADの特権アカウントをEntra IDに同期しないことを強く推奨しています。

ADとEntra IDで別々の特権アカウントを使う
ADのDomain Adminsアカウントとは別に、Entra ID専用のグローバル管理者アカウントを作成する。ADが侵害されても、Entra ID側の特権アカウントは別物であるため被害が拡大しにくい。逆にEntra IDの管理者がADの特権グループに同期されていない設計が重要。

特権アカウントの設計については「AD特権アカウントの設計｜Tier0保護と管理者アカウント分離の実務」を参照してください。

現場でよくある設計ミス

ADの権限設計をそのままEntra IDに持ち込む

ADではOUの階層構造でユーザーを整理していたため、同じ発想でEntra IDも「組織別にグループを作ってメンバーを手動管理する」設計にするケースがあります。Entra IDでは動的グループを活用し、属性ベースで自動管理する設計が適切です。入社・異動のたびにグループを手動変更する運用は抜け漏れのリスクが高くなります。

グローバル管理者を日常業務に使う

「管理者だからグローバル管理者を使えばいい」という発想で、日常の管理作業にグローバル管理者アカウントを使い続けるケースがあります。グローバル管理者はEntra IDのすべてを管理できる最強の権限です。日常業務には必要最小限のロールを付与した管理者アカウントを使い、グローバル管理者はPIMで必要な時だけ一時的に有効化する運用を推奨します。

特権アカウントをADと同期させてしまう

Domain AdminsアカウントをEntra IDに同期し、そのままグローバル管理者ロールを付与してしまうケースがあります。ADが侵害された場合、その特権アカウントを使ってEntra IDまで侵害が拡大します。ADの特権アカウントとEntra IDの特権アカウントは必ず分離してください。

Entra IDのロール設計を後回しにする

「とりあえずグローバル管理者で設定してあとで整理しよう」という運用が続き、気づけばグローバル管理者が何十人もいる状態になるケースがあります。Entra IDの管理者ロールは導入時から最小権限で設計し、PIMで必要な時だけ昇格できる運用を初期から組み込んでください。

チェックリスト

設計の確認

[ ] Entra IDの管理者ロールをグローバル管理者に集中させず、必要最小限のロールを付与している
[ ] 日常業務にグローバル管理者アカウントを使っていない
[ ] グローバル管理者はPIMで一時的に昇格する運用になっている
[ ] 動的グループを活用して入退社・異動時の権限管理を自動化している

ハイブリッド構成の確認

[ ] ADの特権アカウント（Domain Admins等）をEntra IDに同期していない
[ ] Entra Connectサーバーをドメインコントローラーと同等のセキュリティで管理している
[ ] Entra ID専用の特権アカウントをADとは別に作成している
[ ] グローバル管理者アカウントにMFAを設定している

運用の確認

[ ] Entra IDのサインインログで管理者アカウントのアクティビティを監視している
[ ] 条件付きアクセスで管理者アカウントへの常時MFAを要求している

まとめ

Entra ID管理センター（entra.microsoft.com）→「ロールと管理者」→「グローバル管理者」から現在のグローバル管理者一覧を確認してください。

日常業務に使われているアカウントや、ADから同期されている特権アカウントがあれば見直しが必要です。ADとEntra IDは同じMicrosoftの製品ですが、設計の考え方は別物です。ADの「階層構造でコンピューターを管理する」発想から、Entra IDの「ロールでサインイン時のアクセスを制御する」発想に切り替えることが、セキュアなハイブリッド設計の出発点になります。