エンタイトルメント管理でアクセスパッケージを作成する

[アーティクル]
10/29/2023

アクセスパッケージを使用すると、リソースとポリシーを 1 回だけ設定して、アクセスパッケージの存続期間中にアクセスを自動的に管理できます。この記事では、アクセスパッケージの作成方法について説明します。

概要

すべてのアクセスパッケージは、カタログという名前のコンテナーに配置する必要があります。カタログは、アクセスパッケージに追加できるリソースを定義します。カタログを指定しない場合、アクセスパッケージは一般カタログに入ります。現時点では、既存のアクセスパッケージを別のカタログに移動することはできません。

アクセスパッケージを使うと、カタログにある複数のリソースのロールにアクセスを割り当てることができます。管理者またはカタログ所有者であれば、アクセスパッケージの作成時にリソースをカタログに追加することができます。アクセスパッケージの作成後にリソースを追加することもできます。また、アクセスパッケージに割り当てられているユーザーも追加のリソースを受け取ります。

アクセスパッケージマネージャーの場合は、所有しているリソースをカタログに追加することはできません。カタログで利用可能なリソースの使用に制限されます。カタログにリソースを追加する必要がある場合は、カタログ所有者に問い合わせてください。

すべてのアクセスパッケージには、それらにユーザーを割り当てるためのポリシーが少なくとも 1 つ必要です。ポリシーは、アクセスパッケージを要求できるユーザーを指定するほか、承認とライフサイクルの設定、またはアクセスを自動的に割り当てる方法も指定します。アクセスパッケージを作成するときに、ディレクトリ内のユーザー、ディレクトリ内にいないユーザー、または管理者直接割り当てのみに対する初期ポリシーを作成できます。

Diagram of an example marketing catalog, including its resources and its access package.

初期ポリシーを使用してアクセスパッケージを作成する手順の概要を次に示します。

[Identity Governance] で、アクセスパッケージを作成するプロセスを開始します。
アクセスパッケージを配置するカタログを選択し、必要なリソースがあることを確認します。
カタログ内のリソースからリソースロールをアクセスパッケージに追加します。
アクセスを要求できるユーザーの初期ポリシーを指定します。
そのポリシーの承認設定とライフサイクル設定を指定します。

アクセスパッケージが作成されたら、非表示の設定の変更、リソースロールの追加または削除、ポリシーの追加を行うことができます。

作成プロセスを開始する

ヒント

この記事の手順は、開始するポータルに応じて若干異なる場合があります。

次の手順を完了するには、グローバル管理者、Identity Governance 管理者、カタログ所有者、またはアクセスパッケージマネージャーのロールが必要です。

Microsoft Entra 管理センターに Identity Governance 管理者以上としてサインインします。
[Identity Governance]>[エンタイトルメント管理]>[アクセスパッケージ] の順に移動します。
[新しいアクセスパッケージ] を選択します。

基本を構成する

[基本] タブでは、アクセスパッケージの名前を指定し、アクセスパッケージを作成するカタログを指定します。

アクセスパッケージの表示名と説明を入力します。ユーザーがアクセスパッケージの要求を送信するときに、この情報が表示されます。
[カタログ] ドロップダウンリストで、アクセスパッケージを配置するカタログを選択します。たとえば、要求できるすべてのマーケティングリソースを管理するカタログ所有者が存在するとします。この場合、マーケティングカタログを選択できます。

アクセスパッケージを作成する権限を持つカタログのみが表示されます。既存のカタログにアクセスパッケージを作成するには、グローバル管理者または Identity Governance 管理者である必要があります。あるいは、そのカタログ内のカタログ所有者またはアクセスパッケージマネージャーである必要があります。

グローバル管理者、ID ガバナンス管理者、またはカタログ作成者であり、一覧表示されていない新しいカタログにアクセスパッケージを作成する場合は、[新しいカタログの作成] を選択します。カタログの名前と説明を入力し、[作成] を選択します。

作成するアクセスパッケージとそれに含まれるすべてのリソースが、新しいカタログに追加されます。後で、カタログ所有者をさらに追加したり、カタログに入れたリソースに属性を追加したりできます。特定のカタログリソースの属性の一覧や前提条件となるロールを編集する方法の詳細については、「カタログにリソース属性を追加する」を参照してください。
[次へ: リソースロール] を選択します。

リソースロールを選択する

[リソースロール] タブでは、アクセスパッケージに含めるリソースを選択します。アクセスパッケージを要求して受け取るユーザーは、そのアクセスパッケージ内のすべてのリソースロール (グループメンバーシップなど) を受け取ります。

