Test Cloud (専有型) の Microsoft Entra ID 連携

Microsoft Entra ID テナントにアプリを登録して UiPath 組織に接続することにより、Microsoft Entra ID を Test Cloud (専有型) と連携します。

この手順は、Test Cloud (専有型) にのみ適用されます

連携が可能になるよう Azure を設定する

組織では、AD メンバーを参照してアカウント ID を確立できるようにするために、Microsoft Entra ID のテナントでのアプリケーションの登録と、いくつかの設定を必要とします。後で組織を Microsoft Entra ID テナントに接続するために、アプリケーションの登録に関する詳細情報も必要になります。

権限: このセクションの作業を実行するには、Azure の管理者である必要があります。次の Azure 管理者ロールには、必要な権限が付与されています: 全体管理者、クラウド アプリケーション管理者、アプリケーション管理者

連携のために Azure テナントを設定する方法は 2 通りあります。

• 以下の手順を実行して、連携のためにアプリケーションの登録を手動で設定します。
• この作業のために UiPath が作成した UiPath Microsoft Entra ID スクリプト (GitHub から入手可能) を使用します。この configAzureADconnection.ps1 スクリプトは、このセクションで説明するすべての操作を実行して、アプリケーションの登録に必要な詳細情報を返します。その後、testAzureADappRegistration.ps1 スクリプトを実行して、アプリの登録が成功したことを確認できます。

Azure テナントを手動で設定するには、Azure Portal で以下の手順を実行します。

1. Test Cloud のアプリケーションの登録を作成します。詳しくは、アプリケーションの登録について Microsoft のドキュメントをご覧ください。

   登録時には [この組織ディレクトリのみに含まれるアカウント] を選択し、[リダイレクト URI] を https://<customURL>.dedicated.uipath.com/identity_/signin-oidc に設定します。

   注:

   組織の登録済みアプリケーションがある場合は、新しく作成する必要はありませんが、アプリが前述の説明のとおりに設定されていることを確認してください。

2. アプリケーションの [概要] ページを開き、[アプリケーション (クライアント) ID] と [ディレクトリ (テナント) ID] の値をコピーし、後で使用するために保存しておきます。

   

3. アプリケーションの [認証] ページに移動します。

   1. [リダイレクト URI] 下部の [URI の追加] を選択して、新しいエントリを追加します。
   2. [リダイレクト URI] のリストに https://<customURL>.dedicated.uipath.com/portal_/testconnection を追加します。
   3. 下部の [ID トークン] チェック ボックスを選択します。
   4. [保存] を選択します。
   

4. [トークン構成] ページに移動します。

5. [省略可能な要求を追加] を選択します。

6. [トークンの種類] として [ID] を選択します。

7. [family_name]、[ given_name]、および [upn] のチェックボックスを選択して、これらを省略可能な要求に追加します。

   

8. [API のアクセス許可] ページに移動します。

9. [アクセス許可の追加] を選択して、[Microsoft Graph] カテゴリから以下の委任されたアクセス許可を追加します。

   • OpenId の権限 - email、 openid、 offline_access、 profile
   • グループ メンバー権限 - GroupMember.Read.All
   • ユーザー権限 - User.Read、 User.ReadBasic.All、 User.Read.All (管理者の同意が必要)
   

   次の表で、API のアクセス許可について説明します。

   アクセス許可	許可される操作	ユーザーが実行する操作
   email、openid、profile、offline_access、User.Read	Microsoft Entra ID がシステム アプリケーションにユーザー トークンを発行できるようにします。	ユーザーが Microsoft Entra ID ログインを使用してシステムにログインできるようにします。これにより、ユーザー オブジェクトを最新の状態に保ち、属性の一貫性を確保できます。
   User.ReadBasic.All	ログインしたユーザーが表示を許可されているディレクトリ内のすべてのユーザーの基本プロパティを読み取ります。	ユーザーがディレクトリ内の他のユーザーにリソースへのアクセス許可を割り当てると、ユーザーがリソースを検索できます。アクセス管理/承認の機能は、システムのユーザー エクスペリエンスにあります。
   User.Read.All (管理者の同意が必要)	ログインしたユーザーが表示を許可されているディレクトリ内のすべてのユーザー プロパティを読み取れるようにします。	管理者は、これらの追加のユーザー プロパティをインポートして、アクセス許可を設定したり、システム サービス内のカスタム情報を表示したりできます。Microsoft Entra ID から属性の完全なセットを取得しようとしている Automation Hub ユーザーは、アプリに User.Read.All の権限を付与する必要があります。
   GroupMember.Read.All	サインインしているユーザーがアクセスできるすべてのユーザーのグループ メンバーシップを読み取ります。	組織がグループを使用してシステム内の権限を管理している場合、プラットフォームがすべてのグループをリストアップし、グループのメンバーを検出できる必要があります。 これにより、グループに割り当てられた権限の管理と適用の両方が可能になります。

   これらのアクセス許可による UiPath のアクセス権の詳細については、暗号化に関するドキュメントをご覧ください。

