MENU

EntraプロビジョニングでADグループ変更を一元管理する方法【プレビュー対応】

Active Directory

Active DirectoryグループをMicrosoft Entra IDからプロビジョニングしていても、オンプレミス側の管理者や自動化スクリプトが直接メンバーを変更すると、Entra IDとAD DSの状態に差が生じます。同期処理で後から修正できる場合でも、一時的な権限の不整合や意図しない構成ドリフトは避けられません。

この問題を防ぐのが、Microsoft Entra Cloud Syncのプレビュー機能「AD group enforcement」です。対象グループにmsDS-ObjectSoa=Cloudを設定し、すべての書き込み可能なドメインコントローラーで強制機能を有効にすると、Microsoft Entraプロビジョニングサービス以外からの変更を監査またはブロックできます。(Microsoft Learn)

ただし、これは任意のADグループを単純に編集禁止にする機能ではありません。Microsoft Entra IDを管理元としてCloud SyncでADへプロビジョニングするセキュリティグループが対象です。また、プレビュー時点では削除操作を防げないなどの制限もあるため、まずAuditモードで既存の変更経路を洗い出し、その後にEnforcedモードへ移行するのが安全です。

目次

ADグループ変更をEntraプロビジョニングに限定する機能がプレビュー

従来のグループプロビジョニングでは、Microsoft Entra IDのグループ情報をAD DSへ反映できても、AD側での直接変更そのものは止められませんでした。

例えば、次のような状態です。

  1. Microsoft Entra IDでグループメンバーを管理する
  2. Cloud SyncがAD DSへメンバー情報を反映する
  3. AD管理者がActive Directoryユーザーとコンピューターからメンバーを追加する
  4. Entra IDには存在しないメンバーがAD側だけに残る
  5. 次回同期や手動確認まで不整合が続く

AD group enforcementを有効にすると、対象グループへのLDAP書き込みをドメインコントローラーが処理する時点で、変更元のSIDが許可されているかを確認します。許可されていない変更は、Enforcedモードでは書き込み前に拒否されるため、不整合が発生してから修復するのではなく、構成ドリフトそのものを防げます。(Aka.ms)

項目従来のグループプロビジョニングAD group enforcement有効時
Entra IDからADへの反映可能可能
AD側からの直接変更変更できる監査またはブロック
不整合への対応発生後に同期・調査LDAP書き込み時に防止
対象範囲プロビジョニング対象さらにmsDS-ObjectSoaが設定されたグループ
既存のAD権限通常どおり評価通常の権限に追加制限を適用

この機能は既存のADアクセス制御を置き換えるものではありません。ADのアクセス許可で変更できない利用者に、新しい変更権限を与えることもありません。従来のRBACやACLによる判定に加えて、クラウド管理ポリシーによる制限を追加する仕組みです。(Aka.ms)

Microsoft Entra ConnectのGroup Writebackとは別の機能

AD group enforcementが前提とするのは、Microsoft Entra Cloud Syncによる「Microsoft Entra IDからADへのグループプロビジョニング」です。

Microsoft Entra Connect SyncのGroup Writeback v2は非推奨となり、サポートされていません。クラウドセキュリティグループをADへプロビジョニングする場合は、Cloud Syncの利用が案内されています。(Microsoft Learn)

なお、ユーザー同期をMicrosoft Entra Connect Syncで継続しながら、セキュリティグループのADへのプロビジョニングだけをCloud Syncで実行する併用構成も可能です。既存環境をすべてCloud Syncへ移行しなくても、グループ管理部分から段階的に導入できます。(Microsoft Learn)

AD group enforcementが変更を制御する仕組み

AD group enforcementは、次の3要素で構成されます。

構成要素役割
ドメインコントローラー上の強制エンジンLDAP書き込み時に変更元を確認する
ドメイン単位のSOAポリシー許可するSIDとAudit／Enforcedモードを保持する
グループごとのmsDS-ObjectSoa属性どのグループを強制対象にするかを示す

ドメイン単位のポリシーは、次の場所に作成されます。

CN=SOA-Policies,CN=System,DC=<ドメイン名>

その配下にCloudポリシーオブジェクトが作成され、Microsoft Entra Cloud Syncプロビジョニングエージェントのグループ管理サービスアカウント、いわゆるgMSAのSIDが許可リストへ登録されます。

一方、個々のグループには次の属性を設定します。

msDS-ObjectSoa = Cloud