含めるリソースロールが不確定の場合は、アクセスパッケージの作成時にはそれらの追加をスキップし、後で追加できます。

追加するリソースの種類を選択します ([グループとチーム]、[アプリケーション]、または [SharePoint サイト])。
表示される [グループとチーム] パネルで、一覧から 1 つ以上のリソースを選択します。

一般カタログまたは新しいカタログにアクセスパッケージを作成する場合は、自分が所有するディレクトリから任意のリソースを選択できます。少なくともグローバル管理者、Identity Governance 管理者、またはカタログ作成者である必要があります。

Note

動的なグループは、カタログおよびアクセスパッケージに追加できます。ただし、アクセスパッケージで動的グループリソースを管理する場合は、所有者ロールのみを選択できます。

既存のカタログにアクセスパッケージを作成する場合は、そのリソースの所有者でなくても、カタログ内に既にある任意のリソースを選択できます。

グローバル管理者、ID ガバナンス管理者、またはカタログ所有者である場合は、まだカタログに存在しないが自分または管理者が所有するリソースを選択する追加のオプションがあります。ディレクトリ内に存在するけれども、選択されたカタログ内に現在存在しないリソースを選択した場合、それらのリソースもカタログに追加され、他のカタログ管理者がアクセスパッケージの構築に使用できるようになります。カタログに追加できるディレクトリ内のすべてのリソースを表示するには、パネルの上部にある [すべて表示] チェックボックスを選択します。現在、選択したカタログ内にあるリソースのみを選択する場合は、[すべて表示] チェックボックスをオフのままにします (既定の状態)。
[ロール] 一覧で、リソースに対してユーザーに割り当てるロールを選択します。リソースに適したロールを選択する方法の詳細については、「アクセスパッケージに含めるリソースロールを決定する方法」を参照してください。
[Next: Requests](次へ: 要求) を選択します。

要求ポリシーを作成する

[Requests](要求) タブで、最初のポリシーを作成して、アクセスパッケージを要求できるユーザーを指定します。承認設定も構成します。その後、要求ポリシーをさらに作成して、追加のユーザーグループがアクセスパッケージに独自の承認設定を要求できるようにすることができます。

Screenshot that shows the Requests tab for a new access package.

このアクセスパッケージを要求できるようにするユーザーに応じて、次のいずれかのセクションの手順を行います。

ディレクトリ内のユーザーにこのアクセスパッケージの要求を許可する

ディレクトリ内のユーザーがこのアクセスパッケージを要求できるようにする場合は、次の手順を使用します。要求ポリシーを定義するときは、個々のユーザーの指定を行うことも、(より一般的な) ユーザーグループの指定を行うこともできます。たとえば、組織にはすべての従業員のようなグループが既に存在している場合があります。アクセスを要求できるユーザーに対するポリシーにそのグループが追加されている場合、そのグループのすべてのメンバーがアクセスを要求できます。

[Users who can request access](アクセスを要求できるユーザー) セクションで、[For users in your directory](ディレクトリ内のユーザー) を選択します。

このオプションを選択すると、新しいオプションが表示され、ディレクトリ内でこのアクセスパッケージを要求できるユーザーをさらに絞り込めるようになります。

以下のオプションの 1 つを選択します。

オプション	説明
特定のユーザーとグループ	指定したディレクトリ内のユーザーとグループのみがこのアクセスパッケージを要求できるようにする場合は、このオプションを選択します。
All members (excluding guests) (すべてのメンバー (ゲストを除く))	ディレクトリ内のすべてのメンバーユーザーがこのアクセスパッケージを要求できるようにする場合は、このオプションを選択します。このオプションには、ディレクトリに招待したゲストユーザーは含まれません。
All users (including guests) (すべてのユーザー (ゲストを含む))	ディレクトリ内のすべてのメンバーユーザーとゲストユーザーがこのアクセスパッケージを要求できるようにする場合は、このオプションを選択します。

ゲストユーザーとは、Microsoft Entra B2B を介してディレクトリに招待された外部ユーザーです。メンバーユーザーとゲストユーザーの違いについて詳しくは、「Microsoft Entra ID の既定のユーザーアクセス許可とは」をご覧ください。

[特定のユーザーとグループ] を選択した場合は、[ユーザーとグループの追加] を選択します。
[ユーザーとグループの選択] ウィンドウで、追加するユーザーとグループを選択します。
[選択] を選択して、ユーザーとグループを追加します。
「承認設定を指定する」セクションまでスキップします。

ディレクトリ内にいないユーザーにアクセスパッケージの要求を許可する

