orchestrator
2023.10
true
Orchestrator 用户指南
Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Last updated 2024年10月9日

帐户和组

在“帐户和组”页面上,您可以为组织定义本地用户帐户、机器人帐户和本地组。

使用两个元素控制用户可以执行的访问级别和操作:

  • 帐户,用于建立用户身份并用于登录到 UiPath™ 应用程序。
  • 角色,这些角色被分配给帐户,以便在 UiPath 生态系统中向其授予某些权限。

帐户不在 Orchestrator 中创建或管理,仅在角色及其分配中创建或管理。

关于帐户

帐户是具有依赖访问权限的功能的 UiPath 平台实体,其对 Orchestrator 的查看和控制取决于所分配的访问权限。

帐户可以是:

  • 从以下位置在本地创建和管理(本地帐户):

  • 在外部目录中创建和管理(目录帐户和目录组)。请参阅下方的“AD 集成”一节,以便更好地了解目录集成。

您可以从组织级别的管理门户添加帐户,并且帐户仅在相应的组织内可用。

成功添加帐户后,有两种方法可以向其授予 Orchestrator 的访问权限:将帐户添加到组中,以便继承组的角色,或在服务级别为每个帐户分配角色。您可以使用这两种方法对帐户在组织中的访问权限进行精细控制。

注意:机器人管理在用户级别执行。有关详细信息,请参阅管理帐户

AD 集成

Orchestrator 中引用的活动目录 (AD) 使其成员成为潜在的 Orchestrator 用户。在 Orchestrator 中,可以在组级别(目录组)或用户级别(目录用户)配置目录帐户的访问权限级别。

您可以集成:

先决条件

  • WindowsAuth.Domain 参数中填充有效的域。添加目录用户/组时,与 WindowsAuth.Domain 参数中指定的域双向信任的林中的所有域和子域均可用。
  • 将安装了 Orchestrator 的计算机加入到 WindowsAuth.Domain 参数中设置的域中。要查看设备是否已加入域,请从命令提示符中运行 dsregcmd /status,然后导航至“设备状态”部分。
  • 运行 Orchestrator 应用程序池的身份必须属于 Windows 授权访问组 (WAA)。

行为

  • 添加目录组会在 Orchestrator 中创建一个用户组实体,您可以根据需要为其配置访问权限。Orchestrator 中的此条目用作 AD 中找到的组的参考。
  • 登录时,Orchestrator 会检查您的组成员身份。如果确认,它会自动配置您的用户帐户,然后将其与从组继承的访问权限相关联。继承的权限仅在用户会话期间保留。
  • 系统会在您首次登录时进行自动配置。 注销时不会删除自动配置的用户帐户,因为您可能需要该条目进行审核。
  • 登录时,Orchestrator 会检查帐户的组成员身份,或在活动会话期间每小时检查一次。如果帐户的组成员身份发生更改,则该帐户的更改将在下次登录时应用,如果当前已登录,则在一小时内应用更改。

    可以通过设置 IdentityServer.GroupMembershipCacheExpireHours的值来更改检查组成员身份的一小时间隔。

  • AD 中的组会与 Orchestrator 同步,但在 Orchestrator 中所做的更改不会影响 AD 中的用户配置。
  • 无法确定继承的访问权限(从组成员身份)的 AD 用户的行为类似于本地用户,这意味着它们仅依赖于分配给用户帐户的角色。
  • 无论组成员身份如何变化,配置在会话之间持续存在的访问权限的唯一方法是直接将角色分配给 Orchestrator 中的用户帐户,而不是使用组来分配角色。

已知问题

  • 由于各种网络或配置问题,可能并非“域名”下拉列表中显示的所有域都可访问。
  • 在 AD 中对用户名或组名所做的更改不会传播到 Orchestrator。
  • 使用新添加的双向信任域更新域列表最多可能需要一个小时。
  • GetOrganizationUnits(Id)GetRoles(Id) 请求仅返回为自动配置的用户显式设置的文件夹和角色。从组配置继承的文件夹和角色可通过 /api/DirectoryService/GetDirectoryPermissions?userId={userId} 端点检索。
  • 用户界面也是如此,用户页面上仅显示显式设置的文件夹和角色。相反,继承的文件夹和角色具有新的专用位置,即用户权限窗口(用户>更多操作>查看权限)。
  • 默认情况下,用户不会从父组继承警示订阅设置,也不会接收任何警示。要访问警示,您需要显式授予用户相应的权限。
  • 删除目录组并不会删除相关目录用户的许可证,即使删除组后取消了从任何文件夹中分配用户。释放许可证的唯一方法是关闭机器人托盘。
  • 在某些浏览器上,使用您的 AD 凭据登录 Orchestrator 时仅需要用户名。无需同时指定域。因此,如果 domain\username 语法不起作用,请尝试仅填写用户名。