ドメインポリシーを有効にしただけでは、すべてのADグループが自動的に保護されるわけではありません。msDS-ObjectSoaが設定されていないグループは、従来どおりAD側から変更できます。(Aka.ms)

AuditモードとEnforcedモードの違い

モード許可されていない変更主な用途
Audit変更を許可し、イベントログへ記録既存スクリプトや手動運用の調査
EnforcedLDAP書き込みを拒否Entraプロビジョニングへの変更経路統一

Auditモードでは、従来のADアクセス許可で認められている変更はそのまま実行されます。ただし、AD group enforcementのポリシー上では許可されていない変更として、Directory Serviceログへ記録できます。

Enforcedモードでは、Active Directoryユーザーとコンピューター、PowerShell、LDAPクライアントなど、利用する管理ツールにかかわらず、許可されていないLDAP変更が拒否されます。変更はADにコミットされないため、後から同期で修復する必要もありません。(Aka.ms)

導入前に確認する前提条件

AD group enforcementは、通常のCloud Syncグループプロビジョニングよりも、ドメインコントローラー側の要件が厳しくなっています。

項目主な要件
ライセンスMicrosoft Entra ID P1
Entra側の管理ロールHybrid Identity Administrator以上
AD側の管理権限ポリシー設定時にDomain Admin
書き込み可能なDCすべてWindows Server 2022またはWindows Server 2025
プロビジョニングエージェントのサーバードメイン参加済みWindows Server 2019または2022
ADスキーマWindows Server 2016以降のスキーマ
ドメイン／フォレスト機能レベル引き上げ不要
スキーマ拡張不要

msDS-ObjectSoaは既存のADスキーマ属性であるため、このプレビューのために独自のスキーマ拡張を追加する必要はありません。(Aka.ms)

書き込み可能なDCを1台も残さず対応する

最も重要な条件は、対象ドメインに存在するすべての書き込み可能なドメインコントローラーを更新し、強制機能を有効にすることです。

未対応の書き込み可能なDCが1台でも残っていると、そのDCへ送られた変更は通常どおり処理されます。つまり、Enforcedモードを設定していても、接続先DCによっては変更を回避できてしまいます。(Aka.ms)

最初に次のコマンドで対象DCを一覧化します。

Get-ADDomainController -Filter * |
    Where-Object { -not $_.IsReadOnly }

プレビュー公開時点で示されているntdsai.dllの最低バージョンは次のとおりです。

OS最低ファイルバージョン
Windows Server 202210.0.20348.5257
Windows Server 202510.0.26100.32995

各DCでは次のコマンドで確認できます。

(Get-Item C:\Windows\System32\ntdsai.dll).VersionInfo.FileVersion

最低バージョンだけを狙って個別更新するのではなく、原則として最新の累積更新プログラムを適用し、Microsoftが提供するOS別のプレビュー有効化用Group Policyパッケージを展開します。適用後はドメインコントローラーの再起動が必要です。(Aka.ms)

特定のActive Directoryグループを対象にする設定手順

安全な導入順序は、次のとおりです。

  1. Cloud Syncのグループプロビジョニングを確認する
  2. すべての書き込み可能なDCを更新する
  3. SOAポリシーをAuditモードで作成する
  4. 対象グループへmsDS-ObjectSoa=Cloudを設定する
  5. 既存の変更経路を監査する
  6. 問題がなければEnforcedモードへ切り替える

Cloud Syncのグループプロビジョニングを確認する

Microsoft Entra管理センターで、次の順に開きます。

Entra ID
  └ Entra Connect
      └ Cloud sync

新しく構成する場合は、「New configuration」から「Microsoft Entra ID to AD sync」を選択し、対象ドメインや属性マッピング、スコープを設定します。構成には少なくともHybrid Identity Administratorロールが必要です。(Microsoft Learn)

対象グループのスコープには、次の2種類があります。

  • All security groups
  • Selected security groups

特定のADグループだけを一元管理したい場合は、Selected security groupsを選ぶのが基本です。Microsoftも、グループプロビジョニングの標準的なスコープとしてSelected security groupsを推奨しています。意図しないグループまで対象にする事故を避けやすく、初期同期の負荷も抑えられます。(Microsoft Learn)

すべての書き込み可能なDCで機能を有効にする

