Subscribe

UiPath Orchestrator

The UiPath Orchestrator Guide

Managing access and automation capabilities

On the Manage Access page you can define and assign roles as well as configure the automation capabilities of your accounts. In Orchestrator, you use roles to control the level of access a user should have.
On this page we go over the notions you need to understand to effectively plan and implement your access control strategy.

The level of access and the actions that your users can perform is controlled using two elements:

  • accounts, which establish the identity of a user and are used to log in to your UiPath applications
  • roles, which are assigned to accounts in order to grant them certain permissions within the UiPath ecosystem.

Accounts are not created or managed in Orchestrator, only roles and their assignments are.

About accounts


An account is a UiPath platform entity with access-dependent capabilities whose view and control of Orchestrator rely on the assigned access rights.

Accounts can be:

  • created and managed locally (local accounts) from the:
  • created and managed in an external directory (directory accounts and directory groups). See the section AD Integration for a better understanding of directory integration.

More information:
Learn more about the types of accounts.
Learn about Orchestrator's access-control model, which relies on role assignations.

You add accounts from the organization-level Management portal and accounts are only available within the respective organization.
Once an account has been successfully added, there are two ways of granting them access-rights to Orchestrator: by adding the account to a group so that it inherits the roles of the group, or by assigning roles to each account at the service level. You can use both methods for granular control over the access an account has in your organization.

📘

: In modern folders, robot management is performed at the user level. See Managing accounts for details.

AD integration

An active directory (AD) referenced in Orchestrator makes its members potential Orchestrator users. The level of access for a directory account is configured in Orchestrator, either at the group level (directory group) or at the user level (directory user).

You can integrate with:

📘

Using an AD integration together with attended robots auto-provisioning and hierarchical folders allow for effortlessly setting up large deployments. See Managing large deployments for details.

Prerequisites

  • The WindowsAuth.Enabled parameter is set to true.
  • The WindowsAuth.Domain parameter is filled in with a valid domain. All domains and subdomains from forests 2-way trusted with the domain specified in the WindowsAuth.Domain parameter are available when adding users/groups.
  • The machine on which Orchestrator is installed is joined to the domain set in the WindowsAuth.Domain parameter. To check whether the device is joined to the domain, run the dsregcmd /status from the Command Prompt, and navigate to the Device State section.
  • The identity under which the Orchestrator application pool is running must be a part of the Windows Authorization Access group (WAA).

Behavior

  • Adding a directory group creates a user group entity in Orchestrator for which you configure access rights as desired. This entry in Orchestrator serves as a reference to the group as found in AD.
  • When logging in, Orchestrator checks your group memberships. If confirmed, it automatically provisions your user account, and then associates it to the access rights inherited from the group. Inherited rights are only kept for the duration of the user session.
  • Auto-provisioning takes place the first time you log in. An auto-provisioned user account doesn't get deleted at log out as you might need the entry for audit purposes.
  • Changes made to group membership in the directory are synced with Orchestrator at every log in, or once every hour for active user sessions. If your system administrator changes your group membership from, say, the Administrators group to the Automation Developers group while you have an active session, the changes are interrogated by Orchestrator the next time you log in or, if already logged in, within the hour.
    This value can be changed using the WindowsAuth.GroupMembershipCacheExpireHours.
  • Groups in AD sync with Orchestrator, but changes made in Orchestrator do not affect user configuration in AD.
  • AD users whose inherited access-rights (from group memberships) cannot be determined behave like local users, meaning they rely solely on roles assigned to the user account.
  • The only way for you to configure access rights which persist between sessions, regardless of how group membership changes, is to directly assign the role to the user account in Orchestrator, as opposed to using groups to assign roles.

Known issues

  • Due to various networking or configuration issues, there is a chance that not all domains displayed in the Domain Name drop-down list are accessible.
  • Changes made to user or group names in AD are not propagated to Orchestrator.
  • It can take up to an hour to update the domain list with newly added two-way trusted domains.
  • The GetOrganizationUnits(Id) and GetRoles(Id) requests only return folders and roles explicitly set for an auto-provisioned user. The ones inherited from the group configuration can be retrieved through the /api/DirectoryService/GetDirectoryPermissions?userId={userId} endpoint.
  • Same goes for the user interface, where only explicitly-set folders and roles are displayed on the Users page. In contrast, inherited ones have a new dedicated location, the User Permissions window (Users > More Actions > Check Permissions).
  • Users do not inherit alert subscription settings from the parent group, nor do they receive any alerts by default. To have access to alerts, you are required to grant the corresponding permissions to the user explicitly.
  • Removing a directory group does not remove the license of an associated directory user, even if the group removal unassigns the user from any folder. The only way to release the license is to close the Robot tray.
  • On certain browsers, logging in to Orchestrator using your AD credentials only requires your username. There is no need to also specify the domain. Hence, if the domain\username syntax does not work, try filling in the username only.