別の Microsoft Entra ディレクトリまたはドメイン内のユーザーは、まだディレクトリに招待されていない可能性があります。 Microsoft Entra ディレクトリは、[コラボレーションの制限] で招待を許可するように構成されている必要があります。詳細については、外部コラボレーション設定の構成を参照してください。

まだディレクトリに存在しないユーザーからの要求が、承認された、または承認不要の要求である場合、そのユーザー用のゲストユーザーアカウントが作成されます。ゲストは招待されますが、招待メールは届きません。その代わりに、自分のアクセスパッケージの割り当てが配信されるときに電子メールを受け取ります。その後、最後の割り当てが期限切れになったかキャンセルされたためにそのゲストユーザーに割り当てられたアクセスパッケージがなくなると、そのゲストユーザーアカウントはサインインがブロックされ、その後で削除されます。ブロックと削除は既定で行われます。

アクセスパッケージの割り当てがない場合でも、ゲストユーザーがディレクトリ内に無期限に残るようにしたい場合は、エンタイトルメント管理構成の設定を変更できます。ゲストユーザーオブジェクトについて詳しくは、「Microsoft Entra B2B コラボレーションユーザーのプロパティ」をご覧ください。

ディレクトリ内にいないユーザーがこのアクセスパッケージを要求できるようにする場合は、次の手順に従います。

[Users who can request access](アクセスを要求できるユーザー) セクションで、[For users not in your directory](ディレクトリ内にいないユーザー) を選択します。

このオプションを選択すると、新しいオプションが表示されます。

以下のオプションの 1 つを選択します。

オプション	説明
Specific connected organizations (特定の接続済み組織)	管理者が以前に追加した組織の一覧から選択する場合は、このオプションを選択します。選択された組織のすべてのユーザーは、このアクセスパッケージを要求できます。
All connected organizations (すべての接続済み組織)	構成済みのすべての接続済み組織のすべてのユーザーがこのアクセスパッケージを要求できるようにする場合は、このオプションを選択します。
すべてのユーザー (すべての接続済み組織 + 新しい外部ユーザー)	このオプションは、このアクセスパッケージを要求することをすべてのユーザーに許可し、新しい外部ユーザーに対しては B2B 許可リストまたはブロックリストの設定を優先的に適用する場合に選択します。

接続されている組織とは、ご自身と関係のある外部 Microsoft Entra ディレクトリまたはドメインです。

[Specific connected organizations](特定の接続済み組織) を選択した場合は、[Add directories](ディレクトリの追加) を選択して、管理者が以前に追加した、接続済み組織の一覧から選択します。
以前に接続されていた組織を検索するには、名前またはドメイン名を入力します。

共同作業したい組織が一覧にない場合、接続済み組織としてそれを追加することを管理者に依頼することができます。詳細については、接続されている組織の追加に関する記事を参照してください。
[すべての接続済み組織] を選択した場合は、スコープ内に配置する予定の、現在構成されている接続済み組織のリストをグローバル管理者に確認してください。
[すべてのユーザー] を選択した場合は、アクセス要求をインターネット全体のあらゆる ID から受け付けることも可能になるため、承認セクションで承認を構成する必要があります。
接続されているすべての組織を選択したら、[選択] を選択します。

選択した接続済み組織のすべてのユーザーは、このアクセスパッケージを要求できます。この場合に許可されるユーザーには、組織に関連付けられたすべてのサブドメイン (Azure B2B の許可リストまたはブロックリストでブロックされているドメインを除く) に属する Microsoft Entra ID のユーザーが含まれます。ソーシャル ID プロバイダーのドメイン (例: live.com など) を指定すると、そのソーシャル ID プロバイダーのユーザー全員がこのアクセスパッケージを要求できるようになります。詳細については、「B2B ユーザーに対する特定組織からの招待を許可またはブロックする」を参照してください。
「承認設定を指定する」セクションまでスキップします。

管理者直接割り当てのみを許可する

アクセス要求をバイパスし、管理者が特定のユーザーをこのアクセスパッケージに直接割り当てることを許可する場合は、次の手順に従います。ユーザーは、アクセスパッケージを要求する必要はありません。ライフサイクルの設定を行うこともできますが、要求の設定はありません。

[Users who can request access](アクセスを要求できるユーザー) セクションで、[None (administrator direct assignments only)](なし (管理者直接割り当てのみ)) を選択します。

アクセスパッケージを作成した後、それに特定の内部および外部ユーザーを直接割り当てることができます。外部ユーザーを指定すると、ゲストユーザーアカウントがディレクトリ内に作成されます。ユーザーの直接割り当てについては、アクセスパッケージに対する割り当ての表示、追加、削除に関する記事を参照してください。
[Enable requests](要求の有効化) セクションまでスキップします。

