Dataverse接続設定

あなたのポータルは、たまたま閲覧している訪問者としてではなく、独立したアプリケーションとしてDataverseと通信します。これは2つの要素から成り立っています。Microsoft Entra IDでの アプリ登録 が認証情報を所有し、もう1つはDataverse環境内の アプリケーションユーザーが その認証情報にアイデンティティとセキュリティ役割を与えることです。このページは両方を説明し、ポータルが実際に必要とするアクセスについて説明しています。

これはサインインアプリではありません

この登録はポータル自身のサービスアイデンティティであり、ポータルに代わってデータの読み書きを行い、認証情報は D365:ClientId / D365:ClientSecretに分類されます。もう一つの別の登録は、 Microsoftでのユーザーのサインイン を担当します。分けておけばいい:これはリダイレクトURIや権限の委任を必要としませんが、環境内ではるかに大きな権限を持っています。 Entra IDサインイン設定をご覧ください

1. 申請書の登録

Dataverse環境を所有するテナントの Microsoft Entra管理センターで登録を作成します。

1. Entra ID>アプリの登録をブラウズし、「新しい登録」を選択してください。
2. ポータルと環境を識別する 名前 を入力してください。例えば Contoso Portal — Dataverse (Production)。同意画面では誰も見ないので、後で監査する人のために明確にしておくべきです。
3. サポートアカウント タイプの中で「 シングルテナントのみ」を選択してください。このアイデンティティは組織から離れることはありません。
4. リダイレクトURIは空のままにしてください。ここではユーザーがリダイレクトされることは一切ありません。ポータルはクライアントの認証情報フローで認証し、マシン間で認証を行い、ブラウザは関与しません。
5. 登録を選択します。
6. 概要ページでアプリケーション(クライアント)IDをコピーします。その値はD365:ClientIdになり、ステップ4でアプリケーションユーザーを作成する際に再度必要です。

2. クライアントシークレットを作成する

シークレットはポータルの唯一の認証情報なので、環境のデータへの鍵として扱ってください。

1. 「Management」の「Certificates and secrets」を開いて「Clients secrets」タブを選択してください。
2. 新しいクライアント秘密を選択し、環境(例:portal-production)で記述し、期限を選びます。
3. Value列をすぐにコピーしてください — Secret IDはコピーしないでください。一度だけ表示され、D365:ClientSecretになります。

重要

シークレットが切れると、ポータルはDataverseに完全に届かなくなります。機能だけでなく、すべてのリクエストに対してです。ですので、有効期限をどこかに記載してください。本番環境では、証明書認証情報が有効期限の崖を避け、 AuthenticationType.Certificate は秘密の代わりに証明書を受け入れます。

3. API権限:不要

このステップは意図的に空にしており、それが多くの人を驚かせています。古いガイダンスでは、 Dynamics CRM → user_impersonation 委任権限を追加するように指示されています。その権限は サインインしたユーザーの代理として動作するアプリケーションのためのものです。しかしポータルはそれを行わず、認証は自分自身として行われ、そのアクセスは次のステップで作成したDataverseアプリケーションユーザーから完全に行います。

注記

Microsoft自身のサーバー間ガイダンスも同じことを述べています。アプリとして接続すると、 組織ユーザーとしてAccess Dynamics 365を付与しません。なぜなら、アプリケーションは特定のユーザーアカウントに紐づいているからです。追加しても何も壊れませんが、ポータルが決して行使しない機能が与えられます — それはオフにしてください。

4. Dataverseでアプリケーションユーザーを作成する

アプリの登録だけではデータには触れられません。Dataverseはユーザーレコードを割り当てる必要があり、それがクライアントIDを環境が認識するアイデンティティに変換します。