各DCで次の作業を実施します。

  1. 最新の累積更新プログラムを適用する
  2. OSに対応したGroup Policyパッケージを準備する
  3. グループポリシーでプレビュー機能を有効にする
  4. DCを再起動する
  5. ntdsai.dllのバージョンを確認する
  6. ポリシーが全DCへ適用されたことを確認する

PDCエミュレーターが更新され、機能が有効になると、通常はCN=System配下にSOA-Policiesコンテナーが作成されます。ADレプリケーションには時間がかかる場合があるため、ポリシー作成へ進む前に各DCへの複製を確認します。(Aka.ms)

SOAポリシーをAuditモードで作成する

Microsoftが公開しているSet-CloudSyncSOAPolicy.ps1を使用します。

このスクリプトは、ローカルにインストールされているCloud SyncプロビジョニングエージェントからgMSAを読み取ります。そのため、プロビジョニングエージェントがインストールされているサーバー上で実行してください。(Aka.ms)

管理者としてPowerShellを起動し、最初はAuditモードで実行します。

.\Set-CloudSyncSOAPolicy.ps1 `
  -EnforcementMode Audit `
  -Credential (
    Get-Credential -Message "DOMAIN\Username形式でDomain Admin資格情報を入力"
  )

スクリプトを実行すると、SOA-Policies配下にCloudポリシーが作成され、プロビジョニングエージェントのgMSA SIDが許可リストへ追加されます。

対象グループにmsDS-ObjectSoaを設定する

Cloud Syncのグループプロビジョニング構成で、属性マッピングを編集します。

追加するターゲット属性は次のとおりです。

Target attribute: msDS-ObjectSoa
Value: Cloud

設定方法は2通りあります。

設定方法動作向いている構成
Constant mappingスコープ内の全グループへCloudを設定保護対象だけをSelected security groupsで選ぶ構成
Expression mapping条件に一致したグループだけへ設定1つのジョブに保護対象と非対象が混在する構成

初期導入では、次の組み合わせが分かりやすく安全です。

スコープ：Selected security groups
属性マッピング：msDS-ObjectSoa = Cloudの定数

つまり、保護したいグループだけをプロビジョニングスコープへ登録し、スコープ内のグループには一律でmsDS-ObjectSoa=Cloudを付けます。

既存の大規模ジョブに条件式を追加する方法もありますが、条件式の誤りで対象外グループまで強制対象になる可能性があります。プレビュー期間中は、保護対象専用の明確なスコープを作るほうが運用しやすいでしょう。公式ドキュメントでも、定数マッピングは多くの利用者に推奨される方式とされています。(Aka.ms)

設定後、対象グループをプロビジョニングスコープへ割り当て、オンデマンドプロビジョニングまたは同期サイクルを実行します。

AD側で属性を確認する

ADSI Editなどで対象グループのプロパティを開き、次の値が設定されていることを確認します。

msDS-ObjectSoa: Cloud

属性が空の場合、ドメインポリシーが正しくても、そのグループは保護されません。Cloud Syncの属性マッピング、グループのスコープ、プロビジョニングログを確認してください。(Aka.ms)

Auditモードで無許可変更を調査する

Auditモードでは、AD側からの変更は許可されますが、Entraプロビジョニングサービス以外からの変更をイベントログに記録できます。

個別の監査イベントを表示するには、公式手順に従ってSecurity Diagnosticsの値を1に設定し、イベントビューアーのDirectory Serviceログを確認します。デフォルト値の0では、ポリシー読み込みに関するイベントは記録されても、個別のブロック対象操作や監査対象操作は記録されません。(Aka.ms)

Audit期間中は、次の変更元がないかを確認します。

  • Active Directoryユーザーとコンピューターからの手動変更
  • 定期実行されるPowerShellスクリプト
  • 人事・申請・アカウント管理システム
  • オンプレミスアプリケーションのサービスアカウント
  • 夜間バッチや月次処理
  • 障害対応手順に含まれる緊急変更

実務上は、通常の平日運用だけでなく、週次・月次バッチが一巡する期間までAuditモードを継続するのが安全です。

Enforcedモードへ切り替える

Auditログで必要な変更経路を確認し、Microsoft Entra ID側へ管理を移行した後、ポリシーをEnforcedモードへ変更します。

.\Set-CloudSyncSOAPolicy.ps1 `
  -EnforcementMode Enforced `
  -Credential (
    Get-Credential -Message "DOMAIN\Username形式でDomain Admin資格情報を入力"
  )

