Orchestrator
2023.10
false
Banner background image
Orchestrator User Guide
Last updated Feb 15, 2024

Account Types

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

Local Account

An account that was created and can be managed from Orchestrator, through the Management portal, is considered to be local to the UiPath ecosystem.

For local accounts, all account attributes like name and email address are stored in Identity Server.

Directory Account

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.

For directory users, only role assignments and Orchestrator-specific settings are managed within the UiPath ecosystem, in Identity Server and Orchestrator. The external directory admin manages account-specific attributes (name, email, directory group membership).

There are two ways for a directory user to gain access to Orchestrator:

  1. An administrator assigns roles to their directory account in Orchestrator - we refer to this as an individually-added account.
  2. An administrator adds the directory account to a group and the user logs in with their directory account
  3. An Orchestrator administrator adds a directory group to a local group, and then a directory administrator adds the user account to the directory group - we refer to this as an auto-provisioned account.

Regardless of their type, directory account always inherit roles from the groups to which they belong, if they exist in Orchestrator.

Local Group

Local groups are entities originating in Identity Server which represent a collection of user and robot accounts. You can assign roles and licenses to groups as opposed to assigning them to individual users. Anything assigned to the group is automatically assigned to all group members.

Directory Group

An entity created by referencing a group from a linked directory in your Orchestrator instance. All members of the group are potential users of Orchestrator. All roles assigned to a group are inherited by the users that belong to that group, auto-provisioned or individually-added.

  • 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.

Example

Directory Groups

Inherited Rights

Explicit Rights

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

John Smith belongs to both Group X and Y. He logs in to Orchestrator. His user is auto-provisioned with the following rights: X, Y.

In addition to the X and Y sets, John is also granted the Z set explicitly. John now has the following rights: X, Y, Z.

Deleting groups X and Y leaves John with Z.

  • You don't need an explicit user entry to log in to Orchestrator, if you belong to a group that has been added to 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.

Robot

Robot Accounts

Robot accounts are helpful for when you need to run back-office unattended processes that should not be the responsibility of any particular user. These are our RPA-specific equivalent of service accounts. Similar to the accounts that Windows services run as application identities in the OAuth model, they are a non-user identity to be used to run unattended processes.

Working with robot accounts

Robot accounts behave like user accounts in terms of permissions. In UiPath Orchestrator, you can add robot accounts and configure permissions for them in the same way as for any other account.

The only differences compared to user accounts are:

  • robot accounts are not allowed any interactive-related process configuration
  • no email address is required to create a robot account.

You can find and work with robot accounts in broadly the same way as you work with user accounts:

  • Organization administrators can create and manage robot accounts from the Admin > Accounts & Groups page - except not from the Users tab, but from the dedicated Robot accounts tab.

    Robot accounts can also be included in groups and managed as part of the group.

  • When assigning roles in Orchestrator, searching for accounts shows users, groups, and also robot accounts for selection.

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.

  • Local Account
  • Directory Account
  • Local Group
  • Directory Group
  • Robot
  • Robot Accounts
  • Service Account

Was this page helpful?

Get The Help You Need
Learning RPA - Automation Courses
UiPath Community Forum
Uipath Logo White
Trust and Security
© 2005-2024 UiPath. All rights reserved.