承認設定を指定する

[承認] セクションで、ユーザーがこのアクセスパッケージを要求したときに承認が必要かどうかを指定します。承認の設定は次のように機能します。

1 段階の承認の場合、選択した承認者またはフォールバック承認者のうち 1 人だけが要求を承認する必要があります。
2 段階の承認の場合、各ステージで、選択した承認者のうち 1 人だけが要求を承認する必要があります。
承認者になることができるのは、ポリシーのアクセスガバナンスに応じて、マネージャー、ユーザーのスポンサー、内部スポンサー、または外部スポンサーです。
1 段階または 2 段階の承認では、選択したすべての承認者から承認を受ける必要はありません。
承認の決定は、最初に要求をレビューする承認者に基づいて行われます。

要求ポリシーに承認者を追加する方法のデモについては、次のビデオをご覧ください。

要求ポリシーに複数段階の承認を追加する方法のデモについては、次のビデオをご覧ください。

次の手順に従って、アクセスパッケージの要求の承認設定を指定します。

選択されたユーザーからの要求に対して承認を要求するには、 [承認を要求する] トグルを [はい] に設定します。または、要求を自動的に承認するには、トグルを [いいえ] に設定します。自組織に属さない外部ユーザーからのアクセス要求をポリシーで許可している場合は、どのようなユーザーが組織のディレクトリに追加されるかを監視できるよう、承認を必須にしてください。
アクセスパッケージを要求する理由を入力することをユーザーに求めるには、 [要求者の理由を要求する] トグルを [はい] に設定します。
要求で 1 段階または 2 段階のどちらの承認を必要とするかを決定します。 [ステージの数] トグルを、1 段階の承認の場合は [1] に設定し、2 段階の承認の場合は [2] に設定し、3 段階承認の場合は [3] に設定します。

次の手順を使用して、段階の数を選択した後に承認者を追加します。

1 段階の承認

[1 番目の承認者] 情報を追加します。
- ポリシーが [ディレクトリ内のユーザーの場合] に設定されている場合は、[承認者としてのマネージャー] または [承認者としてのスポンサー] を選択できます。または、[特定の承認者の選択] を選択してから [承認者の追加] を選択して、特定のユーザーを追加できます。
  
  [承認] に [承認者としてのスポンサー] を使用するには、Microsoft Entra ID ガバナンスライセンスが必要です。詳細については、一般提供されている Microsoft Entra ID の機能の比較に関するページを参照してください。
- ポリシーが [自分のディレクトリ内以外のユーザーの場合] に設定されている場合は、[外部スポンサー] または [内部スポンサー] を選択できます。または、[特定の承認者の選択] を選択してから [承認者の追加] を選択して、特定のユーザーを追加できます。
最初の承認者として [マネージャー] を選択した場合は、[フォールバックの追加] を選択して、フォールバック承認者として指定する、ディレクトリ内のユーザーまたはグループを 1 つ以上選択します。エンタイトルメント管理でアクセスを要求しているユーザーのマネージャーが見つからなかった場合、フォールバック承認者が要求を受け取ります。

エンタイトルメント管理では、[マネージャー] 属性を使用してマネージャーを検索します。属性は、Microsoft Entra ID のユーザーのプロファイルにあります。詳細については、「ユーザーのプロファイル情報と設定を追加または更新する」を参照してください。
最初の承認者として [スポンサー] を選択した場合は、[フォールバックの追加] を選択して、フォールバック承認者として指定する、ディレクトリ内のユーザーまたはグループを 1 つ以上選択します。エンタイトルメント管理でアクセスを要求しているユーザーのスポンサーが見つからなかった場合、フォールバック承認者が要求を受け取ります。

エンタイトルメント管理では、[Sponsors](スポンサー) 属性を使用してスポンサーを検索します。属性は、Microsoft Entra ID のユーザーのプロファイルにあります。詳細については、「ユーザーのプロファイル情報と設定を追加または更新する」を参照してください。
[特定の承認者の選択] を選択した場合は、[承認者の追加] を選択して、承認者として指定する、ディレクトリ内のユーザーまたはグループを 1 つ以上選択します。
[決定は何日以内に行わなければなりませんか?] ボックスには、承認者がこのアクセスパッケージの要求を確認する必要がある日数を指定します。

この期間内に承認されない要求は、自動的に拒否されます。その場合、ユーザーは、アクセスパッケージに対して新たな要求を送信する必要があります。
判断の理由を入力することを承認者に求める場合は、[Require approver justification](承認者の理由が必要) を [はい] に設定します。