Audit considerations

  • User membership: User [username] was assigned to the following Directory Groups [Directory Groups the user inherits access rights from in the current session].
  • Auto-Provisioning: User [username] was automatically provisioned from the following Directory groups [Directory Groups the user inherits access rights from in the current session].

User types

Group

An entity that serves as a reference to the user group. A user group referenced in Orchestrator makes all group members potential Orchestrator users.
The membership of a user is set from Admin > Users & Groups.
User groups enable automatic access with the group permissions, based on users being added or removed from the group with no need to manage user permissions individually.
There are 4 default local groups: Administrators, Automation Users, Automation Developers, Everyone. All groups come with a default set of permissions in each new service you create. The out-of-the-box roles can be customized later on for each Orchestrator service.
If you need more than the 4 default groups provided by UiPath, you can create custom local groups. Unlike default local groups, custom groups need to be added manually in Orchestrator to ensure the correct mapping between the group membership of a user and the corresponding role in Orchestrator.

More about local groups.

A group's roles are passed on to any users that belong to the group, both auto-provisioned or manually-added. We refer to them as "inherited roles" as opposed to "directly-assigned roles" which can only be set per account.

📘

Remember

A user that belongs to multiple groups inherits access rights from all of them.
A user who belongs to multiple groups, and has been assigned roles directly as well, has the union of all the roles inherited from groups and directly assigned.
You don't need an explicit user account to log in to Orchestrator if you belong to a group that has been added to Orchestrator.
Inherited roles are dependent on the associated user group. If the group is deleted from the service, so are the inherited roles of that account.
Directly-assigned roles are not influenced by groups that the account is in. They persist regardless of the group state.

Example

Say I added John Smith to the Automation Users and Administrators user groups in my organization.

  • The Automation User group exists in the Finance Orchestrator service
  • The Administrator group exists in the HR Orchestrator service
  • Directly assigned roles to John's account in both services as well.

John has the union of inherited and explicit rights for each service:

Service/RolesUser GroupsInherited RolesExplicit RolesOverall
Finance Automation User
Tenant Level Roles 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
Folder Level Roles Automation User on Folder A
Automation User on Folder B
Automation User on Folder A
Automation User on Folder B
Folder Administrator on Folder A Automation User on Folder A
Automation User on Folder B
Folder Administrator on Folder A
HR Administrators
Tenant Level Roles Allow to be Folder Administrator Allow to be Folder Administrator Allow to be Folder Administrator
Folder Level Roles Folder Administrator on Folder D
Folder Administrator on Folder E
Folder Administrator on Folder D
Folder Administrator on Folder E
Folder Administrator on Folder F Folder Administrator on Folder D
Folder Administrator on Folder E
Folder Administrator on Folder F

User

According to the mechanism used for adding user accounts in Orchestrator, they can be classified into two categories:

Manually-added users

Users that have been manually added in Orchestrator and have been granted permissions explicitly either at the tenant level or at the folder level. Manually-added user accounts inherit group access rights if they belong to a group that has been added to that Orchestrator service as well.

Auto-provisioned users

Users that have been added to a local group and log in to Orchestrator. They can access Orchestrator based on the permissions inherited from the group. Once they log in to Orchestrator for the first time, they are automatically provisioned.

On the Users page, in the Roles column, you can see explicitly assigned roles for a user, be it manually added or auto-provisioned. Inherited roles are not displayed in this column.
You can check the entire permission set of a user, inherited ones included, by navigating to More Actions > Check Permissions > User Permissions window for that specific user.

Manually Added UserAuto-provisioned User
Inherits access rights
Can have explicit access rights
Cloud Portal is the central hub for user information
SSO

Robot

The Robot robotrobot user is automatically created when you manually deploy a Robot to Orchestrator. Robot users have the Robot role by default. This role grants your Robot access to multiple pages, making it able to perform various actions.

Permissions for managing users


To be able to perform various operations on the Users and Roles pages, you need to be granted the corresponding permissions:

  • Users - View - Displaying the Users and Profile pages.
  • Users - Edit - Editing user details and settings on the Profile page, and activating/deactivating users on the Users page.
  • Users - View and Roles - View - Displaying user permissions in the User Permissions window.
  • Users - Edit and Roles - View - Editing role assignments on the Manage Access > Assign Roles page.
  • Users - Create and Roles - View - Creating a user.
  • Users - View and Roles - Edit - Managing roles in the Manage Users window, opened from the Manage Access > Roles page.
  • Users - Delete - Removing a user from Orchestrator.

About roles


Orchestrator uses an access-control mechanism based on roles and permissions. Roles are collections of permissions meaning that the permissions needed to use certain Orchestrator entities are assigned to roles.

Role-permissions and user-roles relationships allow for a certain level of access to Orchestrator. A user gets the permissions required to perform particular operations through one or multiple roles. Since users are not assigned permissions directly, but only acquire them through roles, management of access rights involves assigning appropriate roles to the user. See Modifying the Roles of a User.