审核注意事项

  • 用户成员身份:用户 [用户名] 已分配到以下目录组 [用户在当前会话中继承访问权限的目录组]。
  • 自动配置:从以下目录组 [用户在当前会话中继承访问权限的目录组] 自动配置用户 [用户名]。

用户类型

通过组,您可以通过组对多个用户应用相同的角色和配置,同时管理多个用户。

用户的成员身份可从“管理”>“帐户和组”进行设置。

用户组基于组中添加或删除的用户而启用具有组权限的自动访问,而无需单独管理用户权限。

有 6 个默认组:AdministratorsAutomation UsersAutomation DevelopersCitizen DevelopersAutomation ExpressEveryone。在您创建的每个新服务中,所有组都具有默认的权限集。以后可以为每个 Orchestrator 服务自定义现成的角色。

如果您需要的组超过 UiPath 提供的 4 个默认组,则可以创建自定义本地组。与默认本地组不同,自定义组需要在 Orchestrator 中手动添加,以确保用户的组成员身份与 Orchestrator 中的相应角色之间的正确映射。

组的角色将传递给属于该组的任何用户,无论是自动配置的还是手动添加的。我们将它们称为“继承的角色”,而不是“直接分配的角色”,后者只能针对每个帐户设置。

备注:
  • 属于多个组的用户将从所有这些组继承访问权限。
  • 属于多个组并已直接分配角色的用户具有从组继承并直接分配的所有角色的并集。
  • 如果您属于已添加到 Orchestrator 的组,则不需要显式用户帐户即可登录 Orchestrator。
  • 继承的角色取决于关联的用户组。如果组已从服务中删除,则该帐户的继承角色也将删除。
  • 直接分配的角色不受帐户所在组的影响。无论组状态如何,它们都会持续存在。
示例

假设我将 John Smith 添加到了我的 Automation Cloud 组织中的“Automation Users”和“Administrators”用户组。

  • Automation User 组存在于 Finance Orchestrator 服务中
  • Administrator 组存在于 HR Orchestrator 服务中
  • 在这两个服务中,John 的帐户也被直接分配了角色。

John 拥有每个服务的继承权限和显式权限的并集:

服务/角色

用户组

继承的角色

显式角色

整体

财务 租户

自动化用户

   

租户级别角色

  • Allow to be Automation User
  • Allow to be Automation User
  • Allow to be Folder Administrator
  • Allow to be Automation User
  • Allow to be Folder Administrator

文件夹级角色

  • 文件夹 A 的 Automation User
  • 文件夹 B 的 Automation User
  • 文件夹 A 的 Automation User
  • 文件夹 B 的 Automation User
  • 文件夹 A 的 Folder Administrator
  • 文件夹 A 的 Automation User
  • 文件夹 B 的 Automation User
  • 文件夹 A 的 Folder Administrator

HR 租户

管理员

   

租户级别角色

  • Allow to be Folder Administrator
  • Allow to be Folder Administrator
 
  • Allow to be Folder Administrator

文件夹级角色

  • 文件夹 D 的 Folder Administrator
  • 文件夹 E 的 Folder Administrator
  • 文件夹 D 的 Folder Administrator
  • 文件夹 E 的 Folder Administrator
  • 文件夹 F 的 Folder Administrator
  • 文件夹 D 的 Folder Administrator
  • 文件夹 E 的 Folder Administrator
  • 文件夹 F 的 Folder Administrator

用户

根据在 Orchestrator 中添加用户帐户的机制,它们可以分为两类:

手动添加的用户

已在 Orchestrator 中手动添加并已在租户级别或文件夹级别明确授予权限的用户。如果手动添加的用户帐户也属于已添加到该 Orchestrator 服务的组,则它们将继承组访问权限。

自动配置的用户

已添加到本地组并登录到 Orchestrator 的用户。他们可以基于从组继承的权限访问 Orchestrator。首次登录 Orchestrator 后,系统会自动对其进行配置。

重要提示:在“用户”页面上的“角色”列中,您可以看到为用户显式分配的角色,无论是手动添加还是自动设置的。继承的角色不会显示在此列中。

通过导航到特定用户的“更多操作”>“查看权限”>“用户权限”窗口,可以查看该用户的整个权限集(包括继承的权限)。

  手动添加的用户 自动配置的用户

继承访问权限

可以具有显式访问权限

Cloud Portal 是用户信息的中心

可以使用 SSO

机器人

当您手动将机器人部署到 Orchestrator 时,系统会自动创建机器人 用户。默认情况下,机器人用户具有机器人角色。此角色授予您的机器人访问多个页面的权限,使其能够执行各种操作。

帐户和组图标

