订阅

UiPath Orchestrator

UiPath Orchestrator 指南

帐户类型

The UiPath Identity Server stores local accounts and the roles assigned to them, but also validates any directory accounts used in Orchestrator.

本地帐户


An account that was created and can be managed from Orchestrator, through the Management portal, is considered to be local to the UiPath ecosystem.
对于本地帐户,名称和电子邮件地址等所有帐户属性都存储在 Identity Server 中。

目录帐户


User accounts that originate from a directory outside of the UiPath ecosystem (for example, from Azure Active Directory) are directory users. These accounts can access Orchestrator and can receive roles if you integrate with the directory.
对于目录用户,在 Identity Server 和 Orchestrator 的 UiPath 生态系统中仅管理角色分配和特定于 Orchestrator 的设置。外部目录管理员管理特定于帐户的属性(名称、电子邮件、目录组成员身份)。

目录用户有两种方法可以访问 Orchestrator:

  1. 管理员在 Orchestrator 中为其目录帐户分配角色 - 我们将此称为单独添加的帐户。
  2. 管理员将目录帐户添加到组中,并且用户使用其目录帐户登录
  3. Orchestrator 管理员将目录组添加到本地组,然后目录管理员将用户帐户添加到目录组 - 我们将此称为自动配置的帐户。

无论其类型如何,目录帐户始终从其所属的组继承角色(如果它们存在于 Orchestrator 中)。

本地组


本地组是源自 Identity Server 的实体,代表用户和机器人帐户的集合。您可以将角色和许可证分配给组,而不是将其分配给单个用户。分配给组的任何内容都会自动分配给所有组成员。

目录组


通过从 Orchestrator 实例中的链接目录引用组而创建的实体。该组的所有成员都是 Orchestrator 的潜在用户。分配给组的所有角色都由属于该组的用户继承、自动配置或单独添加。

  • A user who belongs to multiple groups inherits roles from all of them.
  • A user who belongs to multiple groups, and has also been granted roles explicitly, has the union of all the roles inherited and explicitly assigned.

Using directory groups enables automatic access with the group permissions, based on users being added or removed from the directory group (when switching departments, for example) with no need to manage user permissions individually.

目录组 继承的权限 显式权限

Added group X with X set of access rights and group Y with Y set of access rights.

John Smith 同时属于组 X 和 Y。他登录到 Orchestrator。他的用户已自动配置有以下权限:X 和 Y。

除了集 X 和 Y 外,John 还被显式授予了集 Z。John 现在拥有以下权限:X、Y 和 Z。

如果删除组 X 和 Y,则 John 仅拥有访问权限集 Z。

 

  • 如果您属于已添加到 Orchestrator 的组(步骤 1 - 行为部分),则不需要显式的用户条目即可登录 Orchestrator。
  • Inherited access rights are dependent on the associated Directory Group. If the directory is deleted, so are inherited access-rights.
  • Explicitly-set access rights are independent of the Directory Group. They persist between sessions, regardless of the group's state.

机器人


机器人帐户

当您需要运行不属于任何特定用户的后台无人值守流程时,机器人帐户非常有用。这些 RPA 特定帐户等同于服务帐户。与 Windows 服务在 OAuth 模型中以应用程序身份运行的帐户类似,它们是用于运行无人值守流程的非用户身份。

处理机器人帐户

在权限方面,机器人帐户的行为类似于用户帐户。在 UiPath Orchestrator 中,您可以使用与其他任何帐户相同的方式添加机器人帐户并为其配置权限。
与用户帐户相比,唯一的区别是:

  • 机器人帐户不允许进行任何与交互相关的流程配置
  • 无需使用电子邮件地址即可创建机器人帐户。

您可以通过与使用用户帐户大致相同的方式来查找和使用机器人帐户:

  • 组织管理员可以通过“管理员” > “帐户和组”页面创建和管理机器人帐户 - 但不能从“用户”选项卡,而是从专用的“机器人帐户”选项卡。
    机器人帐户也可以包含在组中,也可以作为组的一部分进行管理。
  • 在 Orchestrator 中分配角色时,搜索帐户会显示用户、组以及机器人帐户以供选择。

机器人实体

For classic folders, when you manually deploy a robot to Orchestrator, a robot robotrobot entity is automatically created, viewable on the Robots tab.
Robot users have the Robot role assigned to them by default.

Service account


A service account is a non-human account used to provide a security context for running workloads which don't involve the existence of a human account, such as server-to-server authentications. In these cases, Orchestrator assumes the identity of the service account.

Only one service account is created per Orchestrator instance — it is not visible in the user interface, and can only be identified in database tables.
There is no authentication information attached to this type of account, and, as such, it cannot log in interactively via browsers or cookies.

We recommend not to disable or delete the service account, as this will have a direct impact on running workloads.

约一个月前更新


帐户类型


建议的编辑仅限用于 API 参考页面

您只能建议对 Markdown 正文内容进行编辑,而不能建议对 API 规范进行编辑。