理由は、要求者と他の承認者に表示されます。

2 段階の承認

2 段階の承認を選択した場合は、2 番目の承認者を追加する必要があります。

[2 番目の承認者] 情報を追加します。
- ユーザーが自分のディレクトリに存在する場合は、[承認者としてのスポンサー] を選択できます。または、ドロップダウンメニューから [特定の承認者の選択] を選択してから [承認者の追加] を選択して、特定のユーザーを追加します。
- ユーザーがディレクトリ内にいない場合は、2 番目の承認者として [内部スポンサー] または [外部スポンサー] を選択します。承認者を選択した後、フォールバック承認者を追加します。
[決定は何日以内に行わなければなりませんか?] ボックスで、2 番目の承認者が要求を承認しなければならない日数を指定します。
[承認者からの理由が必要] トグルを [はい] または [いいえ] に設定します。

3 段階の承認

3 段階の承認を選択した場合は、3 番目の承認者を追加する必要があります。

[3 番目の承認者] 情報を追加します。

ユーザーがディレクトリ内にいる場合は、[特定の承認者の選択]> [承認者の追加] を選択して、3 番目の承認者として特定のユーザーを追加します。
[決定は何日以内に行わなければなりませんか?] ボックスで、2 番目の承認者が要求を承認しなければならない日数を指定します。
[承認者からの理由が必要] トグルを [はい] または [いいえ] に設定します。

代理承認者

要求を承認できる最初の承認者と 2 番目の承認者を指定するのと同様に、代理承認者を指定できます。代理承認者を指定することにより、有効期限が切れる (タイムアウト) 前に要求が承認または拒否されることを保証できます。 2 段階の承認の場合、最初の承認者と 2 番目の承認者の代理承認者を一覧表示できます。

代理承認者を指定するとき、最初または 2 番目の承認者が要求を承認も拒否もできなかった場合、保留中の要求は代理承認者に転送されます。要求は、ポリシーの設定時に指定した転送スケジュールに従って送信されます。承認者は、保留中の要求を承認または拒否するための電子メールを受信します。

要求が代理承認者に転送された後でも、最初の承認者または 2 番目の承認者は引き続き要求を承認または拒否できます。代理承認者は、最初の承認者または 2 番目の承認者と同じ[マイアクセス] サイトを使用して、保留中の要求を承認または拒否します。

承認者と代理承認者となる個人またはグループを一覧表示できます。最初の承認者、2 番目の承認者、代理承認者には、必ず別のメンバーセットを指定してください。たとえば、アリスとボブを最初の承認者として指定した場合は、代理承認者には Carol と Dave を指定します。

次の手順を使用して、アクセスパッケージに代理承認者を追加します。

[1 番目の承認者]、[2 番目の承認者]、またはその両方で、[詳細な要求の設定を表示する] を選択します。
[アクションが実行されない場合は、別の承認者に転送しますか?] トグルを [はい]に設定します。
[別の承認者の追加] を選択して、一覧から代理承認者を選択します。

最初の承認者として [マネージャー] を選択すると、[代理承認者] ボックスに追加のオプション [第 2 レベルマネージャーを代理承認者とする] が表示されます。このオプションを選択した場合は、システムが第 2 レベルのマネージャーを見つけられない場合に、要求の転送先のフォールバック承認者を追加する必要があります。
[Forward to alternate approver(s) after how many days](別の承認者へ転送するまでの日数) ボックスに、承認者が要求を承認または拒否する必要がある日数を入力します。要求期間内にどの承認者も要求を承認または拒否しなかった場合、要求の有効期限が切れます (タイムアウト)。その場合、ユーザーは、アクセスパッケージに対して新たな要求を送信する必要があります。

要求期間の半分に達した翌日以降からのみ、代理承認者へ要求を転送できるようになります。メイン承認者の決定は、少なくとも 4 日後にタイムアウトする必要があります。要求のタイムアウトが 3 日以下にすると、要求を代理承認者に転送するのに十分な時間を確保できません。

この例では、要求の期間は 14 日です。要求期間が半分に達するのは 7 日目になります。そのため、8 日目以降にしか要求を転送することはできません。

また、要求期間の最終日にも、要求を転送することはできません。そのため、例では、最後に要求を転送できる日は 13 日目です。

要求の有効化

アクセスパッケージを要求ポリシー内のユーザーが要求のためにすぐに利用できるようにするには、[新しい要求と割り当ての有効化] トグルを [はい] に切り替えます。

アクセスパッケージの作成が完了した後は、これをいつでも有効にすることができます。