切り替え後は、権限を持つAD管理者であっても、ポリシーの許可リストにSIDが登録されていなければ、対象グループの変更を拒否されます。(Aka.ms)

Enforcedモードでブロックされる操作

プレビュー時点では、すべてのグループ操作が保護されるわけではありません。

操作Enforcedモードの動作
グループメンバーの追加・削除無許可の変更をブロック
グループ属性の変更無許可の変更をブロック
グループ名の変更無許可の変更をブロック
OU間の移動無許可の変更をブロック
ごみ箱からの復元無許可の変更をブロック
新しいグループの作成許可
グループの削除プレビューでは許可
保護対象グループを非保護グループへネスト許可
未対応DCに送られた変更通常どおり処理

AD group enforcementは、LDAPのModify操作とModify DN操作、ごみ箱からの復元を制御します。一方、LDAP Addによる新規作成と、削除操作はプレビュー時点で許可されています。(Aka.ms)

削除操作は別の方法で保護する

「Enforced」という名称から完全な変更禁止を想像しやすいものの、プレビュー版では対象グループ自体の削除を防げません。

そのため、重要グループでは次の対策を併用します。

  • ADの既存ACLで削除権限を最小化する
  • 削除操作を監査する
  • ADバックアップと復旧手順を確認する
  • グループ削除時のアラートを用意する
  • 復旧後にCloud Syncが正しく再プロビジョニングできるか検証する

AD group enforcementだけを「グループの完全な改ざん防止機能」として扱わないことが重要です。

グループのネストによる実効権限変更にも注意する

保護対象のグループAを、保護されていないグループBのメンバーとして追加する操作は制限されません。

これは、グループA自体ではなく、グループBのmember属性を変更しているためです。グループAのメンバー構成は保護されていても、グループAを別の権限グループへ組み込むことで、実効的なアクセス権が変わる可能性があります。(Aka.ms)

重要なアクセス制御では、単一グループだけでなく、次の範囲を確認してください。

  • 対象グループの親グループ
  • 対象グループをメンバーとして含むグループ
  • ファイルサーバーやアプリケーションに直接割り当てられたグループ
  • グループのネストを変更できる管理者や自動化処理

緊急変更用のbreak-glassアカウントを設計する

クラウド障害やプロビジョニング障害が発生した場合に備え、オンプレミスから変更できる緊急用IDのSIDを許可リストへ追加できます。

設定場所は、CloudポリシーオブジェクトのmsDS-Settings属性です。

CN=Cloud
  └ CN=SOA-Policies
      └ CN=System

ただし、break-glass用SIDを追加しすぎると、Entraプロビジョニングへ変更経路を統一する効果が弱くなります。原則として、プロビジョニングエージェントのgMSAだけを許可し、明確な業務要件がある場合に限って緊急用SIDを追加します。(Aka.ms)

プレビュー時点の許可リストは最大64 SIDです。さらに、無効または削除済みのSIDが1つでも含まれると、ポリシー全体の読み込みに失敗し、すべてのIDが未許可になる可能性があります。(Aka.ms)

break-glassを設定する場合は、次の項目を運用手順に含めてください。

  1. 利用できる担当者を限定する
  2. 通常時は使用しない
  3. 使用時に申請・記録を残す
  4. 使用後にADとEntra IDの差分を確認する
  5. アカウント再作成時はSID変更を確認する
  6. 削除済みアカウントのSIDを許可リストから除去する
  7. 定期的に実際の変更テストを行う

一元管理してもEntra側の変更が即時反映されるとは限らない

AD group enforcementは、AD側の無許可変更を止める機能です。Microsoft Entra IDで行った変更をリアルタイムにADへ反映する機能ではありません。

Cloud Syncのグループプロビジョニングジョブは定期的に実行され、公式ドキュメントでは20分間隔とされています。緊急の変更では、オンデマンドプロビジョニングや同期の再起動を使用できます。(Microsoft Learn)

したがって、Enforcedモードへ移行すると、次のような状況が起こり得ます。

  1. Entra IDでメンバーを追加する
  2. AD側にはまだ反映されていない
  3. 管理者が急いでAD側から追加しようとする
  4. AD group enforcementにより拒否される
  5. 次回Cloud Syncまで利用者がアクセスできない

運用手順には、「緊急時もADを直接変更せず、Entra IDで変更したうえでオンデマンドプロビジョニングを実行する」という流れを明記しておく必要があります。