10811081

Permission types and role types


There are two categories of permissions:

  • Tenant permissions - Define a user's access to resources at the tenant level.
  • Folder permissions - Define the user's access and ability within each folder to which they are assigned.

Based on the permissions they include, there are three types of roles:

  • Tenant roles, which include tenant permissions and are required for working at the tenant level.
  • Folder roles, which include permissions for working within a folder.
  • Mixed roles, which include both types of permissions.
    With mixed roles, for a global operation, only the user's tenant permissions are taken into consideration; for a folder-specific operation, if a custom role is defined, folder permissions are applied in favor of any tenant permissions present.

📘

Note:

Mixed roles are no longer supported and you cannot create new ones. If you have mixed roles, we recommend replacing them with a combination of tenant and folder roles to grant the required permissions.

The following resources are available to users, depending on the type of roles they have:

Tenant ResourcesFolder Resources
Alerts
Audit
Background tasks
Libraries
License
Machines
ML Logs
Packages
Robots
Roles
Settings
Folders
Users
Webhooks
Assets
Storage Files
Storage Buckets
Connections
Environments
Execution Media
Folder Packages
Jobs
Logs
Monitoring
Processes
Queues
Triggers
Subfolders
Action Assignment
Action Catalogs
Actions
Test Case Execution Artifacts
Test Data Queue Items
Test Data Queues
Test Set Executions
Test Sets
Test Set Schedules
Transactions

You can disable permissions completely from the user interface and API using the Auth.DisabledPermissions parameter in UiPath.Orchestrator.dll.config.

Assigning the different types of roles

The type of role is important because you assign roles differently based on their type:

  • If Activate Classic Folders is cleared under Tenant > Settings > General:
    You assign Tenant roles and Mixed roles from the Users page or from the Roles page.
    You assign Folder roles and Mixed roles from the Folders page or from the folder's Settings page.
  • If Activate Classic Folders is selected under Tenant > Settings > General:
    You assign any of the three types of roles from the Users page or from the Roles page.
    You assign Folder roles and Mixed roles from the Folders page or from the folder's Settings page.

Permissions without effect

Typically you can select all available rights (View, Edit, Create, or Delete) for any permission, but the following rights have no effect for the listed permission, and therefore you cannot edit them:

Permission typePermissionUnavailable rights
TenantAlerts Delete
Audit Edit
Create
Delete
License only:
Edit
Create
Delete
FolderExecution Media Edit
Logs Edit
Delete
Monitoring Create
Delete
Connections View
Edit
Create
Delete

This is because, for example, it is not possible to edit system-generated logs.

Security considerations


Basic authentication

By default, Orchestrator does not allow user access via basic authentication. This functionality can be enabled by adding and configuring the Auth.RestrictBasicAuthentication setting. This enables you to create local accounts that can access Orchestrator using their basic authentication credentials, allowing you to maintain existing integrations that relied on basic authentication when calling Orchestrator API.

Enabling basic authentication can be done when creating and editing accounts.

Account lockout

By default, after 10 failed login attempts, you are locked out for 5 minutes.

System administrators can customize the Account Lockout settings from the host Management portal.

Logging in with the same account on a different machine disconnects the user from the first machine.

Configuring accounts to run automations


UiPath accounts can be thought of as identities intended to represent human (user accounts) or non-human users (robot accounts) that need to be authorized to access Orchestrator resources. These accounts and their association with roles allows for a certain level of access to resources in Orchestrator.

To enable user accounts and robot accounts to run automations, an administrator must configure the automation capabilities at the account level:

  • Personal automations: Automations that run under a user's identity either locally on the user's machine, or remotely (personal remote automations) on server-side resources to which the user has no direct access to. Learn how to enable users to run personal automation.
  • Unattended automations: Automations that are suited for processes that perform privileged operations, requiring elevated permissions and credentials. For this reason they typically run under robot accounts on remote infrastructure. Learn how to configure robot accounts to run unattended automation.
  • Unattended automations run on behalf of a user via an unattended robot. Automations running on remote infrastructure, on an unattended robot that impersonates a user. An administrator can enable an unattended robot to impersonate a user account, that is act on behalf of that user identity, to allow the robot to run automations with the same privileges as the user it impersonates. Learn how to enable users to run automations on unattended infrastructure via unattended robots.

Disabling concurrent execution

When a credential cannot be used more than once at a time (e.g., SAP), an administrator can restrict an account from simultaneously executing multiple jobs. Enabling the Run only one job at a time option at the account level restricts the account from simultaneously executing multiple jobs.

Updated a day ago


Managing access and automation capabilities


On the Manage Access page you can define and assign roles as well as configure the automation capabilities of your accounts. In Orchestrator, you use roles to control the level of access a user should have.
On this page we go over the notions you need to understand to effectively plan and implement your access control strategy.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.