[None (administrator direct assignments only)](なし (管理者直接割り当てのみ)) を選択し、[新しい要求と割り当ての有効化] を [いいえ] に設定した場合、管理者はこのアクセスパッケージを直接割り当てることはできません。
アクセスパッケージに確認済み ID 要件を追加する方法については、次のセクションを参照してください。その以外の場合は、 [次へ] を選択します。

確認済み ID 要件を追加する

アクセスパッケージポリシーに確認済み ID 要件を追加する場合は、次の手順を使用します。アクセスパッケージへのアクセスを必要とするユーザーが要求を正常に送信するには、要求された確認済み ID を提示する必要があります。 Microsoft Entra Verified ID サービスを使用してテナントを構成する方法については、「Microsoft Entra Verified ID の概要」を参照してください。

アクセスパッケージに確認済み ID 要件を追加するには、グローバル管理者ロールが必要です。 Identity Governance 管理者、ユーザー管理者、カタログ所有者、またはアクセスパッケージマネージャーは、まだ確認済み ID 要件を追加することができません。

[+ 発行者の追加] を選択し、Microsoft Entra Verified ID ネットワークから発行者を選択します。ユーザーに独自の資格情報を発行する場合は、「アプリケーションから Microsoft Entra 確認済み ID の資格情報を発行する」で手順を確認できます。
要求プロセス中にユーザーに提示を求める資格情報の種類を選択します。

1 つの発行者から複数の資格情報の種類を選択すると、ユーザーは選択したすべての種類の資格情報の提示を求められます。同様に、複数の発行者を含めると、ユーザーはポリシーに含めた各発行者の資格情報の提示を求められます。さまざまな発行者の異なる資格情報を提示するオプションをユーザーに提供するには、受け入れる発行者または資格情報の種類ごとに別個のポリシーを構成します。
[追加] を選択して、アクセスパッケージポリシーに確認済み ID 要件を追加します。

アクセスパッケージに要求元の情報を追加する

[要求元情報] タブに移動し、[質問] タブを選択します。
[質問] ボックスに、要求元に確認したい質問を入力します。この質問は、表示文字列とも呼ばれます。
独自のローカライズオプションを追加する場合は、[add localization](ローカリゼーションの追加) を選択します。

[Add localizations for question](質問のローカリゼーションの追加) ウィンドウで、次の操作を行います。
1. [Language code](言語コード) で、質問をローカライズする言語の言語コードを選択します。
2. [Localized Text](ローカライズされたテキスト) ボックスに、構成した言語で質問を入力します。
3. 必要なすべてのローカライズの追加が完了したら、[保存] を選択します。
[回答形式] で、要求元が回答する形式を選択します。回答形式には、[短いテキスト]、[複数選択]、[長いテキスト] などがあります。
複数選択を選択した場合は、[編集およびローカライズ] ボタンを選択して回答オプションを構成します。

[編集およびローカライズ] ウィンドウで、次の操作を行います。
1. [回答値] ボックスに、要求元が質問に回答するときに提示される応答オプションを入力します。
2. [言語] ボックスで、応答オプションの言語を選択します。追加の言語を選択した場合は、回答のオプションをローカライズできます。
3. [保存] を選択します。
アクセスパッケージへのアクセスの要求時に要求元に対してこの質問への回答を要求するには、[必須] チェックボックスを選択します。
[属性] タブを選択して、アクセスパッケージに追加したリソースに関連付けられている属性を表示します。

注意

アクセスパッケージのリソースの属性を追加または更新するには、 [カタログ] に移動し、そのアクセスパッケージに関連付けられているカタログを見つけます。特定のカタログリソースの属性の一覧や前提条件となるロールを編集する方法の詳細については、「カタログにリソース属性を追加する」を参照してください。
[次へ] を選択します。

ライフサイクルを指定する

[ライフサイクル] タブでは、アクセスパッケージに対するユーザーの割り当ての有効期限を指定します。ユーザーが割り当てを延長できるかどうかを指定することもできます。

[有効期限] セクションで、[Access package assignments expires](アクセスパッケージ割り当ての有効期限) を [日付]、[日数]、[時間数] または [なし] に設定します。
- [日付] の場合、将来の有効期限の日付を選択します。
- [日数] の場合、0 日から 3660 日までの数値を指定します。
- [時間数] には、時間数を指定します。
選択内容に基づき、アクセスパッケージに対するユーザーの割り当ては、特定の日付または承認後の何日か後に期限切れになるか、期限切れになりません。
アクセス権について特定の開始日と終了日をユーザーに要求するようにする場合は、[ユーザーは特定のタイムラインを要求できる] トグルで [はい] を選択します。
[詳細な有効期限の設定を表示する] を選択して、他の設定を表示します。
ユーザーが割り当てを延長できるようにするには、[ユーザーがアクセス権を延長することを許可する] を [はい] に設定します。

