Dataverse（データを一元管理するプラットフォーム）環境における、セキュリティロール（アクセス権限の設定）の割り当て、ユーザーアクセス、アプリケーションユーザー、事業部門、および管理者権限の委譲に対応します。 次のような場合に使用: ユーザーに対してアクセス権を付与したい、ロール（権限の種類）を与えたい、自分が管理者になりたい、またはサービスプリンシパル（プログラムが動作するための専用アカウント）を追加したいとき。
Security-role assignment, user access, application users, business units, and admin self-elevation in Dataverse environments. Use when the user wants to give someone access, grant a role, become an admin, or add a service principal.
このスキルは公式のCLIを使用します — ロール変更にはPAC CLI、検証にはDataverse CLIを使用します。ロール操作用のPythonスクリプトは作成しないでください。
ロール付与と自己昇格は重大な変更です（セキュリティ設定を変更し、Purview（監査ログ）に記録されます）。実行前に、対象ユーザー・ロール・環境といった内容を平文で説明し、不明な部分はプレースホルダー（<ENV_URL>、<USER_EMAIL>）で示した上で、確認と不足情報の入力を同じターンで求めてください。生のpac adminコマンドは表示せず、ユーザーがCLI構文を読まなくてもセキュリティ変更の内容を判断できるようにしましょう。
基本原則： ユーザーが最初のやり取りで起こることを評価できなければいけません。「どの環境を対象にしますか？」という一行の質問では不十分です。「user@contoso.comに対して<ENV_URL>のシステム管理者ロールを割り当てます。続行を確認し、対象環境のURLを入力してください（または、「すべて」と入力してリストを表示し、一括実行します）」という説明なら適切です。
ロール割り当て（ユーザーは指定されているが環境が不明）:
user@contoso.comに対して<ENV_URL>のシステム管理者ロールを割り当てます。続行を確認し、対象環境のURLを入力してください（または、「すべて」と入力してリストを表示し、一括実行します）。」すべての環境でのパワーユーザーアクセス:
<YOUR_UPN>に対して各環境で並行してシステム管理者を割り当てます。環境によってassign-userが失敗した場合は、その環境では自己昇格にフォールバック（Purviewに記録）します。続行を確認し、あなたのUPN（ユーザープリンシパルネーム）を入力してください。」| 必要な操作 | 代わりに使用するスキル |
|---|---|
| テーブル、列、リレーションシップの作成または変更 | dv-metadata |
| 組織設定、監査、一括削除、保持ポリシーの管理 | dv-admin |
| レコードの照会または読み取り | dv-query |
| レコードの作成、更新、削除 | dv-data |
| テナントレベルのガバナンス（DLP、環境ライフサイクル） | pac admin --help |
pac auth createを実行済み）pac auth listで確認python scripts/auth.py --checkで通信を確認してください。詳細はdv-connect/references/headless-hosts.mdを参照。pac admin assign-user --user <email-or-object-id> --role "System Administrator" --environment <url>
| 引数 | 別名 | 必須 | 説明 |
|---|---|---|---|
--user |
-u |
はい | ユーザーのメールアドレス（UPN）またはAzure AD オブジェクトID |
--role |
-r |
はい | セキュリティロール名（例：System Administrator、Basic User） |
--environment |
-env |
はい | 対象環境のURLまたはID |
--application-user |
-au |
いいえ | ユーザーをアプリケーションユーザー（サービスプリンシパル）として扱う |
--business-unit |
-bu |
いいえ | 業務単位ID。デフォルトは実行者の業務単位 |
pac admin assign-userは失敗時でも終了コード0で終了します（環境が見つからない、ロール名が不正、ユーザーが不明な場合も）。クリーンな終了を成功と見なさないでください。
終了コードではなく、出力を読む。 失敗時でも終了コード0ですが、エラーメッセージが出力されます（「環境が見つかりません」「ロールが存在しません」など）。出力にエラーが含まれていれば停止してください。
使用した--environmentと正確に照合する。 再解決や短縮形を使わず、異なるIDは間違った組織で何もせず「成功」と見なされる可能性があります。Dataverse CLIの読み取りでユーザーのロールをクエリしてください：
# ユーザーのsystemuseridを解決し、割り当てられたロールをリストアップします。
# --contextはマネージドCLI呼び出しに対するプラグイン/スキル/エージェント属性を含みます。
dataverse api request --target dataverse --method GET \
--path "/api/data/v9.2/systemusers?%24select=systemuserid&%24filter=internalemailaddress eq 'user@contoso.com'" \
--environment <same-url-as-assign> \
--context "app=dataverse-skills/<ver>;skill=dv-security;agent=<agent>"
dataverse api request --target dataverse --method GET \
--path "/api/data/v9.2/systemusers(<systemuserid>)/systemuserroles_association?%24select=name" \
--environment <same-url-as-assign> \
--context "app=dataverse-skills/<ver>;skill=dv-security;agent=<agent>"
最初のクエリが行を返さない場合、サインイン ID はdomainname（AAD UPN）ではなくinternalemailaddress（メイン メール アドレス）に存在する可能性があります。%24filter=domainname eq '<upn>'または オブジェクト IDで割り当てた場合はazureactivedirectoryobjectid eq '<objectid>'で再試行してください。行が見つからないこと自体は、付与が失敗したことの証拠ではありません。
対象ロールが存在しない場合、割り当てが完了していません。再実行して出力を確認するか、自己昇格にフォールバックしてください。
並行実行します。順序実行は行わないでください：
ステップ 1: pac admin list → すべての環境を取得
ステップ 2: 必要に応じてタイプでフィルタ（例：開発環境、サンドボックス） → 対象を特定
ステップ 3: ユーザーに確認 — 対象環境のリストを表示
ステップ 4: すべての割り当てを1つのbashコマンドで実行:
pac admin assign-user --user user@contoso.com --role "System Administrator" --environment https://dev1.crm.dynamics.com &
pac admin assign-user --user user@contoso.com --role "System Administrator" --environment https://dev2.crm.dynamics.com &
pac admin assign-user --user user@contoso.com --role "System Administrator" --environment https://dev3.crm.dynamics.com &
wait
ステップ 5: 各環境での割り当てを検証し、レポート（「3/3環境で割り当てと検証が完了」など）
重要: ロール割り当ての前に対象となる環境をユーザーに確認し、各割り当てが成功したことを検証してください。クリーンな終了コードは成功を証明しません。
自己昇格は、他のユーザーへのロール割り当てとは大きく異なります。 pac admin assign-user <other>は他のユーザーに権限を付与し、pac admin self-elevateは呼び出し元に権限を付与します。リスク評価と監査対象は異なるため、確認プロトコルはより厳格です。
pac admin assign-userが「ユーザーにロールが割り当てられていません」というエラーで失敗した場合は、以下を使用します：
pac admin self-elevate --environment https://myorg.crm.dynamics.com
--environmentが省略された場合、アクティブな認証プロファイルを使用pac admin self-elevateを実行する前に、エージェントは以下を必ず実行してください：
リスクを明示的に述べる。 実行前の説明に以下のような文言（または同等の内容）を含めてください：
「このコマンドはあなた自身に
<env>のシステム管理者を付与します。この操作はMicrosoft Purviewにあなたの身元とタイムスタンプとともに記録されます。」
実施理由をキャプチャする。 チケットID、インシデント番号、または「開発用サンドボックスアクセス — チケットなし」のような自由形式のメモなど、1行の理由を求めてください。実行前の説明で理由をユーザーに返してください。
リスク説明と理由の両方がユーザーに表示された後、明示的な確認を待つ。 ユーザーが(1)と(2)を見る前の単なる「はい」は受け入れないでください。
暗黙のフォールバックは行わない。 pac admin assign-userが失敗した場合、まずその失敗を表示し、その後このプロトコルを使用してself-elevateを提案してください。自動チェーンは行わないでください。
フロー: 常にpac admin assign-userを最初に試みます。admin self-elevateは文書化されたフォールバックであり、上記のプロトコルで制御されます。
CLIフォールバック: pac admin self-elevateがエラーで終了した場合、Power Platform Admin Center → 環境を選択 → アクセス → システム管理者ロールで手動昇格してください。すべての昇格は依然としてPurviewに記録されます。（PAC CLI 2.6.4では、CLIが空のapi-version=をバックエンドに送信するため、bolt.authentication.http.AuthenticatedClientException / ApiVersionInvalidでコマンドが失敗します。）
This skill uses first-party CLIs — PAC CLI for role changes, Dataverse CLI to verify. Do NOT write Python scripts for role operations.
Role grants and self-elevate are destructive (they change security posture and are logged to Purview). Before running, preview the action in plain prose — target user, role, environment(s) — using placeholders (<ENV_URL>, <USER_EMAIL>) for anything unknown, and ask for confirmation and missing values in the same turn. Skip the raw pac admin block; the user shouldn't have to read CLI syntax to approve a security change.
Key principle: the user should be able to evaluate what's about to happen from your first response. A bare "which environment?" fails that test; a one-line prose preview passes it.
Assign role (user given, env missing):
user@contoso.com on <ENV_URL>. Confirm to proceed and provide the target environment URL (or 'all' to list and batch)."Admin access across all environments:
<YOUR_UPN>. If assign-user fails on any environment, I'll fall back to self-elevate (logged to Purview) for that one. Confirm to proceed and provide your UPN."| Need | Use instead |
|---|---|
| Create or modify tables, columns, relationships | dv-metadata |
| Manage org settings, audit, bulk delete, retention | dv-admin |
| Query or read records | dv-query |
| Write, update, or delete records | dv-data |
| Tenant-level governance (DLP, env lifecycle) | pac admin --help |
pac auth create)pac auth listpython scripts/auth.py --check. See dv-connect/references/headless-hosts.md.pac admin assign-user --user <email-or-object-id> --role "System Administrator" --environment <url>
| Argument | Alias | Required | Description |
|---|---|---|---|
--user |
-u |
Yes | User email (UPN) or Azure AD object ID |
--role |
-r |
Yes | Security role name (e.g., System Administrator, Basic User) |
--environment |
-env |
Yes | Target environment URL or ID |
--application-user |
-au |
No | Treat user as an application user (service principal) |
--business-unit |
-bu |
No | Business unit ID. Defaults to the caller's business unit |
pac admin assign-user exits 0 even when it fails (unresolved environment, wrong role name, unknown user). Never treat a clean exit as success.
environment ... not found, role ... does not exist). Stop if the output contains an error.--environment you used — do not re-resolve or shorten it; a different id silently "succeeds" on the wrong org. Query the user's roles with a Dataverse CLI read:# Resolve the user's systemuserid, then list their assigned roles.
# --context carries plugin/skill/agent attribution on the managed CLI call.
dataverse api request --target dataverse --method GET \
--path "/api/data/v9.2/systemusers?%24select=systemuserid&%24filter=internalemailaddress eq 'user@contoso.com'" \
--environment <same-url-as-assign> \
--context "app=dataverse-skills/<ver>;skill=dv-security;agent=<agent>"
dataverse api request --target dataverse --method GET \
--path "/api/data/v9.2/systemusers(<systemuserid>)/systemuserroles_association?%24select=name" \
--environment <same-url-as-assign> \
--context "app=dataverse-skills/<ver>;skill=dv-security;agent=<agent>"
If the first query returns no row, the sign-in identity may live on domainname (the AAD UPN) rather than internalemailaddress (Primary Email) — retry with %24filter=domainname eq '<upn>', or azureactivedirectoryobjectid eq '<objectid>' when you assigned by object id. A missing row is not proof the grant failed.
If the target role is absent, the assignment did not take — re-run, read the output, or fall back to self-elevate.
Run in parallel — never sequentially:
Step 1: pac admin list -> Get all environments
Step 2: Filter by type if needed (e.g., Developer, Sandbox) -> Identify targets
Step 3: Confirm with user — show list of target environments
Step 4: Run ALL assignments in a single bash call:
pac admin assign-user --user user@contoso.com --role "System Administrator" --environment https://dev1.crm.dynamics.com &
pac admin assign-user --user user@contoso.com --role "System Administrator" --environment https://dev2.crm.dynamics.com &
pac admin assign-user --user user@contoso.com --role "System Administrator" --environment https://dev3.crm.dynamics.com &
wait
Step 5: Verify each landed (exit 0 is not proof — see above), then report ("Assigned + verified on 3/3 environments")
Important: Always confirm which environments will be affected before assigning roles, and verify each assignment landed — a clean exit code does not prove success.
Self-elevation is materially different from assigning a role to another user. pac admin assign-user <other> grants privilege to someone else; pac admin self-elevate grants privilege to the caller. The risk profile and audit posture are different, so the confirmation protocol is stricter.
If pac admin assign-user fails with "user has not been assigned any roles", use:
pac admin self-elevate --environment https://myorg.crm.dynamics.com
--environment is omittedBefore running pac admin self-elevate, the agent MUST:
"This grants YOU System Administrator on
<env>. The action is logged to Microsoft Purview with your identity and timestamp."
"dev sandbox access — no ticket". Echo the reason back in the pre-run summary so the user sees what will be on the record.pac admin assign-user fails, surface the failure first, then offer self-elevate with this protocol — never chain them automatically.Flow: Always try pac admin assign-user first. admin self-elevate is the documented fallback, gated by the protocol above.
CLI fallback: If pac admin self-elevate errors out, self-elevate manually via Power Platform Admin Center → select the environment → Access → System Administrator role. All elevations are still logged to Purview. (In PAC CLI 2.6.4 the command fails with bolt.authentication.http.AuthenticatedClientException / ApiVersionInvalid because the CLI sends an empty api-version= to the backend.)
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。