Cloud Sync側の既存制約も引き続き適用される

AD group enforcementを有効にしても、グループプロビジョニング自体の制約は変わりません。

主な注意点は次のとおりです。

  • 5万メンバーを超えるグループはサポートされない
  • All security groupsを属性スコープフィルターなしで使用する構成はサポートされない
  • ADへメンバー参照を反映できるユーザーには条件がある
  • クラウド専用ユーザーは、そのままAD上のユーザーとして作成されるわけではない
  • ネストされたグループは、必要なメンバーグループも個別にスコープへ追加する必要がある
  • ポータル画面からSelected security groupsとして選択・表示できるグループ数には上限がある

Cloud SyncでADへプロビジョニングされるユーザーメンバーは、オンプレミスと同期され、onPremisesObjectIdentifierが対象ADのobjectGUIDと対応している必要があります。グループは作成されたのに一部メンバーだけがADへ反映されない場合、AD group enforcementではなく、Cloud Syncのメンバー参照条件を確認してください。(Microsoft Learn)

AD group enforcementに向いているグループ

導入しやすいグループ慎重な検討が必要なグループ
Entra IDを正式な管理元にしているAD管理ツールから頻繁に手動変更する
オンプレミスアプリのアクセス制御に使うレガシーシステムがADへ直接書き込む
メンバー変更を申請・承認フローへ集約したい変更元のサービスアカウントを把握できていない
AD側の手動追加によるドリフトが発生している書き込み可能なDCに旧OSが残っている
少数の重要グループから段階導入できる削除まで完全に防ぐ必要がある
クラウド管理のセキュリティグループ5万メンバーを超える大規模グループ

特に効果が高いのは、Microsoft Entra ID側の申請、承認、グループ所有者管理などを正式な変更経路としながら、AD側の管理者が善意で直接修正してしまう環境です。

一方、オンプレミスの業務システムがADグループを直接更新している場合、いきなりEnforcedモードへ移行すると処理が停止します。Auditモードで変更元のアカウント、対象グループ、実行時刻を把握し、Entra ID側の管理経路へ移行できるか判断してください。

変更がブロックされない場合の確認項目

症状確認する内容
AD側の直接変更が成功する接続先DCが更新・有効化済みか
一部の端末からだけ変更できる未対応の書き込み可能なDCが残っていないか
すべての変更が許可されるポリシーがAuditモードではないか
特定グループだけ変更できるmsDS-ObjectSoaが設定されているか
Entraからの変更も拒否されるgMSA SIDがmsDS-Settingsに存在するか
ポリシーが読み込まれない無効・削除済みSIDが含まれていないか
グループは作成されるがメンバーが不足するユーザーのonPremisesObjectIdentifierを確認
ネストしたグループが反映されないメンバーグループもスコープに追加したか

Microsoftが公開しているCheck-CloudSyncSOAPolicy.ps1を各ドメインコントローラーで実行すると、そのDCで強制ポリシーが有効になっているかを確認できます。変更がすり抜ける場合は、ポリシー全体だけでなく、変更を実際に処理したDCを特定して調査することが重要です。(Aka.ms)

まずは少数グループをAuditモードで開始する

AD group enforcementを使うと、Microsoft Entra IDを管理元とするグループについて、変更経路をEntraプロビジョニングサービスへ集約できます。AD側の変更を後から同期で修正するのではなく、ドメインコントローラーがLDAP書き込み時に拒否するため、構成ドリフトを未然に防げる点が大きな利点です。

一方で、プレビュー時点では次の制限があります。

  • すべての書き込み可能なDCへの対応が必要
  • Windows Server 2022または2025のDCが必要
  • グループ削除は防げない
  • 非保護グループへのネストは制限されない
  • ユーザーオブジェクトは対象外
  • Cloud Syncの既存制約がそのまま適用される

最初の作業として、書き込み可能なDCのOSと更新状態を一覧化してください。そのうえで、直接変更されても業務影響が小さいセキュリティグループを数個選び、Selected security groupsとmsDS-ObjectSoa=Cloudの定数マッピングを設定します。

Auditモードで既存の手動変更や自動処理を確認し、変更経路をMicrosoft Entra ID側へ移した後に、対象グループ単位でEnforcedモードへ切り替えるのが安全な導入方法です。

Active Directory
Active Directory Microsoft Entra Cloud Sync AD group enforcement

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次