ポリシーで延長が許可されている場合、アクセスパッケージの割り当ての有効期限が切れる 14 日前と 1 日前にユーザーにメールが送信されます。この電子メールで、ユーザーに割り当ての延長を求めるメッセージが表示されます。ユーザーは、延長を要求する時点で、引き続きポリシーのスコープ内にいる必要があります。

また、ポリシーで割り当ての明示的な終了日が設定されていて、ユーザーがアクセス権の延長を求める要求を送信する場合、要求内の延長の日付は割り当ての有効期限が切れる日か、それより前とする必要があります。アクセスパッケージへのアクセス権をユーザーに付与するために使用したポリシーは、延長の日付が割り当ての有効期限またはそれより前の日付であるかを定義します。たとえば、割り当ての有効期限が 6 月 30 日に切れることがポリシーで示されている場合、ユーザーが要求できる最大の延長は 6 月 30 日です。

ユーザーのアクセス権が延長された場合、そのユーザーは、指定された延長の日付 (ポリシーを作成したユーザーのタイムゾーンで設定された日付) より後にアクセスパッケージを要求することはできません。
延長を許可するための承認を要求するには、[Require approval to grant extension](延長許可の承認を要求する) を [はい] に設定します。

この承認では、[Requests](要求) タブで指定したのと同じ承認設定が使用されます。
[次へ] または [更新] を選択します。

アクセスパッケージを確認して作成する

[Review + create](確認と作成) タブでは、設定の確認と検証エラーのチェックを行うことができます。

アクセスパッケージの設定を確認します。
[作成] を選択してアクセスパッケージを作成します。

新しいアクセスパッケージがアクセスパッケージの一覧に表示されます。
アクセスパッケージがポリシーの対象範囲内のすべてのユーザーに表示されるように意図されている場合は、アクセスパッケージの [非表示] の設定を [いいえ] のままにします。必要に応じて、直接リンクを持つユーザーのみがアクセスパッケージを要求できるようにする場合は、アクセスパッケージを編集して [非表示] の設定を [はい] に変更します。次に、リンクをコピーしてアクセスパッケージを要求し、アクセスが必要なユーザーと共有します。

プログラムでアクセスパッケージを作成する

プログラムでアクセスパッケージを作成するには、2 つの方法 (Microsoft Graph の使用と、Microsoft Graph 用の PowerShell コマンドレットの使用) があります。

Microsoft Graph を使用してアクセスパッケージを作成する

Microsoft Graph を使用してアクセスパッケージを作成できます。委任された EntitlementManagement.ReadWrite.All アクセス許可を持つアプリケーションを有する適切なロールのユーザーは、API を呼び出して、次のことを行うことができます。

カタログ内のリソースを一覧表示し、カタログにまだ存在しないすべてのリソースに対して accessPackageResourceRequest を作成します。
カタログ内の各リソースのロールとスコープを取得します。このロールの一覧は、後で resourceRoleScope を作成するときにロールを選択するために使用されます。
accessPackage を作成します。
アクセスパッケージ内で必要なリソースロールごとに resourceRoleScope を作成します。
アクセスパッケージで必要となるポリシーごとに assignmentPolicy を作成します。

Microsoft PowerShell を使用してアクセスパッケージを作成する

PowerShell で Identity Governance 用の Microsoft Graph PowerShell コマンドレットモジュールのコマンドレットを使用して、アクセスパッケージを作成することもできます。

まず、アクセスパッケージに含めるカタログの ID、そのカタログ内のリソース、およびそのスコープとロールの ID を取得します。次の例のようなスクリプトを使用します。

Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"

$catalog = Get-MgEntitlementManagementCatalog -Filter "displayName eq 'Marketing'" -All
if ($catalog -eq $null) { throw "catalog not found" }
$rsc = Get-MgEntitlementManagementCatalogResource -AccessPackageCatalogId $catalog.id -Filter "originSystem eq 'AadApplication'" -ExpandProperty scopes
if ($rsc -eq $null) { throw "resource not found" }
$filt = "(id eq '" + $rsc.Id + "')"
$rrs = Get-MgEntitlementManagementCatalogResource -AccessPackageCatalogId $catalog.id -Filter $filt -ExpandProperty roles,scopes

次に、アクセスパッケージを作成します。


$params = @{
    displayName = "sales reps"
    description = "outside sales representatives"
    catalog = @{
        id = $catalog.id
    }
}
$ap = New-MgEntitlementManagementAccessPackage -BodyParameter $params

