Azure Data Factory（ADF）のカスタムアクティビティから Microsoft Entra ID（旧Azure AD）のユーザー／グループを更新しようとして、400（Request_BadRequest）や 401（Unauthorized）で止まるケースがあります。原因は「オンプレミス同期オブジェクトはクラウド側で直接更新できない属性がある」という仕様です。本記事ではエラーの意味、所有者（group owner）の制約、そしてADF側で現実的に運用するための実装パターンを整理します。
まず押さえるべき結論
- オンプレミス Active Directory（AD）から Microsoft Entra Connect（旧Azure AD Connect）で同期されたユーザー／グループは、Entra ID（クラウド）側が“更新元（source of authority）”ではありません。
- そのため、Graph API で更新できない属性があり、該当属性を更新しようとすると
Unable to update the specified properties for on-premises mastered Directory Sync objects...が返ります。 - 401 Unauthorized は別問題で、トークン取得・権限（Graph のアプリ権限 / 管理者同意 / ロール割り当て）が不足している可能性が高いです。
- 現場で壊れにくい運用は、（1）同期オブジェクトはオンプレADで更新→同期、（2）クラウド専用（cloud-only）だけ Graph で更新、という切り分けです。
発生しやすいエラー例と、何が起きているか
ADF のカスタムアクティビティ（.NET/PowerShell/任意コード）から Microsoft Graph を呼び出し、ユーザーやグループの属性更新を行う実装はよくあります。しかし、対象がオンプレ同期（DirSync）の場合、次のようなエラーが混在してログに出ることがあります。
Code: Request_BadRequest
Message: Unable to update the specified properties for on-premises mastered Directory Sync objects or objects currently undergoing migration.
Response status code does not indicate success: 401 (Unauthorized).| エラー | 意味（ざっくり） | 優先して疑うポイント |
|---|---|---|
Request_BadRequest（Unable to update…） | 更新対象の属性が、オンプレミスがマスターのためクラウドから更新できない（または移行中のため更新不可） | 対象ユーザー／グループが DirSync か（onPremisesSyncEnabled や onPremisesSecurityIdentifier の有無） |
401 Unauthorized | Graph を呼ぶための認証・権限が足りない、またはトークン取得の実装が誤っている | 使用ID（サービスプリンシパル / マネージドID）の Graph 権限、管理者同意、トークンのスコープ（.default） |
「on-premises mastered / Directory Sync オブジェクト」とは
Microsoft Entra Connect でオンプレADから同期されるユーザー／グループは、Entra ID 上では「ディレクトリ同期（DirSync）オブジェクト」として扱われます。ポイントは、クラウド側のオブジェクトは“写し”であり、更新元はオンプレADだということです。
Microsoft Graph でも、オンプレ同期ユーザー（onPremisesSyncEnabled が true）に対しては、属性によって更新可否が分かれます。たとえばユーザーの電話番号（businessPhones, mobilePhone）は「オンプレ同期ユーザーでは読み取り専用」として明記されています。
この制約は「次回の同期で上書きされるから」という設計意図に基づくもので、Graph から更新しようとすると 400 でブロックされ、前述のエラーメッセージが返ります。実際に Microsoft 側からも、オンプレ同期有効ユーザーの特定属性更新を禁止する変更と、その理由が説明されています。
“同期されているか”の判定に使える代表的なプロパティ
ADF 側の処理を安定させるには、更新前に「対象がクラウド専用か／オンプレ同期か」を機械的に判定し、分岐させるのが効果的です。
| 対象 | 判定に使える例 | 見え方の目安 | 備考 |
|---|---|---|---|
| ユーザー | onPremisesSyncEnabled | true：現在オンプレADから同期中 false：以前は同期していたが、現在は同期していない null：一度も同期されていない（クラウド専用の可能性が高い） | 読み取り専用。フィルター条件にも利用可能。 |
| グループ | onPremisesSecurityIdentifier, onPremisesSamAccountName | これらが入っていればオンプレ同期グループの可能性が高い | グループリソースで「オンプレSID」等が定義されています（読み取り専用）。 |
PowerShell/Graph SDK で大量ユーザーを棚卸しする場合は、OnPremisesSyncEnabled eq true のフィルターが紹介されています。ADF での分岐条件設計にもそのまま応用できます。
クラウドから更新できる属性／できない属性の線引き
「同期ユーザーは一切更新できない」と誤解されがちですが、実務的には次の3分類で考えると整理しやすいです。
| 分類 | 例 | ADF/Graph での扱い | 推奨の更新元 |
|---|---|---|---|
| オンプレがマスター （同期で上書きされる） | 氏名、部署、役職、連絡先など（ディレクトリ同期対象の属性） ユーザー電話番号（mobilePhone / businessPhones） （多くのケースで）グループの所有者・メンバーなど | 更新しようとすると 400（Unable to update…）になりやすい | オンプレADで更新 → 次回同期で反映 |
| クラウド専用属性 （オンプレ同期でもクラウドで持つ） | UsageLocation（ライセンス割り当てに必要な国/地域） クラウド側ライセンス、グループベースライセンスの設計 | 同期ユーザーでも更新できる場合がある（属性次第） | Entra 管理センター / Graph |
| ハイブリッド要件が絡む領域 | Exchange 関連（mail-enabled グループ等） 一部の拡張属性（onPremisesExtensionAttributes など） | Graph では読み取り専用になるケースがある | Exchange 管理（EAC / Exchange Online PowerShell）やオンプレ側の運用に寄せる |
Microsoft Q&A の事例でも、ADF から同期ユーザーを更新しようとした際に同じエラーが発生し、「オンプレADで更新して、Entra Connect の同期で反映させる」のが正攻法と整理されています。また、同期ユーザーでも Usage Location のような Entra 側属性は管理センターから更新できる、という線引きも示されています。
「オンプレ AD セキュリティグループの所有者（group owner）が同期されない」問題
質問文にある you cannot sync on-premises group owners of AD security groups to Azure AD は、かなり本質的なヒントです。オンプレADのセキュリティグループで設定する「Managed by（管理者）」を、Entra ID 側の“Owners（所有者）”として同期させたい、というニーズは多いのですが、少なくとも標準の同期では「グループ所有者は同期されない」と整理されています。
GitHub 上の公式ドキュメント連携の issue でも、Microsoft 側の回答として「Group Owner は同期されない」こと、そして「セキュリティグループは同期できるが、オンプレで“owner”に指定したユーザーがクラウド側でそのグループのメンバー管理をできるわけではない」点が述べられています。
例外的に“それっぽく見える”ケース（mail-enabled グループ / Exchange ハイブリッド）
一方で、Exchange ハイブリッドなどの要件が入ると、属性同期の対象が増えることがあります。Microsoft Learn の「同期される属性一覧」には、Exchange Online のセクションで managedBy が含まれており、mail-enabled グループ等では取り扱いが異なる可能性があります。
ただし、ここで重要なのは「同期される属性がある＝Entra の Owners を Graph で自由に更新できる」ではない、という点です。オンプレ同期グループの所有者管理をクラウド側で完結させたいなら、設計そのものを切り替えるのが安全です。
所有者（owner）を運用したいときの現実的な選択肢
| 選択肢 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| クラウド専用のセキュリティグループを新設 | M365 / Azure / SaaS 連携など、クラウド側でアクセス制御を完結させたい | Owners / Members を Entra / Graph で一貫して管理できる | 既存のオンプレ権限設計と二重管理にならないよう整理が必要 |
| オンプレADのグループをそのまま“参照専用”として扱う | オンプレ資産が多く、グループがオンプレ権限の中核になっている | 権限の“一元性”を保てる（オンプレが単一の正） | Owners のようなクラウドUXは割り切りが必要 |
| （要件が合えば）mail-enabled グループ＋Exchange ハイブリッドの設計で寄せる | Exchange を含むハイブリッド運用が必須 | 同期属性の幅が広がる可能性 | 運用が重くなりがち。Owners 目的だけで導入するとコスト高 |
ADF で失敗させないための実装パターン
ADF は“オーケストレーター”です。Entra ID を直接更新するのは可能ですが、ハイブリッド環境では「更新先が本当にクラウドなのか」を見誤ると、パイプラインが断続的に失敗し続けます。おすすめは次の分岐設計です。
パターン1：更新前にオブジェクト種別を判定して分岐
- Graph で対象のユーザー／グループを取得（必要プロパティだけ
$select） - 同期判定（ユーザー：
onPremisesSyncEnabled、グループ：onPremisesSecurityIdentifier等） - オンプレ同期なら Graph 更新をスキップし、オンプレ更新ルートへ回す
- クラウド専用なら Graph で更新（成功/失敗をログ化）
Graph の例（ユーザーの判定用、概念例）：
GET https://graph.microsoft.com/v1.0/users/{id}?$select=id,displayName,userPrincipalName,onPremisesSyncEnabled,usageLocationここで onPremisesSyncEnabled が true なら、氏名・部署・電話番号など“オンプレがマスターになりやすい領域”を ADF から更新しないようにします。
パターン2：オンプレ更新を“別ジョブ”に分離する
オンプレAD更新が必要な場合、ADF から直接ドメインコントローラーに接続して書き換えるより、次のように責務分離した方が運用が安定します。
| 役割 | 実施内容 | 実装の例 |
|---|---|---|
| ADF | 更新リクエストの作成・承認・キューイング | SQL/Storage/Queue に「誰の何をどう変えるか」を書き込む |
| オンプレ側ジョブ | AD で属性更新 → Entra Connect 同期（必要なら手動トリガー） | ドメイン参加サーバー上の PowerShell、またはハイブリッド実行環境（組織ポリシーに準拠） |
| Entra 側 | 同期結果の反映 | 通常はスケジュール同期。急ぎなら運用手順に“手動同期”を用意 |
「ADF で更新したい」という要求の背景が“人手を減らしたい”であれば、更新経路をクラウドに寄せるのではなく、更新経路を自動化するのが本筋です。オンプレがマスターである以上、更新先を誤ると必ずどこかで破綻します。
401 Unauthorized の切り分け（Graph 権限・同意・認証）
Unable to update... が「仕様による 400」だとすると、401 Unauthorized は「認証・認可の不備」です。両方が同時に出る場合、アプリが複数の Graph 呼び出しを行っており、“更新不可の呼び出し”は 400、“そもそも権限がない呼び出し”は 401になっている可能性があります。
まず整理：Graph の権限には「委任」と「アプリ」がある
Microsoft Graph の権限は大きく Delegated（委任） と Application（アプリ） に分かれます。ADF のようなバックエンド処理は、通常はサインインユーザーを伴わないため、アプリ権限（app-only）で設計するのが一般的です。
更新系でよく使う Graph 権限の目安
必要な権限は“何を更新するか”で変わります。Microsoft Learn の Update user では、更新 API の最小権限や、特定シナリオで必要になる権限が整理されています。
| やりたいこと | Graph 側で意識する権限（例） | 補足 |
|---|---|---|
| ユーザー属性の更新（一般） | User.ReadWrite.All / Directory.ReadWrite.All など | 更新する属性により最小権限は変動 |
| ユーザー電話番号の更新 | User-Phone.ReadWrite.All など | ただしオンプレ同期ユーザーではプロパティ自体が読み取り専用になり得る |
| グループの更新（メンバー/所有者） | Group.ReadWrite.All など | オンプレ同期グループの所有者運用には制約がある点に注意 |
マネージドIDを使う場合にハマる点（Azure RBAC と Graph 権限は別物）
Azure リソース（ADF など）のマネージドIDに Azure RBAC（ロール割り当て）を付けても、それだけでは Microsoft Graph を操作できません。Graph を呼ぶには、Entra 側でそのサービスプリンシパルに対して Graph のアプリケーション権限（アプリロール）を割り当て、必要に応じて管理者同意を行う必要があります。
Microsoft Learn には、Azure CLI や PowerShell を使って「マネージドIDにアプリロールを割り当てる」手順が公開されています。GUI だけで完結しない場面があるため、手順をドキュメント化しておくと事故が減ります。
401 のチェックリスト（ADF カスタムアクティビティ目線）
- トークンの取得先が正しいか（v2 エンドポイントで
scope=https://graph.microsoft.com/.defaultを使っているか） - アクセストークンが “Microsoft Graph” 宛てになっているか（別リソースのトークンを使っていないか）
- サービスプリンシパル / マネージドID に、必要な Graph アプリ権限が割り当て済みか
- 管理者同意（Admin consent）が完了しているか
- 更新対象の API が「アプリ権限だけでは不可」の条件に該当していないか（API ドキュメントの注記）
よくある“見落とし”と回避策
「同期を止めたのに更新できない」ユーザーが混じる
同期無効化の前から存在していたユーザーなど、状態によりクラウド側での更新が制限されるケースが報告されています。「同期を止めた＝全部クラウド管理できる」とは限らないため、対象ユーザーごとに onPremisesSyncEnabled の状態を取得して分岐するのが安全です。
“cloud-only”でも Exchange 由来属性が Graph では読取専用になることがある
ユーザーリソースには、onPremisesExtensionAttributes のように「オンプレ同期ユーザーではオンプレがソース」「クラウド専用でも、過去に同期していた場合は Graph では読み取り専用で、Exchange 管理で扱う」といった注意書きが存在します。属性によって管理プレーンが変わるため、“どの属性を更新したいのか”を先に分解しておくとトラブルが減ります。
「所有者を更新したい」が、実は“メンバー管理の委任”が目的だった
Owners を同期・更新したい背景が「現場担当者にメンバー管理を委任したい」であれば、Owners にこだわるより、クラウド専用グループで委任する、または アクセスパッケージ等のIDガバナンス機能で申請・承認フローを組む方が運用が安定する場合があります（組織のライセンスや方針によります）。
実務で使える対応ステップ（手順テンプレ）
- 更新対象のプロパティを棚卸し（氏名、部署、電話、UsageLocation、グループOwnersなど）
- 対象がオンプレ同期か判定（ユーザー：
onPremisesSyncEnabled、グループ：onPremisesSecurityIdentifier等） - オンプレ同期＋オンプレマスター属性なら、ADF から Graph 更新をしない（オンプレ更新ルートへ）
- クラウド専用なら、ADF から Graph 更新（必要権限・同意を満たす）
- 401 が出る場合は、権限（Graph アプリ権限 / app role）とトークン取得（スコープ、テナント）を優先チェック
- 運用設計として、失敗時に「リトライすべき失敗」と「仕様で必ず失敗する更新」を分け、ログと通知を整備する
まとめ
ADF から Entra ID を更新できない最大の理由は、対象がオンプレ同期（DirSync）で、クラウド側から更新できない属性に触れていることです。これはバグではなく仕様であり、正攻法は「オンプレADで更新→同期」です。加えて、オンプレ AD セキュリティグループの所有者は同期されないという制約もあるため、Owners をクラウドで運用したい場合はクラウド専用グループへ設計を寄せるのが現実的です。
一方、401 Unauthorized は権限・認証の問題なので、Graph の権限設計（委任/アプリ）と、マネージドIDへのアプリロール割り当てを含めて見直すことで改善できます。ハイブリッド環境では「更新元はどこか」を軸に、ADF を“更新の実行者”ではなく“更新フローの統括者”として設計するのが、長期的に一番壊れにくいアプローチです。
コメント