Azure AD 連携を設定する

Azure AD との連携をセットアップし、ユーザー アカウントを管理するために組織を Azure AD のテナントに接続する

概要

会社で Azure Active Directory (Azure AD) または Office 365 を使用している場合は、組織を Azure AD のテナントに直接接続して、UiPath® 環境の既存のユーザー アカウントを表示できます。

Azure AD との連携を使用すると、ローカルのユーザー モデルを利用し続けながら、必要に応じて Azure AD の使用によるメリットも活かして組織の能力を高めることができます。

組織で Azure AD を採用することにした場合は、このページに示した以下の手順を実行して、連携を設定してください。

ヒント:

Azure AD との連携では、既存ユーザーの運用環境が中断されないように、アクティブ化とロール アウトを段階的に進めることができます。

前提条件

Azure AD との連携を設定するには、以下が必要です。

• Orchestrator と Azure AD の両方の管理者権限 (Azure での管理者権限がない場合は、Azure の管理者と協力してセットアップ プロセスを完了してください)。
• Azure AD ユーザーと同じメール アドレスを使用する組織管理者の UiPath アカウント。Azure AD ユーザーは Azure での管理者権限は不要です。
• UiPath Studio および Assistant バージョン 2020.10.3 以降。
• UiPath Studio と Assistant が推奨されるデプロイを使用している。
• 以前にローカル ユーザー アカウントを使用した場合は、すべての Azure AD ユーザーのメール アドレスが Mail フィールドにあることを確認してください。メール アドレスが User Principle Name (UPN) フィールドに入力されているだけでは不十分です。Azure AD との連携では、メール アドレスが一致する場合、ディレクトリ ユーザー アカウントをローカル ユーザー アカウントにリンクします。これにより、ユーザーはローカル ユーザー アカウントでのサインインから Azure AD ディレクトリ ユーザー アカウントに移行するときに、権限を保持できます。

注:

UiPath は、Azure Active Directory との連携において OIDC プロトコルに従います。ただし、この連携では、 appid クエリ パラメーターを専用の URL で要求することによってアプリケーションのカスタム キーを使用することはできません。詳しくは、 こちらで Microsoft のアクセス トークン に関するドキュメントをご覧ください。

連携が可能になるよう 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. Orchestrator のアプリケーションの登録を作成します。詳しくは、アプリケーションの登録について Microsoft のドキュメントをご覧ください。

   登録時には [この組織ディレクトリのみに含まれるアカウント] を選択し、[リダイレクト URI] を https:////{yourDomain}/identity/signin-oidc に設定します。

   注:

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

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

   

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

   1. [リダイレクト URI] 下部の [URI の追加] を選択して、新しいエントリを追加します。

   2. [リダイレクト URI] のリストに https://{yourDomain}/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	サインインしているユーザーがアクセスできるすべてのユーザーのグループ メンバーシップを読み取ります。	組織がグループを使用してシステム内の権限を管理している場合、プラットフォームがすべてのグループをリストアップし、グループのメンバーを検出できる必要があります。 これにより、グループに割り当てられた権限の管理と適用の両方が可能になります。

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

    注:

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

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

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

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

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

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

    

Orchestrator に連携をデプロイする

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

権限: このセクションの作業を実行するには、Orchestrator の管理者である必要があります。

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

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

重要:

アカウントのリンクを正しく機能させるには、すべての Azure AD ユーザーのメール アドレスが Azure の Mail フィールドに追加されていることを確認してください。メール アドレスが User Principle Name (UPN) フィールドに入力されているだけでは不十分です。

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

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

同じジョン・ドウという名前の新しい従業員が入社した場合、同じメール アドレス [e-mail] が割り当てられます。このような場合、ジョン・ドウは組織管理者の権限も継承します。

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

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

注:

はじめる前に

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

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

1. 管理ポータルに管理者としてログインします。

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

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

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

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

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

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

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

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

