- 基本情報
- ベスト プラクティス
- テナント
- リソース カタログ サービス
- フォルダー コンテキスト
- 自動化
- プロセス
- ジョブ
- トリガー
- ログ
- 監視
- キュー
- アセット
- ストレージ バケット
- Test Suite - Orchestrator
- ホストの管理
- Identity Server
- 認証
- 組織管理者
- その他の構成
- Integrations
- トラブルシューティング
アカウントとグループ
[アカウントおよびグループ] ページでは、組織のローカル ユーザー アカウント、ロボット アカウント、およびローカル グループを定義できます。
アクセス権のレベルやユーザーが実行できる操作は、次の 2 つの要素を使用して制御できます。
- アカウント - ユーザーの ID を確立し、UiPath® アプリケーションへのログインに使用されます。
- ロール - UiPath エコシステム内で特定の権限を付与するために、アカウントに割り当てられます。
アカウントは Orchestrator で作成または管理されません。Orchestrator では、ロールとその割り当てのみを管理できます。
アカウントとは、割り当てられたアクセス権に基づいて Orchestrator の表示と制御が許可される、アクセス権限に応じた能力を持つ UiPath Platform のエンティティです。
アカウントの管理は以下のように行われます。
-
以下の場所から、ローカル (ローカル アカウント) で作成・管理できます。
- 外部ディレクトリ (ディレクトリ アカウントとディレクトリ グループ) で作成および管理できます。ディレクトリ連携の仕組みをよりよく理解するには、以下の「Active Directory との連携」をご覧ください。
アカウントは組織レベルの管理ポータルで追加して、対応する組織内でのみ使用できます。
正常に追加されたアカウントに Orchestrator へのアクセス権を付与するには、次の 2 つの方法があります。1 つはアカウントをグループに追加してグループのロールを継承させる方法、もう 1 つはサービス レベルでアカウントごとにロールを割り当てる方法です。2 つの方法を併用することで、組織内のアカウントに付与するアクセス権をきめ細かく制御できます。
Active Directory (AD) をOrchestrator で参照すると、そのメンバーは潜在的な Orchestrator ユーザーとなります。ディレクトリ アカウントのアクセス レベルは、Orchestrator 内で、グループ レベル (ディレクトリ グループ) またはユーザー レベル (ディレクトリ ユーザー) のいずれかで設定されます。
以下と連携できます。
- Azure Active Directory (スタンドアロンの Orchestrator)
-
Azure Active Directory (スタンドアロンの Orchestrator)
注: Active Directory の連携機能を Attended ロボットの自動プロビジョニングや階層フォルダーの機能と共に使用することで、大規模なデプロイを容易に設定できます。詳しくは、「大規模なデプロイを管理する」をご覧ください。
前提条件
WindowsAuth.Domain
パラメーターに、有効なドメインが指定されていること。ユーザー/グループを追加するときに、WindowsAuth.Domain
パラメーターで指定されているドメインと双方向の信頼関係にあるフォレストのすべてのドメインとサブドメインが使用可能であること。- Orchestrator がインストールされているマシンが、
WindowsAuth.Domain
パラメーターで設定されているドメインに参加していること。デバイスがドメインに参加しているかどうかを確認するには、コマンド プロンプトからdsregcmd /status
を実行して、[デバイスのステート] セクションに移動します。 - Orchestrator のアプリケーション プールを実行する ID は、Windows 認証アクセス (WAA) グループに属している必要があります。
動作
- ディレクトリ グループを追加すると、必要なアクセス権を設定できるユーザー グループ エンティティが Orchestrator 内に作成されます。この Orchestrator のエントリは、Active Directory のグループへの参照として機能します。
- ログインすると、Orchestrator はグループ メンバーシップを確認します。確認が済むと、ユーザー アカウントが自動的にプロビジョニングされ、グループから継承されたアクセス権が関連付けられます。継承された権限は、ユーザー セッションの間だけ保持されます。
- 自動プロビジョニングは、最初のログイン時に行われます。自動プロビジョニングされたユーザー アカウントは、監査のためにそのエントリが必要になる可能性があるため、ログアウト時に削除されません。
-
アカウントのグループ メンバーシップは、Orchestrator によってログイン時に、またはアクティブなセッションでは 1 時間に 1 度確認されます。アカウントのグループ メンバーシップが変更された場合、アカウントに対しする変更は次回のアカウントのログイン時に適用されますが、アカウントが現在ログイン中である場合は、1 時間以内に変更が適用されます。
グループ メンバーシップを確認する期間は既定では 1 時間ですが、IdentityServer.GroupMembershipCacheExpireHours パラメーターの値を設定して変更できます。
- Active Directory のグループは Orchestrator と同期しますが、Orchestrator に加えた変更は、Active Directory のユーザー構成には影響しません。
- (グループ メンバーシップから) 継承したアクセス権を持つ Active Directory ユーザーは、ローカル ユーザーと同じように、つまりアカウントに割り当てられたロールに完全に依存して機能するようには定義できません。
- アクセス権がグループ メンバーシップの変更に関係なくセッション間で保持されるよう設定する唯一の方法は、グループを使用してロールを割り当てるのではなく、Orchestrator のユーザー アカウントにロールを直接割り当てることです。
既知の問題
- ネットワークや設定の諸問題により、[ドメイン名] のドロップダウン リストに表示されるドメインの一部にアクセスできない可能性があります。
- Active Directory のユーザー/グループ名を変更しても、その変更が Orchestrator に反映されません。
- 双方向に信頼関係にあるドメインを新たに追加すると、ドメインのリストを更新するのに最大 1 時間ほどかかることがあります。
GetOrganizationUnits(Id)
およびGetRoles(Id)
要求を送信しても、自動プロビジョニングされたユーザーに明示的に設定されたフォルダーおよびロールしか返されません。グループの設定を継承したフォルダーやロールを取得するには、/api/DirectoryService/GetDirectoryPermissions?userId={userId}
エンドポイントを使用してください。- ユーザー インターフェイスも同様です。[ユーザー] ページには、明示的に設定されているフォルダーとロールのみが表示されます。一方、継承されたフォルダーとロールは、新しい専用の [ユーザーの権限] ウィンドウ ([ユーザー] > [その他のアクション] > [権限を確認]) に表示されます。
- 既定では、ユーザーはアラートのサブスクリプションの設定を親グループから継承せず、アラートを受信しません。ユーザーがアラートにアクセスできるようにするには、アラートへの権限を明示的にユーザーに付与する必要があります。
- ディレクトリ グループを削除した際、関連付けられたディレクトリ ユーザーがフォルダーから割り当て解除されたとしても、そのユーザーのライセンスは削除されません。ライセンスをリリースするにはロボット トレイを閉じてください。
- ブラウザーによっては、Active Directory 資格情報を使用して Orchestrator にログインする際に必要なのはユーザー名のみで、ドメインを指定する必要がありません。このため、domain\username の構文が機能しない場合はユーザー名のみを入力してみてください。
監査の考慮事項
- ユーザー メンバーシップ: ユーザー [ユーザー名] は、次のディレクトリ グループ [ユーザーが現在のセッションでアクセス権を継承するディレクトリ グループ] に割り当てられました。
- 自動プロビジョニング: ユーザー [ユーザー名] は、次のディレクトリ グループ [ユーザーが現在のセッションでアクセス権を継承したディレクトリ グループ] から自動的にプロビジョニングされました。
グループ
グループを使用すると同じロールや設定を複数のユーザーに適用できるため、一度に複数のユーザーを管理できます。
ユーザーのメンバーシップは、[管理] > [アカウントとグループ] から設定します。
ユーザー グループを使用するとグループ権限による自動アクセス制御が可能になります。ユーザー権限はグループに対するユーザーの追加または削除に基づいて設定され、個別に管理する必要がありません。
既定のローカル グループは、Administrators、Automation Users、Automation Developers、Citizen Developers、Automation Express、Everyone の 6 つです。すべてのグループには、作成する新規サービスごとに、既定の権限セットが付属しています。そのまま使用できる、この付属のロールは、Orchestrator のサービスごとに後ほどカスタマイズできます。
UiPath が提供する 4 つの既定グループよりも多くのグループが必要な場合は、カスタム ローカル グループを作成できます。既定のローカル グループと異なり、カスタム グループは Orchestrator 内で手動で追加する必要があります。ユーザーが持つグループ メンバーシップとそれに対応する Orchestrator 内のロールが正しくマッピングされるようにするためです。
グループのロールは、自動プロビジョニングされたユーザーまたは手動で追加されたユーザーを問わず、そのグループに属するすべてのユーザーに渡されます。これらのロールは、アカウントごとにのみ設定できる「直接割り当てられたロール」とは対照的に「継承されたロール」と呼ばれます。
- 複数のグループに属するユーザーは、それらすべてのグループからアクセス権を継承します。
- 複数のグループに属し、ロールを直接的にも付与されているユーザーは、グループから継承されたロールと直接割り当てられたロールの和集合を所持します。
- Orchestrator に追加済みのグループに属しているユーザーは、Orchestrator にログインするための明示的なユーザー アカウントを必要としません。
- 継承されるロールは、関連付けられたユーザー グループに依存します。グループがサービスから削除されると、アカウントの継承されたロールも削除されます。
- 直接割り当てられたロールは、アカウントが存在するグループの影響を受けません。これらのロールは、グループのステートに関係なく保持されます。
例
たとえば、ジョン・スミスさんを組織の Automation Users と Administrators ユーザー グループに追加したとしましょう。
- Automation User グループは Finance Orchestrator サービス内に存在します。
- Administrator グループは HR Orchestrator サービス内に存在します。
- ジョンのアカウントには、両方のサービスで直接的にもロールが割り当てられています。
ジョンには各サービスの継承した権限と明示的権限の和集合が与えられます。
サービス/ロール |
ユーザー グループ |
継承されたロール |
明示的なロール |
全般 |
---|---|---|---|---|
Finance テナント |
Automation User | |||
テナント レベルのロール |
|
|
|
|
フォルダー レベルのロール |
|
|
|
|
HR テナント |
Administrators | |||
テナント レベルのロール |
|
|
| |
フォルダー レベルのロール |
|
|
|
|
ユーザー (User)
Orchestrator へのユーザーの追加に使用されるメカニズムによって、ユーザーは 2 つのカテゴリに分類できます。
手動で追加されたユーザー
Orchestrator に手動で追加され、テナント レベルまたはフォルダー レベルのいずれかで明示的に権限を付与されたユーザーです。手動で追加されたユーザー アカウントが、Orchestrator サービスに追加されたグループに属している場合、アカウントはそのグループのアクセス権も継承します。
自動でプロビジョニングされたユーザー
ローカル グループに追加され、Orchestrator にログインするユーザーです。これらのユーザーは、グループから継承した権限に基づいて Orchestrator にアクセスできます。Orchestrator に初めてログインした時に自動的にプロビジョニングされます。
特定ユーザーに対する [その他のアクション] > [権限を確認] > [ユーザー権限] ウィンドウでは、そのユーザーのすべての権限セット (継承したものも含む) を確認できます。
手動で追加されたユーザー | 自動プロビジョニングされたユーザー | |
---|---|---|
アクセス権を継承する |
はい |
はい |
明示的なアクセス権を持つことができる |
はい |
はい |
Cloud Portal がユーザー情報の一元的なハブである |
はい |
はい |
SSO を使用できる |
はい |
はい |
Robot
ロボットを Orchestrator に手動でデプロイすると、ロボット ユーザーが自動的に作成されます。ロボット ユーザーには、既定で Robot ロールが割り当てられます。このロールでは、複数のページへのアクセス権がロボットに付与されるため、ロボットはさまざまなアクションを実行できます。
アカウント、グループ、ロールを管理するページでは、アカウントの種類やグループの種類を認識しやすくするために、それぞれの種類に対する固有のアイコンが表示されます。
アカウントのアイコン
- UiPath ユーザー アカウント: UiPath アカウントに関連付けられ、基本認証を使用してサインインするユーザー アカウントです。
- SSO ユーザー アカウント: SSO を使用してサインインする、UiPath アカウントに関連付けられたユーザー アカウントです。UiPath のユーザー アカウントとディレクトリ アカウントの両方を所有するユーザー アカウントにも、このアイコンが表示されます。
- ディレクトリ ユーザー アカウント: ディレクトリから作成され、Enterprise SSO を使用してサインインするアカウントです。
- ロボット アカウント
グループのアイコン
- ローカル グループ (または、単にグループ): ホスト管理者によって作成されたグループ。
- ディレクトリ グループ: 関連付けられたディレクトリ内で作成されたグループです。
Orchestrator では、ロールと権限に基づくアクセス管理メカニズムを使用します。ロールとは権限の集合です。つまり、Orchestrator の特定のエンティティを使用するために必要な複数の権限がロールに割り当てられます。
ロールと権限、ならびにユーザーとロールの組み合わせにより、Orchestrator に対して一定レベルのアクセスを許可できます。ユーザーは、1 つまたは複数のロールによって、特定の操作を実行するために必要な権限を得られます。権限はユーザーに直接割り当てられるのではなく、ロールを通じてのみ取得できるため、アクセス権限の管理では、ユーザーに適切なロールを割り当てるという作業が伴います。
詳しくは、こちらをご覧ください。
[ユーザー] ページや [ロール] ページでさまざまな操作を実行するには、関連する権限を付与されている必要があります。
- ユーザー - 表示 - [ユーザー] ページと [プロファイル] ページを表示できます。
- ユーザー - 編集 - [プロファイル] ページでユーザーの詳細や設定を編集したり、[ユーザー] ページでユーザーをアクティブ化/非アクティブ化したりできます。
- ユーザー - 表示 と ロール - 表示 - [ユーザーの権限] ウィンドウでユーザーの権限を表示できます。
- ユーザー - 編集 と ロール - 表示 - [アクセス権を管理] > [ロールを割り当て] ページでロールの割り当てを編集できます。
- ユーザー - 作成 と ロール - 表示 - ユーザーを作成できます。
- ユーザー - 表示 と ロール - 編集 - [アクセス権を管理] > [ロール] ページの [ユーザーを管理] ウィンドウでロールを管理できます。
- ユーザー - 削除 - Orchestrator からユーザーを削除できます。
Orchestrator の管理ポータルで作成され、管理できるアカウントは、UiPath エコシステムではローカルと見なされます。
ローカル アカウントについては、名前やメール アドレスなどのアカウント属性が、すべて Identity Server に保存されます。
UiPath エコシステム外のディレクトリ (Azure Active Directory など) で作成されたユーザー アカウントはディレクトリ ユーザーです。これらのアカウントは、ディレクトリと連携すると Orchestrator にアクセスしたり、ロールを付与されたりすることが可能になります。
ディレクトリ ユーザーについては、ロールの割り当てと Orchestrator 固有の設定のみを UiPath エコシステム (Identity Server と Orchestrator) 内で行い、アカウント固有の属性 (名前、メール、ディレクトリ グループのメンバーシップ) は外部ディレクトリの管理者が管理します。
ディレクトリ ユーザーが Orchestrator にアクセスするには、以下の 2 つの方法があります。
- 管理者が Orchestrator でディレクトリ アカウントにロールを割り当てる - これを「個別に追加されたアカウント」と呼びます。
- 管理者がグループにディレクトリ アカウントを追加して、ユーザーがディレクトリ アカウントでログインする。
- Orchestrator 管理者がローカル グループにディレクトリ グループを追加してから、ディレクトリ管理者がディレクトリ グループにユーザー アカウントを追加する - これを「自動プロビジョニングされたアカウント」と呼びます。
ディレクトリ アカウントは、その種類にかかわらず、常にそれらのアカウントが属するグループからロールを継承します (グループが Orchestrator 内に存在する場合)。
ローカル グループはIdentity Server に由来するエンティティで、ユーザー アカウントとロボット アカウントのコレクションを表します。ロールやライセンスを個々のユーザーに割り当てるのではなく、グループに割り当てることができます。グループに割り当てられたものは、すべてのグループ メンバーに自動的に割り当てられます。
Orchestrator インスタンス内で、リンク先ディレクトリのグループを参照することで作成されるエンティティです。グループのすべてのメンバーは、Orchestrator の潜在的なユーザーです。グループに属するユーザーは、そのグループに割り当てられたすべてのロールを、自動プロビジョニングまたは個別の追加のいずれかにより継承します。
- 複数のグループに属するユーザーは、それらすべてのグループからロールを継承します。
- 複数のグループに属し、ロールも明示的に付与されているユーザーは、継承されたロールと明示的に割り当てられたロールをすべて合わせ持ちます。
ディレクトリ グループを使用すると、ディレクトリ グループで追加または削除されるユーザーに基づいた、グループ権限での自動アクセスが可能となり (部門の切り換えなど)、ユーザー権限を個別に管理する必要はなくなります。
例
ディレクトリ グループ |
継承された権利 |
明示的な権利 |
---|---|---|
アクセス権セット X を持つグループ X とアクセス権セット Y を持つグループ Y が追加されています。 |
ジョン・スミスはグループ X と Y の両方に属します。彼は Orchestrator にログインします。彼のユーザーは、X、Y の権限で自動プロビジョニングされます。 |
ジョンには、セット X とセット Y のほか、セット Z も明示的に付与されます。ジョンには現在、X、Y、Z の権限があります。 グループ X と Y を削除すると、ジョンは Z のままになります。 |
- Orchestrator に追加されたグループに属しているユーザーは、Orchestrator にログインするための明示的なユーザー エントリを必要としません。
- 継承されたアクセス権は、関連するディレクトリ グループに依存しています。ディレクトリが削除されると、継承されたアクセス権も削除されます。
- 明示的に設定されたアクセス権は、ディレクトリ グループから独立しています。グループのステートに関係なく、セッション間で維持されます。
ロボット アカウント
ロボット アカウントは、特定のユーザーの責任ではないバックオフィスの無人プロセスを実行する必要があるときに役立ちます。これらは、サービス アカウントに相当する RPA 固有のアカウントです。Windows サービスが OAuth モデルのアプリケーション ID として実行するアカウントと同様に、無人プロセスの実行に使用される、非ユーザー アイデンティティです。
ロボット アカウントを操作する
ロボット アカウントは、権限という観点ではユーザー アカウントと同じように機能します。UiPath Orchestrator では、他のアカウントの場合と同じようにロボット アカウントを追加したり、これらのアカウントの権限を設定したりできます。
ユーザー アカウントとの違いは、以下の点のみです。
- ロボット アカウントでは、対話型プロセス設定は許可されていません。
- ロボット アカウントの作成にメール アドレスは不要です。
ユーザー アカウントとおおむね同様に、ロボット アカウントを検索し操作できます。
-
組織管理者は、[管理] > [アカウントとグループ] ページでロボット アカウントを作成して管理することができます (ただし、[ユーザー] タブではなく、専用の [ロボット アカウント] タブから)。
ロボット アカウントはグループに含めて、グループの一部として管理することもできます。
- Orchestrator でロールを割り当てるときに、アカウントを検索すると、選択できるユーザー、グループ、およびロボット アカウントが表示されます。
サービス アカウントは人間以外のアカウントであり、人間のアカウントが存在する必要がないワークロード (サーバー間認証など) を実行するためのセキュリティ コンテキストを提供する場合に使用します。このような場合、Orchestrator がサービス アカウントの ID を引き受けます。
1 つの Orchestrator インスタンスに対して作成されるサービス アカウントは 1 つのみです。このサービス アカウントはユーザー インターフェイスには表示されず、データベース テーブル内でのみ確認できます。
この種類のアカウントには認証情報が付随しないため、ブラウザーや Cookie を使用して対話型でログインすることはできません。
ワークロードの実行に直接の影響があるため、サービス アカウントを無効化または削除しないことをお勧めします。