10. [管理者の同意を与えます] チェック ボックスを選択します。

    注:

    テナントの Active Directory のすべてのユーザーに代わって管理者が同意します。

これによって、アプリケーションがすべてのユーザーのデータにアクセスできるようになり、ユーザーが同意を求められることはありません。権限と同意について詳しくは、Microsoft Entra ID のドキュメントをご覧ください。:::

11. [証明書とシークレット] ページに移動して、新しいクライアント シークレットまたは新しい証明書を作成します。

    • オプション 1.クライアント シークレット。クライアント シークレットについて詳しくは、 こちらで新しいクライアント シークレットの追加に関する Microsoft のドキュメントをご覧ください。

      注:

      作成したクライアント シークレットは永続的ではありません。有効期間を過ぎたら更新する必要があります。

    • オプション 2. 証明書の場合。証明書の大まかな設定手順については、「UiPath の Azure Key Vault 証明書を設定する」をご覧ください。証明書について詳しくは、Microsoft のドキュメント「Quickstart: Set and retrieve a certificate from Azure Key Vault using the Azure portal」をご覧ください。

12. 組織管理者に ディレクトリ (テナント) ID と アプリケーション (クライアント) ID の値を提供します。クライアント シークレットのオプションを選択した場合は、[ クライアント シークレット] の値も共有します。証明書のオプションを選択した場合は、証明書の詳細を共有します。この情報により、管理者は設定を進めることができます。

    

UiPath の Azure Key Vault 証明書を設定する

このセクションでは、証明書を使用した設定手順の概要について説明します。クライアント シークレットを使用することもできます。証明書の設定について詳しくは、Microsoft のドキュメント「Quickstart: Set and retrieve a certificate from Azure Key Vault using the Azure portal」をご覧ください。証明書を設定するには、以下の大まかな手順に従います。

1. Azure Key Vault にログインし、[ 証明書 ] セクションに移動します。

2. [サブジェクト] が [CN=uipath.com] で、[コンテンツの種類] が PEMの証明書を作成します。

   

3. 作成後、証明書を PFX/PEM 形式でダウンロードします。

4. テキストエディタで .pem ファイルを開きます。 BEGIN PRIVATE KEY/END PRIVATE KEY と BEGIN CERTIFICATE/END CERTIFICATEの 2 つのセクションで構成されます。

5. BEGIN CERTIFICATE から までの行のみを含む新しい .pem ファイルを作成しますEND CERTIFICATE.

6. Azure Portal で、[アプリの登録] の [証明書とシークレット ] タブを見つけ、新しい .pem ファイルをアップロードします。

7. {Delivery option} 設定の一環として、Azure Key Vault からダウンロードした .pem 証明書の内容全体を [ クライアント シークレットまたは証明書 ] フィールドに追加する必要があります。

   注:

   証明書の許容最大サイズは 10 KB です。

連携をデプロイする

Azure の設定が完了したら、連携の準備を行い、アクティブ化してから、古いアカウントをクリーンアップすることができます。 ユーザーの作業が中断することのないよう、プロセスはいくつかの段階に分けて実行されます。

注:

このセクションの作業を実行するには、Organization Administrator である必要があります。

