クラウドのみで Microsoft Entra Domain Services（旧 Azure AD DS）を使っていると、「既定の GPO は効くのに、セキュリティ フィルターをかけたカスタム GPO だけがどうしても適用されない」という悩みがとても多いです。フォルダー作成のようなシンプルな設定でもハマりやすいポイントなので、本記事では原因と直し方、そして同じトラブルを防ぐための設計・運用のコツを詳しく解説します。
Entra Domain Services のカスタム GPO が適用されない原因と対処法
よくある症状：既定 GPO は効くのにカスタム GPO が無視される
まずは、今回の代表的なケースを整理します。
想定している環境例
- オンプレミス AD は無し（クラウドのみ）。
- Microsoft Entra ID（旧 Azure AD）と Microsoft Entra Domain Services（Entra DS、旧 Azure AD DS）を利用。
- ユーザーとグループは Entra ID → Entra Domain Services に同期されている。
- サインインや既定 GPO の適用は問題なく動作している。
発生している現象
| GPO | リンク先 OU | 設定内容（例） | 結果 |
|---|---|---|---|
| AADDC Users GPO（既定） | AADDC Users OU | 全ユーザーに C:\Test1 フォルダーを作成 | 問題なく適用され、フォルダーが作成される |
| Test Users GPO（カスタム） | AADDC Users OU（同じ OU） | 特定グループのユーザーだけに C:\Test2 フォルダーを作成 | どのユーザーにも作成されず、GPO が効いていないように見える |
GPMC で見ると GPO のリンクは有効になっており、設定内容も正しく見えるのに、クライアント側ではまったく反映されない──この状況のとき、かなり高い確率で原因は「セキュリティ フィルターと読み取り権限の設定ミス」です。
原因の核心：セキュリティ フィルターと読み取り権限の勘違い
ポイントは、GPO をダウンロードして評価するのは「ユーザー」ではなく「クライアント PC（コンピューター アカウント）」だという点です。
コンピューターは次のような流れで GPO を処理します。
- コンピューター アカウントが、所属する OU にリンクされた GPO をドメイン コントローラー（Entra DS のマネージド DC）に問い合わせる。
- GPO のセキュリティ（ACL）を確認し、「自分（コンピューター）」が最低限 読み取り（Read） 権限を持っている GPO だけをダウンロードする。
- さらに「グループ ポリシーの適用（Apply group policy）」権限を満たすかどうかを確認し、最終的に適用するかどうかを判断する。
ここでよくやってしまうのが、セキュリティ フィルターから Authenticated Users を削除してしまうパターンです。
- 既定では、GPO のセキュリティには Authenticated Users が 読み取り + 適用 で入っている。
- 「特定のグループにだけ適用したい」と考えて Security Filtering から Authenticated Users を削除し、該当グループのみを残す。
- このとき、コンピューター アカウントが GPO を読む権限まで一緒に消してしまうことになる。
結果として、クライアントはその GPO の存在自体を知らないので、設定は一切適用されません。
「スコープ」と「委任」の役割の違い
GPMC の「スコープ」と「委任」タブの役割を整理すると、次のようになります。
| 項目 | 役割 | Entra DS での注意点 |
|---|---|---|
| スコープ (Scope) タブ セキュリティ フィルター | 「誰に適用するか」を決める（Apply 権限） | ここから Authenticated Users を削除すると、多くの場合 PC が GPO を読めなくなる |
| 委任 (Delegation) タブ | 「誰にどの権限を与えるか」を細かく制御（読み取り、編集、適用 など） | ここで Authenticated Users / Domain Computers に 読み取りのみ を残すのがポイント |
結論を一言でまとめると、
・対象を絞るのは「セキュリティ フィルター」
・PC に GPO を読ませるのは「Authenticated Users / Domain Computers の読み取り権限（委任）」
この 2 つを分けて考えていないと、今回のような「カスタム GPO だけ効かない」という現象にハマりがちです。
最短で修正する手順
では、すでに「Test Users GPO」のようなカスタム GPO があり、それが適用されていないケースを、手早く修正する手順を見ていきます。
手順 1：対象 GPO の委任タブに「Authenticated Users（または Domain Computers）」を追加
- Entra DS に参加済みの管理用サーバー/クライアントから、GPMC（グループ ポリシーの管理）を起動。
- 対象 GPO（例：Test Users GPO）を右クリックし、[プロパティ] を開く。
- [委任 (Delegation)] タブを選択。
- [追加] ボタンから Authenticated Users（または Domain Computers）を追加。
- 該当エントリを選択し、[詳細] → [詳細設定] から権限を開き、「読み取り (Read)」にのみ許可が付いている状態にする。
※「グループ ポリシーの適用 (Apply group policy)」にはチェックを付けないのがポイントです。
こうすることで、コンピューターは GPO を読めるようになりつつ、「誰に適用するか」は別のグループでコントロールできます。
手順 2：スコープタブのセキュリティ フィルターを整理
- 同じ GPO の [スコープ (Scope)] タブを開く。
- セキュリティ フィルターには、適用対象のセキュリティ グループのみが残るように調整する。
例：G-対象ユーザー だけを残す。 - このグループには、対象ユーザーだけが含まれていることを確認。
ここで使用するグループについて、次の点に注意してください。
- 必ず「セキュリティ グループ」であること
Microsoft 365 グループや動的グループはセキュリティ フィルターには使えません。 - Entra ID 側のグループが、Entra Domain Services 側に同期されていること
作成直後やメンバー変更直後は、同期に時間がかかる場合があります。
手順 3：クライアント側でポリシーを再取得して検証
設定を変えたら、クライアント PC から次のコマンドでポリシーを再取得します。
gpupdate /force
ユーザー設定を変更した場合は、サインアウト → サインインを行う方が確実です。
適用状況の確認には gpresult コマンドが便利です。
gpresult /r
ここで、ユーザー側の適用された GPO 一覧に Test Users GPO が表示されていれば、セキュリティ フィルターの設定はほぼ問題ありません。
手順 4：既定 GPO と競合していないかを確認
同じ OU（今回の例では AADDC Users OU）に複数の GPO がリンクされている場合、リンク順序や「強制 (Enforced)」設定によって、どの設定が最終的に有効になるかが変わります。
- 同じ設定項目を複数 GPO で設定している場合、リンク順序の数字が小さい（上にある）GPO が高優先度です。
- 上位 OU からの継承と競合する場合は、必要に応じて「強制 (Enforced)」を有効にすることも検討します。
フォルダー作成のような GPP（グループ ポリシーの基本設定）であれば競合は少ないですが、ログオンスクリプトやレジストリ設定などでは影響が出やすいので、依存関係を整理しておきましょう。
Entra Domain Services 固有の注意点
オンプレミス AD DS と比べると、Entra Domain Services にはいくつか独特の制約があります。GPO 設定を行う前に、次のポイントを押さえておくとトラブルを減らせます。
OU 構成と管理権限の制限
- Entra DS のドメイン コントローラーは マネージドな DC であり、Domain Admins のようなフル権限は付与されません。
- 代わりに AAD DC Administrators グループのメンバーとして、GPO 作成や一部の管理タスクを行います。
- 既定の OU（AADDC Users / AADDC Computers など）は特殊な扱いなので、削除や大胆な変更は避けるのが無難です。
グループの同期と種類
- Entra ID 側で作成したグループが Entra DS に反映されるまで、少しタイムラグが発生する場合があります。
- GPO のセキュリティ フィルターで使えるのは、基本的に セキュリティ グループです。
- メール配布目的の Microsoft 365 グループや、条件ベースの動的グループは対象外なので注意してください。
GPO 管理用サーバーのベスト プラクティス
- GPMC を使うために、Entra DS ドメインに参加した管理用 VMを 1 台用意しておくと運用が楽になります。
- この VM に RSAT（リモート サーバー管理ツール）を入れ、GPO 管理や gpresult の取得などをまとめて行う構成がよく使われます。
チェックリスト：カスタム GPO が効かないときに確認する項目
ここからは、「カスタム GPO が効かない」と感じたときに、順番にチェックすると原因にたどり着きやすいポイントを表にまとめます。
| チェック項目 | 確認ポイント | よくある NG パターン | 修正アクション |
|---|---|---|---|
| 1. 読み取り権限 | 委任タブで Authenticated Users / Domain Computers に「読み取り」が付いているか | Authenticated Users を削除し、PC が GPO を読めなくなっている | 委任タブから Authenticated Users を追加し、読み取りのみ許可 |
| 2. セキュリティ フィルター | 適用対象グループのみが残っているか | Everyone や不必要なグループが残っていて、意図しないユーザーに適用される | 対象セキュリティ グループだけを残す |
| 3. グループ種別 | セキュリティ グループかどうか | Microsoft 365 グループ / 動的グループを指定している | 対象ユーザーを含むセキュリティ グループを新規作成し、そちらを指定 |
| 4. グループ同期 | Entra DS 側にグループとメンバーが反映されているか | 作成直後でまだ同期されていない | しばらく待ってから gpupdate /force で再取得 |
| 5. ユーザー/コンピューターの配置 | 対象アカウントが GPO をリンクした OU に存在するか | 別 OU に移動しており、GPO のスコープ外 | OU 構成を見直すか、リンク先 OU を変更 |
| 6. ユーザー設定かコンピューター設定か | 設定されているポリシーの種類と検証方法が合っているか | ユーザー設定なのに PC 再起動のみで検証している | ユーザー設定の場合は対象ユーザーでログオンし直して確認 |
| 7. GPO の状態 | GPO 自体が有効になっているか（ユーザー構成/コンピューター構成） | 意図せず「ユーザー構成を無効」などにしている | GPO のプロパティで有効化状態を確認 |
| 8. リンクの状態 | GPO のリンクが「無効」になっていないか | 試験中にリンクを無効にしたまま忘れている | OU のリンク一覧で「リンクの有効化」を確認 |
| 9. WMI フィルター | WMI フィルターの条件を満たしているか | 古い OS バージョンを条件にしており、新しい OS には適用されない | WMI フィルターの内容を見直すか、一度外して挙動を確認 |
権限設定の具体例：こうしておけば安心なパターン
Entra Domain Services で「特定グループだけに GPO を適用したい」場合、次のような権限構成にしておくとトラブルが少なくなります。
ユーザー設定 GPO（特定ユーザーだけに適用）の例
| 対象 | 委任タブでの権限 | セキュリティ フィルター | 説明 |
|---|---|---|---|
| Authenticated Users | 読み取りのみ | 指定しない | PC が GPO を読めるようにするためだけのエントリ。「適用」は不要 |
| G-対象ユーザー（セキュリティ グループ） | 読み取り + グループ ポリシーの適用 | G-対象ユーザーを追加 | このグループに含まれるユーザーだけが GPO を適用 |
コンピューター設定 GPO（特定 PC だけに適用）の例
| 対象 | 委任タブでの権限 | セキュリティ フィルター | 説明 |
|---|---|---|---|
| Domain Computers | 読み取りのみ | 指定しない | すべてのコンピューターが GPO を少なくとも読めるようにする |
| G-対象PC（コンピューター アカウントをメンバーにしたセキュリティ グループ） | 読み取り + グループ ポリシーの適用 | G-対象PC を追加 | このグループに含まれる PC だけにコンピューター設定を適用 |
このように、「読ませるグループ」と「実際に適用するグループ」を分けるのがコツです。
トラブルシューティングで必須のコマンド
GPO 周りのトラブルは、コマンドで状況を「見える化」すると原因が一気に絞り込めます。
gpupdate /force – 即時ポリシー更新
gpupdate /force
- 通常の更新間隔を待たずに、GPO を即時再取得します。
- ユーザー設定に関わる場合は、実行後にサインアウト／サインインするのが確実です。
gpresult /r – どの GPO が適用されたかを確認
gpresult /r
- 現在ログオン中のユーザーとコンピューターそれぞれに対して、適用済み GPO の一覧を確認できます。
- 「適用されているはずの GPO 名が載っているか」を確認するだけでも、原因切り分けがかなり進みます。
GUI でじっくり見たい場合は、rsop.msc も有用です。
rsop.msc
- 結果セット（RSoP）として、実際に適用された設定値をツリー表示で確認できます。
- どの GPO が最終的な値を上書きしているかを確認したいときに便利です。
ケーススタディ：C:\Test2 フォルダーが作成されなかった理由
最後に、冒頭の具体例「C:\Test2 フォルダーだけが作成されない」ケースを、実際の挙動に沿って振り返ってみます。
問題発生時の状態
- AADDC Users GPO
・セキュリティ フィルター：Authenticated Users
・委任：Authenticated Users に 読み取り + 適用
→ すべてのユーザーにC:\Test1が作成される。 - Test Users GPO
・セキュリティ フィルター：G-対象ユーザー のみ（Authenticated Users を削除）
・委任：G-対象ユーザーに 読み取り + 適用
→ コンピューター アカウントはこの GPO を読む権限がなく、GPO 自体を認識できない。
このため、gpresult /r で確認しても、ユーザー側の適用された GPO 一覧に Test Users GPO は表示されません。
修正後の状態
- Test Users GPO の委任タブに Authenticated Users（読み取りのみ） を追加。
- セキュリティ フィルターには G-対象ユーザー のみを残す。
gpupdate /force実行後、対象ユーザーでサインインし直す。
この状態で再度 gpresult /r を確認すると、
- ユーザーの適用済み GPO に Test Users GPO が表示される。
- 対象ユーザーのプロファイルで
C:\Test2フォルダーが作成されている。
つまり、今回のトラブルの本質は、「グループで対象を絞りたい」という意図は正しいが、その設定場所をセキュリティ フィルターだけに寄せすぎた結果、読み取り権限ごと削ってしまったことにあります。
まとめ：対象を絞るのはセキュリティ フィルター、読ませるのは Authenticated Users
Entra Domain Services 環境でカスタム GPO を使う場合、次の 2 点をセットで覚えておくと、多くのトラブルを避けられます。
- 対象を絞るのは「セキュリティ フィルター」
→ 適用したいユーザーや PC を含む セキュリティ グループ だけを指定する。 - PC に GPO を読ませるのは「Authenticated Users / Domain Computers の読み取り権限（委任）」
→ 委任タブから読み取りのみを許可しておき、「Apply」は付けない。
この設計パターンをベースにしておくと、クラウド専用の Entra Domain Services 環境でも、オンプレ AD DS と同様に柔軟で安全なグループ ポリシー運用が可能になります。カスタム GPO がうまく動かないときは、まずは 「読み取り権限」と「セキュリティ フィルター」の 2 箇所を真っ先に疑ってみてください。
コメント