アクセスパッケージを作成したら、それにリソースロールを割り当てます。たとえば、先ほど返されたリソースの 1 番目のリソースロールを新しいアクセスパッケージのリソースロールとして含める場合は、このようなスクリプトを使用できます。


$rparams = @{
    role = @{
        id =  $rrs.Roles[0].Id
        displayName =  $rrs.Roles[0].DisplayName
        description =  $rrs.Roles[0].Description
        originSystem =  $rrs.Roles[0].OriginSystem
        originId =  $rrs.Roles[0].OriginId
        resource = @{
            id = $rrs.Id
            originId = $rrs.OriginId
            originSystem = $rrs.OriginSystem
        }
    }
    scope = @{
        id = $rsc.Scopes[0].Id
        originId = $rsc.Scopes[0].OriginId
        originSystem = $rsc.Scopes[0].OriginSystem
    }
}

New-MgEntitlementManagementAccessPackageResourceRoleScope -AccessPackageId $ap.Id -BodyParameter $rparams

最後に、ポリシーを作成します。このポリシーでは、管理者またはアクセスパッケージの割り当て管理者のみがアクセス権を割り当てることができ、アクセスレビューはありません。その他の例については、「PowerShell を通じた割り当てポリシーの作成」と「assignmentPolicy の作成」に関する記事を参照してください。



$pparams = @{
    displayName = "New Policy"
    description = "policy for assignment"
    allowedTargetScope = "notSpecified"
    specificAllowedTargets = @(
    )
    expiration = @{
        endDateTime = $null
        duration = $null
        type = "noExpiration"
    }
    requestorSettings = @{
        enableTargetsToSelfAddAccess = $false
        enableTargetsToSelfUpdateAccess = $false
        enableTargetsToSelfRemoveAccess = $false
        allowCustomAssignmentSchedule = $true
        enableOnBehalfRequestorsToAddAccess = $false
        enableOnBehalfRequestorsToUpdateAccess = $false
        enableOnBehalfRequestorsToRemoveAccess = $false
        onBehalfRequestors = @(
        )
    }
    requestApprovalSettings = @{
        isApprovalRequiredForAdd = $false
        isApprovalRequiredForUpdate = $false
        stages = @(
        )
    }
    accessPackage = @{
        id = $ap.Id
    }
}
New-MgEntitlementManagementAssignmentPolicy -BodyParameter $pparams

エンタイトルメント管理でアクセスパッケージを作成する

概要

作成プロセスを開始する

基本を構成する

リソースロールを選択する

要求ポリシーを作成する

ディレクトリ内のユーザーにこのアクセスパッケージの要求を許可する

ディレクトリ内にいないユーザーにアクセスパッケージの要求を許可する

管理者直接割り当てのみを許可する

承認設定を指定する

1 段階の承認

2 段階の承認

3 段階の承認

代理承認者

要求の有効化

確認済み ID 要件を追加する

アクセスパッケージに要求元の情報を追加する

ライフサイクルを指定する

アクセスパッケージを確認して作成する

プログラムでアクセスパッケージを作成する

Microsoft Graph を使用してアクセスパッケージを作成する

Microsoft PowerShell を使用してアクセスパッケージを作成する

次のステップ

その他のリソース

エンタイトルメント管理でアクセス パッケージを作成する

概要

作成プロセスを開始する

基本を構成する

リソース ロールを選択する

要求ポリシーを作成する

ディレクトリ内のユーザーにこのアクセス パッケージの要求を許可する

ディレクトリ内にいないユーザーにアクセス パッケージの要求を許可する

管理者直接割り当てのみを許可する

承認設定を指定する

1 段階の承認

2 段階の承認

3 段階の承認

代理承認者

要求の有効化

確認済み ID 要件を追加する

アクセス パッケージに要求元の情報を追加する

ライフサイクルを指定する

アクセス パッケージを確認して作成する

プログラムでアクセス パッケージを作成する

Microsoft Graph を使用してアクセス パッケージを作成する

Microsoft PowerShell を使用してアクセス パッケージを作成する

次のステップ

その他のリソース

エンタイトルメント管理でアクセスパッケージを作成する

リソースロールを選択する

ディレクトリ内のユーザーにこのアクセスパッケージの要求を許可する

ディレクトリ内にいないユーザーにアクセスパッケージの要求を許可する

アクセスパッケージに要求元の情報を追加する

アクセスパッケージを確認して作成する

プログラムでアクセスパッケージを作成する

Microsoft Graph を使用してアクセスパッケージを作成する

Microsoft PowerShell を使用してアクセスパッケージを作成する