非アクティブ ユーザーをクリーンアップする

連携をアクティブ化して UiPath を Microsoft Entra ID に接続すると、メール アドレスが一致するアカウントがリンクされ、Microsoft Entra ID のアカウントに、対応する UiPath ローカル アカウントと同じ権限が付与されます。

メール アドレスのリサイクル

組織でメール アドレスを再利用する習慣がある場合、つまり、過去に使用されていたメール アドレスが将来新しいユーザーに割り当てられる可能性がある場合、アクセス権が昇格される危険性があります。

かつて、メール アドレスが [e-mail] である従業員がいたとします。この従業員はローカル アカウントを所有していて、組織管理者の権限を持っていましたが、その後退社したため、このメール アドレスは非アクティブ化されました。しかし、Orchestrator からはユーザーが削除されませんでした。

同じジョン・ドウという名前の新しい従業員が入社した場合、同じ [e-mail] メール アドレスが割り当てられます。このような場合、アカウントが Microsoft Entra ID との連携の一部としてリンクされると、ジョン・ドウは Organization Administrator の権限を継承してしまいます。

非アクティブなメール アドレス

こうした状況が発生するのを防ぐため、次の手順に進む前に、アクティブでなくなったユーザーが UiPath の組織からすべて削除されていることを確認してください。 非アクティブなメール アドレスを組織で再利用しない場合は、以下の手順を省略できます。

Microsoft Entra ID 連携をアクティブ化する

注:

はじめる前に

• Azure の設定 が完了していることを確認します。
• Azure の管理者から、UiPath のアプリケーションの登録に必要な、Azure の ディレクトリ (テナント) ID、 アプリケーション (クライアント) ID、 クライアント シークレット の値を入手します。

Microsoft Entra ID との連携をアクティブ化するには、UiPath で以下の手順を実行します。

1. [管理] に移動し、選択されていない場合は、左側のペインの上部にある組織名を選択します。

2. [セキュリティ] を選択して [セキュリティ設定] を開きます。

3. [認証設定] タブの [SSO のディレクトリ連携] で、[SSO を構成] を選択します。

4. SSO 構成パネルから [Microsoft Entra ID] を選択します。

5. Azure 管理者から提供された情報をフィールドに入力します。

6. [追加済みのユーザーと Microsoft Entra ID ユーザーのメール アドレスが一致する場合は、それぞれのアカウントがリンクされることを理解し、それに同意します。] のチェックボックスをオンにします。

7. [ テスト接続 ] を選択して、連携が正しく設定されていることを確認します。

8. プロンプトが表示されたら、Microsoft Entra ID アカウントでサインインします。

   サインインに成功すれば、連携は正しく設定されています。失敗した場合は、Azure の管理者に Azure が正しく設定されていることを確認してもらってから、再度試してください。

9. [ 保存 ] を選択して、組織の連携をアクティブ化します。

   変更を保存すると、対応するアカウントが自動的にリンクされます。

10. サインアウトします。

11. 組織の URL (<AccessURL>/organizationID/) に移動し、Microsoft Entra ID のアカウントでサインインします。

これで、リンク先のテナントの Microsoft Entra ID 内のユーザーとグループを操作できます。ディレクトリ アカウントとグループは [管理] & [アカウントとグループ] の [ユーザー] ページまたは [グループ] ページに表示されず、検索を通じてのみ確認できます。

Microsoft Entra ID 連携をテストする

連携が機能していることを確認するには、Microsoft Entra ID アカウントで組織管理者としてサインインし、Test Cloud の [グループを編集] パネル ([管理] > [アカウントとグループ] > [編集] >) などの関連するページで Microsoft Entra ID のユーザーやグループを検索してみてください。

Microsoft Entra ID で作成されたユーザーやグループを検索できれば、連携が正しく機能しています。ユーザーまたはグループの種類は、アイコンによって見分けられます。

ユーザーの検索を試して、下の図の例のようなエラーが発生した場合は、Azure での設定に何らかの問題があります。Azure の管理者に連絡して、「 連携が可能になるよう Azure を設定する」のドキュメントで前述されているとおりに Azure が設定されているかどうかの確認を依頼してください。