在管理帐户、组或角色的页面上,系统会针对每种类型显示特定图标,以帮助您识别帐户类型或组类型。

帐户图标

- UiPath 用户帐户:链接到 UiPath 帐户并使用基本身份验证登录的用户帐户

- SSO 用户帐户:链接到使用 SSO 登录的 UiPath 帐户的用户帐户;也适用于同时拥有 UiPath 用户帐户和目录帐户的用户帐户

- 目录用户帐户:该帐户源自目录并使用 Enterprise SSO 登录

- 机器人帐户

组图标

- 本地组 (或简单地说, ):该组由主机管理员创建。

- 目录组:该组起源于已链接的目录。

关于角色

Orchestrator 使用基于角色和权限的访问控制机制。角色是权限的集合,这意味着将使用某些 Orchestrator 实体所需的权限分配给角色。

角色权限和用户角色关系允许对 Orchestrator 进行一定级别的访问。用户通过一个或多个角色获得执行特定操作所需的权限。由于未直接为用户分配权限,用户仅通过角色获得权限,访问权限的管理涉及为用户分配适当的角色。

有关更多信息,请参阅管理角色

用于管理用户的权限

要在“用户”和“角色”页面上执行各种操作,需要获得相应的权限:

  • 用户 - 查看 - 显示“用户”和“个人资料”页面。
  • 用户 - 编辑 - 在“配置文件”页面上编辑用户详细信息和设置,并在“用户”页面上激活/停用用户。
  • “用户 - 视图” 和“ 角色 - 视图 - 显示用户权限”。
  • 用户 - 编辑角色 - 查看 - 在“管理访问权限”>“分配角色”页面上,编辑角色分配。
  • 用户 - 创建角色 - 查看 - 创建用户。
  • 用户 - 查看角色 - 编辑 - 从“管理访问权限”>“角色”页面打开的“管理用户”窗口中管理角色。
  • 用户 - 删除 - 从 Orchestrator 中删除用户。

帐户类型

本地帐户

通过管理门户从 Orchestrator 创建并可以进行管理的帐户被视为 UiPath 生态系统的本地帐户。

对于本地帐户,名称和电子邮件地址等所有帐户属性都存储在 Identity Server 中。

目录帐户

源自 UiPath 生态系统外部目录(例如,来自 Azure Active Directory)的用户帐户是目录用户。 如果您与目录集成,这些帐户可以访问 Orchestrator 并接收角色。

对于目录用户,在 Identity Server 和 Orchestrator 的 UiPath 生态系统中仅管理角色分配和特定于 Orchestrator 的设置。外部目录管理员管理特定于帐户的属性(名称、电子邮件、目录组成员身份)。

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

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

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

本地组

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

目录组

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

  • 属于多个组的用户将从所有组继承角色。
  • 属于多个组并且还被显式授予角色的用户具有继承并显式分配的所有角色的并集。

使用目录组可根据在目录组中添加或删除的用户(例如,切换部门时)使用组权限启用自动访问,而无需单独管理用户权限。

示例

目录组

继承的权限

显式权限

添加了具有 X 组访问权限的 X 组和具有 Y 组访问权限的 Y 组。

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

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

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

  • 如果您属于已添加到 Orchestrator 的组,则不需要显式的用户条目即可登录 Orchestrator。
  • 继承的访问权限取决于关联的目录组。 如果删除了目录,则继承的访问权限也将被删除。
  • 显式设置的访问权限独立于目录组。 无论组的状态如何,它们都会在会话之间持续存在。

机器人

机器人帐户

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

处理机器人帐户

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

与用户帐户相比,唯一的区别是:

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

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

  • 组织管理员可以通过“管理员”>“帐户和组”页面创建和管理机器人帐户 - 但不能从“用户”选项卡,而是从专用的“机器人帐户”选项卡。

    机器人帐户也可以包含在组中,也可以作为组的一部分进行管理。

  • 在 Orchestrator 中分配角色时,搜索帐户会显示用户、组以及机器人帐户以供选择。

服务帐户

服务帐户是一种非人类帐户,用于为正在运行的工作负载提供安全上下文,这些工作负载不涉及存在人类帐户,例如服务器到服务器身份验证。 在这些情况下,Orchestrator 将采用服务帐户的身份。

每个 Orchestrator 实例仅创建一个服务帐户,该服务帐户在用户界面中不可见,并且只能在数据库表格中识别。

此类帐户没有附加身份验证信息,因此,它无法通过浏览器或 Cookie 以交互方式登录。

我们建议不要禁用或删除服务帐户,因为这将对正在运行的工作负载产生直接影响。

此页面有帮助吗?

获取您需要的帮助
了解 RPA - 自动化课程
UiPath Community 论坛
Uipath Logo White
信任与安全
© 2005-2024 UiPath。保留所有权利。