9. 組織の URL (https://{yourDomain}/organizationID/) に移動し、Microsoft Entra ID のアカウントでサインインします。

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

Azure AD との連携をテストする

連携が機能していることを Orchestrator から確認するには、Azure AD アカウントで組織管理者としてサインインし、Azure AD のユーザーやグループを検索機能を持つページ (例: 管理ポータルの [グループを編集] パネル。[管理] > [アカウントとグループ] > [グループ] > [編集] でアクセスできる) で検索してみてください。

• Azure AD で作成されたユーザーやグループを検索できれば、連携が正しく機能しています。ユーザーまたはグループの種類は、アイコンによって見分けられます。
• ユーザーの検索を試して、下の図の例のようなエラーが発生した場合は、Azure での設定に何らかの問題があります。Azure の管理者に連絡して、このページの上部の「 連携が可能になるよう Azure を設定する 」の説明に従って Azure が設定されているかどうかの確認を依頼してください。
  ヒント:

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

Azure AD への移行を完了する

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

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

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

Orchestrator の既存のユーザー グループを Azure AD の新規または既存のグループにマップできます。その方法は、Azure AD でのグループの使用方法に応じていくつかあります。

• Orchestrator 内で同じロールを持つユーザーが Azure AD の同じグループに既に存在する場合、Organization Administrator は、これらのユーザーが属していた Orchestrator ユーザー グループに、これらの Azure AD グループを追加できます。これによって、それらのユーザーが確実に同じ権限とロボットの設定を持つようになります。
• それ以外の場合は、Azure の管理者が Orchestrator のグループに対応するグループを Azure AD 内に新たに作成して、Orchestrator のユーザー グループと同じユーザーを追加します。その後、Organization Administrator が新しい Azure AD グループを既存のユーザー グループに追加すると、同じユーザーが確実に同じロールを持つようになります。

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

例: Orchestrator の Administrators グループに、ユーザー Anna、Tom、John が属しているとします。これらのユーザーは admins という名前の Azure AD のグループにも属しています。Organization Administrator は、Azure の admins グループを Orchestrator の Administrators グループに追加できます。そうすれば、Anna、Tom、John は、Azure AD グループ admins のメンバーとして Orchestrator で Administrators グループのロールのすべての機能を利用できるようになります。

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

Azure AD のグループ割り当ての変更は、ユーザーが Azure AD のアカウントでログインしたときに Orchestrator に適用されます。既にログイン済みだった場合は、1 時間以内に適用されます。

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

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

• 組織固有の URL に移動します。その場合、サインインの種類はあらかじめ選択されています。
• メイン ログイン ページで [Enterprise SSO] を選択します。
  注:

  必ず Orchestrator 用の組織固有の URL をすべてのユーザーに提供してください。Orchestrator でこの情報が表示されるのは Organization Administrator だけです。

移行されたユーザーは、直接割り当てられた権限、または Azure AD のグループから継承された権限、あるいはその両方を使用できます。

ユーザー向けに Studio と Assistant を設定する: これらの製品を Azure AD のアカウントに接続できるように設定するには、以下の手順を実行します。

1. Assistant で [設定] を開き、[Orchestrator への接続] タブを選択します。
2. [サインアウト] を選択します。
3. 接続の種類として [サービス URL] を選択します。
4. [サービス URL] フィールドに組織固有の URL を入力します。例: https://orchestrator.mydomain.local/
5. Azure AD のアカウントに再度サインインします。

重要:

グループに基づく権限で動作させるには、オートメーションをフォルダーで設定し、UiPath Assistant または Studio への接続に サービス URL を使用してください。

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

必須ではありませんが、Orchestrator と Azure AD 間の完全な連携がもたらすコア コンプライアンスと効率のメリットを最大限に活かすために、ローカル アカウントの使用は中止することをお勧めします。

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

重要:

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

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

高度な機能

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

Orchestrator へのアクセスを制限する

Azure AD との連携は Azure テナントのレベルで実行されるため、既定ではすべての Azure AD ユーザーが Orchestrator 組織にアクセスできます。Azure AD ユーザーが Orchestrator に初めてサインインすると、そのユーザーは Orchestrator グループ Everyone に自動的に属し、ユーザーの組織レベルのロールが付与されます。

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

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

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

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

上記の「 権限とロボット用にグループを設定する」セクションで説明したように、Azure AD にグループを作成して、Azure AD から直接簡単に Orchestrator のオンボードを行えるようにした場合、これらのグループに対する Privileged Identity Management (PIM) の高度なセキュリティ オプションを使用して、Orchestrator グループへのアクセス要求を制御できます。