- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Setup Samples
- Storing Robot Credentials in CyberArk
- Setting up Attended Robots
- Setting up Unattended Robots
- Storing Unattended Robot Passwords in Azure Key Vault (read-only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read-only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- SmartCard Authentication
- Audit
- Resource Catalog Service
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Classic Robots
- Host administration
- Organization administration
- Troubleshooting
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.
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.
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.Domainparameter is filled in with a valid domain. All domains and subdomains from forests 2-way trusted with the domain specified in theWindowsAuth.Domainparameter are available when adding users/groups. - The machine on which Orchestrator is installed is joined to the domain set in the
WindowsAuth.Domainparameter. To check whether the device is joined to the domain, run thedsregcmd /statusfrom 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)andGetRoles(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].
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.
- 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 |
|
|
|
|
|
Folder Level Roles |
|
|
|
|
|
HR tenant |
Administrators | |||
|
Tenant Level Roles |
|
|
| |
|
Folder Level Roles |
|
|
|
|
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.
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.
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.
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:
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.
- 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 |
|---|---|
|
|
UiPath.Orchestrator.dll.config.
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.
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 |
|
|
Audit |
| |
|
Folder |
Execution Media |
|
|
Logs |
| |
|
Monitoring |
|
This is because, for example, it is not possible to edit system-generated logs.
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.
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.
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.