ヒント:

Azure 管理者に、Azure の設定中に [管理者の同意を与えます] チェックボックスを選択したことを確かめてもらいます。連携が失敗する一般的な原因の 1 つは、このチェックボックスが選択されていないことです。

Azure 管理者は、GitHub で提供されている UiPath Microsoft Entra ID テスト スクリプト testAzureADappRegistration.ps1 を使用して、原因が明確ではない設定の問題を見つけて修正することができます。

Microsoft Entra ID への移行を完了する

統合がアクティブ化されたら、このセクションの手順に従って、ユーザーの作成とグループの割り当てが Microsoft Entra ID に確実に引き渡されるようにすることをお勧めします。この方法により、既存の ID とアクセス管理インフラストラクチャを基盤として、UiPath のリソースに対する、より簡単なガバナンスとアクセス管理制御を実現できます。

権限とロボット用にグループを設定する (オプション)

グループを設定すると、Azure の管理者も、連携前に設定済みだったものと同じ権限とロボットの設定を使用して、新規ユーザーのオンボーディングを確実に行えるようになります。Microsoft Entra ID グループに必要なロールを割り当て済みであれば、このグループに新規ユーザーを追加するだけでオンボーディングを完了できます。

UiPath の既存のユーザー グループを Microsoft Entra ID の新規または既存のグループにマッピングできます。これは、Microsoft Entra ID でのグループの使用方法に応じて、いくつかの方法で行うことができます。

• UiPath で同じロールを持つユーザーがすでに Microsoft Entra ID の同じグループに属している場合、組織管理者はこれらの Microsoft Entra ID グループを、これらのユーザーが属していたユーザー グループに追加できます。これにより、ユーザーは同じ権限とロボットの設定を維持できます。
• それ以外の場合、Azure 管理者は UiPath のグループと一致する新しいグループを Microsoft Entra ID 内に作成し、UiPath ユーザー グループと同じユーザーを追加できます。その後、組織管理者は新しい Microsoft Entra ID グループを既存のユーザー グループに追加して、同じユーザーが同じロールを持つようにすることができます。

すべての場合において、ユーザーに具体的に割り当てられているロールを確認してください。 可能な場合は、これらのロールの直接割り当てを削除し、これらのロールが既に割り当てられているグループにこれらのユーザーを追加します。

たとえば、UiPath の Administrators グループに、Anna、Tom、John というユーザーが属しているとします。これらのユーザーは admins という名前の Microsoft Entra ID のグループにも属 しています。Organization Administrator は、Azure の admins グループを UiPath の Administrators グループに追加できます。これにより、Anna、Tom、John は、Microsoft Entra ID グループ admins のメンバーとして、UiPath の Administrators グループのロールのメリットを享受できます。

admins は Administrators グループの一部になったため、新しい管理者のオンボードが必要になった場合、Azure 管理者はその新しいユーザーを Azure の admins グループに追加できます。そのため、UiPath で変更を加える必要なく、UiPath での管理者権限を付与できます。

注:

Microsoft Entra ID のグループの割り当てへの変更は、ユーザーがその Microsoft Entra ID アカウントでログインしたときに UiPath に適用されます。すでにログイン済みである場合は、1 時間以内に適用されます。

既存のユーザーを移行する

Microsoft Entra ID のユーザーやグループに割り当てられた権限を適用するには、ユーザーが少なくとも 1 回はサインインする必要があります。連携が開始された後に、ローカル アカウントからサインアウトして Microsoft Entra ID アカウントでサインインし直すよう、すべてのユーザーに指示することをお勧めします。Microsoft Entra ID のアカウントでのサインインは、次の手順で実行できます。

• UiPath 組織固有の URL に移動します。その場合、サインインの種類はあらかじめ選択されています。URL は組織 ID を含み、スラッシュで終る必要があります (例: <AccessURL>/orgID/)。
• メイン ログイン ページで [ Enterprise SSO ] を選択します。必ず組織固有の URL をすべてのユーザーに提供してください。