1. Power Platform管理センターにサインインしてください。
2. ナビゲーションペインで 「管理 」を選択し、次に 「環境」→「あなたの環境」を選びます。
3. 「 設定 > ユーザー+権限 」> アプリケーションユーザーを選択します。
4. + を選択:新しいアプリユーザー。
5. +アプリを追加を選択して、ステップ1のクライアントIDまたは名前で登録を検索し、追加を選択します。このリストにはEntraアプリの登録のみが表示され、エンタープライズアプリケーションには含まれません。
6. 事業部門を選択してください。ルート事業部門が通常の答えです。子ユニットは、セキュリティ役割が適用される前からポータルが到達できる範囲を絞り込みます。
7. セキュリティロールの隣にある編集アイコンを選択し、ポータル用に作成したロールを割り当ててください。次のステップで、何を含める必要があるかを確認してください。
8. 「 作成」を選択します。

ヒント

アプリケーションユーザーは有料ライセンスを消費せず、環境ごとにEntraアプリごとに登録は1つまでです。各環境ごとに別々の登録を設定し、開発アクセスを取り消しても本番環境には影響しません。

5. アプリケーションユーザーにセキュリティ役割を与える

組み込みのロールを使い回すのではなく、カスタムのセキュリティロールを作成すれば、ポータルのアクセスが可視化され、確認可能です。役割に必要なものは、使用するフレームワーク機能によって異なります:

重要

システム管理者を割り当てる誘惑に抗い、先に進みましょう。ポータルはインターネット対応で、この認証情報が秘密が漏れた場合に攻撃者が何に到達するかを決めます。実際の役割を構築するためにかかる午後の時間は価値があり、開発環境は見落としたものを見つけるのに最適な場所です。

6. 接続設定を保存する

ポータルは D365 セクションの設定からこれらを読み取ります。開発中はユーザーシークレットに保持し、ソース制御に到達しないようにしてください:

EmailSenderEmailAddress はポータルの発信メールの送信元アドレスです。環境内の queue または有効 systemuser に一致している必要があります。キューが通常選択で、ポータルメールを後に離れる可能性のある人物に紐づけないためです。

ヒント

ホスト環境では、環境変数と同じキーや秘密ストアから提供し、コロンの代わりにダブルアンダースコア( D365__ClientId、 D365__Secret )を用います。これはコロンセパレータがプラットフォーム間で持ち運べないためです。

7. 接続の配線

サーバープロジェクトはフレームワークを登録する際に ConnectionOptions を設定します:

プロジェクトテンプレートがこれを自動で書いてくれるので、生成されたプロジェクトでは追加するものは何もありません。3つの設定値を入力すれば接続が正常になります。ポータルを起動し、Dataverseデータに裏付けられたページを閲覧して確認してください。

トラブルシューティング

• 呼び出し者は有効なDataverseユーザーでない場合、認証が完全に失敗します。 アプリ登録は存在しますが、この環境ではどのアプリケーションユーザーもそれに縛られていません。アプリケーションユーザーは環境ごとに分かれており、開発中に作成しても本番環境には影響しません。
• 認証は無効なクライアントシークレットで失敗します。 通常、シー クレット の 値の代わりにシークレットIDがコピーされたか、シークレットが期限切れになっています。新しいシークレットを作成し、設定を更新してください。
• プリンシパルが権限を欠いています。 アプリケーションユーザーの役割がエラーに記載されたテーブルへのアクセスを欠いています。Dataverseはサーバーノードごとに権限をキャッシュしているため、役割変更後に1〜2分待ってから変更を終了しても効果はありませんでした。
• すべてのデータエンドポイントは402を返します。 ウェブサイトのライセンスチェックが失敗しています。管理型ソリューションがインストールされていること、Portalウェブサイトレコードにライセンスキーが保管されていること、そしてアプリケーションユーザーの役割が実行可能であること ppp_ProWebsiteLicenseCheck確認してください。
• メールが失敗し、「メールアドレスの送信者を見つけることができます」と表示されます。EmailSenderEmailAddress環境内のどのキューや有効化されたシステムユーザーとも一致しません。