Managing Access and Automation Capabilities

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 created and managed by organization administrators. Accounts must already exist to be able to assign roles to them.

This page, and the following pages, describe:

• how to manage roles
• how to manage automation capabilities, which are configured as part of role setup.

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)

• created and managed in an external directory (directory accounts and directory groups). See the section AD Integration below for a better understanding of directory integrations.

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.

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:

• a local Active Directory

• Azure Active Directory

  Note: 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.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.

• Group membership for an account is checked by Orchestrator at login, or once every hour during active sessions. If an account's group memberships change, for the account the changes apply the next time the account logs in or, if currently logged in, within one hour.

  This one hour interval for checking group membership can be changed by setting the value of IdentityServer.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

Groups let you manage several users at a time, by applying the same roles and configuration to them through the group.

• The membership of a user is set from Admin > Accounts & 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.

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.

Note:

• 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 Automation Cloud 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/Roles	User Groups	Inherited Roles	Explicit Roles	Overall
Finance tenant	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 tenant	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.

Note: 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 User	Auto-provisioned User
Inherits access rights
Can have explicit access rights
Cloud Portal is the central hub for user information
SSO

Robot

The Robot 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.

Account and Group Icons

On pages where you manage accounts, groups, or roles, specific icons are displayed for each type to help you recognize the type of account or the type of group.

Account icons

- UiPath user account: user account that is linked to a UiPath account and signed in using basic authentication

- SSO user account: user account linked to a UiPath account that signed in using SSO; also applies to user accounts that have both a UiPath user account and a directory account

- Directory user account: the account originates from a directory and signed in with Enterprise SSO

- Robot account

Group icons

- Local group (or plainly, group): the group was created by a host administrator.

- Directory group: the group originates in a linked directory.

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 features are included in roles.

For example, here's a custom role where you can see some of the permissions it includes:

Permission and role types

There are two types of permissions, as follows:

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

Two primary permission sets govern operations within folders:

• Folder permissions (tenant scoped):
  • allow a user to create, edit, or delete all folders within the entire tenant.
  • are typically granted to admins, or users responsible for managing the organization.
• Subfolder permissions (folder scoped):
  • allow a user to create, edit, or delete a particular folder they are assigned to, along with any subfolders under it.
  • offer more granular control, enabling users to manage specific folders without having control over the other folders in the tenant.

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 to work 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 resources	Folder 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, and it also depends if classic folders are enabled:

• If Activate Classic Folders is cleared under Tenant > Settings > General:

  • You assign Tenant roles and Mixed roles from either the Assign roles tab or from the Roles tab of the Tenant > Manage Access 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 either the Assign roles tab or from the Roles tab of the Tenant > Manage Access 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 type	Permission	Unavailable rights
Tenant	Alerts	Delete
	Audit	Edit Create Delete
Folder	Execution Media	Edit
	Logs	Edit Delete
	Monitoring	Create Delete

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

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.

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.

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