移行したユーザーは、Microsoft Entra ID グループの権限とともに、UiPath で直接割り当てられた結合された権限を受け取ります。

Studio と Assistant が Microsoft Entra ID アカウントに接続するように設定するには、以下の手順を実行します。

1. Assistant で [設定] を開き、[Orchestrator への接続] タブを選択します。
2. [サインアウト] を選択します。
3. 接続の種類として [サービス URL] を選択します。
4. [ サービス URL ] フィールドに組織固有の URL を追加します。URL は組織 ID を含み、スラッシュで終る必要があります (例: <AccessURL>/orgID/)。そうしないと、ユーザーはどの組織にも属していないことを示すため、接続が失敗します。
5. Microsoft Entra ID アカウントでサインインし直します。
   重要:

   Microsoft Entra ID グループの権限は、クラシック フォルダーのオートメーションや、マシン キーを使用して接続されたロボットには影響しません。グループに基づく権限で動作させるには、オートメーションをモダン フォルダーで設定し、[ サービス URL ] オプションを使用して UiPath Assistant または Studio に接続します。

UiPath のローカル アカウントの使用を中止する (任意)

UiPath と Microsoft Entra ID 間の完全な連携がもたらすコア コンプライアンスと効率のメリットを最大限に活かすために、ローカル アカウントの使用は中止することをお勧めします。

重要:

管理者以外のアカウントのみを削除します。後から認証設定を変更できるようにするには、少なくとも 1 つの組織管理者のローカル アカウントを保持しておくことをお勧めします。

すべてのユーザーの移行が完了したら、[ ユーザー ] タブより、非管理者ユーザーを削除し、今後ローカル アカウントではサインインできないようにします。そのようなアカウントには、ユーザー アイコンが表示されています。

Orchestrator サービスなどの UiPath サービス内の権限を個別にクリーンアップしたり、グループからユーザーを個別に削除したりして、権限が Microsoft Entra ID のグループ メンバーシップだけに基づいて付与されるようにすることもできます。

高度な機能

これで Azure AD 連携が設定されました。以下のセクションでは、活用できる高度な機能について役に立つヒントをいくつか説明します。

組織へのアクセスを制限する

Azure AD との連携は Azure テナントのレベルで実行されるため、既定ではすべての Azure AD ユーザーが Test Cloud にアクセスできます。Azure AD ユーザーが UiPath 組織に初めてサインインすると、そのユーザーは UiPath グループ Everyone に自動的に属し、UiPath エコシステム内で基本レベルのアクセス権を提供する組織のユーザー ロールが付与されます。

特定のユーザーにのみ組織へのアクセスを許可する場合、Azure での UiPath アプリの登録時のユーザーの割り当てをアクティブ化できます。これによって、ユーザーはアプリに明示的に割り当てられないと、そのアプリにアクセスできなくなります。手順については、こちらで、 アプリを一連のユーザーに制限 する方法に関する Microsoft の Azure AD のドキュメントをご覧ください。

アクセスを信頼できるネットワークまたはデバイスのみに制限する

ユーザーが、信頼できるネットワークまたは信頼できるデバイスからのみ Test Cloud にアクセスできるようにする場合は、 Azure AD の条件付きアクセス 機能を使用できます。

Azure AD のグループのガバナンス

「 権限とロボット用にグループを設定する」で前述したように、Azure AD にグループを作成して、Azure AD から直接簡単に UiPath のオンボードを行えるようにした場合、これらのグループに対する Privileged Identity Management (PIM) の高度なセキュリティ オプションを使用して、UiPath グループへのアクセス要求を制御できます。詳細については、 こちらで PIM に関する Microsoft のドキュメントをご覧ください。

よくある質問

連携後、ユーザーにどのような変化がありますか?

連携後、ユーザーは Microsoft Entra ID アカウントでサインインして、既存の権限を保持できます。ローカル ユーザー アカウントがまだアクティブな場合は、両方のサインイン方法を引き続き使用できます。

ディレクトリ アカウントでサインインするために、ユーザーは次のいずれかの操作を行います。

• 組織固有の URL に移動します。 <AccessURL>{organizationName}/
• メイン ログイン ページで、[Enterprise SSO で続行] を選択します。

連携の設定後にユーザーやグループを検索できないのはなぜですか?

ディレクトリ アカウントではなくローカル ユーザー アカウントを使用してサインインした場合、組織内のユーザーやグループは検索できません。

ローカル アカウントとディレクトリ アカウントの違いを理解するには、「ローカル アカウントを段階的に廃止する」をご覧ください。

この問題を解決するには、Microsoft Entra ID アカウントでサインインしていることを確認してください。

権限を再割り当てする必要がありますか?

いいえ、権限を再割り当てする必要はありません。アカウントがリンクされると、組織は既存の権限を対応する Microsoft Entra ID アカウントに自動的に適用されます。ディレクトリ ユーザー アカウントは、直接割り当てとディレクトリ グループ メンバーシップの両方からアクセス許可を受け取ります。

UiPath ディレクトリ ユーザー アカウントにマッピングされる Microsoft Entra ID の属性とその更新時期を教えてください。

UiPath は、Microsoft Entra ID 属性の限られたセットのみをディレクトリ ユーザー アカウントにマップします。次の表は、利用可能な属性をまとめたものです。

すべてのユーザー属性は、サインイン中、および UiPath 組織内のユーザーが検索されるかリソースへのアクセス権が割り当てられたときに更新されます。

UiPath の組織の属性	Microsoft Entra ID の属性	目的
ユーザー名	user.userPrincipalName	一意の識別子。このプロパティは、ユーザーの作成時に必要であり、更新時にクリアすることはできません。
表示名	user.displayName	ユーザーのフルネーム (通常は、姓と名の組み合わせ)。このプロパティは、ユーザーの作成時に必要であり、更新時にクリアすることはできません。
名	user.givenName	ユーザーの名。
姓	user.surName	ユーザーの姓。
メール	user.Mail	ユーザーのメール アドレス。このプロパティは、ユーザーの作成時に必要であり、更新時にクリアすることはできません。
役職1	user.JobTitle	ユーザーの役職です。
Department1	user.Department	ユーザーの部署。
市町村1	user.City	ユーザーの市区町村。
会社名1	user.CompanyName	ユーザーの会社名。

¹ Automation Hub は、Microsoft Entra ID の市区町村、役職、部署、および会社名の値を活用する唯一のサービスです。これらの属性が必要な場合は、「Microsoft Entra ID 連携を設定する」の説明に従って、より高い特権の権限をリクエストする必要があります。

注:

Microsoft Entra ID の属性の説明については、 Microsoft のドキュメントをご覧ください。

Microsoft Entra ID グループ メンバーシップの変更が適用されるまでにどのくらいかかりますか?

Microsoft Entra ID グループ メンバーシップの変更は、次回のサインイン時、またはすでにサインインしているユーザーの場合は 1 時間以内に有効になります。

連携後にローカル アカウントに戻すことはできますか?

はい、Microsoft Entra ID と連携した後にローカル アカウントに戻すことができます。組織管理者は、次の手順を完了する必要があります。

1. ローカル ユーザー アカウントを再度招待します。
2. すべてのディレクトリ グループに基づく権限を、対応するローカル アカウントへの直接割り当てに移行します。
3. サインアウトしてからローカル ユーザー アカウントでサインインするよう、ユーザーに依頼します。

Microsoft Entra ID 連携から SAML 連携に移行できますか?

はい、Microsoft Entra ID 連携から SAML 連携に移行できます。組織管理者は、両方の ID システムで各ユーザーに同じメール アドレスを使用していることを確認する必要があります。また、管理者は、Microsoft Entra ID グループを使用して割り当てられたすべての権限を SAML プロビジョニング ルールに移行する必要があります。

連携で Microsoft Entra ID のハイブリッド OAuth 2.0 認証コード付与フローが使用されるのはなぜですか?

UiPath では、 Microsoft Entra ID のドキュメントに記載されているように、ハイブリッド フローを使用して認可エンドポイントから ID トークンを取得し、認証の待機時間を短縮します。